Problem/Motivation

PrivateFileOnTranslatedEntityTest uses form submissions to change language settings.

This is expensive, and not what the test is covering.

Steps to reproduce

Proposed resolution

Change to API calls.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

I am trying to embed private videos and display them in nodes using CKEditor5 in Core. (Running version 10.1.6 currently.) But more recent uploads do not display. I tracked the issue down to "include file in display" box showing checked (i.e. yes, display) but internally being set to NULL in the DB. See forum post https://www.drupal.org/forum/support/post-installation/2024-01-17/embedd...

Steps to reproduce

1. Add a new Blog Post type node.
2. Insert a private video using the "Insert media" widget.
3. Save the node.

On my site, the video does not display. The video is uploaded properly and the embed code looks fine but the video doesn't display. (See the forum post for more details.)

The video's media page at /media/86/edit shows the "include file in display" box is checked but the DB shows the "display" flag as NULL instead of 1 as the older uploads show.

mysql> select * from media__field_media_video_file_1;
+---------------+---------+-----------+-------------+----------+-------+------------------------------------+----------------------------------+--------------------------------------+
| bundle        | deleted | entity_id | revision_id | langcode | delta | field_media_video_file_1_target_id | field_media_video_file_1_display | field_media_video_file_1_description |
+---------------+---------+-----------+-------------+----------+-------+------------------------------------+----------------------------------+--------------------------------------+
| private_video |       0 |        66 |          66 | en       |     0 |                                143 |                                1 |                                      |
| private_video |       0 |        69 |          69 | en       |     0 |                                146 |                                1 |                                      |
| private_video |       0 |        72 |          72 | en       |     0 |                                149 |                                1 |                                      |
| private_video |       0 |        73 |          73 | en       |     0 |                                150 |                                1 |                                      |
| private_video |       0 |        76 |          76 | en       |     0 |                                153 |                                1 |                                      |
| private_video |       0 |        79 |          79 | en       |     0 |                                156 |                             NULL | NULL                                 |
| private_video |       0 |        80 |          80 | en       |     0 |                                157 |                             NULL | NULL                                 |
| private_video |       0 |        82 |          82 | en       |     0 |                                159 |                             NULL | NULL                                 |
+---------------+---------+-----------+-------------+----------+-------+------------------------------------+----------------------------------+--------------------------------------+
8 rows in set (0.01 sec)

So I tried the resolution below.

I also don't see the recently uploaded media in the DB table. Idk if that is just buffered somewhere and will eventually sync, or if it is another problem. (The latest video upload is number 86, which is not in the table at all.) It's there now.

Proposed resolution

I found that if I go to the specific video's media page at /media/86/edit and first UNcheck the "include file in display" box and save it, then CHECK it again and save it, then the video appears.

This is happening with all my new uploads though. My config is set to display and the "include file in display" checkbox is checked as it should be, but it is misleading b/c it isn't the actual state for my newly uploaded videos. (i.e. they don't display)

Resolution would be to fix the problem of the misleading checkbox. It should really be set to display (1) when the box is checked.

Merge request link

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

As mentioned in the parent issue #3238306: [META] Where possible, refactor existing jQuery uses to vanillaJS to reduce jQuery footprint, we are working towards reducing our jQuery footprint. One of the ways to accomplish this is to reduce the number of jQuery features used in Drupal core. We have added eslint rules that identify specific features and fail tests when those features are in use.

There are (or will be) individual issues for each jQuery-use eslint rule. This one is specific to jquery/no-parents, which targets the jQuery parents function.

Steps to reproduce

Proposed resolution

Remaining tasks

