Problem/Motivation

If code is called which calls the Messenger service to add a message (e.g., a status update when adding a commerce product to a cart), a session will be written to hold the message data. This is fine in browser contexts, however if not using cookie auth (or, really, not using the html format) you get a session for a message that will never display. This can create WTF conditions when testing non-HTML endpoints (e.g., JSON:API) in clients like Insomnia or Postman, and also calls the cache kill switch unnecessarily.

Steps to reproduce

Make a non-HTML request (e.g., when using Bearer token auth) to a page that calls the messenger. Even though you do not need a cookie session, one is created.

Proposed resolution

No-op on setting messages when the request is not html format. We could in theory also consult the auth method, but I think this is unnecessary mixing of concerns.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

I was working now with css clip-paths and it all works well, untill it goes to production. In the combined css `clip-path: url('#clip-cloud')` is then rewritten to `clip-path: url('/themes/my-theme/css/#clip-cloud')`, which breaks the svg reference.

Steps to reproduce

Use any theme css file with a svg id refference: `clip-path: url('#clip-cloud')`

Proposed resolution

I would say, best would be, if I could mark some parts of a css file to not be rewritten... Alternatively, `url(#whatever)` should NOT be rewritten. It's probably safe, but might lead in cases i don't know to an error.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

As per reviews by @webchick and discussion between @alexpott, @xjm and @effulgentsia, it may be a problem that configuration forms work totally opposite in terms of overridden values compared to how they worked in Drupal 7 and before. In Drupal 7 if you had a settings.php configuration override for example, that got used to build the configuration form and whatever you changed, the change did not stick. That was a WTF, but at least it was some sort of feedback on the value not being possible to change. In Drupal 8 however, overrides are not used to build forms and you can actually change settings and they would actually be saved and then displayed again on the form as if they were persisted. They are actually persisted but overrides may still apply on them, so the operation may be moot.

Proposed resolution

Following #2392319: Config objects (but not config entities) should by default be immutable each configuration form knows about the configuration keys edited and centralizes an accessor ($this->config()) to access them. Thanks to this, we can track if there were any configuration details loaded that may have overrides applied (by loading the editable version as well and comparing the data). That way, we can detect if there are overridden values at least under the same conditions as the admin form was displayed (eg. static global overrides). Using that information, we can display a message on top of the form if there is overridden configuration and editing is pointless.

Remaining tasks

Implement. Add tests. Review. Commit.

User interface changes

Configuration forms may display a message on the top if there are overridden values.

API changes

None.

Making a theme compatible with Drupal core's theme generator tool is very difficult. Theme generator was introduced in 9.3, and in two years the only theme (that I know of) that is clonable is core's starterkit theme.

I believe that the reason is that making a theme compatible is too difficult. Within the issue to make Olivero compatible (#3301173: Allow starterkit theme generator tool to clone Olivero), we need 240 lines of fairly complicated PHP. This is unreasonable for a themer to do, and most don't have the necessary skillset to do so.

Plan

To be determined. Maybe we could have a YML file where a themer could define what strings are to be replaced and with what, what directories to search, etc.

Problem/Motivation

#2521800: List key|label entry field is textarea, which doesn't give guidance towards the expected input changed the options field types to use similar pattern that is used for fields allowing unlimited field cardinality. This is nice because the new UI makes it clear what the user needs to enter, as well as automates generating the machine names when possible. However, what could be improved is that adding multiple values to the field requires more steps now than it did before.

Proposed resolution

Allow adding a new value to a list of fields by pressing enter on the last item. When pressing enter on a value that is not the last item, navigate to next item instead of adding a new item.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

For PHP 8.1, calling the mb_strtolower() function with a null argument returns a deprecation error:

Deprecated function: mb_strtolower(): Passing null to parameter #1 ($string) of type string is deprecated in Drupal\Component\Utility\Html::getId() (line 219 of core/lib/Drupal/Component/Utility/Html.php).
Drupal\Component\Utility\Html::getId(NULL) (Line: 121)
__TwigTemplate_fdec0ba362e0f13a146c27640b999ff1->doDisplay(Array, Array) (Line: 405)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
Twig\Template->display(Array) (Line: 390)
Twig\Template->render(Array) (Line: 55)
twig_render_template('themes/citizen_patterns/templates/zzz-custom/widgets/00-base/field--node--field-paragraphs.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('field', Array) (Line: 422)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
Drupal\Core\Render\Renderer->render(Array) (Line: 479)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 122)
__TwigTemplate_225f1ad20ce32204822f192356151c59->block_content(Array, Array) (Line: 182)
Twig\Template->displayBlock('content', Array, Array) (Line: 111)
__TwigTemplate_225f1ad20ce32204822f192356151c59->block_blockContent(Array, Array) (Line: 182)
Twig\Template->displayBlock('blockContent', Array, Array) (Line: 78)
__TwigTemplate_225f1ad20ce32204822f192356151c59->doDisplay(Array, Array) (Line: 405)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
Twig\Template->display(Array) (Line: 390)
Twig\Template->render(Array) (Line: 55)
twig_render_template('themes/citizen_patterns/templates/zzz-custom/blocks/block--field-block.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('block', Array) (Line: 422)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 435)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
Drupal\Core\Render\Renderer->render(Array) (Line: 479)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 97)
__TwigTemplate_1259748214d9a4428585fb011ef8998c->doDisplay(Array, Array) (Line: 405)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
Twig\Template->display(Array) (Line: 390)
Twig\Template->render(Array) (Line: 55)
twig_render_template('themes/citizen_patterns/templates/zzz-custom/layout/layout--twocol-quad-split.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('layout__twocol_quad_split', Array) (Line: 422)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
Drupal\Core\Render\Renderer->render(Array) (Line: 479)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 221)
__TwigTemplate_8e8ddbeacf22bec82b0db581af4be584->block_layoutSectionContent(Array, Array) (Line: 182)
Twig\Template->displayBlock('layoutSectionContent', Array, Array) (Line: 194)
__TwigTemplate_8e8ddbeacf22bec82b0db581af4be584->block_layoutSections(Array, Array) (Line: 182)
Twig\Template->displayBlock('layoutSections', Array, Array) (Line: 154)
__TwigTemplate_8e8ddbeacf22bec82b0db581af4be584->block_node(Array, Array) (Line: 182)
Twig\Template->displayBlock('node', Array, Array) (Line: 58)
__TwigTemplate_045d80dce83336544d39f3d671ded776->doDisplay(Array, Array) (Line: 405)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
Twig\Template->display(Array, Array) (Line: 53)
__TwigTemplate_8e8ddbeacf22bec82b0db581af4be584->doDisplay(Array, Array) (Line: 405)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
Twig\Template->display(Array) (Line: 390)
Twig\Template->render(Array) (Line: 55)
twig_render_template('themes/citizen_patterns/templates/zzz-custom/content/node.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('node', Array) (Line: 422)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 241)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 564)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 242)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 132)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 174)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 709)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Steps to reproduce

I'm not sure I can describe how to reproduce this error reliably but it seems to be related to the use of paragraphs. On the site I'm working on, if the page does not have a paragraph reference, no errors display. The error only shows on pages with paragraphs. Regardless of the cause, the variable needs to checked for a value prior to running any string functions on it.

Proposed resolution

Adding this snippet to line 219 of the web/core/lib/Drupal/Component/Utility/Html.php appears to remedy the problem:

  if (!$id) {
    return;
  }

or converting the code on line 219 to a ternary statement appears to work as well:

  $id = $id ? istr_replace(['', '_', '[', ']'], ['-', '-', '-', ''], mb_strtolower($id)) : '';

Problem/Motivation

In the Drupal 8 cycle we removed most info hooks and replaced them with plugins.

In #3356894: Make field selection less overwhelming by introducing groups we added a new one hook_field_type_category_info

That issue represents a huge win for Drupal so we didn't want to slow progress debating whether it should be a hook or plugins.

This issue is to explore that further.

Steps to reproduce

Proposed resolution

See what the code looks like using YML discovery with an alter hook.
Add a default plugin implementation and change some of the logic in FieldStorageAddForm to it (e.g ->getWeight, ->getDescription, ->isDefault)
Consider bundling in #3372092: [PP-1] Allow hook_field_type_category_info entries to define libraries too

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

It is now necessary that a module is enabled, so that the service exists to use it.

I don't think that is bad but I think we could handle the fact that the service doesn't exist much more nicely and simply fall back to the default if not provided.

Proposed resolution

In CacheFactory::get(), check if the specified service in $cache_settings exists before calling it (bin specific and default). Don't check the default backends. Should be possible to simply specify that inline in the existing if cases.

Add a hook_requirements() to tell people something is wrong.

Remaining tasks

User interface changes

API changes

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 run Webpack 5 with Browsersync on my Drupal website. Whenever I acces the website locally via the IP-address and port for Browsersync to work, a piece of code get's printed. The code doesn't appear when visiting the website via the url.

When I uninstall the Toolbar module, the code dissappears.

Steps to reproduce

• Webpack 5
• Browsersync
• Enable Toolbar
• Visit website via IP-adres in order for Browsersync to work

This is the code that appears, but I can't find from which file it originates. It get's printed right after the body opening tag.

, but this code
  // executes before the first paint, when  is not yet present. The
  // classes are added to  so styling immediately reflects the current
  // toolbar state. The classes are removed after the toolbar completes
  // initialization.
  const classesToAdd = ['toolbar-loading', 'toolbar-anti-flicker'];
  if (toolbarState) {
    const {
      orientation,
      hasActiveTab,
      isFixed,
      activeTray,
      activeTabId,
      isOriented,
      userButtonMinWidth
    } = toolbarState;

    classesToAdd.push(
      orientation ? `toolbar-` + orientation + `` : 'toolbar-horizontal',
    );
    if (hasActiveTab !== false) {
      classesToAdd.push('toolbar-tray-open');
    }
    if (isFixed) {
      classesToAdd.push('toolbar-fixed');
    }
    if (isOriented) {
      classesToAdd.push('toolbar-oriented');
    }

    if (activeTray) {
      // These styles are added so the active tab/tray styles are present
      // immediately instead of "flickering" on as the toolbar initializes. In
      // instances where a tray is lazy loaded, these styles facilitate the
      // lazy loaded tray appearing gracefully and without reflow.
      const styleContent = `
      .toolbar-loading #` + activeTabId + ` {
        background-image: linear-gradient(rgba(255, 255, 255, 0.25) 20%, transparent 200%);
      }
      .toolbar-loading #` + activeTabId + `-tray {
        display: block; box-shadow: -1px 0 5px 2px rgb(0 0 0 / 33%);
        border-right: 1px solid #aaa; background-color: #f5f5f5;
        z-index: 0;
      }
      .toolbar-loading.toolbar-vertical.toolbar-tray-open #` + activeTabId + `-tray {
        width: 15rem; height: 100vh;
      }
     .toolbar-loading.toolbar-horizontal :not(#` + activeTray + `) > .toolbar-lining {opacity: 0}`;

      const style = document.createElement('style');
      style.textContent = styleContent;
      style.setAttribute('data-toolbar-anti-flicker-loading', true);
      document.querySelector('head').appendChild(style);

      if (userButtonMinWidth) {
        const userButtonStyle = document.createElement('style');
        userButtonStyle.textContent = `#toolbar-item-user {min-width: ` + userButtonMinWidth +`px;}`
        document.querySelector('head').appendChild(userButtonStyle);
      }
    }
  }
  document.querySelector('html').classList.add(...classesToAdd);
})();

