Problem/Motivation

The 'Edit' link for custom menu links does not contain the language prefix of the current language, so it always takes you to the edit page in the default language.

Steps to reproduce

1. Install Drupal
2. Enable Language and Configuration translation
3. Create a node and add a link to the main menu
4. Switch to another language and go to the main menu admin page (e.g. /fr/admin/structure/menu)
5. See that the 'Edit' button for the default home link points to /fr/admin/structure/menu/link/standard.front_page/edit
6. See that the 'Edit' button for the custom link points to /admin/structure/menu/item/1/edit

Expected result would be the edit link points to /fr/admin/structure/menu/item/1/edit to reflect the current language.

Proposed resolution

Ensure that the menu edit links for custom menu items use the current language prefix.

Remaining tasks

1. Write patch
2. Review

User interface changes

Update the menu edit links to add the current language prefix.

Problem/Motivation

In \Drupal\Core\Test\TestRunnerKernel::boot() we create a folder in the main sites public files directory. This is bad for two reasons:

• Potentially this could end up on a live site
• Potentially this can cause random fails when running concurrent tests - see #3175112: hold_test module creates files in incorrect place leading to possible random errors

Proposed resolution

Proceed with #3175112: hold_test module creates files in incorrect place leading to possible random errors as that can cause a random fail.
Remove usage in \Drupal\Tests\file\Functional\MultipleFileUploadTest::testMultipleFileFieldWithAllFileExtensions() here
Add check to TestRunnerKernel destruction that the directory it creates is empty and if not issue a deprecation notice
Test the added deprecation

Remaining tasks

User interface changes

None

API changes

Deprecate the global test artefact directory

Data model changes

None

Release notes snippet

@todo

FILE: /var/www/html/core/modules/toolbar/tests/src/Functional/ToolbarAdminMenuTest.php
------------------------------------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 16 WARNINGS AFFECTING 16 LINES
------------------------------------------------------------------------------------------------------------------------------------------
 120 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
 122 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
 132 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
 150 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
 171 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
 201 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
 202 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
 242 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
 243 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
 285 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
 286 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
 290 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
 312 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
 313 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
 323 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
 324 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
------------------------------------------------------------------------------------------------------------------------------------------


FILE: /var/www/html/core/modules/toolbar/tests/src/Functional/ToolbarMenuTranslationTest.php
-----------------------------------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 4 WARNINGS AFFECTING 4 LINES
-----------------------------------------------------------------------------------------------------------------------------------------
 59 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
 73 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
 88 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
 96 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
-----------------------------------------------------------------------------------------------------------------------------------------

Problem/Motivation

From #2630230-61: Image effect convert fails when image file is in the public files root:

We need a follow-up to fix StreamWrapperManagerInterface $stream_wrapper_manager = NULL - that cannot be NULL - we missed this in #3097453: Remove system.module BC layers

Proposed resolution

Make the deprecatied condition dance to the constructor argument.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Make sure Drupal keeps being compatible with PHP 8. Work with dependencies as needed. See #3086374: Make Drupal 8 & 9 compatible with PHP 7.4 for how we did it with PHP 7.4. PHP 8.0 is feature frozen and beta4 is out, see https://www.php.net/archive/2020.php#2020-09-17-1

Proposed resolution

The following task list has been determined by testing on #3156595: Make Drupal 9 installable on PHP8.

1. Dependency updates to support PHP 8

To produce a list of dependencies that are blocking PHP 8 support, you can do the following:

$ composer create-project drupal/recommended-project:9.1.x whynotphp8
$ cd whynotphp8
$ composer why-not php:8

Additionally to the composer reported dependencies above:

• behat/mink-selenium2-driver - https://github.com/minkphp/MinkSelenium2Driver/pull/320

2. Drupal issues that can be addressed in Drupal 8 & 9 today

These issues can proceed without worrying about the how and if vendor support works for PHP 8 since the changes are all PHP 7 compatible. We can keep the changes PHP 7.0 compatible to make things easy for Drupal 8.

• #3156542: \ReflectionParamter::getClass() is deprecated in PHP 8.0
• #3156881: Various methods of \Drupal\Core\Database\StatementInterface have changed their signature for PHP 8
• #3174022: call_user_func_array() and named arguments in PHP 8

3. Drupal issues that need a largely working PHP 8 build to test

• #3156887: \Drupal\system\Plugin\ImageToolkit\GDToolkit needs to support \GdImage objects for PHP 8 compatibility
  
  Should be okay for PHP 7.0 because it's really only loosening what we expect in \Drupal\system\Plugin\ImageToolkit\GDToolkit::$resource but testing this will be harder without all the above fixes and the fixes to vendor.

DONE