• In core/.eslintrc.jquery.json Change "jquery/no-parents": 0, to "jquery/no-parents": 2, to enable eslint checks for uses of jQuery parent(). With this change, you'll be able to see uses of the undesirable jQuery feature by running yarn lint:core-js-passing from the core directory
• Add the following lines to core/scripts/dev/commit-code-check.sh so the DrupalCI testing script can catch this jQuery usage on all files, not just those which have changed
  

  # @todo Remove the next chunk of lines before committing. This script only lints
  #  JavaScript files that have changed, so we add this to check all files for
  #  jQuery-specific lint errors.
  cd "$TOP_LEVEL/core"
  node ./node_modules/eslint/bin/eslint.js --quiet --config=.eslintrc.passing.json .
  
  CORRECTJQS=$?
  if [ "$CORRECTJQS" -ne "0" ]; then
    # No need to write any output the node command will do this for us.
    printf "${red}FAILURE ${reset}: unsupported jQuery usage. See errors above."
    STATUS=1
    FINAL_STATUS=1
  fi
  cd $TOP_LEVEL
  # @todo end lines to remove

  Add the block about 10 lines before the end of the file, just before if [[ "$FINAL_STATUS" == "1" ]] && [[ "$DRUPALCI" == "1" ]]; then, then remove it once all the jQuery uses have been refactored.

• If it's determined to be feasible, refactor those uses of jQuery parents() to use Vanilla (native) JavaScript instead.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

AVIF image file format is getting traction in browsers' support.

Write up with examples https://jakearchibald.com/2020/avif-has-landed/

This issue is proposing to implement support to this image format in Drupal core's GD Toolkit.

Done:

• libgd should support the AVIF format - DONE, first release supporting is 2.3.2, released on: March 6, 2021
• a PHP version supporting an IMAGETYPE_AVIF constant - upstream PR https://github.com/php/php-src/pull/5127 - supported with PHP 8.1
• a DrupalCI testbot container should be available for testing.
• #3239935: Refactor ToolkitGdTest
• a bot with a PHP 8.1. instance compiled with libavif support
• a PHP 8.2 bot to test getimagesize() on AVIF
• #3116611: Add a requirements check for GD support of allowed image types
• Bots having PHP instances that can fully support AVIF files - currently the bots' PHP, 8.1 and 8.2, cannot save files via imageavif(), the (bundled?) GD library is missing an appropriate codec supporting the write. (Also see https://bugs.php.net/bug.php?id=81217 , https://github.com/php/php-src/pull/7526 )

Proposed resolution

Extend the GD toolkit to support AVIF too.

Remaining tasks

Figure out what to do about the fact that AVIF has to be compiled into PHP and that automatic detection is hard.

https://github.com/libgd/libgd/issues/782

https://github.com/php/php-src/pull/7526

User interface changes

new conversion format available for image effect "convert"

API changes

no

Data model changes

no

Release notes snippet

GDToolkit now supports the AVIF image format.

Problem/Motivation

The Tour module is used in tests.

Steps to reproduce

$ grep --exclude-dir={vendor,node_modules,tour,themes,toolbar} -riw tour core | grep -i test
core/profiles/testing_multilingual/testing_multilingual.info.yml:  - tour
core/modules/help/tests/fixtures/update/drupal-10.access-help-pages.yml:    - tour
core/modules/help/tests/fixtures/update/drupal-10.access-help-pages.yml:  - 'access tour'
core/modules/config/tests/config_test/config/optional/config_test.dynamic.override_unmet.yml:    - tour
core/modules/system/tests/src/Functional/UpdateSystem/UpdatePathTestBaseFilledTest.php:      'tour',

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Drupal should use modern PHP attributes for route discovery ala Symfony.

This will allow us to add an attribute to a method name and use that for routing information. For example:

  /**
   * The default 401 content.
   *
   * @return array
   *   A render array containing the message to display for 401 pages.
   */
  #[Route(
    path: '/system/401',
    name: 'system.401',
    requirements: ['_access' => 'TRUE'],
    defaults: ['_title' => 'Unauthorized']
  )]
  public function on401() {
    return [
      '#markup' => $this->t('Please log in to access this page.'),
    ];
  }

will replace the following entry in system.routing.yml

system.401:
  path: '/system/401'
  defaults:
    _controller: '\Drupal\system\Controller\Http4xxController:on401'
    _title: 'Unauthorized'
  requirements:
    _access: 'TRUE'

What are the advantages of doing this?