Problem/Motivation

Spun off from this request for Drupal 7 (token module): #823780: Add site logo token, where a token for the logo and logo-url have been proposed. However, since all site:* tokens are in core, I feel this belongs to core as well. Therefore I am proposing it here for Drupal 8.

Proposed resolution

The new tokens are [site:logo] and [site:logo-url] and they provide a rendered image and a local path respectively. In addition to that, both tokens also take a theme parameter ([site:logo:?], [site:logo-url:?]) to fetch a logo for a specific theme.

Steps to reproduce:
- without applying patch, install and enable 'token' module (so you can easily browse the list of available tokens)
- edit Article content type, go to manage fields, edit Body
- click "Browse available tokens" link underneath Help text, to open Available tokens popup
- verify no site logo tokens in the Site information list

- now apply patch
- drush cr
- reload Available tokens popup, verify [site:logo] and [site:logo-url] added
- insert them into help text and create or edit an article to verify the Drupal logo and standard URL (/core/themes/bartik/logo.svg) are now visible
- configure a different logo for another theme (seven)
- insert [site:logo:seven] and [site:logo-url:seven] to have the logo show up.
- [site:logo:non-existing-theme] should not be replaced

Remaining tasks

Review.
Resolve #2855653: FilterHtmlImageSecure filters out valid local svg images so the default logo's work as well (user uploaded png/jpg files already work).

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

