🇨🇦Canada @b_sharpe

Oooook, rebased, changed and back to review :)

Added MR. Needs tests.

b_sharpe → changed the visibility of the branch 3315694-cache-could-be to hidden.

b_sharpe → changed the visibility of the branch 3315694-cache-broken-after-install to hidden.

I found the root cause of this here, in which the RecipeCommand's Kernel was set to not allow writing to the container.

-    $kernel = new DrupalKernel('prod', $this->classLoader, FALSE);
+    $kernel = new DrupalKernel('prod', $this->classLoader);

This causes discovery, bootstrap, and container caches to not update from the recipe which is why plugin and entity discovery acts up as well as some routes.

What I'm not sure of is WHY this was specifically set to FALSE as the default for the function is TRUE so I have to assume this was an intentional change at this point, so am holding off on the MR until I can confirm with original committers.

@phenaproxima, I had already added this here: https://git.drupalcode.org/project/drupal/-/merge_requests/8451/diffs#b4... is there somewhere else this is expected?

    $this->expectDeprecation('Unsilenced deprecation: The plugin ID "entity_create:ensure_exists" is deprecated. Use "entity_create:ensureExists" instead.');

Also, I've been informed by @thejimbirch that this method is changing to `createIfNotExists` which likely means this issue needs an entire rework. I will check and see what expected order of operations will be here.

I can replicate the issue with the given "pathauto" recipe above, but what I find interesting is that I can run: ./vendor/bin/drush php:eval "\Drupal::service('module_installer')->install(['pathauto']);" in the exact same state as before the recipe and I do not see the issue.

This leads me to believe something else is at play here since the Recipe is using that same method to install the module. I don't think just killing all cache when applying a recipe is the answer rather than tracking down the cause of this issue.

b_sharpe → changed the visibility of the branch 11.x to hidden.

b_sharpe → made their first commit to this issue’s fork.

Possibly needs relation to reverting?

It appears there were tests around this already. Updated and added stable9 template as was expected as well.

Done. I did not create templates for themes like Claro/Olivero here as I believe those are opinionated and should be their own issues. I also didn't create tests here as no messaging has changed.

What might be needed is a change record, as pages previously utilizing the maintenance page for this will now get a different template. Marking for review for now.

Makes sense and code looks good, thanks!

b_sharpe → made their first commit to this issue’s fork.

Jeez, 11.x instead of 11.0.x...

b_sharpe → changed the visibility of the branch 3455113-recipe-plugins-ids to hidden.

b_sharpe → changed the visibility of the branch 11.x to hidden.

Test bot failed cause I pushed while running :S

So it appears the change record → I was looking at is actually not yet committed. So instead, I've moved this to triggering a deprecation notice upon instance creation of the old names. Added a test for this as well.

Relating to ✨ Rename ensure_exists to createIfNotExists, and camel-case simpleConfigUpdate for consistency RTBC

Fixed up 10.4 backport, passing phpcs now.

b_sharpe → made their first commit to this issue’s fork.

Needs review, its passing tests, but not entirely sure about the deprecation/backward compat implementation.

Thanks @thejimbirch, that was my findings as well. How should changes like this be handled to communicate to the documentation there? Is there a way to link the two?

b_sharpe → created an issue.

Code looks good, Tested locally and confirmed both recipes are independently composable. RTBC

@m-p-j You can see the source here: https://git.drupalcode.org/project/ckeditor_bs_grid/-/tree/2.0.x/js/cked...

You can build this code on your machine with yarn, from the module root, run yarn install to get all the dependencies, and then yarn run build to compile. It's using the webpack config in that same folder, so you can do whatever you like there to debug.

I believe on points 2 and 3 it should note that this means you are overriding the default module installation and point out the possibility of unwanted affects

Thank you

b_sharpe → made their first commit to this issue’s fork.

Maybe related to 🐛 Cannot have div tags inside columns in CKEditor 5 Needs work ?

MR should do the trick! Added default option, and hides dropdown when only 1 option exists. Existing builds will remain unaffected.

b_sharpe → created an issue.

b_sharpe → created an issue.

Given this is a debug-specific change, I don't think a change record here is necessary; however, updating any docs referring to debugging headers is definitely a good idea.