• The defaults._controller value is determined by the method you add the attribute to
• The route definition and the controller code live side by side
• No longer need route names - these can be automatically provided based on the class and method name
• Less difference between modern Symfony and Drupal

What are the disadvantages?

• The routing.yml file can give a good overview of what a module does and makes reviewing route access a bit simpler

Mitigations of the disadvantages:

• Currently the code is scanning all the classes in a module's src/Controllers directory for attributed methods - therefore it's not that difficult to scan this code and you benefit from the controller and route definition being together.
• We should and can build CLI tools to expose all the routes provided by a module. This would be good not just for routes determined by attributes but also dynamic routes

Proposed resolution

• Remove yaml discovery from the RouteBuilder into it's own service
• Add a new static routing event for the yaml discovery to listen to
• Add a new service for PHP attribute discovery and listen to the same event. This reflects on all classes in a module's src/Controllers directory to find routes

Remaining tasks

• Add more test coverage
• Decide which of the Symfony route features to keep in - env, localized_paths, priority, _locale, _canonical_route stuff... not sure what to do with this.

User interface changes

None

API changes

TBD

Data model changes

None

Release notes snippet

@todo

Problem/Motivation

Layout Builder introduces a new paradigm shift in page building and block placement for content entities without introducing a block visibility mechanism.

Proposed resolution

Provide a mechanism for configuring each block/component of a layout region to have conditional visibility using core's visibility plugins similar to existing blocks.

Remaining tasks

Finalize patch

User interface changes

- New "Configure Visibility" link on LB component links.
- New configuration forms for managing visibility within Layout Builder.

API changes

Visibility is added into the existing configuration schema and functionality is built into the event system so no API changes are needed.

Data model changes

See API changes.

Problem/Motivation