The original problem was that SQLite has a variable limit of 999 for versions before 3.32.0 (core 10 requires SQLITE_MINIMUM_VERSION = '3.26') which is not configurable and which makes this database driver unusable for medium sized sites. The solution that we came up with is combining multiple inserts and updates in a single query, which makes SQLite a lot faster. The newer minimum required version of SQLite has a much higher variable limit and therfor it is no longer a problem in combination with Drupal. Only it makes multiple insert queries and multiple upsert queries a lot faster. See #2031261-124: Make SQLite faster by combining multiple inserts and updates in a single query. In the order of from 108k microseconds to 16k microseconds.

Proposed resolution

Combining multiple inserts and in a single query and combining multiple upserts and in a single query. For both queries is having more than 50 variables the limit for merging it into a single query.

Original report by @axel.rutz

SQLite performance Optimization: PDO::ATTR_EMULATE_PREPARES

Like we've done on Mysql and Postgres we should also do on Sqlite. See #827554: PostgreSQL performance Optimization: PDO::ATTR_EMULATE_PREPARES.

(As suggested by Damien Tournoud in #2028713-11: Menu router does "too many SQL variables" on SQLite resulting in silent nondisplay of menu items)

See #2028713: Menu router does "too many SQL variables" on SQLite resulting in silent nondisplay of menu items but this can bite us in any other place too.

A first patch that set PDO::ATTR_EMULATE_PREPARES on the connection (proposed by Damien Tournoud) did not work out probably due to a bug in the underlying driver. This can be reproduced as outlined in #2028713-18: Menu router does "too many SQL variables" on SQLite resulting in silent nondisplay of menu items:

php > $options = array(
php (   PDO::ATTR_EMULATE_PREPARES => true,
php (   PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
php ( );
php > $dbh=new PDO('sqlite:dummy.sqlite', NULL, NULL, $options);
php > $dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES, true); // Give it another try.
php > $values = range(1,1111);
php > $placeholders = implode(',', array_fill_keys(array_keys($values), '?'));
php > $query = "select v from (select 0 v) where v not in ($placeholders);";
php > $stmt = $dbh->prepare($query);
PHP Warning:  Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 1 too many SQL variables' in php shell code:1

Problem/Motivation

This came up in #2953566: Allow entities to specify a "collection permission".

Currently there is no expansive documentation about an entity type's admin_permission or collection_permission annotation keys. The only thing that exists is:

The name of the default administrative permission.

which is the property documentation of \Drupal\Core\Entity\EntityType::$admin_permission,

The name of the collection permission.

which is the property documentation of \Drupal\Core\Entity\EntityType::$collection_permission

and this bit in entity.api.php about access handlers:

If your configuration entity has complex permissions, you might need an access control handling, implementing \Drupal\Core\Entity\EntityAccessControlHandlerInterface, but most entities can just use the 'admin_permission' annotation property instead.

But there is no actual documentation about what the admin permission and collection permission do concretely.

Steps to reproduce

-

Proposed resolution

1. Change the documentation of \Drupal\Core\Entity\EntityType::$admin_permission to be:
   

   The name of the administrative permission.

   This permission must be declared separately by the module providing the entity type. Users with the administrative permission by default are allowed to perform any operation (for example create, view, update or delete) on any entity of the type and are granted access to the overview (or collection) of the entities of that type, if one exists. If a custom access control handler is declared, access can be restricted even for users with this permission.

2. Change the documentation of \Drupal\Core\Entity\EntityType::$collection_permission to be:
   

   The name of the collection permission.

   This permission must be declared separately by the module providing the entity type. Users with the collection permission by default are allowed to access the overview (or collection) of the entities of that type, if one exists. It does not grant access to any particular entities, but in combination with other permissions makes it possible to grant users, for example, access to view entities of this type in the overview, but not edit or delete them or only grant users access to manage certain entities from the overview, but not all of them. If a custom access control handler is declared, access can be restricted even further for users with this permission or, alternatively, further access can be granted.

Remaining tasks

User interface changes

-

API changes

-

Data model changes

-

Release notes snippet

-

Problem/Motivation

When you have more than one usage for a file, in the list of usages of this file (the page_2 of views.view.files.yml), each usage is listed the same amount of times as results are. As the view is doing a join between file_managed and file_usage and then again another join with file_managed with the result.

Steps to reproduce

Here is some code to reproduce the issue (if you use the same file in 2 nodes, you will have 4 rows on the file usage page; if you use the same file in 3 nodes, you will have 9 rows on the file usage page; if you use the same file in 4 nodes, you will have 16 rows on the file usage page, etc.):

$file = \Drupal\file\Entity\File::create([
  'uri' => 'public://test.png',
]);
$file->save();
$node = \Drupal\node\Entity\Node::create([
  'type' => 'article',
  'title' => 'Test 1',
  'field_image' => ['target_id' => $file->id()],
]);
$node->save();
$node = \Drupal\node\Entity\Node::create([
  'type' => 'article',
  'title' => 'Test 2',
  'field_image' => ['target_id' => $file->id()],
]);
$node->save();
drupal_flush_all_caches();

Proposed resolution

This is due to a double join between file_managed and file_usage, remove the duplicated join.
We should remove the following duplicate join of file_managed from the FileViewsData.php

$data['file_usage']['table']['join'] = [
      'file_managed' => [
        'field' => 'fid',
        'left_field' => 'fid',
 ],

Remaining tasks

1. Needs review

User interface changes

N/A

API changes

TBD

Data model changes

N/A

Release notes snippet

N/A

Problem/Motivation

Error: Call to a member function has() on null in Drupal\Core\Mail\Plugin\Mail\PhpMail->mail() (line 114 of core/lib/Drupal/Core/Mail/Plugin/Mail/PhpMail.php).
Drupal\mailsystem\Adapter->mail(Array) (Line: 307)
Drupal\Core\Mail\MailManager->doMail('reroute_email', 'test_email_form', 'reniersediego@prometsource.com', 'en', Array, NULL, 1) (Line: 180)
Drupal\Core\Mail\MailManager->Drupal\Core\Mail\{closure}() (Line: 583)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 181)
Drupal\Core\Mail\MailManager->mail('reroute_email', 'test_email_form', 'reniersediego@prometsource.com', 'en', Array, NULL, 1) (Line: 70)
Drupal\mailsystem\MailsystemManager->mail('reroute_email', 'test_email_form', 'reniersediego@prometsource.com', 'en', Array) (Line: 191)
marquettelaw_custom_form_alter(Array, Object, 'reroute_email_test_email_form') (Line: 545)
Drupal\Core\Extension\ModuleHandler->alter('form', Array, Object, 'reroute_email_test_email_form') (Line: 840)
Drupal\Core\Form\FormBuilder->prepareForm('reroute_email_test_email_form', Array, Object) (Line: 284)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 583)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 166)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 74)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Steps to reproduce

Run

\Drupal::service('plugin.manager.mail')->mail('reroute_email', 'test_email_form', 'reniersediego@prometsource.com', 'en',
    [
      'cc' => '',
      'bcc'=> '',
      'subject' => 'test',
      'body' => 'test'
    ]);

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

TypeError: Cannot assign null to property Drupal\views\Plugin\views\argument\ArgumentPluginBase::$operator of type string in Drupal\views\Plugin\views\argument\NumericArgument->query() (line 96 of C:\xampp\htdocs\cmacgm\drupal-10\docroot\core\modules\views\src\Plugin\views\argument\NumericArgument.php).

Steps to reproduce

TBA

Proposed resolution

Remaining tasks

See question in #16

User interface changes

API changes

Data model changes

Release notes snippet

This is postponed on:

a) #2920309: Add experimental module for Help Topics being committed

b) #3027054: Help Topics module roadmap: the path to beta and stable having all the other tasks being done.

So the task for this module is to finally merge the Help Topics module into the core Help module for stable release. Sub-tasks:

• Merging the hook_help() from the experimental Help Topics module into existing topics
• Making sure that no help topics mention the Help Topics module (because it will be part of the Help module instead).
• Adding to the drupal.org docs page for the existing Help module
• #3087499: Merge Help Topics classes into Help with BC layer
• Changing function names of hook implementations, deprecate help_topics' classes
• The standard things done in Core to finalize a module, such as adding templates to the Stable/Classy themes, updating the module category in the .info.yml file, removing @internal tags, adding @api tags, etc., (Is there a standard procedure for this?)
• #3025577: Move help topics to core or the correct modules
• #3144933: Merge help topics admin theme test into base class
• #3358340: Update help.help_topic_search to remove mention of Help Topics module
• #3370070: Update Maintainers for the Help module
• ...issue to remove help topics in D11 ... [TBD]
• #3074040: Move testing of help topic rendering into InstallUninstallTest
• #3031642: Deprecate hook_help() and combine with Topics -- the part about "Deprecate and remove hook_help()"

Problem/Motivation

As part of #2164373: [META] Untie config validation from form validation — enables validatable Recipes, decoupled admin UIs …, we are going to want to validate language codes as language codes, with their own constraints, rather than as plain strings.

Steps to reproduce

N/A

Proposed resolution

Add a new langcode data type to config schema, which implements certain validation constraints that are specific to language codes.

Remaining tasks

Figure out how to implement the feature and add robust test coverage.

User interface changes

None.

API changes

TBD, but there will probably be at least one new config data type (langcode) and possibly a new validation constraint or two.

Release notes snippet

TBD

After we upgraded to Drupal 10.1 we also changed the nginx configuration as the release notes mentioned. But some cases we found that when the asset aggregation is enabled the page does not appeared properly in the browser. We found Chrome 114 "Refused to apply style ... because its MIME type ('text/plain') or ('text/troff') is not a supported stylesheet MIME type, and strict MIME checking is enabled."

When I've cleared the generated files, the page is appeared properly. But when i refresh the page, the browser got these assets with the wrong Content type header.

If I modify the AssetControllerBase::deliver method, the add "Content-type" header the probleam disapears.

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