Problem/Motivation

The at() matcher has been deprecated. It will be removed in PHPUnit 10. Please refactor your test to not rely on the order in which methods are invoked.

Steps to reproduce

Proposed resolution

Convert PHPUnit stub setup calls to $this->at() to $this->once(), $this->exactly() or $this->any() depending on the intent of the test.

Convert multiple calls to $this->at() on the same stub method to use either ->willReturnMap() or ->withConsecutive() and/or ->willReturnOnConsecutiveCalls() depending on the test requirements.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

We are seeing a significant number of the following errors in our logs:
Error: Call to a member function getTranslation() on null in Drupal\\Core\\Entity\\ContentEntityBase->hasTranslationChanges()

Steps to reproduce

A contrib module is calling hasTranslationChanges on an entity (method inherited from ContentEntityBase).
By the time the method attempts to load the unchanged entity (L:1415 of ContentEntityBase) the entity has been deleted by a process running in another thread, meaning that $original === NULL. ( The race condition makes this quite challenging to reliably reproduce.)
Therefore, the call on L:1431 as follows $translation = $original->getTranslation($this->activeLangcode); results in an error.

Proposed resolution

Check if the unchanged entity could be loaded. If not, return FALSE from hasTranslationChanges. The logic being that the entity cannot have changes if it has been deleted. Normally actions (such as updated the changed timestamp on the entity) are taken as a result of hasTranslationChanges returning TRUE. Therefore, it is hoped that this change does not introduce unintended side-effects.

Remaining tasks

Create a merge request.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

To be defined.

HI,

I just noticed something while building a view and either I misinterpret what's happening or it's some kind of a bug. I searched for any relevant issues but couldn't really find anything.

When you have both an exposed filter and a contextual filter in a view, they'll combine by default. Example: an /events overview where you can filter on categories: /events/webinar. Within a category it's possible to filter on a country: /events/webinar?country=US.

However, when you turn on "Exposed form in block", this functionality stops working and you can only either filter on a contextual argument or on an exposed filter.

Meeting Agenda

1. Introductions
2. Status and what's next
3. Issue updates and discussion
4. Where can people help this week?

Meeting Details

Time: 2pm UTC (10am Eastern)
‬Meeting Location: #olivero channel on drupal.slack.com

Meeting Notes

[to be added after the meeting is complete]

Problem/Motivation

The docblocks for Connection::select and Select::__construct only describe $table as a string, but in reality it can also be a subquery in form of a SelectInterface object (for example, for rowcount queries).

Proposed resolution

Fix

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Easy Out of the Box - June 21 Meeting in Slack

• 0 - Introductions
• 1.0 - Roadmap is located here: https://www.drupal.org/project/ideas/issues/3191533.
• 2.0 - Where can contributors help this week. There will be threads for the individual components.
• 2.1 - Claro discussion. Meta issue here: https://www.drupal.org/project/ideas/issues/3167121
• 2.2 - Layout builder discussion. Meta issue here: https://www.drupal.org/project/ideas/issues/3194761
• 2.3 - Media discussion. Meta issue here: https://www.drupal.org/project/ideas/issues/2825215
• 2.4 - Marketing EOOTB initiative. Meta issue here: https://www.drupal.org/project/promote_drupal/issues/3208461
• 3.0 - Upcoming events with contrib days.
• 3.1- DrupalCamp Colorado (August 6-8 with contrib day on Sunday the 8th) is coming up. We have submitted the keynote (from DC) as a session. As the event gets closer, let's plan the sprint.
• 4.0 - Any additional topics to discuss?

Let the conversation can continue here in Slack. Thank you for showing up and contributing! If you have additional questions or comments, please post them in the issue or here.

Meeting Agenda

1. Introductions
2. Status and what's next
3. Utility CSS classes in Olivero: #3218688: Feature: Add utility classes to Olivero to be used by site-builders
4. Convert colors to HSL and normalize hues and saturations: #3217924: Olivero: Convert all colors (blues and grays) to HSL and normalize hues and saturations.
5. Other Issue updates and discussion
6. Where can people help this week?

Meeting Details

