What is the next step here? Is it technical or product? I mean do we want to define what that starter recipe is? I believe core already has recipes for what is equivalent of the standard profile, no? So its more about pairing that down and introducing that as the primary means to install Drupal rather than the profiles?
Add HTMX headers as requirement based on https://www.drupal.org/node/3539472 →
I realized we added this at the wrong place and also did not link it into the governance text. Opened #3569830: Standing orders file is not accessible on docs site → to integrate it.
Removing needs tests tag.
Updated issue summary to explain what is in scope and not in scope.
I don!t think it would be about translating it as "Canvas pages" for the UI but more about the question of whether the existing widely used translation of "Pages" is appropriate for this usage or translators translated it assuming it meant something else (a fieldable node type). Since string translation in Drupal is not version dependent if the word was primarily used in a different context, then differentiating from that would be potentially needed. But I do not know if that is the case or not. Even if it is, it may only apply to a couple languages?
I'm not sure "Pages" should have a Canvas context, maybe "Landing pages" or something? Context is supposed to explain logically what it is not as a tech marker. I can see the potential confusion without the context, just not sure "Canvas" is the best context to add.
I created an MR to run the test suite on it with the base URL change :)
This looks surprisingly simple for a start but would help with the main part of what currently looks like bugos behaviour. Is updating that single place for base URL enough for advanced features including media library access, etc? I don't think the UI to specify the language of the page needs to be in this issue as long as the key underlying missing pieces are resolved, that could be a followup.
It was parsed right away. There was probably an intermittent issue. Localize.drupal.org is not that good with retrying when the remote server does not respond. Thanks for flagging.
The release is listed in https://www.drupal.org/files/releases.tsv → , not sure why it was not parsed, it should happen automatically. I set back the parsing timestamp, so it would attempt to look at this again on next cron. Will see if this helps soon.
Posted the announcement at https://www.drupal.org/about/core/blog/announcing-drupal-1200-platform-r... → , moving to needs work to update all the pages following the announcement.
All the arguments point to it being the most logical step to remove it, so signing off as a Drupal core product manager too.
I updated https://www.drupal.org/docs/getting-started/system-requirements/php-requ... → to the PHP version decision since that was not questioned :)
Also removed the third party library related section from the announcement draft. Anything else to do to announce? :)
I agree with the issue summary as it stands now, thanks for the summary.
Update example image. While it is an example, it would be good to be roughly accurate. :)
Re MySQL how do we determine the supported version? Eg. https://www.mysql.com/support/supportedplatforms/database.html says both Ubuntu 22.04 LTS and Ubuntu 24.04 LTS support MySQL 8.0. The Standard EOL of Ubuntu 22.04 LTS is April 2027, while for 24.04 LTS it is May 2029.
Do formatters format usernames as link by default though? Eg on node view or comments?
I think remaining on MySQL 8.0 would be the best unless we really need something from later MySQL versions. I agree that hosts have a much harder time updating databases compared to PHP and other components, so keeping the Drupal 11 requirement would make adopting Drupal 12 much easier.
This was discussed at a meeting of the Core Leadership team at DrupalCon Barcelona 2024. Those present agreed to the removing the search module from core and moving it to contrib. The product managers were not able to attend so tagging for their review.
Responding as a Drupal core product manager. I believe we discussed this on prior Drupal core leadership meetings too and product managers there agreed. I don't believe core search is a fundamental ecosystem module that various contributed modules build on or contributed modules need to integrate with to be consistent. It could easily be a contributed module that people add. In fact that would make it easier to do what @xmacinfo hopes, that it could be enhanced with more flexibility and a more dynamic timeline than core. If there are interested folks that is to maintain it there :) There are various other key modules and tools that are not in core but immensely useful on simple sites too such as pathauto or drush, so I think a feature being historically in core is not by itself an argument to keep it in core.
We are publishing that next week when the release is out :) Until then you can check https://www.drupal.org/list-changes/drupal/published?keywords_descriptio... →
Summar of Slack discussion with info from @catch and @xjm:
- The latest MR suggestion needs review and applying.
- Then it needs a full round of manual testing again.
- If an upgrade path test is also added, that would be best (not an absolute must have).
- Probably also need a follow-up to add tests for the UI step @ericgsmith found.
Note that deferring the upgrade path tests is dependent on manual testing of the upgrade path itself (in addition to the bug fixes), both from 11.2 and from an 11.3 beta with the broken update. See the comment in #159. That goes for subsequent regressions as well as the original one.
The paragraph from remaining tasks, was that already added prior to this issue though?
Sitting with @akmalfikri, discussed this and made him the owner and granted permissions. Did not remove any of @ckng reviewer permissions.
Actually https://localize.drupal.org/translate/languages/ms already says Malay language team, so only need to fix the langcode name.
Indeed, Bahasa Malaysia would be correctly said Bahasa Melayu, but the language code for that is actually zsm and not ms, see https://en.wikipedia.org/wiki/Malaysian_Malay. We have ms which has a wider understanding of Malay. It should just be called Malay. Sitting with @akmalfikri discussing this. I can fix this on localize, but a core issue is needed too.
Thanks all! This was a long time in the making and only received minor updates since the agreement 2 years ago :) So it was about time to land :)
🐛 langcode change leads to new active_version Active was added as a child too :)
Ensuring recipe application is in the site default language would still only be enough for monolingual sites. Multilingual sites could have config in any specific language in active config, so the right translation should be applied to each (and their config translations applied too). So the current approach does not work for multilingual sites, only monolingual sites even if the recipe application language is enforced. Rather IMHO the translation should be ran for each specific config in the config's language.
Updated issue summary with clearer problem statement.
Reviewed the MR changes. The main question I have if there is some way that language matching is ensured? That I don't see in the MR, but I may be missing it? As far as I see translations are pulled from the language used when the recipe is applied, which may or may not match the language of the config that the config action is applied to. I think the translation should be applied to the language of the config, not based on what language is active when the recipe itself is run. Otherwise the config may end up with a jumble of languages.
Also at the time of the recipe being applied, the translatable pieces are known, so the recipe application could/should update (create?) the config translations to also save the appropriate translations of the values as available, not just apply the translation behaviour to the active config IMHO.
I understand an alpha deadline is tomorrow ( https://www.drupal.org/about/core/blog/drupal-113x-alpha-phase-begins-oc... → ) so wondering if we can segment this feedback in a way where the committed version can be built on top later or get a core exception? :) Or it may be that I'm missing this in the MR and it is already there :)
Content templates support works surprisingly well for multilingual, I tried! Found two bugs and a feature request.
- BUG (maybe in CMS?) #3552918: Blog post tags don't appear in Canvas as potential field →
- BUG (in Canvas) 🐛 When rendering translated entities with content templates, entity references get the default language rendered Active
- FEATURE (I designed it!) #3552928: Entity preview selector should have a way to preview in other languages →
gábor hojtsy → changed the visibility of the branch 3534466-integrate-with-search to hidden.
gábor hojtsy → made their first commit to this issue’s fork.
I didn't know xb was also a problem, hm. My assumption was that if we rename the demo repo it will cause problems for people looking for the old name / systems like drupal forge that offer it as a demo. But it may be redirecting based on https://docs.github.com/en/enterprise-cloud@latest/repositories/creating..., so that may be a better / cleaner solution. That said, I don't think I can do the rename, it is @phenaproxima's repo.
Retitled for more general problem we are seeing.
Added the hook to PageHooks.php with the new OOP format instead of procedural. :) Moving to Page component too. And adding as a Drupal CMS release blocker, since picking a metatag media image does not work without this fix in Drupal CMS.
gábor hojtsy → made their first commit to this issue’s fork.
I think for Canvas being consistent with what Drupal does elsewhere on admin pages that look exactly like all the other content admin pages is the best direction. When/if Drupal CMS wants to change that it can :)
This did not only get a manual test, but also automated test, so I think that should be good :)
I also manually reviewed the diff and it looks good to me.
I believe this is the part that is related to the issue:
- behavior_desktop: '5'
- behavior_tablet: scroll
- behavior_mobile: scroll
+ behavior_desktop: '6'
+ behavior_tablet: '6'
+ behavior_mobile: '3'I like the other updates too, which are also very timely: better sample quotes, not linking to example.com, etc. :)
I did not test manually but on patch review it looks good.
Pam pointed out this can be worked around in Byte for now by either removing this section or configuring it to not scroll. So I opened 🐛 Remove "Trusted by world class experts" or remove the scroll setting on it Active which if fixed reduces the criticality of this issue.
gábor hojtsy → created an issue. See original summary → .