i have this configuration:

if there are no results the view print: {{ 'News'|t }}

if there are results instead it is correctly printed

(this issue don't fix this problem: https://www.drupal.org/node/2610236)

Problem/Motivation

When a base field (e.g. entity path) properties are changed (e.g. it is made non-translatable), it's isInternal() method is inherited from FieldConfigBase, so that any computed field becomes internal though initially the field might be non-internal. This, for example, will remove the field from JSON:API results and might have other undesired consequences.

Steps to reproduce

1. Create node and set up JSON:API for the node to be exposed via API.
2. Make sure the path is exposed in the attributes section.
3. Mark URL Alias as untranslatable and clear caches.
4. See that the path has disappeared from the JSON:API response.

Proposed resolution

The correct approach is to inherit the internal property from the base field definition like other properties like "computed" and "read only" are.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem

Without proper caching, Drupal is SLOW, just like many extensible PHP frameworks. Despite the great cache tag feature of Drupal 8, not everything can be fully cached.
One major problem is Drupal's bootstrap is very resource-intensive. Regardless of how much time we put into optimizing it, it can only become slightly faster. The reason for this as i believe is because we're using the wrong approach. Bootstrapping the whole application for every request is just wrong. Things get even worse when one wants to use Drupal as a headless REST API for something like a progressive application with many small simultaneous requests.

Why is this critical

The web is becoming much faster and the content is extremely customized. In many cases caching just wouldn't cut it.
just to name few related technologies: Progressive Apps, HTTP2, IoT, REST, Li-Fi, 5G, etc.
With Drupal headless initiative which makes using Drupal for modern web much easier and semantic versioning which makes it possible to add many new features to core every several months, can Drupal really compete with Walled Garden ? Will 200-300ms for dynamics content acceptable for users and clients? Drupal can be used for sites with heavy traffic and dynamic content, but if we put aside how challenging it's, it can never deliver the same performance as more modern Web solutions written by likes of Node.js

I think this is important enough to become an initiative.

Solution

It's simple, not to bootstrap Drupal every time. Up until a few years ago, there wasn't any reliable solution fast enough worth the effort. But now there are several open-source projects already in production (PHP-PM, PHPFastCGI, Icicle, AppServer.io , etc). And it is fast, we're talking about 10-30ms and few kilobytes of memory usage without any caching or optimization against 100-150ms and megabytes of memory usage (The numbers come from my experiment with ReactPHP HTTP server and a custom Silex application). This is without any optimization, just changing the approach! But when the application bootstraps only once and objects are persistent, a lot of things can be greatly optimized.

Demonstration

I haven't been able to find any benchmarks for Drupal, but for other frameworks the are several :

• https://github.com/Blackshawk/SymfonyReactorBundle
• https://medium.com/laravel-4/eaa550829538
• https://drupal.org/project/drushd
• Benchmarking Codswallop: NodeJS v PHP
• 280 rq/s to 1770 rq/s - Speed up Symfony, Silex and Slim with PHPFastCGI
• Bring High Performance Into Your PHP App (with ReactPHP)
• PHPFastCGI Benchmarks - Symfony, Silex and Slim

More information on the wiki page: https://groups.drupal.org/node/417723

Work already done

There has been several attempts, discussions and experiments so far using different approaches :

• https://drupal.org/project/daemoncli
• https://drupal.org/project/daemon
• https://drupal.org/project/drushd
• https://groups.drupal.org/node/192173
• Drupal8 Adaptor for PHP-PM: https://github.com/php-pm/php-pm-drupal

Roadmap

• Making core compatible with app servers: https://github.com/php-pm/php-pm-drupal/tree/master/patches
• Using one of the available solutions like PHP-PM in core
• Adding new tests for app-server, this also helps contrib module developer to make their modules compatible

Problem/Motivation

Providing a UI for an entity type involves a lot of boilerplate code.

In particular, three YML files have to be provided:

- MODULE.links.menu.yml
- MODULE.links.task.yml
- MODULE.links.action.yml

These contain repetitive boilerplate code, where furthermore it's very easy to make a mistake and match up the route names incorrectly.

Proposed resolution

Add a new handler type for entities, 'link_provider'. This defines menu, task, and action links for an entity type.

Provide two link provider handlers in the Entity component that follow the standard admin UI pattern (for example, as used by Media module's entity types):

- DefaultContentEntityLinkProvider
-- defines a local task link for the collection under admin/content, alongside the Content admin listing
-- defines a menu link for the collection as well, so it appears in the admin toolbar
-- defines the 'add new entity' action link on the collection page
-- defines a set of local tasks link for view/edit/delete for a single entity

- DefaultConfigEntityLinkProvider
-- defines a menu link for the collection under admin/structure
-- defines the edit form local task link, which allows Field UI to attach its own tasks for the case that this config entity is the bundle for a content entity.

Both of these link provider handler classes expect to find the route names created by core's route_provider classes.

Entity types that customize their route provider to change or add routes would need to use their own link_provider handler (or keep using hardcoded link plugins of course).

Remaining tasks

- Get a review from one of the managers of the plugin system. YAML plugins are not discoverable in core/lib (unlike annotation-based plugins), and so the current patch declares the plugin derivatives that are in core/lib/Core/Entity in system module's YAML files. This approach needs framework manager review.

Follow-ons

Convert core's entity types to use these handlers. This is left as as follow-up, because changing an entity type to use a link provider handlers will cause the plugin IDs of the link plugins to change. It's not clear whether the BC policy on plugin IDs applies to menu plugins, and there is no policy or defined way on how to handle YAML plugin ID changes -- see #2922451: [policy no patch] Make it possible to mark plugins as deprecated.

User interface changes

None.

Problem/Motivation

This task is part of the audio/video accessibility plan - #3002770: Provide authors with tools to manage transcripts and captions/subtitles for local video and audio.

We want to provide authors with the ability to upload WebVTT <track> files with subtitle, caption, and audio description, to supplement HTML <video> and <audio> elements.

Proposed resolution

1. Provide a FieldType and FieldWidget plugin to represent a WebVTT file.
2. Support all of the attributes of the HTML <track> element. Authors should be able to set kind, label, src, srclang, default. Browsers currently only support captions and subtitles, but some JS player libraries support audio descriptions and chapters tracks too (notably AblePlayer).
3. The field type config can allow site builders to limit the values of the kind attribute which a given MediaTrackItem can accept.
4. Rendering the track element is out of scope for this issue. FieldFormatter will be done in another task issue.

Challenges

Validation: the default attribute has a peculiar usage. It says which track is to be considered the default track to use, but this means the default track for each possible value of the kind attribute. For example, a <video> could have chapters, audio description, subtitles, and captions tracks, in 3 languages. There could be up to 4 default <track> elements in this case. Validating this could be tricky for the UI. Decide if validation is required/feasible for the <track default> attribute. We might just trust authors to use it correctly.

Remaining tasks

1. Use a select element for the srclang in the FieldWidget plugin.
3. Add some configuration options in the FieldType plugin, so that site builders can specify which values of the kind attribute to accept.
5. Decide if validation is required/feasible for the <track default> attribute.
6. Implement generateSpecimenValue. The patch has some pseudocode already.
7. Tests.

User interface changes

Adds new FieldType and FieldWidget plugins to represent a HTML <track> element.

API changes

None.

Data model changes

Adds a new FieldType plugin to represent a HTML <track> element.

Problem/Motivation

Regarding #2350939: Implement a generic revision UI @smustgrave asked if the node's view filter "Get the actual content from a content revision" should be made generic or per entity.

Steps to reproduce

@todo

Proposed resolution

@todo

Remaining tasks

Discuss the best approach
Propose a resolution
Work on a patch/MR
Review
Commit

User interface changes

@todo

API changes

@todo

Data model changes

@todo

Release notes snippet

@todo

Problem/Motivation

Note: As far as I know unnecessary code counts as a bug, but this could also be seen as a task (and then retargeted for 9.4?), not sure.

Found in #3257407: Use "content" region in BlockCreationTrait::placeBlock() instead of "sidebar_first".

SettingsTrayBlockFormTest's implementation of getTestThemes() is identical to that of it's parent SettingsTrayTestBase

Steps to reproduce

-

Proposed resolution

Remove SettingsTrayBlockFormTest::getTestThemes().

Remaining tasks

User interface changes

-

API changes

-

Data model changes

-

Release notes snippet

Problem/Motivation

The current web.config doesn't relax the default requestPathInvalidCharacters settings of IIS.
This means that colons (:) in URLs are classified as invalid characters.
Because of this URLs like the one from the block management (http://wl56www523.webland.ch/drupal/web/admin/structure/block/add/block_content%3Adc5f60cf-8510-4a21-b899-641571747188/bodies?region=section_first&_wrapper_format=drupal_modal) are blocked.

Proposed resolution

Add the <httpRuntime requestValidationMode="2.0" requestPathInvalidCharacters="*,%,?,\,&amp;,&lt;,&gt;" /> directive to the web.config file.
This should allow colons in URLs.

Remaining tasks

This was tested with "Microsoft-IIS/7.5" and "AspNet-Version:4.0.30319" - as I'm very unfamiliar with IIS this defintitely needs a review from someone that's more familiar with that webserver.
Another open question is if the config syntax for &,<,> is valid - I had to use &,<,&gt to avoid a 500 error from IIS, and it seems like the related chars are filtered properly.
However, if this is server version / configuration specific syntax we might break installations if we simply update the web.config.

User interface changes

None

API changes

None

Data model changes

None

Problem/Motivation

\Drupal\Tests\rest\Functional\BcTimestampNormalizerUnixTestTrait was deprecated in Drupal 9 and should be removed for Drupal 10.

Steps to reproduce

Proposed resolution

Remove the class.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

There are various bits of code in the \Drupal\Core\Update and \Drupal\update namespaces that were deprecated in Drupal 9 for removal in Drupal 10.

Steps to reproduce

Proposed resolution

Remove the deprecated code.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

\Drupal\FunctionalTests\Image\ToolkitTestBase was deprecated in Drupal 9.1 and should be removed in Drupal 10.

Steps to reproduce

Proposed resolution

Remove the class.
Remove any remaining references.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

From #3275864: [upstream] Update to Symfony 6.1.1.

Full test results: https://www.drupal.org/pift-ci-job/2364329

  1x: The "Symfony\Component\Validator\Constraints\Range::$minMessage" property is considered final. You should not override it in "Drupal\Core\Validation\Plugin\Validation\Constraint\RangeConstraint".
    1x in ContextDefinitionIsSatisfiedTest::testIsSatisfiedBy from Drupal\Tests\Core\Plugin\Context

  1x: The "Symfony\Component\Validator\Constraints\Range::$maxMessage" property is considered final. You should not override it in "Drupal\Core\Validation\Plugin\Validation\Constraint\RangeConstraint".
    1x in ContextDefinitionIsSatisfiedTest::testIsSatisfiedBy from Drupal\Tests\Core\Plugin\Context

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

The range validator for entities now yields a more accurate 'value not in range' message, with its violation error code also more accurately being Range::NOT_IN_RANGE_ERROR.

Agenda items

Standing items

• Who is here
• Any other suggested topics
• Wins / Thanks / Blockers
• Statistics and functionality update. X new bugs created in last two weeks. Y closed by the initiative.
• The bug I would most like to see fixed
• Update on target items from last meeting
• What should be the initiative focus for the next 2 weeks?

Statistics

Statistics graph

Agenda items

Standing items

• Who is here
• Any other suggested topics
• Wins / Thanks / Blockers
• Statistics and functionality update. X new bugs created in last two weeks. Y closed by the initiative.
• The bug I would most like to see fixed
• Update on target items from last meeting
• What should be the initiative focus for the next 2 weeks?

Statistics

Statistics graph

0️⃣ Who is here today? Comment in the thread to introduce yourself. We’ll keep the meeting open for 24 hours to allow for all timezones.

0️⃣.5️⃣ What are you looking forward to with the change in seasons?

1️⃣ Do you have suggested topics you are looking to discuss? Post in this thread and we’ll open threads for them as appropriate.

2️⃣.1️⃣ Wins - what wins have you had since the last meeting? Share your successes!

2️⃣.2️⃣ Thanks - a space for callouts to other contributors who’ve helped you

2️⃣.3️⃣ Blockers - what’s getting in the way of your issues / goals

2️⃣.4️⃣ :loudspeaker: If you helped with the triage since the last meeting then don't forget to post a comment to triage issue on d.o.

2️⃣.5️⃣ Approve last fortnight's minutes

3️⃣ Core bug statistics - current state of open bugs

4️⃣ Lets check back on our targets and set some new ones

5️⃣ Help me - Is there anything you could use a :hand:

6️⃣ Let's look back at progress closing PMNMI issues that we are now eligible

7️⃣ Would it make sense to have an issue of the day, say 12 hours after the current one to suit more timezones via quietone

Participants:

quietone, larowlan, darvanen, ambermatz, Kristen Pol, lendude, Tinto, dipakmdhrm, dww

Introduction

The Bug Smash Initiative is a community effort to fix known bugs in Drupal core. See the Bug Smash Initiative handbook page for more information.

We meet fortnightly on Tuesday at 0400 UTC in the #bugsmash channel in Drupal Slack. Beware, this might be Monday evening for some people:

• 2:00 pm Tuesday - Australian Eastern Standard Time (AEST)
• 9:30 am Tuesday - India Standard Time (IST)
• 6:00 am Tuesday - Central European Standard Time (CET)
• 9:00 pm Monday - Pacific Daylight Time (PDT)
• When in doubt, ask the oracle.

All meetings are posted as child issues.

Please do not comment on this issueexcept to add a new child issue for an upcoming meeting and change the title here. Thanks!

Next meeting

The next meeting is on Tuesday 2022-06-21
#3284765: Meeting of the Bug Smash Initiative 2022-06-21

Past meetings

Please see the "Child issues" block in the right sidebar or at the bottom of this page for links to past meetings.

Follow-up to #2855675: Add orderby key to all sequences in core

Problem/Motivation

Sequences that are not sorted can result in unexpected configuration differences whilst importing configuration. Which confuses users because they are being told something is different when it is not. Also this behaviour can result in random test fails

Third party settings are ordered by the order in which the third party settings are added. This means that the same configuration can be different on depending on the order in which it is was configured.

Proposed resolution

Add orderby key and test it.

Remaining tasks

User interface changes

None

API changes

None.

Data model changes

All sequences in configuration sorted. This patch will introduce the generic upgrade path for all #2855675: Add orderby key to all sequences in core sub-issues.

Problem/Motivation

If CKEditor 5 is selected as text editor for the Basic HTML format then the "Language" button is added automatically to the toolbar. This is also the case, if the text editor is switched from a CKEditor configuration where the Language button is disabled.

For the other default text formats (Full and Restricted HTML), the "Language" button is not automatically added.

The "Language" button has very limited use in a Drupal site because content languages are organized through the Core modules, and the user experience can be really confusing if HTML markup for languages can also be added within a field. Therefore enabling the "Language" button should be a conscious choice of a site builder, not the default option. Enabling it just to support the <span> tag is not appropriate and should therefore be considered a regression.

Steps to reproduce

• Enable the CKEditor 5 module
• Go to the configuration of Basic HTML at /admin/config/content/formats/manage/basic_html
• Change the text editor from "CKEditor" to "CKEditor 5"

(Also see GIFs in User interface changes.)

Proposed resolution

Do not add the "Language" button to the default CKEditor 5 toolbar configuration for Basic HTML to support <span>.

How? See #5.

Remaining tasks

None.

User interface changes

Switching from CKEditor 4 to CKEditor 5 when <span> was supported in the text format but not the "Language" plugin

Before

After

Enabling a plugin which only is able to add attributes to a tag but not create the tag

Now when you try to enable the Language plugin when <span> is not yet supported, you will get a warning:

And it disappears/never appears if <span>is supported:

API changes

CKEditor 5 plugin metadata now needs to explicitly list tags it can create, by listing it under drupal.elements as just <tag>, in addition to listing it as <tag attrA attrB>.

Data model changes

None.

Release notes snippet

The drupal.elements metadata in CKEditor 5 plugin definitions must now explicitly list which tags are creatable. Previously, any listed tag was assumed to be creatable by the CKEditor 5 module, even if it was only able to create attributes on an already existing tag.

Problem/Motivation

When you have a problem in some early bootstrap/installer process you even end up with errors in the Logger, which triggers the authentication

Proposed resolution

Check first, whether the user is already set. In case its not, don't manually load them.

Remaining tasks

User interface changes

API changes

I am trying to add a relationship "file usage" to a view. I click the submit button, but the relationship never gets added and UI never closed. I can add other relationships as expected.

To replicate (with "standard" profile):

1. Create a new view listing node content (no displays need to be added).
2. Don't touch the base view config in any way (the default "title" field will be the only field, etc.)
3. Add a File Usage "File" relationship via the UI

After these steps the relationship config dialog reports "The handler for this item is broken or missing" and no config form is displayed. The relationship can then be saved on the view (without configuration) but cannot be used.

Immediately upon adding the relationship an error similar to the following is printed in the views UI:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'fid' in 'field list': SELECT node_field_data.created AS node_field_data_created, node_field_data.nid AS nid, fid AS fid FROM {node_field_data} node_field_data WHERE (( (node_field_data.status = :db_condition_placeholder_0) )) ORDER BY node_field_data_created DESC LIMIT 10 OFFSET 0; Array ( [:db_condition_placeholder_0] => 1 )

And a barrage of notices are logged, containing and/or repeating:

Notice: Undefined index: id in Drupal\views\Plugin\ViewsHandlerManager->getHandler() (line 109 of /var/www/drupal-8/core/modules/views/src/Plugin/ViewsHandlerManager.php).
Notice: Undefined variable: items in Drupal\views\Plugin\views\relationship\Broken->buildOptionsForm() (line 79 of /var/www/drupal-8/core/modules/views/src/Plugin/views/BrokenHandlerTrait.php).
Notice: Undefined index: original_configuration in Drupal\views\Plugin\views\relationship\Broken->buildOptionsForm() (line 61 of /var/www/drupal-8/core/modules/views/src/Plugin/views/BrokenHandlerTrait.php).

Problem/Motivation

During the Drupal 9 development process, we've discovered that setting platform requirements (PHP version, supported databases, etc.) is best done early during the major branch development process. Setting these to "obvious" minima as soon as possible and then increasing them more afterward was also valuable.

Proposed resolution

• Continue adding PHP dev environments annually as soon as PHP alphas become available, and stable environments as soon as stable releases are available.
• Ensure that testing environments are available for the latest database versions before 10.0.x is opened.
• Require at least PHP 8.0 as soon as 10.0.x is opened. See #3173787: [policy] Require PHP 8.1 for Drupal 10.0 if a dependency does, otherwise require PHP 8.0. (up from 7.3 in Drupal 9).
• Determine similar obvious minima for supported databases based on support cycles, distro support, and hosting provider support as of when 10.0.x will be opened.
• Further increase the requirements as feasible.
• Set a deadline 1-2 months ahead of the initial 10.0.0-beta1 target deadline for finalizing platform requirement policies. (The final implementations can still be beta blockers.)

Remaining tasks