The get_value_options on filters currently not returns the actual available options, but just set the value on the object, which is fine, though the function name implies to return something, so let's do that.

Problem/Motivation

views_ui_truncate() works the same like Unicode::truncate(), but Unicode::truncate() has more features. I think this views_ui_truncate() can be removed.

Steps to reproduce

Proposed resolution

Deprecate views_ui_truncate() and use Unicode::truncate(),

Remaining tasks

Patch
Review
Commit

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Follow-up from #3275557: Add webp image conversion to core's install profile's image style which didn't actually do what the issue summary suggested.

We should add a webp image conversion to all shipped image styles with core install profiles.

Steps to reproduce

NA

Proposed resolution

add a webp image conversion to all shipped image styles

Remaining tasks

Update remaining styles
Review

User interface changes

NA

API changes

NA

Data model changes

NA

Release notes snippet

NA

Problem/Motivation

First requests to the httpKernel will cache request properly but the following requests handled by the same httpKernel instance will return the same response that was cached for the first request.

Proposed resolution

Add check for the comparison of cached cid and current cid in the getCacheId() method of the Drupal\page_cache\StackMiddleware\PageCache class.

Remaining tasks

-

User interface changes

-

API changes

-

Data model changes

-

Release notes snippet

-

Problem/Motivation

As noted in #3412268: Should core-dev include a dependency on composer/composer?, https://github.com/drupal/core-dev is is a subtree split from the core repo.

The code is maintained at https://git.drupalcode.org/project/drupal/-/blob/11.x/composer/Metapacka...

Proposed resolution

1. Create a documentation page
2. Include a README in the core-dev repo

Remaining tasks

Problem/Motivation

The return statement is missing in MenuLinkManager::menuNameInUse , in /core/lib/Drupal/Core/Menu/MenuLinkManager.php

  public function menuNameInUse($menu_name) {
    $this->treeStorage->menuNameInUse($menu_name);
  }

The function menuNameInUse in core/lib/Drupal/Core/Menu/MenuTreeStorage.php will always return true

public function menuNameInUse($menu_name) {
    $query = $this->connection->select($this->table, NULL, $this->options);
    $query->addField($this->table, 'mlid');
    $query->condition('menu_name', $menu_name);
    $query->range(0, 1);
    return (bool) $this->safeExecuteSelect($query);
  }

Proposed resolution

The fix would be just adding 'return'

  public function menuNameInUse($menu_name) {
    return $this->treeStorage->menuNameInUse($menu_name);
  }

Remaining tasks

Waiting for review

API changes

core/lib/Drupal/Core/Menu/MenuLinkManager.php method menuNameInUse will return bool.
core/lib/Drupal/Core/Menu/MenuTreeStorage.php method menuNameInUse will return bool.

Data model changes

NA

Release notes snippet

NA

Problem/Motivation

The SysLog logger service depends on the configuration storage service (which in turn depends on the configuration caching service) and that creates a circular service dependency in some cases when using an alternative backend for caching that itself requires logging.

Steps to reproduce

Examples:

• Memcache module: https://www.drupal.org/project/memcache/issues/2887558
• File Cache module: https://www.drupal.org/project/filecache/issues/3045245

Proposed resolution

Proposed resolution A) Use site settings or container parameters to configure SysLog. This would require sites to update their settings or container parameter files, which could be mitigated by proper upgrade instructions.

Proposed resolution B) Use a ServiceProvider to decouple the SysLog service from config storage. See patch #53

Chosen resolution C) Use lazy services to avoid instantiating config until something is logged. SysLog could use a new lazy config factory as a drop-in replacement for the standard config factory. See patch #62 MR !5925

Any other suggestions?

Remaining tasks

Review the patch.

User interface changes

API changes

A new config.factory.lazy service is introduced, implementing ConfigFactoryInterface, which lazily loads config storage.

Data model changes

Release notes snippet

Problem/Motivation

Currently drupal/core-dev includes composer/composer as a dependency.

As noted on https://github.com/composer/composer/issues/11216#issuecomment-1860525590:

requiring composer is generally not a great idea, and something I discourage unless you have no other choice

So should this dependency be removed?

Or is there a good reason for keeping it?

Problem/Motivation

\Drupal::service('typed_data_manager')->createDataDefinition('entity:user')->getLabel(); helpfully returns the the label of the entity type, in this case user.

\Drupal::service('typed_data_manager')->createDataDefinition('field_item:string')->getLabel(); returns nothing.

