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.
phenaproxima → created an issue.
This is not going to happen; site templates are, at this point, unlikely to be install profiles themselves.
Closing as a duplicate of 🐛 Flush all caches once done Active , which was reverted and reopened.
Maddeningly, I had to revert this because it turns out that flushing all caches wipes the session, forcing you to log in after the installation is complete. It's not clear why this happens, and it also seems to be semi-random (affecting 11.1.x but...not 11.2.x? maybe? it's not clear).
drupal_flush_all_caches() is a very aggressive cache wipe so this probably makes sense to revert for now and postpone until there is a CI pipeline with test coverage.
Get a load of that diffstat! 😍😍😍
phenaproxima → created an issue. See original summary → .
All the pieces are now in place, save for a tagged release of Recipe Installer Kit (which is waiting on a bug fix). I think this can be called done.
Merged into 2.x and cherry-picked to 1.2.x.
Manually tested this and confirmed it does what we expect. This does temporarily allow a dev snapshot of Recipe Installer Kit, but that's okay. We only need to require a tag for the 1.2.0 release of Drupal CMS.
Merged into 1.x.
phenaproxima → created an issue.
Postponed on the next release of Recipe Installer Kit.
phenaproxima → created an issue.
Merged into 1.x.
Pretty straightforward; I tested this in Drupal CMS and it worked fine. Merging.
phenaproxima → created an issue.
Merged into 1.x!
Anjali and I manually tested this and confirmed that, apart from a couple of relatively minor bugs, it does what we want it to.
Merged into 2.x and will cherry-pick to 1.2.x, 1.1.x, and 1.0.x.
phenaproxima → created an issue.
Crediting @moshe-weitzman for the upstream fix.
phenaproxima → created an issue. See original summary → .
Some testing with Drupal CMS seems to work as intended.
Merged into 2.x. Opted not to backport this for the reasons explained in #10, and because we still have a few more dominoes to fall before we can properly support multilingual sites at install time.
Worked well for me in manual testing. Pam confirmed that we can commit this to 2.x now, since we won't be releasing 2.0.0 for a while and therefore have plenty of time to get the rest of the multilingual stuff in order. We can discuss later if the absence of install-time multilingual support should block the 2.0 release.
Escalating even further. I guess this can't block a Drupal CMS release, since existing sites updating to Drupal 11.2 will encounter this, but hopefully we can get it solved sooner rather than later.
Transferring credit from 📌 Reintroduce the language selector in the Drupal CMS installer Active .
✨ Bring the installer's language selector back Active has an MR for this, so closing this as a duplicate and transferring credit.
Adding 📌 Create a .tar.gz for drupal.org to consume Active as related. The reason we don't have any proper releases of Drupal CMS on localize.drupal.org, except for the long-dead 1.0.0-rc1, is apparently because (according to @drumm) localize.drupal.org only works with .tar.gz files, and until I committed that issue, we were only shipping zip files.
Beyond that, 📌 Reintroduce the language selector in the Drupal CMS installer Active restores the language selector to the installer (without any plumbing), and ✨ Download translations for the current profile and theme Active (in Recipe Installer Kit) puts some teeth behind it. These three issues, combined, should effectively render it possible to have all strings that are part of the Drupal CMS project template be translatable.
Merged into 2.x and cherry-picked to 1.2.x.
Works as intended (extraction is into a separate drupal-cms directory), so merging. Crediting @drumm for giving me the tar commands.
phenaproxima → created an issue.
phenaproxima → created an issue.
Crediting @anjali-rathod for pioneering this approach in https://git.drupalcode.org/project/drupalcmsmultilingual/-/merge_requests/1 and working through the mad science with me on Slack.
phenaproxima → created an issue.
Created an initial (streamlined) adaptation of this with basically no styling (that can come later). Here's what it looks like, and what it does when you change the selected language.
Crediting @anjali-rathod, who wrote the original merge request I'm basing this on.
phenaproxima → created an issue.
Here's how the blocks look if laid out in a dashboard. By no means is this good, or even particularly usable, but it's a start. This MR at least accomplishes what I want it to.
phenaproxima → created an issue.
Clean!
Merged into 2.x and cherry-picked to 1.2.x.
@tim.plunkett signed off on this with me in Zoom, so in it goes.
Super easy, barely an inconvenience.
phenaproxima → created an issue.
Two things still needed here:
- Sign-off on this approach from @tim.plunkett -- just want it sanity-checked.
- A destination repository. I'm hoping we can host this one on GitHub so that I don't have to cut a new release manually every time we push a tag, but the decision to grant me a GitHub-hosted repo in the
drupalnamespace lies with @drumm and @hestenet.
That looks pretty good to me, and is in line with what I was imagining.
The test failures seem to be unrelated and are likely preexisting in HEAD.
Assigning to @tim.plunkett for review, since I'm pretty sure he will like this clean-up.
phenaproxima → created an issue.
Now that recipes are unpacked in Drupal CMS 2.0
This is also the case in 1.2.0. Just wanted to be clear about that, in case anyone sees this issue and thinks they have to wait until autumn for recipe unpacking.
Merged into 1.2.x. Since doing this for 2.x would be a more involved bunch of work (changing many more constraints), and this is only temporary anyway, not going to cherry-pick it.
phenaproxima → created an issue.
@catch, there is no need to specify a version; Automatic Updates 4.x is only at 4.0.0-alpha2 (and will need to be tagged stable before Drupal core 11.2 is released, since project templates have minimum-stability: stable, and AU 4.x is identical to 3.1.x anyway -- which is stable -- apart from the internal integration with core's Package Manager).
Tests are failing due to a known flaw in Recipe Installer Kit. I don't feel like fighting it right now, certainly not this close to the release of Drupal 11.2 and a certain chance of us blocking early adopters of Drupal CMS from updating core.
I'm merging it.
phenaproxima → created an issue.
phenaproxima → created an issue.
Merged into 2.x, cherry-picked to 1.2.x.
phenaproxima → created an issue.
This seems quite straightforward to me, but it needs a test. RecipeActivatorTest already exists and it should be pretty simple to add a couple of assertions that a config checkpoint was created when a recipe was applied.
I can't easily write a test for this, because although composer/composer is a dev dependency of core, vendor/bin/composer doesn't exist because it's cleaned up by the vendor hardening plugin, which has no way to prevent a package from being cleaned up. This also means that end users can't take advantage of this improvement if they have the vendor hardening plugin at all.
Not sure how to proceed. Should I change our build tests to confirm that this works? Should we file a blocking issue to allow the vendor hardening plugin to skip certain packages if configured to do so?
Been thinking more about this. Now that I have a working patch, I am actually not sure if we want to do this at all, for a few reasons:
- Having proc_open disabled seems to be, to at least some degree, an edge case. We haven't heard this complaint too much. We get far more complaints about Composer and rsync not being auto-detectable, which is something we are trying to ameliorate in other issues.
- We are very clear here that proc_open is by far the best way to run Composer, since it prevents weird behavior and the heightened risk of OOM and timeout errors. We already have documentation in our hook_help that says what to do if proc_open is disabled.
- If you have proc_open disabled, not only can you not use Composer; you can't use rsync either, and rsync is still required, in almost all cases, for Package Manager to work. It doesn't make any sense to allow a fallback method of executing Composer without having something similar for rsync -- but that brings us back to the "PHP file syncer" days, when Composer Stager tried to reimplement the relevant parts of rsync in PHP, and we ended up throwing out all that work (and it was a shit ton of work). Even if we ended up using a file syncer that was not rsync (like xcopy, for example), it'd still need proc_open.
- This would be yet another example of the "having more than one way to do things" syndrome that core has historically suffered from. Maybe we don't want that.
- The implementation (using a test harness as an execution driver) is clever, and we could rely on it, but it is kind of...sideways. I doubt Symfony would be expecting anyone to use their test harness for this purpose, so we are at slightly higher risk of breaking changes in Symfony Console.
- I didn't spend too much time on this, and I am okay throwing out my work here if it doesn't, ultimately, make strategic and technical sense overall.
I therefore leave this one up to @catch and other framework managers. Is there really a benefit to implementing this, or is it really a poison pill in disguise?
Looks like the controller class is still there, but I'm not sure it's needed anymore...?
Reviewable, but not ready quite yet since tests are needed.
phenaproxima → created an issue.
phenaproxima → created an issue.
The failing kernel tests now pass.
phenaproxima → created an issue.
It's not that we want to remove the line, we want to remove the link. We should remove the link because the link cannot be generated unless you have the ID of an enabled source plugin. You can compute that dynamically, but it's sort of pointless to do in the context of the Help page.
Committers, please backport this to 11.2.x. It is a show-stopping bug for the new direct-write mode, and is an internal change in an experimental module that does not affect the data layer in any way.
phenaproxima → created an issue.
That seems extremely shippable, and definitely blocks a 2.1.0 release since that's the one with Drupal 11.2 compatibility.
This is a duplicate of 🐛 RecipeActivator needs to handle unpacked recipes that aren't Composer-managed Active , which is a bit further along and more robust.