b_sharpe → created an issue.

@tunic this was previously run, but I guess retriggered on rebase. For access I think you just need to request access to the fork and then sign in to gitlab.

Either way, here's the pass on main, and fail on test-only run: https://git.drupalcode.org/issue/drupal-2844620/-/pipelines/148275

Some minor nits

b_sharpe → created an issue.

b_sharpe → created an issue.

Thanks for the callout, https://www.drupal.org/project/lazy_views/releases/1.0.1 →

Considering this is still an issue in D11, I figured we should move it forward. Added tests and new MR for 11.x, back to review

b_sharpe → made their first commit to this issue’s fork.

Committed, note that this module is no longer support nor maintained. Feel free to put in a request for maintainership.

Was dealing with the same but needed it for mutliple drush tasks for other modules as well, this might help: https://www.drupal.org/project/drush_firewall →

b_sharpe → created an issue.

b_sharpe → made their first commit to this issue’s fork.

Good finds, thank you!

b_sharpe → made their first commit to this issue’s fork.

Good catch, thank you

b_sharpe → made their first commit to this issue’s fork.

back to review, forgot patch

Thanks, as a heads up, its usually bad practice to be building/committing these packages to publicly accessible places as they are strictly used in development of the module, never in application.

Anyhow, I've updated the patch to not just update the lock, but require the same versions as core and remove raw-loader per core issue #3319917: Remove raw-loader dependency → .

I'd be in favor of using the "Most popular" set, and then anyone with other needs could use library overrides.

I just ran a fresh D10.2 and can't reproduce this, are you using the email field or the Text Filter (CKEdtior)?

This was covered in the release notes here: https://www.drupal.org/project/obfuscate_email/releases/2.1.0 → as well as hook for uninstall was covered in #3314887: rot13 sub-module makes no sense, please unify with main module →

I'll add to the project pages as well.

Added the ability to define to/from with click/hover/scrolltrigger. Anything above and beyond this likely would be custom code anyhow.

Makes sense, Thank you!

b_sharpe → made their first commit to this issue’s fork.

I see no reason why #2 can't work.

The restriction is definitely around field output + rendered entity; however, using either the style plugin (i.e. unformatted/grid/table) and/or twig + js could likely get you to a Calendar display. Things like tables obviously aren't great since field output is always one column, but for a calendar you likely could extract from each entity what you need (i.e. date/time) in template/preprocess.

Closing as 2.1.x is now active branch. Will create new issues for extension options.

There was conflicting code from the module and composer.json files. I've rebased and resolved.

Thanks

b_sharpe → made their first commit to this issue’s fork.

b_sharpe → created an issue.

This need to be passing the interface FileUrlGeneratorInterface otherwise you'll have issues with other file generators.

Just adding a 10.1 patch for composer.

The MR contains code unrelated to this task

b_sharpe → created an issue.

Added MR and patch for composer addition. Back to review.

I'm not sure timestamp makes sense here? Wouldn't all values be essentially unique causing just a larger index with no real gain?

Though I believe this makes sense, it would not be a backwards compatible change. We'd either need to have an update to fix existing views with now broken handlers, or have a major release version here with docs. I'd lean towards the former.

This could cause further issue if it's not defined. Here is an updated version.

I see no problem with that approach

@jjancel that was fixed in 🐛 Div not allowed by default. Fixed which currently is only on dev. I'm merging this as its none destructive and will create a new release

Adding patch for composer.

Thank you

b_sharpe → made their first commit to this issue’s fork.

Removed and updated project page as well as 📌 Update README about Web Push Active

b_sharpe → created an issue.

It looks like this is a result of 📌 Automated Drupal 10 compatibility fixes Fixed in which webpush isn't d10 ready, the patch isn't going to work as it still is missing. Instead of applying patches here, I think for now the best bet is to remove this dependency as it's only needed for notification_system_dispatch_webpush module in which case a user can work out a solution there.

b_sharpe → created an issue.

I can't reproduce, but logically it makes sense to check if null, so see the Merge Request. Marking as needs review.

b_sharpe → changed the visibility of the branch 2.0.x to hidden.