While developing a module that extends the External Entities contrib module, I've been working on views support. A view using fields is working fine, but I found that if I selected the option to display rendered entities instead, nothing appears.

I've traced this back to the fact that the external_entities_views_pre_render hook invokes $view->getDependencies. As you might expect, getDependencies ensures that all the required plugins are initialised, as part of building the list of dependencies. In the case of the Grid style plugin, which doesn't override the init method in the abstract StylePluginBase class, this results in line 122 of StylePluginBase being invoked, replacing the rowPlugin instance with a fresh one that has a null value for entityTranslationRenderer, rather than the instance previously instantiated. This, in turn, results in no results being displayed when the render call for the view is invoked.

On my local, I have added && !$this->view->rowPlugin to the test in line 121, and I then get results appearing, as expected. Patch coming once I know the issue number.

Hello, running:

phpcs --standard=Drupal,DrupalPractice,PHPCompatibility --extensions=php composer

reports few issues with phpdoc comments as are currently set via the PHP_CodeSniffer rules.

To not fix an entire code base at once and have too big and unmanageable patch file, I'm opening this issue separately for the composer dir...

Thanks.

With Inline Form Errors module enabled errors on datetime render (form) elements are repeated.
The error should just be thrown once.
Or if there is an specific error for one of the input/selects it should be shown only for that part of the element.

Before:

Problem/Motivation

This is issue is spun off from UX team feedback on #2831944-203: Implement media source plugin for remote video via oEmbed.

For security reasons, the oEmbed system uses an iframe to serve content from a third-party oEmbed provider. By default. the iframe is served from the same domain as the main Drupal site, but this is not secure. Therefore, Media introduced a setting, exposed in a configuration form, which allows site builders/admins to set up an alternate domain from which to serve the iframe.

In order to serve oEmbed content more securely, the iFrame domain needs to point to the Drupal site. This is explained on the form, but not validated in any way.

Proposed resolution

It would be nice to add some sort of validation to ensure that the iFrame domain is actually pointing to the Drupal site, because if it isn't, then almost all oEmbed content on the site will break (404 errors or worse), which scare the pants off of our users.

Remaining tasks

1. Discuss if we should even do this, and if so, how to do it in a way that will please the security team.
2. Write a patch
3. Review it until we're all sick of looking at it
4. Commit it

User interface changes

TBD, but probably none.

API changes

TBD, but probably minimal or none.

Data model changes

None anticipated.

If Drupal uses a node as startpage, and an admin deletes that user (ignoring that the user has ownership of nodes) the website has no frontpage and gives an error.

I suggest an extra check when a user gets deleted that displays a message like "If you deletes this owner and his/hers content, the website will have no frontpage. Are you sure you want to do that?" or perhaps even a level of security that prevents admin from deleting that particular user and his/hers content.

Problem/Motivation

The introduction of hasTranslationChanges() and using it when validating entities introduced some problems with field types that don't return TRUE when they should.

Before that, it was only used in the storage to optimize saving, so it was only a minor performance issue when the field values had to updated wen it actually wasn't necessary.

Now, it can prevent users from saving translations, without any workaround, so I'm setting this to major.

One example in core is the image field, from #2826021-48: FieldItemList::equals is sufficient from the storage perspective but not for code checking for changes:

Unfortunately it's not quite that simple. The widget used for images can end up submitting with no change in the referenced image, but clearing the height & width. So currently that's then considered a change, even though the preSave would only go and set the height & width properties what they already are in storage. ie. something like the following are compared:

array(
  'file reference' => 'fid123',
  'height' => NULL,
  'width' => NULL,
  'alt' => 'no change',
)

vs

array(
  'file reference' => 'fid123',
  'height' => '456',
  'width' => '789',
  'alt' => 'no change',
)

Those are not considered equal, even though the height & width in the first array will get set to '456' and '789' by preSave. I hope that makes sense?

Additional examples can be found in contrib, from #2826021-41: FieldItemList::equals is sufficient from the storage perspective but not for code checking for changes:

We've been testing this in our distribution as part of enabling and using content moderation. We've been running into some problems with more complex field types, problems identified so far:

GeolocationItem: It has a bunch of extra properties that it recalculates in preSave(), but that's only called after validation. I had some success in fixing that by doing that logic in setValue(), or maybe an onChange so that the computed + stored properties are always in sync if you change lat/long. However, it also has a map property that isn't set at all and then the properties don't match. Worked around that by initializing that in setValue() to an empty array, but that's kind of an API change?

WebformEntityReferenceItem: Same deal with a map property.

What seemed to help with the data properties was to put an array_filter() into the callback in FieldItemList::equals(), but not sure if that makes sense? Does seem fine to ignore a property being NULL/''/[] with one that's not set at all, which == fails on?

Proposed resolution

There are multiple approaches on how to deal with it, for example not doing value recalucation in preSave() but doing that in setValue(), to make sure it is always consistent, or overriding the equals() method to ensure it happens there.

Fix the field types in core, test them, create a change record to help contrib do the same.

Remaining tasks

User interface changes

None.

API changes

Likely none.

Data model changes

Also none.

Problem/Motivation

This issue is in relation to https://www.drupal.org/project/drupal/issues/2865579 and the removal of the revision tracker table in favor of a simple SQL query to return latest revision. While this change makes sense it seems to have a very negative impact on larger sites that have very large revision tables.

A client I'm currently working with has recently made the update to content moderation from workbench moderation. With workbench moderation we previously were able to return the latest revision of nodes to editors through a view. Now after updating to content moderation, the same views configurations will completely lock up the db. Instead of hitting a much smaller latest revision table we have to now query a much larger revisions table.

It seems without that revision tracker table our only real course of action will be to destroy revision history to make the revision tables as small as possible and hopefully improve performance that way. While it may not be necessary to maintain a complete revision history it still seems that there should be a better solution to this issue though.

Problem/Motivation

When settings the default value for a "Text (formatted)" field (either as a textfield, textarea, or textarea with summary), if you only set the default format, the result is not saved. In order to save the default format, you must enter non-whitespace text in the default value field. This is a usability issue as site builders want to specify a given text format (and, thus, the WYSIWYG editor config or the lack of an editor altogether) for a field without entering default text.

Proposed resolution

Include the format value in \Drupal\text\Plugin\Field\FieldType\TextItemBase::isEmpty().

Remaining tasks

1. Write patch.
2. Write tests.
3. Write change record for TextItemBase::isEmpty

User interface changes

None. Other than the expected result of having your settings saved! :)

API changes

Classes that extend TextItemBase will need to consider the change to the isEmpty() method.

Data model changes

None.

Original report

I try to set a default text format to a field (Long text) but it's not saved if i don't set a default value for the field.

1. I edit the field
2. I set the Text processing to "Filtered text (user selects text format)"
3. I set "Text format" to a another text format
4. Then i save

If i also set a default value for my field, my text format is set as default
But if i leave the default value of my field, it's not saved.

The function "text_field_is_empty (field/modules/text/text.module - line 51-)" is called. This function check only the value for the field, not the format. It return true and the function "_field_filter_items (field/field.module - line 51-)" unset this item including my text format.

If i change the function function text_field_is_empty

function text_field_is_empty($item, $field) {
  if ((!isset($item['value']) || $item['value'] === '') && (!isset($item['format']) || $item['format'] === '')) {
    return !isset($item['summary']) || $item['summary'] === '';
  }
  return FALSE;
}

to

function text_field_is_empty($item, $field) {
  if (!isset($item['value']) || $item['value'] === '')) {
    return !isset($item['summary']) || $item['summary'] === '';
  }
  return FALSE;
}

my text format is set as default event i don't enter a default value for my field.

But i'm not sure it's the good way to fix this issue.

Problem/Motivation

Update drupal/coder to the latest version.

• Includes PHP 7.4 support
• Bugfixes
• #2958175: Add rule to prevent direct usage of $_GET, $_POST, $_REQUEST and $_FILES in Drupal 8

Proposed resolution

Fix failing coding standards. Note DateTimePlus contains some non-standard documentation that doesn't work. See $settings documentation on https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Date...

    * @param array $settings
    *   @see __construct()

The @see does not work at all - and doesn't work in PHPStorm either. Fortunately there are other methods that already have

   * @param array $settings
   *   (optional) A keyed array for settings, suitable for passing on to
   *   __construct().

so we can copy that.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation
Progress throbber position and styling are incorrect while viewing in table display as compared with other displays.

Steps to replicate
Example:
1. Go to admin/structure/block and click on place block to check the throbber effect.
2. After that click on the place block button from place block modal popup form and check the throbber effect.

See the below screenshots

Problem/Motivation

When processing a queue, it's common to run into situations where a single item cannot be processed. For example, perhaps an upstream URL is 404'ing, while other URLs in other queue items work fine. If the worker throws a SuspendQueueException, or nothing at all, all items end up blocked on the single failing item.

In the HTTP 404 case, the error is often transient and will solve itself, in which case trying again later provides a near seamless experience. In other cases (such as a broken queue item), at least other items in the queue won't be blocked from processing.

Proposed resolution

Let's allow queue processors to recreate items at the bottom of a queue, and allow queue workers to throw an exception indicating that the individual queue item is broken and should be recreated.

Remaining tasks

User interface changes

None.

API changes

reCreateItem becomes a new interface method required for queue implementations. This doesn't violate our b/c policy today as the interface isn't marked as @api, but if that was a concern we could create a new RecreateQueueInterface for the new method.

Data model changes

None.

Problem/Motivation

Currently the Secondary tabs are using the wrong size and spacing, taking too much vertical space:

Proposed resolution

Correct secondary tabs styles according to the design system. Full specs can be checked on Figma, and here's an screenshot:

User interface changes

Vertical spacing will be smaller.

Test instructions

- /admin/content
- /admin/people

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the breakpoint, color, layout_builder, layout_discovery, and field_layout modules.

Also the parts of the system module related to installing/uninstalling/configuring themes.

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
   

     switch ($route_name) {
       case 'help.page.contact':
   

   And ends either at the end of the function, or where you find another case 'something': line.

3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig (and "MODULENAME" can be "core" as discussed above).
7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

1. Apply the patch.
2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
4. Review the topic text that you can see on the page, making sure of the following aspects:
   • The text is written in clear, simple, straightforward language
   • No grammar/punctuation errors
   • Valid HTML -- you can use http://validator.w3.org/ to check
   • Links within the text work
   • Instructions for tasks work
   • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the views, views_ui module(s).

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
   

     switch ($route_name) {
       case 'help.page.contact':
   

   And ends either at the end of the function, or where you find another case 'something': line.

3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig (and "MODULENAME" can be "core" as discussed above).
7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

1. Apply the patch.
2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
4. Review the topic text that you can see on the page, making sure of the following aspects:
   • The text is written in clear, simple, straightforward language
   • No grammar/punctuation errors
   • Valid HTML -- you can use http://validator.w3.org/ to check
   • Links within the text work
   • Instructions for tasks work
   • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the admin UI-related modules: contextual, help, inline_form_errors, quickedit, settings_tray, shortcut, toolbar, tour module(s).

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
   

     switch ($route_name) {
       case 'help.page.contact':
   

   And ends either at the end of the function, or where you find another case 'something': line.

3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig (and "MODULENAME" can be "core" as discussed above).
7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

1. Apply the patch.
2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
4. Review the topic text that you can see on the page, making sure of the following aspects:
   • The text is written in clear, simple, straightforward language
   • No grammar/punctuation errors
   • Valid HTML -- you can use http://validator.w3.org/ to check
   • Links within the text work
   • Instructions for tasks work
   • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the basic_auth, hal, jsonapi, rdf, rest, and serialization modules.

NOTE: What is below is the generic instructions for converting hook_help to topics. We want to end up with task-based topics; in this case, there really aren't "tasks" per se for these modules. So let's just make one topic called something like "Enabling web services on your site" with a filename starting with "core." (so it is not in one module's namespace), and describe what web services are, and what each of these 5 web services modules does.

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core RDF module, the module files is core/modules/rdf/rdf.module, and the function is called rdf_help().
2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
   

     switch ($route_name) {
       case 'help.page.contact':
   

   And ends either at the end of the function, or where you find another case 'something': line.

3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the RDF module, you could create a topic about managing actions with filename rdf.overview.html.twig (and "MODULENAME" can be "core" as discussed above).
7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

1. Apply the patch.
2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/rdf.overview.html.twig, you can view the topic at the URL admin/help/topic/rdf.overview within your site.
4. Review the topic text that you can see on the page, making sure of the following aspects:
   • The text is written in clear, simple, straightforward language
   • No grammar/punctuation errors
   • Valid HTML -- you can use http://validator.w3.org/ to check
   • Links within the text work
   • Instructions for tasks work
   • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Hi ,

The issue is after submitting registration form by site users form fields not clear its value so anyone see the major details of the previous user.

Problem/Motivation

Follow up to #3075695: Move search_index() and related functions to a service there are a number of text processing/tokenisation functions that can be moved to a service and deprecated. This includes:

• search_index_split()
• search_simplify()
• search_expand_cjk()

Proposed resolution

Move them to a SearchTokenizer service and deprecate.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

#3096078: Display core compatibility ranges for available module updates added displaying core compatibility ranges for available module updates. @dww had some followup concerns with the code comments in #3096078-28: Display core compatibility ranges for available module updates onwards. Transporting patches here for continued work.

Proposed resolution

Discuss, refine and commit.

Remaining tasks

Discuss, refine and commit.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A.

Problem/Motivation

In #2826722: Add a 'fence' around settings tray with aggressive CSS reset., insufficient testing resulted in multiple select elements being styled in an unusable manner:

Proposed resolution

Update 'core/themes/stable/css/core/dialog/off-canvas.form.css' as follows:

  #drupal-off-canvas input[type="radio"] {
    -webkit-appearance: radio;
  }
-  #drupal-off-canvas select {
+ #drupal-off-canvas select:not([multiple]) {
    -webkit-appearance: menulist;
    -moz-appearance: menulist;
  }
+ #drupal-off-canvas select[multiple] option {
+   color: initial;
+   background: initial;
+ }
  #drupal-off-canvas option {
    display: block;
    font-family: "Lucida Grande", "Lucida Sans Unicode", "liberation sans", sans-serif;

The following is the result:

Remaining tasks

• Submit patch
• Community review
• Commit

User interface changes

Multiple select elements rendered in the settings tray will be styled in a useable manner.

API changes

None.

Data model changes

None.

Release notes snippet

None.