• In/with dependencies:
  • symfony/*, twig/twig, composer/* #3156558: Upgrade dependencies prior to 9.1.0 and #3157296: Upgrade dependencies prior to 9.1.0
  • Update symfony contract php requirement - https://github.com/symfony/symfony/pull/37494
  • phpspec/prophecy - https://github.com/phpspec/prophecy/pull/470
  • phpdocumentor/reflection-docblock - https://github.com/phpDocumentor/ReflectionDocBlock/pull/240
• Within Drupal itself:
  • #3156944: Support nullable typehints and return types in ProxyBuilder and as a result support PHP 8
  • #3156878: \Drupal\Component\Datetime\DateTimePlus should pass correct parameter types to checkdate()
  • #3156885: Change \Drupal\error_test\Controller\ErrorTestController::generateWarnings() to throw E_NOTICE error compatible with PHP 8
  • #3156879: \Drupal\Component\Utility\Bytes::toInt() - ensure $size is a number type
  • #3156882: \Drupal\Core\Render\Element\StatusReport::preRenderGroupRequirements() and \Drupal\user\PermissionHandler::sortPermissions() sorts return bools
  • #3156883: \Drupal\Core\Url ensure fragment is not an empty string
  • #3170648: CKEditorPluginManager::getEnabledButtons throws warnings on PHP 8.0.0 beta3
  • #3173958: PHP 8 error: method_exists(): Argument #1 ($object_or_class) must be of type object|string, null given
  • #3173888: Error handler signature changed in PHP 8
  • #3174038: ZipArchive::open(): Using empty file as ZipArchive is deprecated in PHP 8
  • #3173991: Incorrect passby reference use in anonymous functions
  • #3174158: Division by zero is not warning since PHP 8.0 beta4

Remaining tasks

See above.

User interface changes

None.

API changes

Data model changes

None.

Release notes snippet

Problem/Motivation

The SetInlineBlockDependency event subscriber fails to assign the correct access dependency to inline blocks when creating a pending revision of override section storage.

This creates a conflict between inline blocks, override layouts, paragraphs and content moderation, since the ERR formatter and paragraphs widget creates the following access dependency chain:

1. Paragraphs entity checks host access (view/update).
2. Inline block content checks the host, or "access dependency" for access.
3. Node access should be granted, but the node is assigned to NULL, since the associated revision IDs are checked against the default entity, not the active entity.

Proposed resolution

For the purposes of access dependencies load the 'active' revision from the entity repository for the 'update' and 'delete' operation and load the canonical revision of the entity for all other operations.

Remaining tasks

Agree on an approach and tests.

User interface changes

None.

API changes

Method and constructor signatures only modified on @internal classes.

Data model changes

None.

Release notes snippet

Adding media library field on any entity and making it as required. Create the entity and submit the form without having value in media library field and it will show wrong validation message.

Problem/Motivation

We currently have a token [site:url]. The URL of the site's front page. The language prefix is added if the page is multilingual (e.g. http://www.example.com/pl).

In many cases a language prefix is unnecessary.

Example:

Open graph image path
[site:url]/sites/default/files/og_image.jpg

JSON LD ImageObject path
[site:url]/sites/default/files/logo.jpg

We need a new token that returns the base url without the language prefix.

Proposed resolution

Add token [site:base-url]. Base URL.

Remaining tasks

Add test.

User interface changes

Users can use the new token [site:base-url].

API changes

Data model changes

The kittens you are looking for cannot be found from here.

Problem/Motivation

My concern is to use the ability provided by $settings['file_public_path'] and $settings['file_public_base_url'] to
provide a separate webserver dedicated to serve static files and user content. For security, this web server has
deliberately no PHP support.

To facilitate the debug of this issue, I created a simple docker-project hosted on Github:
https://github.com/mickaelperrin/drupal-issues/tree/2754273-image_styles...

Steps to reproduce using the docker container:

1. Launch the docker container with docker-compose up -d`
2. Go to http://your.docker.machine.ip:8888
3. Authenticate with drupal / drupal
4. Go to http://your.docker.machine.ip:8888/node/add/article
5. Click on the "Add image" button
6. Select a file

Exepected result: The thumbnail of the selected image is properly displayed

Result: The thumbnail show a missing image (error 404)`

Proposed resolution

The problem seems to be related with the `PathProcessor`of the module `image`. It appends at the beggining of the
public setting path a slash wether the path is absolute or relative.

In case of absolute path, two slashs begin the path and the method to detect if the path is public or private fails, and
so on the url processing.

The attached add a simple test to check if a slash is needed or not.

You can test the issue with the path by launching the docker containers with the command: `docker-compose -f docker-compose.yml -f docker-compose.patched.yml up -d`

Remaining tasks

As it is my first patch and I am new to Drupal, a review is obviously needed.

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Original report by [username]

N/A

Problem/Motivation

Currently, core and contrib modules are listed in between each other on the Extend page (/admin/modules), which can be confusing.

Steps to reproduce

Add a few contrib modules, go to /admin/modules and see that core and contrib modules are listed in between each other.

Proposed resolution

Separate core and contrib modules, by first showing the basic core modules, followed by experimental core modules, and then the rest of the core modules, labeling them clearly, for example "Core - Multilingual". Show contrib modules below, under their own "Contrib modules" header.

Current order

New order

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Since symfony/phpunit-bridge 5.1: Using "@expectedDeprecation" annotations in tests is deprecated, use the "ExpectDeprecationTrait::expectDeprecation()" method instead.

Proposed resolution

• use Symfony\Bridge\PhpUnit\ExpectDeprecationTrait in Drupal base (unit, kernel, build, functional) test classes
• change @expectedDeprecation annotations to $this->expectDeprecation() calls

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem

I am stuck with an unfamiliar Composer error message, whilst trying to run composer update on a Drupal installation ( 8.9.6 ). I haven't seen this before and can't seem to find any relevant info on it in the composer documentation.

When running composer update drupal/core-recommended --with-dependencies
I get:

> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies (including require-dev)

                          
  [ErrorException]        
  Undefined index: extra  

and it stops.

Problem/Motivation

Admin paths are defined now in route definitions (see https://www.drupal.org/node/2224207). But in Views UI, the route is build via UI and you'll need to code to mark a view route as admin route. This is very painful.

Use case: As a site moderator, I'm able to use a View, located at /articles/moderate, with VBO to bulk approve/decline articles. I want to access this moderation tool using the admin theme in the same way I'm using the node edit page.

Proposed resolution

Add a new page setting "Always use admin theme" in the page display that allows site builders to make that page an admin one, similar to https://www.drupal.org/project/page_manager.

Remaining tasks

None.

User interface changes

See the screenshots:

API changes

None.

Data model changes

New page display option: always_use_admin_theme

Problem/Motivation

When using a date/time filed as exposed filter using the "offset from the current time" setting, the filter doesn't display as I expected.

The setting for the filter are:

This leads to the filter being displayed like:

As you can see the dates are output in the filter as the relative text string. This can lead to problems if using a date selector dialog.

Proposed resolution

The output I expected is:

This has the dates computed and entered in the input element.

Problem/Motivation

To make core compatible with PHP 8 #3174022: call_user_func_array() and named arguments in PHP 8 arguments passed to trusted callback are limited by array_values() for $args array.
But render callbacks could benefit using https://wiki.php.net/rfc/named_params

Steps to reproduce

See usage of \Drupal\Core\Render\Renderer::doCallback() and \Drupal\Core\Security\DoTrustedCallbackTrait::doTrustedCallback()

Proposed resolution

TBD

Remaining tasks

- discuss and create patch
- remove todo from \Drupal\Core\Security\DoTrustedCallbackTrait::doTrustedCallback()

User interface changes

no

API changes

TBD

Data model changes

no

Release notes snippet

TBD

Problem/Motivation

@mcdruid has been a provisional maintainer of the 7.x branch for approaching a year (commit).

In that time, he's contributed to and overseen 6 releases (7.68 - 7.73) and published and maintained a Roadmap / Release Schedule for D7.

To quote myself (Fabianx):

I'd like mcdruid to be a real committer (no longer provisional) as he does great work and presents patches that are for most cases directly committable and don't need further work. In addition for complex patches he always solicits feedback from me and others.

Therefore I am very happy to propose that mcdruid be made a full core committer.

Proposed resolution

Make @mcdruid a full maintainer of the 7.x branch.

Remaining tasks

Review and commit patch to MAINTAINERS.txt

Problem/Motivation

The Comment settings currently does not display a vertical tab summary:

Proposed resolution

Correct the Drupal JavaScript behavior that renders the vertical tab summary, so the Comment settings is summarized in the vertical tab:

Remaining tasks

1. Write a patch
2. Review
3. Commit

User interface changes

The Comment settings are summarized in the vertical tab.

API changes

None.

Data model changes

None.

Original report by Chi

I guess comment-entity-form.js was not updated when we replaced fieldsets with details.

Problem/Motivation

The order of the media items is messed up when using Media Library widget in a particular use-case (when arranging the media items and after that inserting a new media).

Steps to reproduce:
1. Create a Content Type with an unlimited media reference field.
2. In form display for that field chose the Media library widget.
3. Add new content of that Content Type.
4. In the media field add more than 3 media items.
5. Save the node.
6. Go to the edit page of that node.
7. Re-arrange the media by drag and drop.
8. Press the "Add Media" button.
9. Select a new image to insert and press the "Insert Selected" button.
10. The media items will be ordered correctly but their weights will be messed up. You can look at them by pressing "Show media item weights".
11. Save node.

Expected behavior:
The order of the media should remain the way it was arranged before inserting a new image and the new image should be the last one.

Current behavior:
The media items order is not the way it was arranged.

Proposed resolution

I didn't find what was the cause of this problem but one of the solutions/workarounds will be to get the weights from the $field_state (which are the correct ones) and put them in the $element in the updateWidget memthod.

Remaining tasks

Add tests.

Problem/Motivation

After updating a section in the layout builder page or update a block configuration all views with contextual filter content disappeared.
After debugging the issue I noticed that the layout builder replace the view content in "layout_builder.configure_section" router and the entity doesn't exist.

Steps to reproduce

1- Create a view(block) with contextual filters (Taxonomy term ID from Url)
2- Add the block in layout builder page taxonomy term
3- Edit the layout
4- Update any section or block
5- click update
6- All views with contextual filters content disappeared and replaced with "Placeholder for the "Related content" views block"

Proposed resolution

I think we can add the entity to the router or can change how argument_default works, I don't know still thinking about the best solution.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet