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 .
gábor hojtsy → created an issue.
gábor hojtsy → created an issue.
I don't think we can do anything about composer not installing phpunit/phpunit, that is an entirely independent project and we do not interfere with how that is installed. I hope this worked out for you at the end.
gábor hojtsy → changed the visibility of the branch 3486565-update to hidden.
gábor hojtsy → made their first commit to this issue’s fork.
I think this is the same as 🐛 Ignore Twig 3.15 deprecation issues for now Active was?
The discussion in 🌱 D11-ready Active is interesting. Can we get an updated screenshot? It may be that the supported flags were updated due to your other issue and then not properly refreshed in your environment when you reported it. :)
Thanks, merged!
Upgrade status is for major version upgrades. There should be no API changes between 10.2 and 10.3 to worry about. When running on any version of 10.x, Upgrade Status will check readiness to Drupal 11 by design.
Thanks, looks good, merged.
This is way too much CSS/twig for me to competently review, but I came here to say that the main pain I see without this fix is the page title not being displayed by the top bar on admin pages.
borisson_ → credited gábor hojtsy → .
I'll assume that was in reference to the explanation above the "---", because under that I intended to outline a solution that is IMHO not really useful :)
The config update and override creation/update needs to happen as part of the recipe application, before the recipe application is completed. After that the system has no idea if the "customized" string came from a source code (and can be t()-ed) or was manually entered (and cannot be t()-ed).
If a site has English default language + French and Spanish config translations, how do both of the French and Spanish translations get into the language configuration override collection if we t() when the recipe is applied?
We would t() the string from the config action to create or update the French and Spanish config overrides as part of the recipe application. Since the English is default, we'll not t() the config action string for the default language in this case. If the site has a Spanish default with English and French translations, then we would need to apply the untranslated config action string to the English translation on the site and t() for Spanish default config and t() for the French override.
---
When the recipe is applied, I guess one backward way of figuring out which config actions may be translatable is to backreference from the config schema as part of applying the recipe, but such backreferencing needs to be built into the recipe application then. However that still does not solve the l.d.o extraction problem. L.d.o does not have a Drupal runtime for extracting strings where the code would actually be run, it always statically inspects the code. (From a Drupal 7 system even at this time). It does not run the code it handles.
Which makes me wonder if there could be a build step on l.d.o, or for recipes themselves, that installs the recipe and exports the resultant config, so it can then be parsed for translation.
For l.d.o: I think this would result in a much bigger set of translatable strings. I'm not sure how we can tell apart from the resulting config which parts were from config actions and which ones were not? So far for all other string extractors we do get the specific strings, not a superset that includes a bunch of unrelated stuff :)
For a specific website: As Jose wrote, when recipes get applied on an actual site, they may get applied to a multilingual site where the default is not English anymore or the edited config value is not as expected. Let's consider this theoretic situation for the sake of demonstration:
- The default Drupal setting for anonymous username is "Anonymous"
- We have a recipe that changes that to "Unknown name"
- The site the recipe is applied on is in Spanish by default and changed this to "Sin nombre" manually.
In this situation, the config translation's shipped by Drupal for the username are for "Anonymous". Those are not useful as the site changed the setting.
The new value shipped with the config action is not the same as the Drupal default, but it is in English.
So when it is applied, the default config on the site needs the Spanish translation of "Unknown name" set. This requires recipe application to be aware that the value is translatable and needs to t("Unknown name") as part of the recipe application, which will possibly make "Nombre desconocido" the anonymous name.
If there was an English language config translation, THAT would get "Unkown name" applied from the config action at the same time and other translations would get the t("Unknown name") too.
Lifecycle after recipe applied: After the recipe is applied, there will be no trace that the recipe applied the use of "Unknown name" and that is somehow a source string that needs translations applied. We discussed that this is by design, so the config system cannot deal with translating "Unknown name" after the fact that the recipe got applied, because "Unknown name" does not even necessarily appear in config anymore and also because config does not know that "Unknown name" came from some shipped source code that could be t()-ed.
---
All in all I think the above point to needing to explicitly mark translatable strings in recipes, parse them out on l.d.o explicitly and t() them when applied, because afterwards there is no chance to do it.
Also 🐛 Restore README.md to top level Active was opened in the meantime.
I'm not sure that would keep https://project.pages.drupalcode.org/governance/ working, the README.md in the docs folder serves as the index of that mkdocs output. Maybe we should add an alternate shorter README.md that explains where to view the output in a nicely formatted format?
Followup problem found at 🐛 Formatting of PUWG charter mkdocs output is wrong Active , does @froboy know what to do maybe?
gábor hojtsy → created an issue.
Api.drupal.org also has other EOL Drupal version pages like 8.9.x and 9.x, those should get a similar treatment IMHO.
borisson_ → credited gábor hojtsy → .
borisson_ → credited gábor hojtsy → .
Contributed modules can still provide toolbars at any other location with any other kind of interaction :)
#3421969-81: [PLAN] New Navigation and Top Bar to replace Toolbar Roadmap: Path to Stable → onwards discusses that Settings Tray also has a hard dependency on Toolbar, however Settings Tray has such low usage that decoupling them may not be effort well spent. Should their move to contrib be handled together then?
If people don't use settings tray then it is indeed better to move it out of core than to invest time into making Navigation and Settings Tray compatible somehow. Crossposting this info on 📌 [meta] Deprecate Toolabr module Active .
- Settings tray also requires toolbar module.
- Navigation suggests to uninstall toolbar module when navigation is used.
Is there a plan to resolve this somehow? I don't see a reference above to settings tray.
gábor hojtsy → created an issue.
@luukyb: it is a requirement yeah but Drupal should be more graceful when this happens and not overwrite the plural handling?
I don't think anything changed with this in the meantime.
balintbrews → credited gábor hojtsy → .
balintbrews → credited gábor hojtsy → .
Flag "administer languages" as "restrict access".
I think this makes the most sense.
Thanks a lot, good find!
Woah did the job run the analysis on all of those date spots that the MR includes dumps of JSON results for?
I think this is fine, we need to tell the community as soon as possible to give them time to do stuff they were planning quicker now as long as it is possible.
Agreed. Experience Builder already has previews in multiple viewports and the design system used should support this there.
I have not seen recent designs for content type editing, but Lauri presented a UI for mapping dynamic fields from content types to props in https://youtu.be/5ViCxc8ksb4?si=TqFStM83dgjzJTw7&t=942 (this timestamp going forward) that is based on the same UI based editing as XB for static pages, so I assume that is roughly what will happen. (Those are designs not working implementation).
I don't think this needs to be in core, it can work / improve better in contrib I think alongside the rest of the tooling.
With Drupal CMS it is not possible to add modules and content without adding them to core. Eg Drupal CMS could include this kind of messaging somewhere. There was a lot of discussion as to how to do a friendly support experience that does not require a drupal.org account right away, which is where I would start drawing the user in. That should be a related issue to this one and issue moved to Drupal CMS?
Experience Builder turns the node form inside out and you edit the content on a preview-first UI with the form on the side. I think that solves this problem?
Are there benefits for the whole ecosystem in this additionally to SDCs that are in core?
I believe this will now be within the realm of Experience Builder. Not sure if there is a corresponding XB issue, but XB explicitly provides mobile/desktop previews and may support variance based on viewports?
Hm, introduce custom hooks rather than a generic hook?
gábor hojtsy → created an issue.
You did not include a change in formatTree() but you rely on a change I think? Why not solve the formatting inside the format methods for global errors?
Anyone tested this other than roderik? Not that I don't trust roderik but a second set of eyes would be great :)