Recipe Installer Kit deals with this by wrapping the messenger service with an implementation of MessengerInterface that can store a list of (untranslated) messages to ignore. Profiles built on Recipe Installer Kit can list those messages in their info file.
https://git.drupalcode.org/project/recipe_installer_kit/-/blob/1.x/src/H...
Maybe a similar approach for core?
phenaproxima → created an issue.
Merged into 2.x and cherry-picked to 1.2.x. Thanks!
The command will be:
ddev composer drupal:recipe-unpack
We should have it before ddev launch.
We could do that but I think we'll just end up with the same bug next year. :-\
That won't work for a recipe, unfortunately, since recipes can't contain any code (nor can they affect imported content dynamically).
composer remove such-and-such. There's no UI for pruning Composer dependencies, although surely one could be created with Package Manager as its base.
Were you successful? Or did you continue to get the error you described in #25?
Since we have now released a few versions of Drupal CMS, I think it's become clear that patching dependencies is okay only during development, and the patches cannot be in tagged releases of Drupal CMS.
My feeling is that we should allow patching all the way through beta periods (I think we're probably only likely to bother with betas for major releases of Drupal CMS), but all patches must be removed by the RC phase. Any dependencies which have not committed and released needed patches are removed from Drupal CMS.
Do we still need this? Drupal CMS 1.2.0 uses recipe unpacking by default, so site owners are free to prune unnecessary dependencies as desired. I think that pretty much obviates this issue...?
Drupal 11.2 came out last week and Drupal CMS is confirmed to work properly with it. :)
Another quick-win approach here would be to adjust the default content to reference some future event (DrupalCon Chicago?), and ensure we have test coverage that the view has something on it.
@chike:
Could you provide me a sample composer command to do this?
Try just composer update --with-all-dependencies. Let it update everything, not just core. If you feel that's too risky, you can allow it to also update Gin, Project Browser, and Automatic Updates -- all of which broke compatibility with Drupal 11.1 and earlier:
composer update "drupal/core*" drupal/automatic_updates drupal/gin drupal/project_browser --with-all-dependencies
I also strongly recommend you set up recipe unpacking, if you haven't already, before you do this -- just to take the recipes out of the dependency solving equation. Doing that is documented in the Drupal CMS release notes → (see "How to update an existing project to Drupal 11.2").
Wrote the CR.
nicxvan → credited phenaproxima → .
I don't yet understand why merely retrieving definitions is sufficient (and nor did @larowlan) — see MR comment for details. Can you articulate why?
Retrieving definitions will regenerate all the component entities if needed (as you know), but you're right that this is setting up a bug if the cache is not empty. So I added an explicit cache clear.
This must be generalized to not hardcode assumptions for the 2 plugin-powered ComponentSources we have today (block + sdc).
I changed the subscriber to a service collector for CachedDiscoveryInterface. That still ties it to plugins...for now. But using a service collector gives us some more leeway later, if we add a new interface for component discovery. That will make it easier to refactor. I didn't do it as you suggested in [#16120596-7] because that makes the dependency injection trickier/impossible. Besides, service collection is a well-used pattern in core.
there's some CI fails we likely need to address
Looks like the only one outstanding is in component-operations.cy.js, with the same damn failure that seems to inexplicably haunt every goddamned MR I submit to Experience Builder. :) I don't see how the changes here could be affecting that, since the recipe event subscriber only does anything if a recipe is applied. I'm not really sure how to approach fixing it, since I'm not sure the cause of it was ever discovered the previous times I encountered it.
phenaproxima → created an issue.
Why would this be a core bug?
XB is the thing that is decorating these plugin managers, and it targets them incorrectly. AFAICT, core isn't doing anything wrong here, apart from having more than one way to refer to these services, with the "canonical" way being the old names.
Right you are, that's a great point.
Merged into 1.2.x and cherry-picked to 2.x, for a change.
Merged into 2.x.
Pam approved this in Slack.
phenaproxima → created an issue.
phenaproxima → created an issue.
Per @larowlan, restored missing dependencies to kernel tests which were (mistakenly) passing without them, obscured by this decoration bug.
Merged into 2.x and cherry-picked to 1.2.x.
phenaproxima → created an issue.
Gin 5 has been released so this can proceed.
Whew. That was quite a slog, but with much help, we made it. Obviously the template is not usable in the wild, but at least we've got something we can iterate on! Merged into 2.x.
XB follow-ups needed here, which will allow us to remove nearly all the patches I'm adding here:
- Fix XB's broken service decoration (already exists)
- Subscribe to recipe events to ensure that you have all component entities properly generated for you once the recipe is applied, and before content is imported
- Call processDefaultValue() on field items when generating component entities, since that is necessary to actually be conformant with field schema
Discussed this with @larowlan a bit more and I think we have our solution.
First of all, having the recipe ship the Component config entities is, we agreed, the worst of all possible worlds. It's basically having to maintain the components in two places (Mercury, and the recipe). The coupling is a nightmare. Mediacurrent also feels that this is very much the wrong path.
So the fix probably lies in Experience Builder supporting recipes in some way. Lee suggested a config action that creates the components. That would work, but would be awkward because config actions generally need to target some existing config object. So I had an idea that we both liked better - how about if Experience Builder subscribes to the DefaultContent system's PreImportEvent, and unconditionally creates the components before importing content? That should vault us past this hurdle.
I think we may still want to have a config action as well, to ensure that specific components are created when needed, but that can be a separate feature request in XB and would not be a blocker to building this site template.
It might have just been the hook being wrong. It's hook_themes_installed, not hook_themes_install.
Clarifying that this is a workaround that could theoretically be backported to 11.2.x, not a full fix.
Adding ✨ Add proper validation constraints to the `value` property of date fields Active as related, since would represent the full, robust bug fix rather than the temporary kludge I'm proposing here.
phenaproxima → created an issue.
phenaproxima → created an issue.
Discovered that this bug also exists for the block plugin manager. Let's fix that too.
Dead simple fix with a well-targeted test.
phenaproxima → created an issue.
Merged into 2.x and cherry-picked to 1.2.x. Thanks!
The test failure is legit, unfortunately. This probably needs some level of manual testing to be sure no broken blocks are showing up in the navigation.
phenaproxima → created an issue.
Merged into 2.x and ported to 1.2.x. Thanks!
Back to shippable.
Merged into 2.x and cherry-picked to 1.2.x. Thanks!
Marcus told me in Slack that the modules have stable 1.1.0 releases, so let's revert the changes to the project template.
That seems like a reasonable approach to me.
My only question: is there anything that existing Drupal CMS sites need to do in order to adjust? If so, we'll need a change record.
Straightforward.
MR looks good; I will merge this into 2.x and 1.2.x, with the caveat that Drupal CMS 1.2.0 will be blocked on having stable releases of these modules.
Could you tag stable, not alpha? An alpha won’t allow users of Drupal CMS with existing projects to update. :-/
Merged into 2.x and cherry-picked to 1.2.x.
phenaproxima → created an issue.
Composer changes look legit; confirmed that the phpcs.xml.dist in 11.2.x appears to match the changes made here.
This was fixed in Drupal CMS 1.2.x and later, but not backported to 1.1.x. That happened in 📌 Unable to upgrade to field_group 4.0 Active .
I checked with @thejimbirch and he feels it should be okay to backport to 1.1.x if you really need it. Alternately, we should be releasing Drupal CMS 1.2.0 within a week -- is this super urgent, or can it wait until we release that version (which does allow Field Group 4)? :)
phenaproxima → created an issue.
Nobody has objected here, and I put this in front of @catch and didn't hear anything. Everyone seems to agree that ~ is too restrictive at scale, and can cause update issues. I think I'm comfortable with this as policy.
I'm happy to pull this out of postponement. We'd need to do additional refactoring to move the dashboard into another module (maybe drupal_cms_admin_ui, so that drupal_cms_accessibility_tools could depend on it) but that could all happen in this issue's scope. For now, implement it in whatever way gets it looking and working how you want. I can assist with the refactoring.
phenaproxima → created an issue.
A few points.
Merged into 2.x and cherry-picked to 1.2.x. Thanks!
No objections here.
Merged into 2.x and ported to 1.2.x.
Merged into 4.x, thanks!
phenaproxima → created an issue.