It would be helpful if this returned the label of the field type. This can be used when working with configurable contexts to show what type of data a context is.

Steps to reproduce

Run \Drupal::service('typed_data_manager')->createDataDefinition('field_item:string')->getLabel(); get nothing returned

Proposed resolution

Add a getLabel() method to FieldItemDataDefinition that returns the label of the field type plugin.

Remaining tasks

Change record

User interface changes

NA

API changes

core/lib/Drupal/Core/Field/TypedData/FieldItemDataDefinition.php has a new method getLabel().

Data model changes

NA

Release notes snippet

NA

The global view result counter passes itself wrapped in double curly braces when rendered, rather than as an integer value. This patch fixes that by adding a render function in Drupal\views\Plugin\views\field\Counter.php.

So, for example, a drupalist can put a global view counter and a global custom text field in a view, and then to add filters to counter in the text replacement field.

Fields:
Global: View result counter
Global: Custom text

In the custom text field:
{% if counter is even %}
... do something ...
{% endif %}

This was before not possible, as the string "{{ counter }}" was passed to the "even" filter, rather than the value of counter itself.

Problem/Motivation

In some situations the translations directory (where downloaded translation files get stored; e.g. sites/default/files/translations) is missing. This may happen for example in a development process, where a site is re-created on a dev machine from git and a live DB but without populating the files directory (as you use StageFileProxy).

Simplified steps to reproduce in a normally working site (translations directory = sites/default/files/translations)

$ rm -r sites/default/files/translations
$ drush locale-update

Example error messages:

 [notice] File temporary://filejmiMlj could not be moved/copied because the destination directory translations:// is not configured correctly.
 [error]  Unable to download translation file https://ftp.drupal.org/files/translations/8.x/admin_toolbar/admin_toolbar-8.x-1.24.de.po. 
 [warning] fopen(translations://admin_toolbar-8.x-1.24.de.po): failed to open stream: "Drupal\locale\StreamWrapper\TranslationsStream::stream_open" call failed PoStreamReader.php:154
 [warning] fgets() expects parameter 1 to be resource, boolean given PoStreamReader.php:248
 [notice] Unable to import translations file: translations://admin_toolbar-8.x-1.24.de.po

Processes that will profit from a fix:

• Update translation via user interface
• Upload a translation via the Translation import page
• Adding a language

Proposed resolution

• Auto-create the directory if at the start of the batch check/update process.
• Auto-create the directory when importing a translation via the Translation import page.

Remaining tasks

Find other other processes where the translation directory is yet not auto-created.

User interface changes

none

API changes

none

Data model changes

none

Issue summary updated as of comment #35

Problem/Motivation

Checkboxes are not rendered in the Media Library widget/the wrong media item is inserted after selection of a media item in the Media Library widget.

The issue is related to caching and pagination. Each paged record set in the filter builds the checkbox placeholders in PreRenderViewsForm method of the ViewsFormMainForm class from a 0 index resulting in search array looking like this

array:4 [▼
  0 => "<!--form-item-media_library_select_form--0-->"
  1 => "<!--form-item-media_library_select_form--1-->"
  2 => "<!--form-item-media_library_select_form--2-->"
  3 => "<!--form-item-media_library_select_form--3-->"
]

If Media items are returned from the cache having been on a page where the placeholder key is different then the rendered checkbox will return the wrong media item when selected.

If the placeholder key is beyond the range of the current result, then no substitution takes place and no checkbox is rendered. The following values returned for 4 media items result in only one checkbox being rendered (the one with the key of 3).

<!--form-item-media_library_select_form--3-->
<!--form-item-media_library_select_form--4-->
<!--form-item-media_library_select_form--5-->
<!--form-item-media_library_select_form--7-->

No JavaScript errors are observed, and there is nothing in the webserver or PHP logs.

Steps to reproduce

1. Install the core Media and Media Library modules.
2. Add an entity reference field of type Media to a content type.
3. Create a new instance of this content type.
4. Click the Add media button to open the media library modal.
5. Perform a search for a media entity that yields just one result.
6. Perform a different search for a media entity that yields just one result.
7. Or page through search results that return multiple pages.
8. The checkbox to select the media entity does not appear.

Proposed resolution

The buildForm method of the ViewsFormMainForm class looks for 2 methods on the MediaLibrarySelectForm field that don't exist so defaults to building the placeholders from the row index. The methods appear to be legacy code as the methods are snake case?

The getValue method and the viewsForm method on the MediaLibrarySelectForm field both use the ResultRow $row->index value where I think the $row->mid value might be more appropriate.

Adding the following methods to the MediaLibrarySelectForm class and updating the getValue and viewsForm methods to use the entity mid appears to fix the issue.

Add new methods to MediaLibrarySelectForm:

  public function form_element_name(): string {
    return $this->field;
  }

  public function form_element_row_id(int $row_id): string {
    return $this->view->result[$row_id]->mid;
  }

Refactor MediaLibrarySelectForm::getValue to use $row->mid

 public function getValue(ResultRow $row, $field = NULL) {
    return '<!--form-item-' . $this->options['id'] . '--' . $row->mid . '-->';
  }

Refactor MediaLibrarySelectForm::viewsForm to use $row->mid if views field is a media entity

    foreach ($this->view->result as $row_index => $row) {
      $entity = $this->getEntity($row);
      if (!$entity) {
        $form[$this->options['id']][$row_index] = [];
        continue;
      }
      $form[$this->options['id']][$row->mid] = [
        '#type' => 'checkbox',
        '#title' => $this->t('Select @label', [
          '@label' => $entity->label(),
        ]),
        '#title_display' => 'invisible',
        '#return_value' => $entity->id(),
      ];
    }

Remaining tasks

Reviews needed

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

None

Problem/Motivation

When interface translation is installed after language the interface translations are not downloaded.

Steps to reproduce

1. from a fresh Drupal 8.0.0-rc3 standard install, enable "Language"
2. go to admin/config/regional/language and add a new language
3. enable "Interface translation"

Expected behaviour
Translations of the user interface should have been imported.

What happens instead
User interface appears not translated when switching to the given language

Currently available workaround
From there, the following works fine:

1. delete the given language
2. add the given language again (while "Interface Translation is still enabled): then import process happens as expected, and the user interface appears translated (apart from the part currently missing, but this is another point)

Proposed resolution

1. when enabling "Interface Translation", warn that there are translations ready for import, with a link

Remaining tasks

review
commit

User interface changes

API changes

none

Data model changes

none

Release notes snippet

Steps to reproduce

1. create an entity type that includes AJAX calls on the node edit form, e.g. node with a link field and a media field, or a field with multiple elements and "add another" links
2. as a user without the 'link to any page' permission, try to create an instance of that entity
3. enter an invalid path in the link field, e.g. 'foo'
4. click on the button that initiates an AJAX request, e.g. file upload, add another

Expected result

An error message should appear about the invalid internal path, but you should be able to proceed with the action

Actual result

It isn't possible to proceed.
The AJAX call responds with a 500 error "The internal path component is invalid. Its path component must have a leading slash" with field widget type "Link".

↵An AJAX HTTP error occurred.↵HTTP Result Code: 500↵Debugging information follows.↵Path: /fr/node/6/edit?element_parents=field_test/widget/0&destination=/admin/content&ajax_form=1↵StatusText: 500 Service unavailable (with message)↵ResponseText: The website encountered an unexpected error. Please try again later.InvalidArgumentException: The internal path component 'test' is invalid. Its path component must have a leading slash, e.g. internal:/foo.

This error generates from \Drupal\Core\Url::fromInternalUri

It happens from \Drupal\link\Plugin\Field\FieldWidget\LinkWidget::formElement
in code
$item->getUrl()->access() (core/modules/link/src/Plugin/Field/FieldWidget/LinkWidget.php:175)

For avoidance of this error we have next element validator where check input values
\Drupal\link\Plugin\Field\FieldWidget\LinkWidget::validateUriElement

So we can't catch this error on common entity save operation.
But we can catch it with any additional ajax buttons, which skip validation with #limit_validation_errors

It appears on all browsers.

In my example "foo" value is incorrect for Link field. We can avoid this error by putting only correct values. But customer can be confused. He doesn't know what values are correct, and he doesn't know why all his AJAX buttons don't work. So we should avoid 500 error with ajax buttons.

I have investigated this issue and found, that we need to add additional check in \Drupal\link\Plugin\Field\FieldWidget\LinkWidget::formElement
I have prepared patch and I will apply it in comment.

Problem/Motivation

A cancel button is standard on most modals. But it's missing on the media library widget popup.

Steps to reproduce

1. Enable media and media library modules
2. Add a media field to a taxonomy (/admin/structure/taxonomy/manage/tags/overview/fields)
3. Add a term to the vocabulary (/admin/structure/taxonomy/manage/tags/add)
4. Click Add media button
5. See the media library popup, but no cancel button

Proposed resolution

Add a cancel button

User interface changes

Before

After

Problem/Motivation

The persist service tag and its associated functionality has been the source of many nasty issues. The number of persisting services has been reduced by #2190665: Remove persist flag from services that do not need it, #2277481: Remove persist flag from container.namespaces service and #2272987: Do not persist session manager and now only two of them remain (request_stack and router.request_context). Let's remove them now.

Proposed resolution

Remove support for the persist service tag and instead manually set up the request stack after a container rebuild. Also remove support for persisting synthetic services across container rebuilds because this feature is unused since the removal of the request service.

Remaining tasks

Review, commit.

User interface changes

None.

API changes

Removal of the persist service tag.

Beta phase evaluation

Problem/Motivation

In #3094304: Create tests that cover contrib non-full releases and contrib patch versions we realized that \Drupal\Tests\update\Functional\UpdateCoreTest::testNormalUpdateAvailable()
Does have support for the current major and the next both being supported.

\Drupal\Tests\update\Functional\UpdateCoreTest::testMajorUpdateAvailable() in test cases the current major version is not supported.

Proposed resolution

Update \Drupal\Tests\update\Functional\UpdateCoreTest::testNormalUpdateAvailable() with this test coverage.

#3094304: Create tests that cover contrib non-full releases and contrib patch versions has a version for contrib that we can work from

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

n/a

Problem/Motivation

Symfony services can have arrays as arguments. They can converted to \Symfony\Component\DependencyInjection\Argument\IteratorArgument by the ContainerBuilder. They are not supported by \Drupal\Component\DependencyInjection\Dumper\OptimizedPhpArrayDumper::dumpValue().

Proposed resolution

Convert \Symfony\Component\DependencyInjection\Argument\IteratorArgument to an array so we can dump it.

Remaining tasks

User interface changes

None

API changes

No change.

Data model changes

None

Problem/Motivation

Our gitlabci template makes use of the CI_MERGE_REQUEST_PROJECT_URL environment variable for fetching.
This assumes the repository is publicly available and doesn't work for private repositories.

The security team has a private fork of core on our gitlab instance for testing security issues.

Tests currently fail on the use of this variable because we can't fetch the repository over https

Steps to reproduce

Proposed resolution

Use 'origin' instead of the repository URL

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Following up on discussions in issues such as #2938800: Finalize wording for Toolbar warning message and #2941582: Create a drupal.org documentation page for Umami profile to explain why it shouldn't be used in production sites and elsewhere, the Umami profile should implement hook_help() so as to provide an introduction about what the profile is for.

The toolbar warning message can then link to this help text, and the help text can in turn link to https://www.drupal.org/docs/8/umami-drupal-8-demonstration-installation-... (the drupal.org page that was created in #2941582: Create a drupal.org documentation page for Umami profile to explain why it shouldn't be used in production sites).

This has a couple advantages:

1. It more closely follows the standard Drupal help pattern (in-site basic help, plus a link to drupal.org for more in-depth discussion).
2. It allows the help text to be translated.
3. It allows the help text to be reached via the standard Help system (not just via the toolbar).

To address concerns raised previously about what happens to the toolbar warning when the Help module is turned off, we could just make the warning in the toolbar link directly to the drupal.org documentation page when the Help module is disabled.

As part of this issue, it would also be good to review the text at https://www.drupal.org/docs/8/umami-drupal-8-demonstration-installation-... and make sure it is conveying the message it should be and that it meshes well with the text in hook_help(). For example:

1. I interpreted this as being the install profile's generic documentation page, but the current text focuses too much on the recommendation not to use it for a real site. That can be part of the page, but shouldn't be the loudest part. I think that could be mostly addressed by deleting the really large "The Umami installation profile is for demo purposes only" sub-headline that is currently there.

2. Once you've tried Drupal using Umami and want to build your own site, simply reinstall Drupal selecting the Minimal or Standard profiles from the install screen.

   We shouldn't assume Standard or Minimal are the only ones available, since there are contrib profiles too. I would change this to something like "...simply reinstall Drupal and select a different installation profile (such as Standard) from the install screen."

Finally, when we link to this page, the code currently in core links to it via https://www.drupal.org/node/2941833. That's the same page as https://www.drupal.org/docs/8/umami-drupal-8-demonstration-installation-... but a less friendly URL. I suggest using the friendly URL instead.