Problem/Motivation

At https://www.drupal.org/docs/drupal-apis/configuration-api/configuration-... there's no information at all about possible length limits for the several data types.

So when creating a config entity settings form (or anything else like that), you might assume that you can use data types like

• string
• label
• ...

without having to care for a limit. For config entities, I guess that assumption is also absolutely correct (if it is, it would still be nice to write that down on the documentation page). For content entities that are stored into the database, of course limits are important. Still 128 isn't a good limit anymore?

Now, when creating the settings forms for the config entity, we were wondering that a text with > 128 characters could not be entered and was cut off in the UI.

The reason was the maxlength="128" attribute on the form elements. Okay so far, but strange default behavior.
Modifying this limit were unsure, if there's a technical limit, so that when changing this FAPI textfield element #maxlength and saving it, might lead to any kind of errors or just cut off text. As I couldn't find any documentation, we tried and couldn't find issues with that.

Later on, we used config translation to allow translating the values and run into the same issue again, now for the config translation form. To increase / remove the limit, we used a hook, until this is solved.
The issue came up with #3327045: Cookies Service Input fields limit text length too short at the COOKiES module.

Steps to reproduce

Follow the steps at https://www.drupal.org/docs/drupal-apis/configuration-api/creating-a-con... and try to enter a label with > 128 characters.

Even if there's no storage reason for the limit, the input is limited to 128 characters and changing this is hard.

Proposed resolution

There are several levels, where this might be solved, but I'm not experienced enough to decide the long term strategy.

These are the options from most global and BC-dangerous to BC-safe solutions:
a) Remove the #maxlength default from \Drupal\Core\Render\Element\Textfield entirely

b) Increase the #maxlength default at \Drupal\Core\Render\Element\Textfield to 256 to match at least 99% of the cases when making such an assumption

c) Unset the #maxlength limit at Drupal\config_translation\FormElement\Textfield

d) Increase the #maxlength limit at Drupal\config_translation\FormElement\Textfield to 256 to match at least 99% of the cases when making such an assumption

e) Introduce a maxlength or size similar property for config schema (abc.schema.yml) which is used to define the limits centrally and provide helpers to determine the limit.

f) ...?

Based on the results of the discussion here, possible the title and component of this issue might have to be changed accordingly.

Remaining tasks

Document the limits or that there is no technical limit at the Configuration schema/metadata docs page after that has been confirmed
Discuss which way to go

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

While in the entity reference widget you can configure the autocomplete widget settings, you can't do the same for the link field.

Link field widget:

Entity reference field widget:

Steps to reproduce

Standard Drupal installation, article content type, add two fields: 1. Entity reference, referencing other articles and 2. Link field allowing both internal and external links.

Proposed resolution

Port #2863188: Hardcoded result size limit in the entity reference autocomplete widget. to the link field widget enabling the same settings if internal links are allowed.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In a multilingual context, where the ability to change the entity language from the edit form is enabled, aliases are lost when the language is modified.

Steps to reproduce

1. Enable language module and activate 2 languages in a clean Drupal site, A&B
2. Edit a content type and check the "Show language selector on create and edit pages" option
3. Create a node of the content type above and fill the alias field
4. Edit the node and change the language to B (You can modify the alias field or not)
5. Save

Expected result

The alias is updated and available in language B

Actual result

The alias is lost and is necessary to edit again the node only to save the alias in language B

Proposed resolution

Remaining tasks

User interface changes

API changes

None

Data model changes

None

Release notes snippet

Making a theme compatible with Drupal core's theme generator tool is very difficult. Theme generator was introduced in 9.3, and in two years the only theme (that I know of) that is clonable is core's starterkit theme.