As discovered by mglaman/phpstan-drupal 1.2.0 (see #3383279: Bump mglaman/phpstan-drupal to latest to make daily "updated deps" QA run pass again), we are using some deprecated functionality throughout Drupal core.

This issue is for dealing with code calling deprecated "things" in classes used for testing that don't extend \PHPUnit\Framework\TestCase.

Until now this code wasn't throwing any deprecation warnings, but after #3383279: Bump mglaman/phpstan-drupal to latest to make daily "updated deps" QA run pass again landed, they do.

So far, this issue has identified and tries to fix the following PHPStan failures:

 ------ -------------------------------------------------------------------------------------------------------------------------------------------------------------
  Line   ExternalCommandRequirementTest.php
 ------ -------------------------------------------------------------------------------------------------------------------------------------------------------------
  136    Usage of deprecated trait Drupal\BuildTests\Framework\ExternalCommandRequirementsTrait in class Drupal\BuildTests\Framework\Tests\UsesCommandRequirements:
         in drupal:10.2.0 and is removed from drupal:11.0.0. Use
         Drupal\\TestTools\\Extension\\RequiresComposerTrait instead.
  149    Usage of deprecated trait Drupal\BuildTests\Framework\ExternalCommandRequirementsTrait in class Drupal\BuildTests\Framework\Tests\ClassRequiresAvailable:
         in drupal:10.2.0 and is removed from drupal:11.0.0. Use
         Drupal\\TestTools\\Extension\\RequiresComposerTrait instead.
  162    Usage of deprecated trait Drupal\BuildTests\Framework\ExternalCommandRequirementsTrait in class Drupal\BuildTests\Framework\Tests\ClassRequiresUnavailable:
         in drupal:10.2.0 and is removed from drupal:11.0.0. Use
         Drupal\\TestTools\\Extension\\RequiresComposerTrait instead.
  168    Usage of deprecated trait Drupal\BuildTests\Framework\ExternalCommandRequirementsTrait in class Drupal\BuildTests\Framework\Tests\MethodRequires:
         in drupal:10.2.0 and is removed from drupal:11.0.0. Use
         Drupal\\TestTools\\Extension\\RequiresComposerTrait instead.
 ------ -------------------------------------------------------------------------------------------------------------------------------------------------------------

 ------ --------------------------------------------------------------------------------- 
  Line   core/modules/system/tests/modules/deprecation_test/src/DeprecatedController.php  
 ------ --------------------------------------------------------------------------------- 
  18     Call to deprecated function deprecation_test_function():                         
         in drupal:8.4.0 and is removed from drupal:9.0.0. This is                        
           the deprecation message for deprecated_test_function().                        
 ------ --------------------------------------------------------------------------------- 

Steps to reproduce

Proposed resolution

Add @group legacy to the code, which makes mglaman/phpstan-drupal aware this is using deprecated code and won't emit a deprecation warning.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

As mentioned in the parent issue #3238306: [META] Where possible, refactor existing jQuery uses to vanillaJS to reduce jQuery footprint, we are working towards reducing our jQuery footprint. One of the ways to accomplish this is to reduce the number of jQuery features used in Drupal core. We have added eslint rules that identify specific features and fail tests when those features are in use.

There are (or will be) individual issues for each jQuery-use eslint rule. This one is specific to jquery/no-each, which targets the jQuery each function.

Steps to reproduce

Proposed resolution

Remaining tasks

• In core/.eslintrc.jquery.json Change "jquery/no-each": 0, to "jquery/no-each": 2, to enable eslint checks for uses of jQuery .each(). With this change, you'll be able to see uses of the undesirable jQuery feature by running yarn lint:core-js-passing from the core directory
• Add the following lines to core/scripts/dev/commit-code-check.sh so the DrupalCI testing script can catch this jQuery usage on all files, not just those which have changed
  

  # @todo Remove the next chunk of lines before committing. This script only lints
  #  JavaScript files that have changed, so we add this to check all files for
  #  jQuery-specific lint errors.
  cd "$TOP_LEVEL/core"
  node ./node_modules/eslint/bin/eslint.js --quiet --config=.eslintrc.passing.json .
  
  CORRECTJQS=$?
  if [ "$CORRECTJQS" -ne "0" ]; then
    # No need to write any output the node command will do this for us.
    printf "${red}FAILURE ${reset}: unsupported jQuery usage. See errors above."
    STATUS=1
    FINAL_STATUS=1
  fi
  cd $TOP_LEVEL
  # @todo end lines to remove

  Add the block about 10 lines before the end of the file, just before if [[ "$FINAL_STATUS" == "1" ]] && [[ "$DRUPALCI" == "1" ]]; then, then remove it once all the jQuery uses have been refactored.

• If it's determined to be feasible, refactor those uses of jQuery .each() to use Vanilla (native) JavaScript instead.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

If a column in a view has the option "Add default classes" turned off, then its header and data cells get the same classes as the prior column. This can lead to more than one column seeming to be "active" for sorting, and other possible problems with incorrect classes being applied.

Steps to reproduce

Install the attached view. In the views UI, note that the first field (Title) has "Add default classes" turned on, whereas the second field (Authored On) has it turned off. This results in the Authored On field getting the is-active class when it should not.

Proposed resolution

The bug occurs twice in the views-view-table.html.twig that is part of every theme. The first time is:

<tr>
        {% for key, column in header %}
          {% if column.default_classes %}
            {%
              set column_classes = [
                'views-field',
                'views-field-' ~ fields[key],
              ]
            %}
          {% endif %}

Because column_classes is not reset when column.default_classes (the "Add default classes" option) is turned off, the list of classes is reused from the previous column. The solution is simply to add a line:

<tr>
        {% for key, column in header %}
          {% set column_classes = [] %} {# ADDED THIS LINE #}
          {% if column.default_classes %}

A similar fix must be made further down in the template, where the data cells are generated. The attached patch addresses this problem for all of the themes in core, as well as the default template in Views itself.

It's worth noting that any custom themes that include a version of this template, such as the contrib version of Classy, also need this fix.

Problem/Motivation

Enabling aggregation can cause SQL errors. This happens when a fields that has multiple columns (like an image field) has been added to to the View. Views currently sets no default column for such fields and it has no fall back or catch for fields that have no group_column set.

Reproduction Instructions

(From #8)

1. Create new view for article or basic page
2. Add fields title, body and image
3. Enable views aggregation

Proposed resolution

Fix the field query so that this problem does not occur by adding better settings of defaults and adding a fall back for empty values.

Remaining tasks

• Write patch to fix the error
• Manual testing of patch
• Write automated test(s)
• Manual review of code

User interface changes

No UI changes.

API changes

No API changes.

Data model changes

No data model changes.

Original Bug Report

Created a view using content of type officers. Using taxonomy to designate a position for each officer. That field is set to unlimited.

The content title field is being used for the officer name, and there is a link field, which provides a link to each officer's contact form, each of which were created under Structure > Contact Form.

The Contact form link field is hidden in the view, and the title field is rewritten so that it displays the officer's name with a link to the contact form.

One officer has two positions, so I added the two positions to that particular officer's content item. The entry for the officer with two positions appeared twice in the view, so I turned aggregation to 'on,' which I understand it the tool to handle these types of situations.

I received the following error:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'node__field_officer_contact_form.field_officer_contact_form_' in 'field list': SELECT node__field_officer_contact_form.field_officer_contact_form_ AS node__field_officer_contact_form_field_officer_contact_form_, node_field_data.title AS node_field_data_title, node__field_officer_position.field_officer_position_target_id AS node__field_officer_position_field_officer_position_target_i, taxonomy_term_field_data_node__field_officer_position.weight AS taxonomy_term_field_data_node__field_officer_position_weight, MIN(node_field_data.nid) AS nid, MIN(taxonomy_term_field_data_node__field_officer_position.tid) AS taxonomy_term_field_data_node__field_officer_position_tid FROM {node_field_data} node_field_data LEFT JOIN {node__field_officer_position} node__field_officer_position ON node_field_data.nid = node__field_officer_position.entity_id AND (node__field_officer_position.deleted = :views_join_condition_0 AND node__field_officer_position.langcode = node_field_data.langcode) INNER JOIN {taxonomy_term_field_data} taxonomy_term_field_data_node__field_officer_position ON node__field_officer_position.field_officer_position_target_id = taxonomy_term_field_data_node__field_officer_position.tid LEFT JOIN {node__field_officer_contact_form} node__field_officer_contact_form ON node_field_data.nid = node__field_officer_contact_form.entity_id AND (node__field_officer_contact_form.deleted = :views_join_condition_2 AND node__field_officer_contact_form.langcode = node_field_data.langcode) WHERE (( (node_field_data.status = :db_condition_placeholder_4) AND (node_field_data.type IN (:db_condition_placeholder_5)) )) GROUP BY node__field_officer_contact_form_field_officer_contact_form_, node_field_data_title, node__field_officer_position_field_officer_position_target_i, taxonomy_term_field_data_node__field_officer_position_weight ORDER BY taxonomy_term_field_data_node__field_officer_position_weight ASC; Array ( [:db_condition_placeholder_4] => 1 [:db_condition_placeholder_5] => officer [:views_join_condition_0] => 0 [:views_join_condition_2] => 0 )

and of course, the view will not display.

I can't take a close look at this now, but I thought I'd report it to the community. in case anyone else has encountered it. I will parse through the error message later to see if I can figure out what is going on.

Problem/Motivation

In #3414627: Convert StreamWrapperManager to use a service locator we modified StreamWrapperManager.

In install_begin_request() we define a minimal container to bootstrap the install system, including:

  $container
    ->register('stream_wrapper_manager', 'Drupal\Core\StreamWrapper\StreamWrapperManager')
    ->addMethodCall('setContainer', [new Reference('service_container')]);

However, the setContainer method has been removed and the service locator (container) should be passed as an argument.

Question: why doesn't this fail?

Steps to reproduce

Proposed resolution

Merge request link

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

This is part of the CSS modernization initiative.

Currently consolidating several into 1

Steps to reproduce

NA

Proposed resolution

Remove @nest from claro stylesheets

Remaining tasks

User interface changes

NA - nothing should change

API changes

NA

Data model changes

NA

Release notes snippet

NA

Problem/Motivation

DisplayFeedTranslationTest uses form submissions to change language settings.

This is expensive, and not what the test is covering.

Steps to reproduce

Proposed resolution

Change to API calls.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

I haven't found a practical example in the Drupal Core, but support for union and intersection types in autowiring will be useful in some cases.

Example:

public function __construct(
    protected FooClass|BarClass $service,
) {}

public function __construct(
    protected FooClass&BarClass $service,
) {}

We will receive an AutowiringFailedException even if the services exist.

Problem/Motivation

This is the complete message at time tu run cron.

Warning: Trying to access array offset on value of type null in web/core/lib/Drupal/Core/Cron.php line 264

looks like the code $worker->getPluginDefinition() returns null

Steps to reproduce:

Drupal core:
Drupal version: 10.1.5

Run drupal cron by behat testing:
Behat uses drupal/drupal-extension version v5.0.0alpha1 project to run core/lib/Drupal/Core/Cron.php::processQueue

Problem/Motivation

There's no menu specific identifier in the menu blocks and for that reason theming menu blocks might be hard.
Note: This is the tools menu.

<div class="block block-system block-menu" id="block-atdknkh9" role="navigation">
  
      <h2>mR0u20MI</h2>
    

  <div class="content">
          <ul class="menu">
    <li class="leaf"><a href="/test_page_display_menu_link" data-drupal-link-system-path="test_page_display_menu_link">New title</a></li>

  </ul>
      </div>
</div>

Proposed resolution

Discuss wheter we should have a menu specific class on menu blocks or not.

Remaining tasks

User interface changes

API changes

Summary

When adding an empty extra field in Layout Builder, the resulting page will always render the wrapping div of ExtraFieldBlock even when the extra field has empty content.

Steps to reproduce

1. Add an extra field on a node using hook_entity_extra_field_info().
2. Add the hook_ENTITY_TYPE_view() for the extra field, but don't add anything to the $build array.
3. Create a node type with Layout Builder enabled on Full Content.
4. Add that field into the type's layout.
5. Create a page of that node type.
6. View the page.

Expected

On Step 6, the field should not render at all.

Actual

On Step 6, an empty div of that extra field will be on the page.

Details

ExtraFieldBlock.php's build() method will always return a placeholder render array if an extra field is present. While BlockComponentRenderArray.php's onBuildRender() methods attempts to screen out empty blocks, the extra field block will always pass because of the placeholder. This causes it to add the block for rendering ($build = ['#theme' => 'block', ...). When time comes to render the contents, since core/lib/Drupal/Core/Render/Renderer.php's doRender() method will always render arrays with a #theme present, it renders the wrapper div, even when it contains no content.

When rendering the page without using Layout Builder, the extra field just doesn't exist in the render array and no wrapper div is rendered.

Unsure whether this is expected behavior or not for Layout Builder. But I do expect that it would behave similar to how it did without using Layout Builder.

References:

• https://github.com/drupal/drupal/blob/9.0.0/core/modules/layout_builder/...
• https://github.com/drupal/drupal/blob/9.0.0/core/modules/layout_builder/...
• https://github.com/drupal/drupal/blob/9.0.0/core/lib/Drupal/Core/Render/...

Problem/Motivation

The creation of dynamic properties is deprecated in PHP 8.2

Steps to reproduce

Ran into this error when using a TableField field on a fresh install of Drupal 10.0

Deprecated function: Creation of dynamic property Drupal\tablefield\Plugin\Field\FieldFormatter\TablefieldFormatter::$ModuleHandler is deprecated in Drupal\tablefield\Plugin\Field\FieldFormatter\TablefieldFormatter->__construct() (line 57 of modules/contrib/tablefield/src/Plugin/Field/FieldFormatter/TablefieldFormatter.php).

Proposed resolution

Add the property in TypedData.php

Remaining tasks

Needs review

If you create a taxonomy and then a user who can only edit the terms of the taxonomy and use the admin toolbar, the link to edit the taxonomy is not shown anywhere. The user can edit the taxonomy, so far the rights work, but under drupal 7 the structure link in the toolbar was shown and inside the taxonomy links where shown. The taxonomy could be reached by the toolbar, this is not the case in d8.