Time: 2pm UTC (10am Eastern)
‬Meeting Location: #olivero channel on drupal.slack.com

Meeting Notes

[to be added after the meeting is complete]

Problem/Motivation

In Layout Builder, when you go to add a block to a section, and click "Create custom block", a list of links of the type of custom block content you want to add as a inline block appears. On a multilingual site, this list of links displays only in one language, which is language the site is using when it caches the derivate plugin definitions.

This is because of line 52 of docroot/core/modules/layout_builder/src/Plugin/Derivative/InlineBlockDeriver.php:
$this->derivatives[$id]['admin_label'] = $type->label();
Which sets the admin_label of the derivate plugin definition to a string instead of TranslatableMarkup.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

On #3090659: Make a way for help topics to generate links only if they work and are accessible, we are adding two new functions for making links in help topics.
Related change record is https://www.drupal.org/node/3192582

Once that is committed (this issue is postponed until then), we need to fix up all of the existing help topics to use the new functions.

As an example, this is how the block.place.html.twig file was updated in the patch on that issue (that was the only production topic that was updated):

-{% set configure = render_var(url('help.help_topic', {'id': 'block.configure'})) %}
+{% set configure_topic = render_var(help_topic_link('block.configure')) %}
 
...

-  <li>{% trans %}In the <em>Manage</em> administrative menu, navigate to <em>Structure</em> &gt; <a href="{{ layout_url }}"><em>Block layout</em></a>.{% endtrans %}</li>
+  <li>{% trans %}In the <em>Manage</em> administrative menu, navigate to <em>Structure</em> &gt; {{ layout_link }}.{% endtrans %}</li>

...

-  <li>{% trans %}Configure the block and click <em>Save block</em>; see <a href="{{ configure }}">Configuring a previously-placed block</a> for configuration details.{% endtrans %}</li>
+  <li>{% trans %}Configure the block and click <em>Save block</em>; see {{ configure_topic }} for configuration details.{% endtrans %}</li>

Steps to reproduce

N/A

Proposed resolution