I believe that the reason is that making a theme compatible is too difficult. Within the issue to make Olivero compatible (#3301173: Allow starterkit theme generator tool to clone Olivero), we need 240 lines of fairly complicated PHP. This is unreasonable for a themer to do, and most don't have the necessary skillset to do so.

Plan

To be determined. Maybe we could have a YML file where a themer could define what strings are to be replaced and with what, what directories to search, etc.

Updated: Comment #16

Problem/Motivation

The original poster, Dave Cohen, reported this problem running D6:

I get Page not Found errors with pathauto when locale is enabled. The aliases get associated with "English" and never work. If I manually edit an alias, changing it to "All languages", then it works. Not sure whether this is bug or my configuration, would appreciate help either way.

The problem was simplified (the Pathauto module is not required) and reproduced in D7 and D8. The configuration quirks in the original poster's site do not seem to be relevant.

Steps to reproduce (from #11 and #13)

Using Drupal core 7.21 and Pathauto 7.x-dev: Elaborating on the steps to reproduce in D7 and D8 (based on the thread above):

1. Configure Drupal:
   • D7: enable the core Locale and Content Translation modules.
   • D8: enable the core Language and Content Translation modules
2. D7/D8: visit admin/config/regional/language, press "Add language" and select "Spanish" from the drop-down
3. D7/D8: press the "Detection and Selection" tab aka as admin/config/regional/language/configure
4. D7/D8 In the column of tick boxes make sure that Detection Method URL is unticked while Detection Method Session is ticked; leave the remaining tickboxes set to what they are
5. Configure Content Types:
   • D7: on the content type settings page for Article admin/structure/types/manage/article tick the Publishing options tab and then the Enabled radio button under "Multilingual support."
   • D8: visit /admin/config/regional/content-language and tick the Content box (Custom Language Settings) as well as the Article box in the Translatable column.
6. D7/D8: add content: node/add/article, specify an alias under "URL path settings" and in the Language drop-down select "English". Save
7. D7/D8: Verify that you can View the page via the URL alias
8. D7/D8: Edit the page, changing the language selector to Spanish. Save.
9. You can now no longer View the page via its URL alias, although node/... still works.

Is this the problem or a feature?? It's a problem, at the very least it s counterintitutive and not clearly documented…

Proposed resolution

In #8 SiliconMind proposed an explanation of the problem:

I think that this happens because drupal_lookup_path from path.inc uses global $language_url variable to get current language. But the problem is that $language_url is set to default language if language was not set via url. This is wrong because language could be selected through user preferences or browser language.

The real problem is that url alias should work always regardless of selected language!

Workaround for this is to alter drupal_lookup_path queries to search url_alias table for entries that match provided alias but not necessarily match language that is provided by $language_url variable. The goal is to always return alias source if it exists regardless of selected language.

Remaining tasks

1. Finish charactarizing the problem and determine if we have one issue or several.
2. Decide what the desired behavior is.
3. Create a patch.
4. Design tests.
5. Update documentation
6. Backport to D7.

User interface changes

(New or changed features/functionality in the user interface, modules added or removed, changes to URL paths, changes to user interface text.)

There will clearly be some…

Once this is sorted out it would be very good to document the behavior and make it easily accessible from the language configuration pages.

Another nice change would be to include the language of a page in the content listing on multi-lingual sites (although this should probably be a separate issue).

API changes

At the moment there do not appear to be any.

Original report by Dave Cohen

Rather than "hijack"#320710: Pathauto URL Alias leading to Page Not Found, submitting new issue. I find I get Page not Found errors with pathauto when locale is enabled. The aliases get associated with "English" and never work. If I manually edit an alias, changing it to "All languages", then it works. Not sure whether this is bug or my configuration, would appreciate help either way. More about the problem: Drupal is unilaterally modifying paths specified by the content author, without notifying the content author.

Proposed resolution

1. Do not modify user-supplied paths.
2. If it's absolutely necessary to modify user-supplied paths, at least inform the user.
3. Avoid 404'ing user-supplied paths -- make them redirect to the changed path, maybe?

Beta phase evaluation

Problem/Motivation

As I was working on #3373867: [regression] "Comments field is required" when creating content for types with a comment field configured as hidden, I realized there are several issues with the comment settings:

1. When comment settings default value is set as hidden, the radio button loads without a default value. This is not recommend most of the time according to Nielsen Norman.
2. When there are no comments, the hidden option is not shown. Shouldn't the "Closed" option be hidden since that option displays an empty list of comments without an option to submit new comments?

Proposed resolution

Always show the option selected by default so that it's visible to users which option has been selected. Also, hide the "Closed" option when there are not comments posted to the entity.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

If we compare the UI for creating and managing content types with that for comment types, there are some inconsistencies that are likely to lead to confusion, even among users who are familiar with the Drupal UI:

Creating a new comment type

When adding a new comment type (/admin/structure/comment/types/add), the default "Target entity type" is "custom block", which should probably not be the default. When performing the same operation programmatically (e.g. for tests), the default is Content (node). This should be the default target for comments, IMHO, as it's the most likely actual need and could be accidentally overlooked (and, since the value cannot be changed, once a custom comment type is saved, this could lead to frustration).

When editing custom comment type, the breadcrumb is missing the name of the custom type.

This is not consistent with the form for content types and may lead to confusion about what the user is actually editing (global comment form settings?). Only the URL shows the custom comment type name.

Compare the content type editing UI...

... with the UI for editing comment types

The h1 header for the form does not include the custom comment type name

Except for the "Translate comment type" form, we are missing the custom (missing from the h1 on the "Manage fields", "Manage form display", and "Manage Display" tabs). This is actually consistent with content types, but we should probably have the comment type (and content type) in the h1 for all tabs. In Drupal 7, the default is to clearly show the content type in the h1 (whether overlay is enabled or not).

Currently, we only see the comment type name in the h1 if we are on the translation tab (assuming config for multilingual)

Since the custom comment type is missing from both the breadcrumb and the h1, a user may be easily confused about what they are actually editing, especially if on a device (or working in a window size) where the URL is not fully visible.

Problem/Motivation

As part of #2164373: [META] Untie config validation from form validation — enables validatable Recipes, decoupled admin UIs …, we are going to need to add some constraints to the _core_config_info struct that is added to all config, entities and simple objects alike.

Steps to reproduce

N/A

Proposed resolution

Add some constraints to every field in that struct.

User interface changes

N/A

API changes

TBD, but probably none.

Data model changes

TBD, probably none.

Release notes snippet

TBD, probably none.

Problem/Motivation

When a dialog is opened with the "modal" option, all other elements on the page are hypothetically disabled. Even though those other elements are masked, you can still scroll-through the modal to the body, which is awkward and not expected behavior. This can lead to the user being confused after closing a modal as the page has scrolled past where they initiated the modal originally.

This patch disables body-level scrolling when a dialog is opened as a modal, which should address this problem.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Drupal 10.1.0 introduced a validation message "Comments field is required" when creating a content item for a content type that has comments set to hidden.

Steps to reproduce

Configure comment field on type Article to be "Hidden". Create an article, fill in title only and try to save.

Proposed resolution

I traced this back to #3347296: Conditionally show default value fields, which changed the comment settings field to a required field, regardless of the form being rendered on the administration page or the content creation page.
Somehow conditionally setting required to TRUE could bring back the old behaviour, I guess.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

After I added a new language (Italian, for example), in the Drupal translation page (/admin/config/regional/translate), every search term returned empty results instead of the list of translations.

Again, the pre-existent translations not working, all terms stay in English.

My env:

• SQL Server as Database;
• Contrib modules:
• https://www.drupal.org/project/sqlsrv
• https://www.drupal.org/project/adv_varnish
• https://www.drupal.org/project/redis
• Drupal 9
• PHP 8.1

The strange thing: on another env with the same set, the translations work.

Steps to reproduce

1. Add new language;
2. Set the new language as default;
3. Try to search a string or translate a string;
4. The translation is not applied;

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

TDB

API changes

TDB

Data model changes

TBD

Release notes snippet

TBD

Problem/Motivation

In #2431329: Make (content) translation language available as a field definition we introduced a translated default_langcode field, but we prevented it from being altered as it should be considered read-only. We did not use a standard method to implement this as read-only constraints were not working at the time. Moreover until #2137801: Refactor entity storage to load field values before instantiating entity objects is fixed, the field is actually populated so it cannot be read-only. However we should switch to a standard method as soon as possible.

Proposed resolution

TBD

Remaining tasks

• Figure out a solution
• Write a patch
• Review it

User interface changes

None

API changes

None

Problem/Motivation

In the Olivero theme, there is an inconsistency in the use of spacing variables or layout helpers in the PostCSS files. While variables.pcss.css defines spacing variables like --sp1, --sp2, --sp3, etc., based on the variable --sp.

there are instances in some pcss files where values are directly assigned the `calc(2 * var(--sp));` value instead of using the equivalent --sp2. This inconsistency occurs for different versions of the layout helpers across several PCSS files.

I am mentioning --sp2 as an example but the situation is with different version of the layout helpers.

Steps to reproduce

1. Open the PostCSS files in the Olivero theme.
2. Check for occurrences of the full formula instead of the corresponding variable.

Example in file core/themes/olivero/css/components/header-search-narrow.css line 47:

height: calc(3 * var(--sp));

Proposed resolution

To maintain consistency and readability, all instances of `calc([number] * var(--sp));` should be replaced with the equivalent --sp[number]. The same applies to other versions of the layout helpers. This will ensure that the usage of spacing variables is consistent across all PCSS files in the Olivero theme.

Test pages

The changes should be reflected in all pcss files of the Olivero theme.

Before/After screenshots

Screenshots are not applicable for this issue as it's a code consistency issue.

Markup changes

The markup changes involve replacing instances of `calc(2 * var(--sp));` with --sp2 (and similar replacements for other versions of the layout helpers) in the relevant PCSS files.

Cross browser tests

Cross-browser testing is not applicable for this issue as it's a code consistency issue.

Related Issues

No related issues.

Problem/Motivation

New Revision UI was added in #2350939: Implement a generic revision UI and any revisionable entity can extend it by following this change record. When trying to revert a entity which have multiple translations, one would expect that only that translation is reverted as is the case for node (which currently do not use the New Revision UI - #2453153: Node revisions cannot be reverted per translation) but this reverts all of the translations and a new revision which is copy of one of the old revision of that langauage's translation gets created.

Steps to reproduce

media_revision_ui 3.x version uses New Revision UI to provide this interface for revisionable media.

1. Setup a multilingual Drupal site with atleast 2 languages.
2. Install Core media and contrib media_revision_ui(v3.x) module.
3. Make a media type revisionable.
4. Create several revisions for this media type in each language.
5. Trying reverting a revision in any of the translation.
6. After reverting, a new reverted revision is created for each of the language. Only the reverted language is reverted to correct old revision and other translations point to random old revisions.

Expected: Only the translation which is being reverted should have the new reverted revision and other translation revision should not be impacted.

Problem/Motivation

On field storage the form can be submitted even the "Comment type" dropdown shows no entries. This creates a comment field with an empty comment_type.

Steps to reproduce

1. Go to: Admin > Structure > Taxonomy
2. Create a new vocabulary
3. On the new vocabulary page click the "Manage fields" tab, then click "Add field"
4. Select "Comment" from "Add a new field" dropdown, fill a field name and press "Save and continue"
5. Note that the "Comment type" select is empty.

You cannot submit this form because the field has no value but if you go back to the "Manage fields" page (may requirrefresh), you'll note tha the field has been added.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Site Install Produces warning Warning: Undefined array key on 11.x Head

I am seeing below warnings in watchdog logs Both with Drush 12+ and Site install from UI.

Warning: Undefined array key "/var/www/html/web/core/modules/system/system.links.action.yml" in Drupal\Component\Discovery\YamlDiscovery->findAll() (line 55 of /var/www/html/web/core/lib/Drupal/Component/Discovery/YamlDiscovery.php)
#0 /var/www/html/web/core/includes/bootstrap.inc(164): _drupal_error_handler_real(2, 'Undefined array...', '/var/www/html/r...', 55)
#1 /var/www/html/web/core/lib/Drupal/Component/Discovery/YamlDiscovery.php(55): _drupal_error_handler(2, 'Undefined array...', '/var/www/html/r...', 55)
#2 /var/www/html/web/core/lib/Drupal/Core/Plugin/Discovery/YamlDiscovery.php(75): Drupal\Component\Discovery\YamlDiscovery->findAll()
#3 /var/www/html/web/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(86): Drupal\Core\Plugin\Discovery\YamlDiscovery->getDefinitions()
#4 /var/www/html/web/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(291): Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDefinitions()
#5 /var/www/html/web/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(181): Drupal\Core\Plugin\DefaultPluginManager->findDefinitions()
#6 /var/www/html/web/core/lib/Drupal/Core/Menu/LocalActionManager.php(165): Drupal\Core\Plugin\DefaultPluginManager->getDefinitions()
#7 /var/www/html/web/core/lib/Drupal/Core/Menu/Plugin/Block/LocalActionsBlock.php(80): Drupal\Core\Menu\LocalActionManager->getActionsForRoute('user.login')
#8 /var/www/html/web/core/modules/block/src/BlockViewBuilder.php(171): Drupal\Core\Menu\Plugin\Block\LocalActionsBlock->build()
#9 [internal function]: Drupal\block\BlockViewBuilder::preRender(Array)
#10 /var/www/html/web/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php(111): call_user_func_array(Array, Array)
#11 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(788): Drupal\Core\Render\Renderer->doTrustedCallback(Array, Array, 'Render #pre_ren...', 'exception', 'Drupal\\Core\\Ren...')
#12 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(377): Drupal\Core\Render\Renderer->doCallback('#pre_render', Array, Array)
#13 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(449): Drupal\Core\Render\Renderer->doRender(Array)
#14 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(204): Drupal\Core\Render\Renderer->doRender(Array, false)
#15 /var/www/html/web/core/lib/Drupal/Core/Template/TwigExtension.php(475): Drupal\Core\Render\Renderer->render(Array)
#16 /var/www/html/web/sites/default/files/php/twig/64a6df758725d_page.html.twig_TGnBvuDsKBS2w1q4s_heud9ln/fFb5Lxm6_yvNz5tDPV0VWTlqVBIpThdGsR6aexckF1Y.php(124): Drupal\Core\Template\TwigExtension->escapeFilter(Object(Drupal\Core\Template\TwigEnvironment), Array, 'html', NULL, true)
#17 /var/www/html/vendor/twig/twig/src/Template.php(394): __TwigTemplate_eb126d6a44902446b4f87edb09059cac->doDisplay(Array, Array)
#18 /var/www/html/vendor/twig/twig/src/Template.php(367): Twig\Template->displayWithErrorHandling(Array, Array)
#19 /var/www/html/vendor/twig/twig/src/Template.php(379): Twig\Template->display(Array)
#20 /var/www/html/vendor/twig/twig/src/TemplateWrapper.php(40): Twig\Template->render(Array, Array)
#21 /var/www/html/web/core/themes/engines/twig/twig.engine(39): Twig\TemplateWrapper->render(Array)
#22 /var/www/html/web/core/lib/Drupal/Core/Theme/ThemeManager.php(345): twig_render_template('core/themes/oli...', Array)
#23 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(436): Drupal\Core\Theme\ThemeManager->render('page', Array)
#24 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(204): Drupal\Core\Render\Renderer->doRender(Array, false)
#25 /var/www/html/web/core/lib/Drupal/Core/Template/TwigExtension.php(475): Drupal\Core\Render\Renderer->render(Array)
#26 /var/www/html/web/sites/default/files/php/twig/64a6df758725d_html.html.twig_Huwg9ef7MUdT5L_buGFY3Vhlb/Oiws4bCYs2W5gdXiVxO167b56HsUUdoPM58PMzKJHRU.php(93): Drupal\Core\Template\TwigExtension->escapeFilter(Object(Drupal\Core\Template\TwigEnvironment), Array, 'html', NULL, true)
#27 /var/www/html/vendor/twig/twig/src/Template.php(394): __TwigTemplate_39e9826c392d3e1c6117e13445af8b58->doDisplay(Array, Array)
#28 /var/www/html/vendor/twig/twig/src/Template.php(367): Twig\Template->displayWithErrorHandling(Array, Array)
#29 /var/www/html/vendor/twig/twig/src/Template.php(379): Twig\Template->display(Array)
#30 /var/www/html/vendor/twig/twig/src/TemplateWrapper.php(40): Twig\Template->render(Array, Array)
#31 /var/www/html/web/core/themes/engines/twig/twig.engine(39): Twig\TemplateWrapper->render(Array)
#32 /var/www/html/web/core/lib/Drupal/Core/Theme/ThemeManager.php(345): twig_render_template('core/themes/oli...', Array)
#33 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(436): Drupal\Core\Theme\ThemeManager->render('html', Array)
#34 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(204): Drupal\Core\Render\Renderer->doRender(Array, false)
#35 /var/www/html/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(158): Drupal\Core\Render\Renderer->render(Array)
#36 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(583): Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}()
#37 /var/www/html/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(159): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#38 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php(90): Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch))
#39 [internal function]: Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object(Symfony\Component\HttpKernel\Event\ViewEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#40 /var/www/html/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\ViewEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#41 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(171): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object(Symfony\Component\HttpKernel\Event\ViewEvent), 'kernel.view')
#42 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(74): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#43 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#44 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#45 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(191): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#46 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(128): Drupal\page_cache\StackMiddleware\PageCache->fetch(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#47 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(82): Drupal\page_cache\StackMiddleware\PageCache->lookup(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#48 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#49 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#50 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#51 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(704): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#52 /var/www/html/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#53 {main}
.

Warning: Undefined array key "/var/www/html/web/core/modules/views_ui/views_ui.links.contextual.yml" in Drupal\Component\Discovery\YamlDiscovery->findAll() (line 55 of /var/www/html/web/core/lib/Drupal/Component/Discovery/YamlDiscovery.php)

Warning: Undefined array key "/var/www/html/web/core/modules/user/user.links.contextual.yml" in Drupal\Component\Discovery\YamlDiscovery->findAll() (line 55 of /var/www/html/web/core/lib/Drupal/Component/Discovery/YamlDiscovery.php)

Warning: Undefined array key "/var/www/html/web/core/modules/taxonomy/taxonomy.links.contextual.yml" in Drupal\Component\Discovery\YamlDiscovery->findAll() (line 55 of /var/www/html/web/core/lib/Drupal/Component/Discovery/YamlDiscovery.php)

Warning: Undefined array key "/var/www/html/web/core/modules/field_ui/field_ui.links.action.yml" in Drupal\Component\Discovery\YamlDiscovery->findAll() (line 55 of /var/www/html/web/core/lib/Drupal/Component/Discovery/YamlDiscovery.php)

Warning: Undefined array key "/var/www/html/web/core/modules/node/node.links.contextual.yml" in Drupal\Component\Discovery\YamlDiscovery->findAll() (line 55 of /var/www/html/web/core/lib/Drupal/Component/Discovery/YamlDiscovery.php)

Warning: Undefined array key "/var/www/html/web/core/modules/menu_ui/menu_ui.links.contextual.yml" in Drupal\Component\Discovery\YamlDiscovery->findAll() (line 55 of /var/www/html/web/core/lib/Drupal/Component/Discovery/YamlDiscovery.php)

---------------------------------------------------------------------------------------------------------
Warning: Undefined array key "" in Drupal\user\PermissionHandler->Drupal\user\{closure}() (line 215 of /var/www/html/web/core/modules/user/src/PermissionHandler.php)

Warning: Undefined array key "" in Drupal\user\PermissionHandler->Drupal\user\{closure}() (line 211 of /var/www/html/web/core/modules/user/src/PermissionHandler.php)

Warning: Undefined array key "" in Drupal\user\PermissionHandler->Drupal\user\{closure}() (line 215 of /var/www/html/web/core/modules/user/src/PermissionHandler.php)

drush st
Drupal version   : 11.0-dev
Site URI         : https://drupal-contrib.ddev.site
DB driver        : mysql
DB hostname      : db
DB port          : 3306
DB username      : db
DB name          : db
Database         : Connected
Drupal bootstrap : Successful
Default theme    : olivero
Admin theme      : claro
PHP binary       : /usr/bin/php8.1
PHP config       : /etc/php/8.1/cli/php.ini
PHP OS           : Linux
PHP version      : 8.1.16
Drush script     : /var/www/html/vendor/bin/drush
Drush version    : 12.1.1.0
Drush temp       : /tmp
Drush configs    : /var/www/html/vendor/drush/drush/drush.yml
Install profile  : standard
Drupal root      : /var/www/html/web
Site path        : sites/default
Files, Public    : sites/default/files
Files, Temp      : /tmp

Steps to reproduce

Run drush si and you observe above messages in dblog.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Most entity types in Drupal have a description (content types, media types, menus, vocabularies, views, roles, etc. For sites built with a lot of custom form modes and view modes to manage how media is displayed on an entity, it would be helpful for site builders to be able to provide a description for each form/view mode to describe why the custom view mode was created.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

While checking the Glossary 2 module with phpstan, I noticed a warning about the tips method.

FilterInterface::tips() is defined as:

  /**
   * ...snip...
   *
   * @return string|null
   *   Translated text to display as a tip, or NULL if this filter has no tip.
   */
  public function tips($long = FALSE);

However, all implementations in core actually return TranslatableMarkup|null.

Steps to reproduce

Read all filter implementations in core.

Proposed resolution

• Modify FilterInterface to match what code actually does: update the PHPdoc to @return \Drupal\Core\StringTranslation|null
• Optional: add a return type hint: public function tips($long = FALSE): ?TranslatableMarkup . I'm not sure where we stand on return typing for D10.

Remaining tasks

Decide on the return typing.

User interface changes

None.

API changes

If it is just a phpdoc, none. If we type the return value, it may qualify as an API change, but one that matches core implementations, and those implementations I looked at in contrib.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

Split from #3050720: [Meta] Implement strict typing in existing code.

PHP allows child classes to add return type hints in the parent class doesn't. This means we can add return type hints to interfaces in Drupal 11, contrib modules can add them whenever, and those modules will continue to work in both Drupal 10 and 11.

What we can't do, is notify contrib modules that they need to add the type hint to continue to work.

Symfony has partially solved this issue - it looks at @return phpdoc, and if there's no matching type hint, the debug classloader issues a deprecation message. However, this is overkill - it issues deprecations for classes even where the new version doesn't have a return type hint, so can be misleading (and noisy).

Steps to reproduce

Proposed resolution

We want something similar to Symfony's implementation, but explict instead of implicit. For example, could we add an attribute like [#ReturnTypeHintDeprecation]. To do this would require overriding Symfony's debug classloader though.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet