Removed.
I agree that not having anything in update module that is called update manager would be best, but there is some effort vs benefit review needed here :) The service name in the global namespace is indeed highly confusing once there is another module called update manager in core.
I understand the update.manager service sound like a problem as it exists in the global namespace, but do the classes under update module really pose that much of a problem?
How would that be a blocker?
Update from the core community account "The Drop is Always Moving" that I shared data about 3 months ago above too. This was never on Meta platforms. I did not post the latest UX Manager news this week to Twitter already. Posted this just now there and updated the bio too to reflect it.
Cristina landed as UX Manager in 📌 Add Emma Horrell as UX Manager to Drupal core Active now.
Merged, thanks all!
Opened 📌 Make coffee module work in Experience Builder Active for coffee.
gábor hojtsy → created an issue.
Let's be explicit if we agree on Dec 16 :) No link to estimates needed. Updated proposed text.
Thanks for looking into this! Tested the MR. The webform block I created is almost validatable now :) The provider and webform block ID seems to have errors still in config inspector:
I don't know if this block has all the keys that webform blocks have all the time, but if it does, then solving these two would solve it for all webform blocks :)
I also looked at the component list in XB and it still says that it is not validateable indeed.
@catch: re the metatag, I did not mean to imply that the current solution is the final one. The XB page type is not for demos, it is the main thing that XB is built against and can manage the list of XB pages (titles, paths, etc) inside XB in the top bar. XB is being adapted to nodes too with field matching to props for sure. I meant that the metatag field on entities could get very unwieldy so there needs to be some kind of UX definition of what should be exposed in XB of metatags.
Updated the note on event type to be clearer about being removed not meaning that the feature will entirely go away (dependent on site templates, eg. it could be an addon still).
Re sitemap, that was moved to not applying inside XB, while that is true, is it confirmed that XB pages show up fine in sitemaps? I think if that is not the case, we should keep it and solve it. :)
The current usability maintainers are as follows (from MAINTAINERS.txt):
Usability
- Cristina Chumillas 'ckrina' https://www.drupal.org/u/ckrina
- Roy Scholten 'yoroy' https://www.drupal.org/u/yoroy
- Bojhan Somers 'Bojhan' https://www.drupal.org/u/bojhan
Roy and especially Bojhan have not been active in years. It would be true to reality I think to remove them anyway, which leaves Cristina. At that point, we don't have dedicated Usability maintainers other than the UX manager which Cristina is being assigned to already.
Added reference to xb transform docs thanks @penyaskito.
@penyaskito tricked XB to allowing the block with the following:
block.settings.webform_block:
type: block_settings
label: 'Webforms block'
constraints:
FullyValidatable: ~Which is how the block config showed up in XB and the YAML default values storage appeared. Also adding to issue summary.
Added 📌 Add xb transform to webform block storage so that it works with Experience Builder Active for that, so we can keep scope there.
gábor hojtsy → created an issue. See original summary → .
Added webform issue that I just opened :) Also result of discussion about token with @berdir.
Added steps to reproduce with screenshot from config inspector and guidance on where to find compatibility checking in XB.
gábor hojtsy → created an issue.
@catch: for metatag there is also the question I think of what should be expose din XB of the metatag fields. XB seems to have a hardcoded meta image and description field that is not provided by metatag currently.
Identified more modules that do not apply inside XB.
Opened 📌 Make Umami a testing profile (not shown to users) in preparation of moving to contrib Active and posted a one line MR there.
gábor hojtsy → created an issue.
Looks good, reflects discussions in the committer team. Changed title to reflect this.
I think local translation tools use the reference location value to help translators find where the string came from which is useful especially if the string was ambiguous. This:
#: lib/error.c:116
msgid "Unknown system error"
msgstr "Error desconegut del sistema"But the "generated from files" list is a Drupalism and I don't think there is any need to keep that.
Closed @catch's 🌱 Figure out role of Umami in relation to Drupal CMS Active as duplicate.
Sorry for opening 📌 Deprecate and remove the Umami demonstration profile from core, make it a contributed site template Active later, I did not realize you had this one. I think mine may be a duplicate, and even though it was later, it also has more followers / activity now. So what about closing this one as duplicate?
Added more of the pathauto related issue :)
Is this at a state where it can be tried with Pathauto and other entity form extending modules? :) Or can you signal when it is? :)
Marking ready based on the internal core team discussion, some of which is reflected above :)
Marked some of the items that do not apply. Also added 📌 Confirm Semi-coupled form elements can work with State API visibility Active for pathauto which I've been told has the potential to make the pathauto widget work.
📌 Add 'supported' flag to branches to use to direct users and bots Active added a UI and canonical links to older versions :) So I think that implemented the main things suggested here :) It is planned to be rolled out later this week.
📌 Add 'supported' flag to branches to use to direct users and bots Active that is already committed and will be deployed later this week help a lot with this IMHO, although not directly implementing this per say.
This was at the end implemented as part of 📌 Add 'supported' flag to branches to use to direct users and bots Active .
Ok now this may be the complete version? :)
A. Now displays on all the pages because I made the alternate rendering run even if there were no alternates (will return an empty dataset then for alternates but the canonical/message computation can still run for that as needed).
B Made the messages more friendly like Symfony, eg. adding project name and version number.
C. Added canonical setting for alternate rendering but only if we specifically know which is the alternate version, not in the general situation.
Now displays these 3 types of messages:
1. When there was no specific alternate version (note the words are slightly different from the other two). There is no canonical link added in this case to the HEAD.
2. When there was an up to date version but the currently viewed version is still supported. There is a canonical link added in this case to HEAD.
3. When there was an up to date version and the currently viewed version is not supported anymore. There is also a canonical link added in this case to HEAD.
Added messages to alternate handling too. Still need to be cleaned up and figure out how to do canonical propagation to render array from here.
Video of current MR state :) Still does not work on standalone pages, because there is no classic version nav there.
Started adding implementation for the sake of discussion. Looks like the implementation would be slightly different based on which page template it is on. Let's agree on a general direction on some questions:
- Should we have a reassuring message when reading current doc? That may be useful, maybe superflous?
- Should we have the logic for displaying messages in twig or in the formatter?
- Is this kind of approach to do a per page type level direction is good or is there a good way to abstract this? (There will be lots of copies of this message otherwise, maybe it should be part of the navigation method/logic, which is added on all pages?).
- Is this markup what we want to use to wrap this message? Would this show fine on api.drupal.org (it looks quite bad on Olivero, but it should pop on api.drupal.org :D).
For comparison this is the visual treatment that Symfony uses inform users:
Hm PHPUnit fail seems to be on this second line, which is odd since there is a lot of things passed earlier:
$this->drupalGet('api/' . $this->branchInfo['project'] . '/duplicates.php/function/duplicate_function');
$this->assertLinkUrl('foo_function', 'http://example.com/function/foo_function', 'foo_function is linked', 'foo_function link goes to right place');
That said, it also triggers this deprecation:
1) /builds/issue/api-3524717/web/core/lib/Drupal/Core/Test/HttpClientMiddleware/TestHttpClientMiddleware.php:52
Renderer::renderPlain() is deprecated in drupal:10.3.0 and is removed from drupal:12.0.0. Instead, you should use ::renderInIsolation(). See https://www.drupal.org/node/3407994
Since the update function and UI all worked in my manual testing, this should be needs review :)
Ugh, wrong screenshot :D Here is the correct one.
This is how it looks like (with Gin) on the backend. The update function worked in my manual testing. The checkbox also worked, it saved properly both checked and unchecked.
gábor hojtsy → created an issue.
I agree that there would be two things to do here:
1. As suggested in #4, add a link rel=canonical when "same name in other versions" is known, and link that to the current version.
2. As suggested in #6, when viewing outdated documentation add a banner like "You are viewing outdated documentation, for the index of the most current documentation, go to X".
3. A special case of #6 I think is when a "same name in other versions" is known, we can specifically list to that page for the current version instead of generally to the index of the other version.
I'm trying to find docs on how to set up a local API test site, but only found it for Drupal 7 so far.
gábor hojtsy → created an issue.
gábor hojtsy → created an issue. See original summary → .
https://daringfireball.net/projects/markdown/syntax#html does allow for inline HTML to add anchors for example. Also https://www.mkdocs.org/user-guide/writing-your-docs/ says
Linking from raw HTML
Markdown allows document authors to fall back to raw HTML when the Markdown syntax does not meets the author's needs. MkDocs does not limit Markdown in this regard. However, as all raw HTML is ignored by the Markdown parser, MkDocs is not able to validate or convert links contained in raw HTML. When including internal links within raw HTML, you will need to manually format the link appropriately for the rendered document.
So I think we can keep our explicit IDs by using HTML?
Hm, it is unfortunate if we need to use the title, if we change a title, the link will break. I believe the github markdown supports anchors. Is there no such support on mkdocs? https://squidfunk.github.io/mkdocs-material/reference/
Reviewing as core product manager.
I really like this feature, it would have saved me when editing big tag vocabularies. I also applaud the attention to accessibility details too.
That said, I agree with @rkoller that there is not really an existing pattern of how the visual of the matched items should look like and the green background and arrow is a one-off made up for this issue. It would be great if the designers involved with Claro could chime in and provide a Claro-compatible solution. Even better if there is a Claro + Gin fit since core plans to add Gin sooner or later to replace Claro. The same can be said about the message of why dragging was disabled which IMHO has an odd placement (it does not appear anywhere near you would expect the dragging to happen).
I think with more UI polish this would be great.
Should this also do this issue in 11.3 or in Drupal 12? I don't know what other contribs may depend on the install profile selector (ie. they would come with multiple install profile selector).
Add tagify.
gábor hojtsy → created an issue.
I think the theme + layouts update to XB should be done later assuming we can lift and shift Umami to contrib in a working way :) Especially if the recipe conversion works. I don't think we need to build it necessarily to have reusable components outside of it. But food blog is not a site template currently being built for Vienna, so it could be a great contrib one. It could be one of the first if not the first contrib template since we already have the site itself figured out all with images and sample content :) It would be unfortunate to not to rescue it in the tumult around Drupal CMS and site templates :)
It would be really great if the work is not lost here but can be applied to the contrib copy of Umami following 📌 Deprecate and remove the Umami demonstration profile from core, make it a contributed site template Active , would that still be possible? It would be sad to need to restart this and Umami as a contrib site template would need it to be based on recipes.
https://www.drupal.org/project/upgrade_status/releases?version=7.x → -- I don't believe it is possible to list them anymore on the project page. I updated the project page text to link to that release listing.
Good point, I think the default site templates planned for Drupal CMS 2.0 would serve the same purpose in an updated way with Experience builder, etc. So at that point Umami is superseded already. Yeah. This would probably mean removing the install profile selection in 11.3 (2025 december) and deprecate Umami in core 📌 Deprecate and remove the Umami demonstration profile from core, make it a contributed site template Active at the same time?
I think Drupal CMS 2.0 will change from the recipe picker to a site template picker with the built-in site templates as options. So I would not yet go towards what CMS 1.0 does :) In a way the site templates are more similar to the install profiles (in concept, not in technology!) than recipes were :) I don't think site templates will be install profiles at all though, so I think the install profile selector will not come back in CMS for sure.
I opened 📌 Deprecate and remove the Umami demonstration profile from core, make it a contributed site template Active to free Umami from core and revitalise it in contrib as a contrib site template showcase :)
gábor hojtsy → created an issue.
I like this version best :) Will post in Slack to get more feedback :)
input:
recipient:
data_type: email
# Plain list, faster to write, but not that clear
description: !translate ['The email address that should receive submissions from the feedback', 'First context']Discussed the relationship of this role to Usability topic maintainers briefly on Slack. We decided to defer that to a followup. See 📌 Define relationship of UX Manager and Usability topic maintainers RTBC . Crediting folks from that thread that provided feedback on this issue there.
gábor hojtsy → created an issue.
@bbrala points out we have code on our own side to filter project release compatibility, so we don't need d.o changes for this, we can do it ourselves :)
See https://git.drupalcode.org/project/project_analysis/-/blob/master-d11/.g...
Hm, https://git.drupalcode.org/project/project_analysis/-/blob/master-d11/.g... is where we filter the project list, so I don't think we need to have the d.o side filter that. Thanks @bbrala for raising that :)
Checkmark is misleading actually, remove that. Those issues are not done.
Found 📌 Update to Rector 2.0 Active , that already exists. Added.
This is also needed for 📌 Start running against "Drupal 12" to help prioritise tooling efforts Active according to @bbrala, so parenting to that.
Opened 📌 Create TSV that lists Drupal 11 compatible projects Active .
gábor hojtsy → created an issue.
gábor hojtsy → created an issue.
gábor hojtsy → created an issue.
Both https://squidfunk.github.io/mkdocs-material/reference/lists/#using-order... and https://www.markdownguide.org/basic-syntax/ and https://docs.gitlab.com/user/markdown/#task-lists document lists as 1. not 1) so I think its safe to assume 1. will work fine in all environments.
@cmlara posted this on slack:
- Python markdown vs GLFM.
- Python is generally a stricter adherent to the original markdown specs
- https://squidfunk.github.io/mkdocs-material/reference/lists/#using-order...
gábor hojtsy → made their first commit to this issue’s fork.
gábor hojtsy → created an issue.
Before image (note checkbox column width too and border inconsistencies in color and width)
After image (note fixed column width and lack of inconsistent and distracting border). Background color is still there on hover as screenshot.
gábor hojtsy → created an issue.
Fixed the test fails within Upgrade Status itself at 🐛 Tests fail due to Twig 3.15 deprecations Active .