1. [done] Make sure that the help topics standards on https://www.drupal.org/docs/develop/documenting-your-project/help-topic-... are updated to use the new functions.
2. Fix up the rest of the topics in core/modules/help_topics/help_topics to use the new help function help_topic_link (help_topic_route is on #3215784: Fix up topics to use new help_route_link function

Remaining tasks

Make a patch, review, and commit.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

Not necessary. This is an Experimental module.

Problem/Motivation

On #3090659: Make a way for help topics to generate links only if they work and are accessible, we are adding two new functions for making links in help topics.
Related change record is https://www.drupal.org/node/3192582

Once that is committed (this issue is postponed until then), we need to fix up all of the existing help topics to use the new functions.

As an example, this is how the block.place.html.twig file was updated in the patch on that issue (that was the only production topic that was updated):

-{% set layout_url = render_var(url('block.admin_display')) %}
+{% set layout_link_text %}
+{% trans %}Block layout{% endtrans %}
+{% endset %}
+{% set layout_link = render_var(help_route_link(layout_link_text, 'block.admin_display')) %}
 
...

-  <li>{% trans %}In the <em>Manage</em> administrative menu, navigate to <em>Structure</em> &gt; <a href="{{ layout_url }}"><em>Block layout</em></a>.{% endtrans %}</li>
+  <li>{% trans %}In the <em>Manage</em> administrative menu, navigate to <em>Structure</em> &gt; {{ layout_link }}.{% endtrans %}</li>

...

-  <li>{% trans %}Configure the block and click <em>Save block</em>; see <a href="{{ configure }}">Configuring a previously-placed block</a> for configuration details.{% endtrans %}</li>
+  <li>{% trans %}Configure the block and click <em>Save block</em>; see {{ configure_topic }} for configuration details.{% endtrans %}</li>

Steps to reproduce

N/A

Proposed resolution

1. [done] Make sure that the help topics standards on https://www.drupal.org/docs/develop/documenting-your-project/help-topic-... are updated to use the new functions.
2. Fix up the rest of the topics in core/modules/help_topics/help_topics to use the new help functions.
3. (separate issue?) Add code to core/modules/help_topics/tests/src/Functional/HelpTopicsSyntaxTest to make sure that:
   • Both help_topic_link and help_route_link functions are being used for links and not the base Twig url() function.
   • If help_route_link or help_topic_link is used, the text is translated.
   • The syntax test includes "bad" examples to verify the tests are working, so there should also be "bad" examples added that violate those two test cases, to make sure the test is working properly.

Remaining tasks

Make a patch, review, and commit.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

Not necessary. This is an Experimental module.

Problem/Motivation

When editing a book, the [add child page] link allows adding a new child page. Far more often people are adding sibling pages (subsequent pages at the same nesting level). It would be ideal to allow an add sibling button as well.

Proposed resolution

Add a link [insert sibling after this page] that adds a page at the same nesting level immediately after the current page.

Remaining tasks

User interface changes

Add a link [insert sibling after this page] that adds a page at the same nesting level immediately after the current page.

Release notes snippet

User interface improvement allows adding sibling pages in books.

Problem/Motivation

Retrieving counts of source data when the source data can include translations is troublesome. It isn't possible to just call `$this->query()->count()->execute();` That won't return anything but the main translation count.

Proposed resolution

Figure out a fancy SQL query that will retrieve a more valid count.

Remaining tasks

• Code it
• Test it
• Review it

User interface changes

API changes

Data model changes

In a multilingual site I set content access to enable translation for Basic page and another content type called "Club".
Permissions for "Translate Basic page content" are set for administrator only.
I need an editor to be able to translate content type "club" so I set permission for editor to "Translate Club content".

Now I am facing two problems:
1. If I do not set the "Create translations" permission for editor, there is no local task for "Translate" when editor views a "Club" node.
2. If I do set the "Create translations" permission for editor, there is a local task for "Translate" and all works fine but this "Translate" local task is also showing on other content types (which are not configured for editor translations).
When editor clicks on "Translate" for other content types (like Basic page) he gets the translation table but not edit or add option i.e you cannot really translate.

Steps to reproduce:

• Enable translation for 2 content types
• Create a role and give permission to translate 1 of them. Give the user permission to create/edit/delete translations
• When using that role visit a node of the other content type where you do not have translation permission.
• You will now see a translation tab there even if you don't have permission to translate into that entity. When you click on the translation tab you will see all translations listed, but you cannot perform any actions.

Problem/Motivation

When using the linkit, it is possible to use linkit also on the link button in CKEditor. In this case, the default link field is replaced with an autocomplete field. The results window has a maximum size; if many results are returned by linkit, a scrollbar is displayed.
This does not work when using Claro as the admin theme, as the scrollbar is hidden. Hence, only the first 8 / 12 results are displayed to users; all the other results are hidden.

Steps to reproduce

• Install drupal vanilla, select Claro as the admin theme;
• Install linkit, enable the module and enable it also in the "CKEditor plugin" section of the Content authoring --> Text formats and editors page;
• Create a bunch of nodes, e.g. 20 articles
• Try to create a link via ckeditor, from any node.

The results will be displayed like this:

Proposed resolution

Replace overflow: hidden for the autocomplete field to overflow: auto (unless there's a good reason to keep it set to hidden).

User interface changes

The scrollbar will now be displayed also for autocomplete fields.

FormBuilder::buildForm() currently disables form redirects for all AJAX forms. Why? Here's an attempt to remove that.

Problem/Motivation

\Drupal\layout_builder\SectionListInterface provides methods for manipulating a list of sections.
\Drupal\layout_builder\SectionStorageInterface extends that interface to provide methods to load and persist that list.

\Drupal\layout_builder\Plugin\SectionStorage\SectionStorageBase exists to provide a base class for implementations of SectionStorageInterface

\Drupal\layout_builder\SectionStorage\SectionStorageTrait exists to provide a trait for implementations of SectionListInterface

That name mismatch is rather confusing.

Proposed resolution

Move the code to a new trait named SectionListTrait and empty out and deprecate the old trait, importing/using the new one for BC.

Remaining tasks

Change record should be updated.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When previewing nodes that use a Views Reference Field with a view that includes a node contextual filter configured to use the default argument using the content id from the URL, the view does not render any results as expected and seen when rendering the node.

The node views argument default expects the node parameter, as seen here.

\Drupal\node\Plugin\views\argument_default\Node::getArgument()

  public function getArgument() {
    if (($node = $this->routeMatch->getParameter('node')) && $node instanceof NodeInterface) {
      return $node->id();
    }
  }

However, the entity.node.preview route provides the node_preview parameter, which is upcasted to the node entity via the Drupal\node\ParamConverter\NodePreviewConverter()

See line 31 of node.routing.yml

entity.node.preview:
  path: '/node/preview/{node_preview}/{view_mode_id}'
  defaults:
    _controller: '\Drupal\node\Controller\NodePreviewController::view'
    _title_callback: '\Drupal\node\Controller\NodePreviewController::title'
  requirements:
    _node_preview_access: '{node_preview}'
  options:
    parameters:
      node_preview:
        type: 'node_preview'

Proposed resolution

Can we simply convert the parameter name in entity.node.preview from node_preview to node?

Remaining tasks

Patch, tests, ?

User interface changes

None

API changes

Unsure

Data model changes

None

Problem/Motivation

Migration::set() was provided as a work-around for the inability to properly modify migration plugin configuration at run time (#2681869: Provide clean way to merge configuration into migration plugins) - once that is committed, set() should be deprecated. The only core usages remaining after that commit are in tests, which should be changed to use the plugin manager to merge configuration.

Note that set() is documented with {@inheritdoc}, yet is not in MigrationInterface and thus is not properly documented. This fix should properly document it in the Migration class.

Proposed resolution

Add individual setters to MigrationInterface and implement them in Migration. Setters added are

• setDependencies(array $value)
• setRequirements(array $value)

In MigrateTestBase, add an optional $configuration parameter to getMigration() and executeMigration(), where $configuration is an array of values to merge into the migration definition.

In MigrateTestBase and the traits for file migrations, remove prepareMigration(). Instead, the traits add fileConfiguration(). Tests that run file migrations pass that to executeMigration().

Change the use of Migration::set() in

• MigrationPluginManager
• d6/MigrateUploadTest
• d6/FileMigrationTestTrait
• d7/FileMigrationSetupTrait
• ReferenceBase.php

Move test in MigrationTest to MigrationPluginConfigurationTest.php
Add doc bloc for Migration::set() and deprecate it.

Theses changes may require changes to migration tests in contrib.

Remaining tasks

If #2953111: [PP-1] Only migrate role permissions that exist on the destination is fixed before this issue, then update the test. See Comment #43.14 there.

Add follow-up issues for the following contrib modules (see #85 here):

• media_migration
• location_migration
• migrate_tools
• migrate_upgrade

User interface changes

API changes

Problem/Motivation

On #3090659: Make a way for help topics to generate links only if they work and are accessible, we created two new functions for making links in help topics that degrade nicely when the link cannot be accessed or doesn't exist: help_route_link and help_topic_link.

On #3215784: Fix up topics to use new help_route_link function and #3192585: Fix up topics to use new help_topic_link function, we fixed up the existing help topics to use these functions.

On this issue, we want to enforce the correct use of those functions in a test. The test should add code to core/modules/help_topics/tests/src/Functional/HelpTopicsSyntaxTest to make sure that:

• Both help_topic_link and help_route_link functions are being used for links and not the base Twig url() function.
• If help_route_link or help_topic_link is used, the text is translated.
• The syntax test includes "bad" examples to verify the tests are working, so there should also be "bad" examples added that violate those two test cases, to make sure the test is working properly.

Steps to reproduce

Proposed resolution

Add code to HelpTopicsSyntaxTest for these tests.

Remaining tasks

1. Patch, review, commit.
2. Add a change record to note that use of these functions is required by this test. See also the change record for #3090659: Make a way for help topics to generate links only if they work and are accessible: https://www.drupal.org/node/3192582

User interface changes

No, test only

API changes

Sort of -- we'll be requiring use of these functions.

Data model changes

No.

Release notes snippet

No.

Edit article content image field alignment missing