I'm unable to reproduce the mismatch (except uuid, id, field_name, label) on my end using the reproduce steps. Isn't there a difference switching to 8.x-2.x instead of checking out commit d444b603d8 in step 3? the viewsreference_update_8104 hook doesn't exist in 8.x-2.x branch.
Hi all,
Pulled in #22 and the changes look OK on my end :^) CI is passing + I've done some manual testing of the hook with things such as per request nonces in the CSP and blocking based on the CSRF Origin header.
hi @scott_euser, I've updated the IS with the reproducible steps. config_inspector module was used to produce the failed validation error.
Not exactly the same issue as yours @DamienMckenna but I also get the error when I try to batch process just a single queue that has cron disabled, as I was testing a use case where I wanted to manually batch process the queue.
As $form['cron'] is a table it's also being validated against Table::validateTable() and failing due to 'Cron time' not being set:
thanks @abhishek_gupta1, those changes look OK. As for the CI failing it looks like some unit tests are failing, none of which are an affect of this change. So I'd say there outside the context of this issue.
I can confirm #26 also works, note that there's 2 tests failing however. Not sure on their relevance to this issue.
awesome :^) I've created an issue fork & MR, thanks @renatog
Thanks @renatog,
I'm not too sure i'm following. The maximization feature is op-in and disabled by default, in ModalForm.php:
+ $enableMaximizeButton = FALSE;
+
+ if (!empty($modal->getEnableMaximizeButton())) {
+ $enableMaximizeButton = $modal->getEnableMaximizeButton();
+ }
Pre-existing/new modals will need to check 'Enable Maximize Button' and then save the edit modal form in order to have the button display in their modal.
I think the enable_modal_header dependency is sensible as it follows the same pattern as other buttons (close button) placed in the header region.
Hi, thought i'd give this a try. Please see attached patch + screenshots
+1 to this, FWIW there's some inconsistency in the path definitions between different modules as well, for example the ckeditor_iframe uses libraries/iframe/...
Thanks @mfb. Yeah, anyone using the module should have it set to '' if they've saved config (with/without setting style-src). AFAIK the only edge case is a fresh install and then interacting with the config via code.
Created an
issue
🐛
style-src key missing in seckit.settings.yml
Fixed
for adding the CSP setting style-src to seckit.settings.yml
Attached patch to add style-src to the config install file
@mfb Thanks for reviewing.
Opening a separate issue for adding the style-src key in config install sounds good.
The way I wrote it will indeed flush the caches twice. I've removed the hook_update_N() in favour of an empty hook_post_update_NAME().
Wouldn't want to creep in more coding standards issues so I've looked at the ones in the modified files.
Ah, wasn't using the same pattern for the report path seen in the other tests. Updated patch.
Hi @jweowu & @mfb, I've attached a patch which attempts to replicate (D9 style) how the D7 version of seckit alters options via hook as mentioned in
#12
✨
Provide hook_seckit_options_alter() D8
Needs review
. Some of the patterns in the D7 still seem to make sense currently so some logic is replicated. An initial test is included, but could be expanded on.
Since we're dealing with the configuration system and we don't want overrides appearing in the config form, getSeckitConfig() interacts with ImmutableConfig, and caches the overrides as advised since it runs more than once during the request cycle.
Including the "Needs manual testing" tag :^)
Oops, missed updating comment.
It looks like 5.0.x-dev is running on PHP 5.3 & MySQL 5.5, should these be bumped up to PHP 8.1 & MySQL 5.7?
Unsure what that second failing test is caused by, hopefully fixing the first one resolves it.
hi @danflanagan8,
Thanks for the summary, that'll also help bring newcomers up to speed.
I agree, the issue defined in the IS is not being able to manage the Messages block in LB. It isn't obvious to me whether or not #2 is within the scope of the IS.
I'm for deferring #2 with a follow up, more eyes on this would be good.
In my opinion, Approach A is probably more usable, but Approach B gives a more-realistic content preview, which is one of the goals of LB. So I don't know which way to go!
It does give a more realistic content preview, but you can argue that a realistic preview isn't needed for the Messages block in LB, AFAIK every other preview in LB is using placeholder content.
I don't think it's quite a bug that the placeholder text appears even when the content preview box is unchecked, but that's different from how the "Links" field behaves, for example.
I don't think so either, the olivero theme is responsible for that behaviour. The theme wraps a blocks {{ content }} in a div with the block__content class. When "Show content preview" is unchecked it's display is set to none.