Problem/Motivation

The new JS optimizer added in Drupal 10.1 is now breaking async functions if this keyword is infront of function.

Steps to reproduce

Foo = {
  async bar() {},
  baz: async () => {},
}

Expects to be Foo={async bar(){},baz:async()=>{}}; but Foo={bar(){},baz:async()=>{}}; provided.

bar() lost its async prefix and any await inside will lead to JS error and break aggregated JS file completely.

Proposed resolution

Find out why is that happened and fix it.

A user of clientside_validation reported this bug (#1585554: Validating lists (select-fields) not working correctly), it is caused by the fact that the options.module uses the following: $options = array('_none' => $label).

First problem is that the outputted HTML contains <option value="_none"> and this means the select element has a value.
Second (unrelated) problem is that we allow people to enter "_none|oops" as an allowed value, but it will never be outputted unless a default value is selected.

I found #735426: Fields with select widget: first option is selected by default even if no 'default value' set for the field where this was introduced, so I would like to change the use of '_none' to NULL

Summary:

Generically, the issue seems to be no graceful failure when form builder expects an array and gets a string.

Steps to Reproduce:

• Create a view.
• Add a filter (e.g. a taxonomy with filter identifier "tid"), make it exposed; configure the filter to "Allow multiple selections"
• Make a page display (e.g. "/test_view") to allow easy access to the filter query params. Save and navigate to the page.
• Use the exposed filter and note that the URL becomes something like "test_view?tid[N]=N" where N is the id of your taxonomy term.
• Change the query parameter to be something like "?tid=foo".
  Note that you get a fatal error "Cannot create references to/from string offsets in /mnt/www/html/[project]/docroot/core/lib/Drupal/Component/Utility/NestedArray.php on line 155 #0
  /mnt/www/html/[project]/docroot/core/lib/Drupal/Core/Form/FormBuilder.php(1259): Drupal\Component\Utility\NestedArray::setValue(Array, Array, NULL) #1"

This error is identical to that mentioned in original issue description, summarized here:

When Layout builder is active and I try to save a Content type "The website encountered an unexpected error. Please try again later." turns up and I have the below errors. What could this be?
PHP 7.2.13-1+0~20181207100540.13+stretch~1.gbpf57305
DB 5.5.5-10.1.37-MariaDB-0+deb9u1
Error: Cannot create references to/from string offsets i Drupal\Component\Utility\NestedArray::setValue() (rad 155 av /web/core/lib/Drupal/Component/Utility/NestedArray.php)... [rest of stack trace omitted]

Note that the patches offered below (with the exception of the debug patch) are essentially identical and differ only in the line number in core/lib/Drupal/Core/Form/FormBuilder.php where the change is applied.

The patch has worked for me (D9.5.9, PHP8.1) with custom views - again, with a different line number.

Problem/Motivation

According to Drupal's advice, when we change the default transaction isolation level from "REPEATABLE READ" to READ-COMMITTED for databases, the following error is reported.

Transaction isolation level:READ-COMMITTED
Error:
For this to work correctly, all tables must have a primary key. The following table(s) do not have a primary key: forum_index. See the setting MySQL transaction isolation level page for more information.

Steps to reproduce

Install forum module in Drupal 10.1

Proposed resolution

Add a primary key to the forum_index table

Remaining tasks

Review
Commit

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Since #3277784: copyRawVariables should support default route parameters menu active trail information is missing from menu items under certain circumstances. In my case I've got a view with a path and menu entry and the rendered menu item no longer sets in_active_trail to TRUE when accessing the view on a page with the menu.

This issue is broken out from a different regression: #3358402: [regression] route defaults are now automatically route parameters. There a few relevant comments there:

Comment from @znerol:

I think that $this->routeMatech->getRawParameters()->all() returns a different set of key-value pairs which in turn leads to an empty result from $this->menuLinkManager->loadLinksByroute() in MenuActiveTrail::getActiveLink():

  public function getActiveLink($menu_name = NULL) {
    [...]
      $route_parameters = $this->routeMatch->getRawParameters()->all();

      // Load links matching this route.
      $links = $this->menuLinkManager->loadLinksByRoute($route_name, $route_parameters, $menu_name);
      // Select the first matching link.
      if ($links) {
        $found = reset($links);
      }
    [...]
  }

Comment from @lisotton:

I have some routes that share the same Controller and Action, but in the route declaration it declares default parameters. For example I have the route mymodule.news_list (/news) which have the controller ListPageController::entryPoint with a default parameter called type with value news-list. Then I have another route called mymodule.articles_list (/articles) which shares the same controller, but the default parameter type with value articles-list.

Before when I was calling \Drupal::service('plugin.manager.menu.link')->loadLinksByRoute('news_list'), without any second second parameter (route params), it was returning me the menu links, but with the change in 9.5.9, I'm enforced to call \Drupal::service('plugin.manager.menu.link')->loadLinksByRoute('news_list', ['type' => 'news-list').

For me this broke many small things, like breadcrumbs, custom menu blocks, etc.

Steps to reproduce

1. Log in as admin.
2. Navigate to /admin/structure/views/add.
3. Add a view with options:
   • View name: Site content
   • Create a page: checked
   • Create a menu link: checked
   • Menu: Main navigation
4. Navigate to /site-content.
5. Inspect "Site content" main navigation item with browser tools and confirm class primary-nav__menu-link--active-trailis not present on a element.
6. Revert changes from #3277784: copyRawVariables should support default route parameters (or just comment out core/lib/Drupal/Core/Routing/Enhancer/ParamConversionEnhancer.php#L71-75).
7. Rebuild caches.
8. Navigate to /site-content.
9. Inspect "Site content" main navigation item with browser tools and confirm class primary-nav__menu-link--active-trailis present on a element.

Proposed resolution

None yet.

Remaining tasks

Come with a proposed resolution and MR.

Problem/Motivation

It is common that form validators are validating the form values using form state. However, in some unique cases like \Drupal\Core\Field\FieldItemList::defaultValuesFormValidate, the validation depends on the actual entity that is attached to the form. In these cases, it is important that the entity is up-to-date, and that any normalizing done prior have been extracted to the entity, because otherwise the validation is not validating what it's supposed to validate.

In #3345149: Extra Default value field when adding a field with an unlimited values, we needed to add a manual call to \Drupal\Core\Entity\EntityForm::buildEntity to ensure that the entity has been updated which isn't ideal for DX.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Splitting off a child issue from #3014752: [PP-1] Convert drupal_rebuild(), drupal_flush_all_caches() and _drupal_flush_css_js() functions into cache Rebuilder class where @alexpott suggested in comment #83:

I think this issue could do with coming in 2 parts. One that deals with the new CSS / JS query string service and converting usages of _drupal_flush_css_js() and anything that accesses the 'system.css_js_query_string' state directly. And another that deals with drupal_flush_all_caches() and drupal_rebuild().

This issue is for the first part of that.

Steps to reproduce

Proposed resolution

• Deprecate _drupal_flush_css_js()
• Create a new AssetQueryString cache service
• Convert usages

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

While debugging a problem with the ClamAV module, I discovered that it was caused by the file validator hook attempting to find an uploaded file in its final destination while it was still a temporary upload. As an antivirus that module *should* be checking the file while it is in temp storage, and needs access to the exact file location to do so. $file->getFileUri() was returning a URI with the public:// scheme.

@larowlan pointed out on Slack that this was happening because \Drupal\ckeditor5\Controller\CKEditor5ImageController::upload sets the file uri before triggering validation.

Setting to Major as this "blocks a contributed module with no workaround".

Steps to reproduce

Add CkEditor5 and clamav module
Allow image upload in CkEditor5
Configure clamav
Upload an image via CkEditor5

Clamav errors because the file it is passed has a file path that does not exist yet

Proposed resolution

Not sure yet.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Problem/Motivation

I did some grepping to find @todo items that reference closed issues

grep -r "@todo .*[\r\n]* https://.*drupal.org/.*" . | grep -o  '/[0-9]\+' | while read -r line ; do
     markup=$(curl --silent "https://www.drupal.org/node$line" | hxnormalize -x) 
     status=$(echo $markup |  hxselect '.field-name-field-issue-status .field-item' | sed 's/<\/\?[^>]\+>//g')
     if [[ "$status" == *"Closed"* ]]; then
       echo "[#$line]" | sed 's/\///g'
     fi
 done | uniq

39 were found on the initial run. These should be cleaned up.

Proposed resolution

Create child issues for each of the closed @todo items. In that child issue:

• If it can be confirmed that the @todo is truly addressed in the referenced issue, follow the instructions of the @todo then remove it
• If the circumstances of the @todo are not truly addressed, find out if the @todo should be referencing a different existing issue, or create a new one to address the needs of the @todo.
• As issues are completed, update the issue summary to document that, so it's not neccessary to rely on drupal.org dynamically representing the issue status.

Many of these issues can get a novice tag, but this can be omitted if the solution seems like it will be more complex.

Remaining tasks

See if the search used to find these issues can be improved. If additional completed @todos are found, add them to the issue summary.

Follow the steps in proposed resolution. Create child issues and complete them, update the table below as they are updated/completed

@todo Fixed in a dedicated issue

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The page title for comment type edit form is just "Edit". This is pretty confusing because it doesn't contextualize the local tasks, but also leads into incorrect breadcrumbs on the subpages as reported in #2587415: Comment types UI confusing and inconsistent.

Proposed resolution

Change the page title to the current comment type.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

I cannot remove media from media_library widget when creating/editing a node, when the field has an error

Drupal code 8.9.8, PHP 7.3

Steps to reproduce

I have a field that is media reference on a content type and I run a custom validation through a hook at a custom module on that specific field. When I click Submit/Create to save my changes or create a new node and the custom validation check throws an error, I cannot remove the media entity from the widget in order to add a new one.

• Go to a content type and add a field media reference (the media type is irrelevant) with machine name field_media
• Create a custom module that validates this field. I used the following code on the content type "Basic Page" that is available on a fresh install. I have in purpose enabled the form_state to this field in order to reproduce the issue
  My test.module file:

  /**
   * Implements hook_form_FORM_ID_alter().
   */
  function test_form_node_page_form_alter(&$form, FormStateInterface $form_state, $form_id) {
    $form['#validate'][] = 'test_validate_form_media_field';
  }
  
  function test_validate_form_media_field(&$form, FormStateInterface $form_state) {
    $form_state->setErrorByName('field_media', 'There is an error');
  }
  

• Go to Create a new Basic Page
• Fill in needed fields like title, add a new media from the widget.
• Click submit
• It should throw the above error.
• Try to remove the media

What should happen
Media is removed and the user is able to add another

What is happening
The media is not removed and the log has the following entries

Notice: Undefined index: removed_item_id in Drupal\media_library\Plugin\Field\FieldWidget\MediaLibraryWidget::updateWidget() (line 686 of /var/www/html/web/core/modules/media_library/src/Plugin/Field/FieldWidget/MediaLibraryWidget.php)

#0 /var/www/html/web/core/includes/bootstrap.inc(600): _drupal_error_handler_real(8, 'Undefined index...', '/var/www/html/w...', 686, Array)
#1 /var/www/html/web/core/modules/media_library/src/Plugin/Field/FieldWidget/MediaLibraryWidget.php(686): _drupal_error_handler(8, 'Undefined index...', '/var/www/html/w...', 686, Array)
#2 [internal function]: Drupal\media_library\Plugin\Field\FieldWidget\MediaLibraryWidget::updateWidget(Array, Object(Drupal\Core\Form\FormState), Object(Symfony\Component\HttpFoundation\Request))
#3 /var/www/html/web/core/lib/Drupal/Core/Form/FormAjaxResponseBuilder.php(69): call_user_func_array(Array, Array)
#4 /var/www/html/web/core/lib/Drupal/Core/Form/EventSubscriber/FormAjaxSubscriber.php(109): Drupal\Core\Form\FormAjaxResponseBuilder->buildResponse(Object(Symfony\Component\HttpFoundation\Request), Array, Object(Drupal\Core\Form\FormState), Array)
#5 [internal function]: Drupal\Core\Form\EventSubscriber\FormAjaxSubscriber->onException(Object(Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent), 'kernel.exceptio...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#6 /var/www/html/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent), 'kernel.exceptio...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#7 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(227): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.exceptio...', Object(Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent))
#8 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(79): Symfony\Component\HttpKernel\HttpKernel->handleException(Object(Drupal\Core\Form\FormAjaxException), Object(Symfony\Component\HttpFoundation\Request), 1)
#9 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#10 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#11 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#12 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#13 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#14 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#15 /var/www/html/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#16 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(708): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#17 /var/www/html/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#18 {main}

Warning: array_flip(): Can only flip STRING and INTEGER values! in Drupal\Core\Entity\EntityStorageBase->loadMultiple() (line 266 of /var/www/html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php)

#0 /var/www/html/web/core/includes/bootstrap.inc(600): _drupal_error_handler_real(2, 'array_flip(): C...', '/var/www/html/w...', 266, Array)
#1 [internal function]: _drupal_error_handler(2, 'array_flip(): C...', '/var/www/html/w...', 266, Array)
#2 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(266): array_flip(Array)
#3 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(250): Drupal\Core\Entity\EntityStorageBase->loadMultiple(Array)
#4 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityBase.php(544): Drupal\Core\Entity\EntityStorageBase->load(NULL)
#5 /var/www/html/web/core/modules/media_library/src/Plugin/Field/FieldWidget/MediaLibraryWidget.php(686): Drupal\Core\Entity\EntityBase::load(NULL)
#6 [internal function]: Drupal\media_library\Plugin\Field\FieldWidget\MediaLibraryWidget::updateWidget(Array, Object(Drupal\Core\Form\FormState), Object(Symfony\Component\HttpFoundation\Request))
#7 /var/www/html/web/core/lib/Drupal/Core/Form/FormAjaxResponseBuilder.php(69): call_user_func_array(Array, Array)
#8 /var/www/html/web/core/lib/Drupal/Core/Form/EventSubscriber/FormAjaxSubscriber.php(109): Drupal\Core\Form\FormAjaxResponseBuilder->buildResponse(Object(Symfony\Component\HttpFoundation\Request), Array, Object(Drupal\Core\Form\FormState), Array)
#9 [internal function]: Drupal\Core\Form\EventSubscriber\FormAjaxSubscriber->onException(Object(Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent), 'kernel.exceptio...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#10 /var/www/html/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent), 'kernel.exceptio...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#11 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(227): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.exceptio...', Object(Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent))
#12 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(79): Symfony\Component\HttpKernel\HttpKernel->handleException(Object(Drupal\Core\Form\FormAjaxException), Object(Symfony\Component\HttpFoundation\Request), 1)
#13 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#14 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#15 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#16 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#17 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#18 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#19 /var/www/html/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#20 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(708): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#21 /var/www/html/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#22 {main}

Error: Call to a member function label() on null in Drupal\media_library\Plugin\Field\FieldWidget\MediaLibraryWidget::updateWidget() (line 686 of /var/www/html/web/core/modules/media_library/src/Plugin/Field/FieldWidget/MediaLibraryWidget.php)

#0 [internal function]: Drupal\media_library\Plugin\Field\FieldWidget\MediaLibraryWidget::updateWidget(Array, Object(Drupal\Core\Form\FormState), Object(Symfony\Component\HttpFoundation\Request))
#1 /var/www/html/web/core/lib/Drupal/Core/Form/FormAjaxResponseBuilder.php(69): call_user_func_array(Array, Array)
#2 /var/www/html/web/core/lib/Drupal/Core/Form/EventSubscriber/FormAjaxSubscriber.php(109): Drupal\Core\Form\FormAjaxResponseBuilder->buildResponse(Object(Symfony\Component\HttpFoundation\Request), Array, Object(Drupal\Core\Form\FormState), Array)
#3 [internal function]: Drupal\Core\Form\EventSubscriber\FormAjaxSubscriber->onException(Object(Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent), 'kernel.exceptio...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#4 /var/www/html/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent), 'kernel.exceptio...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#5 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(227): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.exceptio...', Object(Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent))
#6 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(79): Symfony\Component\HttpKernel\HttpKernel->handleException(Object(Drupal\Core\Form\FormAjaxException), Object(Symfony\Component\HttpFoundation\Request), 1)
#7 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#8 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#9 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#10 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#11 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#12 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#13 /var/www/html/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#14 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(708): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#15 /var/www/html/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#16 {main}

Problem/Motivation

#3362864: [Ignore] In space (and/or this issue), no one can hear patches scream VI

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In #1521996: Password reset form reveals whether an email or username is in use we try to find a solution that stops guests to use the 'Request new password' form to learn that a user with a specific email address is registered on the site.

The same privacy issue exists with the 'Create new account' form (as was pointed out by penyaskito).

Steps to reproduce the issue:

1. Register an account with the email address me@example.com.
2. Try to register another account with the email address me@example.com.
3. You’ll get an error:
   

   The email address me@example.com is already registered. Have you forgotten your password?

Proposed resolution

• Instead of displaying an error, display exactly the same success message that is used when registering with an unused email address.
  • If email verification is required:
    • In case the address is unused: No change, send the normal registration confirmation.
    • In case the address is already used: Send an email explaining something like: "You or someone else tried to register an account on example.com with your email address me@example.com. However, you already have an account on this site. Did you forget your password? Then …"
  • If email verificiation is not required (i.e., new users are directly logged in after registration):
    • If the same password is used: Just log the old user in, and maybe show a notification that the account already existed.
    • If a different password is used: This becomes ugly … (we can’t tell if the user is the same or not). What could we do? Maybe we should only provide a solution in case email verification is required?

Remaining tasks

…

User interface changes

…

API changes

…

Problem/Motivation

As part of the final merge of Help Topics into Help
#3037230: Finalize the merge of Help Topics into Help
once it is stable, we need to move all of the classes that are currently in Help Topics module into the Help module, leaving behind a BC layer (except for test classes, which do not need to support BC).

Proposed resolution

- move config and topics
- update hooks (install schema and fix config) & test
- disable help_topics if enabled (debatable)
- Copy the classes to the help module. In case other modules use the original classes, make those wrappers for the corresponding classes in the help module.
- Keep help-topics.html.twig in case other modules or themes use it.

Remaining tasks

- discuss transition
- finish patch
- review/commit

User interface changes

- Help topics available in Help module

API changes

- TBD

Data model changes

- new table help_search_items

Release notes snippet

The Experimental Help Topics module has moved to stable and been subsumed by the existing Help module. An update path will uninstall the help topics module and leave behind an empty shell. The Help Topics module should no longer be used, the functionality has been moved to the existing Help module.

Problem/Motivation

The code managing database transaction is very complex - part of it sits in the Connection class, part of it in the Transaction class, and there's back and forth of calls between the two objects.

This makes hard to implement transaction management in contrib database drivers if they need to deviate from the core implementation. Also when looking at #3348590: Add transaction-related events to the Database API, it's complicated to find the right places to dispatch events.

Proposed resolution

Disentangle the transaction management code, introducing a transaction manager that does all the client operations and deals with the calls stack; reduce code in Connection and Transaction to a minimum i.e. calls to the manager's methods.

In the course of that, fix #3074033: Add a test for Connection::addRootTransactionEndCallback

Deprecate something (???)

Remaining tasks

Review by committers if something we want.
Identify if anything needs to be deprecated.
Change Record
Final Review

User interface changes

NA

API changes

TODO

Data model changes

TODO

Release notes snippet

TODO

Problem/Motivation

We have a site that actively uses fallbacks and some fallback chains have the default Entity language disabled.
For example, we have an Entity with French (fr) as default language, and allowed fallback chain as Dutch (nl) » German (de) (both translations are missing).

So, when we're calling the function EntityRepository::getTranslationFromContext($entity, 'nl') - we're receiving the French (fr) translation, that is wrong because the buisness logic should disable the fallback convertation from Dutch (nl) to French (fr)!

Steps to reproduce

1. Configure three languages: French (fr), Dutch (nl), German (de).

2. Configure a fallback chain from Dutch (nl) to have a transition to only German (de), so make French (fr) as disabled fallback for it.

3. Create a Node in French (fr) language.

4. Require a fallback of this Node in Dutch (nl) language.

You will receive a translation in French (fr), which is disabled as a fallback for the Dutch (nl) language!

Proposed resolution

The problem is located in this part of the code in the function Drupal\Core\Entity\EntityRepository::getTranslationFromContext()

  public function getTranslationFromContext(EntityInterface $entity, $langcode = NULL, $context = []) {
...
        $candidates = $this->languageManager->getFallbackCandidates($context);

        // Ensure the default language has the proper language code.
        $default_language = $entity->getUntranslated()->language();
        $candidates[$default_language->getId()] = LanguageInterface::LANGCODE_DEFAULT;
...

So we're adding the default language to fallback candidates array always, even if it is missing in the list, received from getFallbackCandidates($context);!

The proper solution from my perspective should be returning NULL from the function getTranslationFromContext(), if no suitable fallback translation is available.

But the current function return value doesn't expect returning NULL as result. So just returning NULL breaks a lot of logic in Drupal Core code and contrib modules too.

But what this function can return if the Entity has no allowed translations to the desired language? From my point of view, the NULL is a good response.

So, to not break the previous behavior, I've added a flag strict_fallback to the context array, that enables the new mode.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Since PHP 8.1 setAccessible() method is no-op
https://github.com/php/php-src/blob/php-8.1.0beta1/UPGRADING#L486-L490
It's widely used in tests

Steps to reproduce

visit
- https://github.com/php/php-src/blob/php-8.1.0beta1/ext/reflection/php_re...
- https://github.com/php/php-src/blob/php-8.1.0beta1/ext/reflection/php_re...

Proposed resolution

Clean-up usage of the method when core require PHP 8.1

Remaining tasks

- agree and patch
- commit

User interface changes

no

API changes

no

Data model changes

no

Release notes snippet

Usage of ReflectionProperty::setAccessible() and ReflectionMethod::setAccessible() is removed

Problem/Motivation

Background: We currently do most of our development against the "Most recently opened Development Branch", and when the first alpha of that minor is released, we open a new branch, which then logically changes what the "Most recently opened Development branch". Anything that's eligible to apply to either the currently supported minor or previous minor (security patches) is then cherry picked to those lower branches.

Problem: This means that our "logical HEAD" of core is a moving target that changes every six months, and perhaps more frequently when we add in Major version branch openings as well.

This causes a couple of problems:

1. Issues are assigned to a specific branch, like "9.3.x" that then have to be re-assigned to the new logical HEAD. In the vast majority of cases these issues aren't actually targeting the specific branch, they are trying to chase the logical HEAD, and when that HEAD changes labels (i.e. from 9.3.x->9.4.x) we have to go through a process to manipulate all of the issue metadata to move them.
2. Now that we have merge requests, those MRs also need to be migrated to be filed against the latest logical HEAD. We currently do not have a programmatic way to accomplish this, and the permissions on gitlab only allow the opener of the MR to do it, so even manual community issue grooming is onerous, and sometimes demands a new MR be opened to move branches.
3. A new user to the project doesn't have an obvious signpost where development happens. They have to look at all the open branches, and deduce that the highest numbered one is where all the momentum is happening. -> it is more common in projects for main is the place where work happens.

Proposed resolution

Ideally we would switch our logical HEAD to main asap, however Drupal.org does not have support for non-numeric branches out of the box.

Instead, we can implement an interim step on Drupal.org which should work with minimum or zero d.o changes and only minor core changes:

• Branch 11.x instead of 10.2.x now (i.e. 10.1.0-alpha/beta period).
• 11.x will follow 10.x minor release commit rules for the time being, no 11.x-specific patches yet and no 10.2.x branch.
• When we are ready to tag 10.2.0-alpha1, we would then branch 10.2.x and tag all 10.2 releases from there. The 11.x branch then continues as HEAD.
• When we need to diverge 11.x and 10.x, we would branch 10.LAST.x. 11.x would then start to get 11.x-specific commits
• When we're ready to tag 11.0.0-alpha1 we would branch 11.0.x and tag all releases from that branch.
• Continue with 11.x minor branches branched off 11.x when they reach alpha
• Hopefully, by the time we're working on 12.x, we'll be able to branch 'main' and work from that indefinitely.

Advantages:
One bulk issue update from 10.1.x to 11.x, and eventually a bulk issue update to 'main' in two or so years, instead of every six months. Same with branch retargeting.

DIsadvantages:
It is weird and non-semantic to use 11.x as the target for 10.x commits and release branches, however this will only be the case for a few months, then it will fold into sync with the 11.x release cycle anyway.

Original Proposal: Change our logical HEAD to main. All of our current existing policies would still apply, with one exception: instead of opening "the next branch for development" when we release an alpha, we instead open the release branch for that release at the time the alpha is released. (Do nothing with d7 and leave it as it is)

Example

(Now out of date in terms of current version, but still conveys the idea)

The current regime:
All of our commits happen to 9.3.x and:

The proposed strategy:
(rename current 9.3.x to main)
All of our commits happen against the main branch

So essentially: we develop in main untilwe open a release branch, at the same time that we make that branch's first release.

Question: The one part of this change that I'm unfamiliar with is what we do around major version branch releases:

If we are opening 9.4.x and 10.0.x at different times, then with this change in place we would open the 9.4.x branch when we are ready to start committing '10.0.x only' changes to main

Implementation considerations:

• Add main as a 'dev' release?
• Do we need both a 'main' and a 'next'?
• Allow main to exist in the version selector for issues
• Look at places where 'branch' might be standing in for a version.
• disable force pushes to main - at least for core.

Remaining tasks

• Finalize decision
• Identify all places where there are hard coded assumptions about 'branch' and 'version'
• Choose an appropriate transition window in an upcoming version cycle
• Documentation changes, including wiki pages and policy

User interface changes

Release notes snippet

Problem/Motivation

Working on #3346765: Add PerformanceTestBase for allowing browser performance assertions within FunctionalJavaScriptTests I noticed that Largest Contentful Paint is well over two seconds.

Checking Lighthouse shows an image in the hero content being lazy loaded, additionally, inspecting that element, the image is hidden by CSS anyway via overflow: none; and some sizing, but not actually display none. So the hero content view mode could potentially not have that image configured to display at all, saving an HTTP request. A hacky fix for this would be to set the image/field to display:none; so it doesn't render at all and then doesn't affect LCP.

However, the reason this is done is for this template logic:

themes/umami/templates/components/banner-block/block--bundle--banner-block.html.twig:{% set background_image = file_url(content.field_media_image[0]['#media'].field_media_image.entity.uri.value) %}
themes/umami/templates/components/banner-block/block--bundle--banner-block.html.twig:<div{{ attributes.addClass(classes) }} style="background-image: url({{ background_image }})">

Proposed resolution

• Display the image from the <img> tag instead of rendering a background image. The background image was coming in at full width (not being processed by an image style) at 3000px wide.
• Utilize responsive image styles.
• Utilize WebP image format.
• Remove lazy-loading on the image.

Testing steps

There should be no visual difference. To test

1. Ensure image displays properly at multiple screen widths (small, medium, large)
2. Ensure image displays properly both when authenticated and anonymous

Problem/Motivation

blocks createdwith views not visible on pages when installed

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet