Maybe I'm missing something, but if the Inline Form Errors module is stable as of 8.4.0 and if its goal is to have "improved usability and accessibility" when there are errors displayed on a form, Drupal turn it on by default once it's ready.

Postponed on

#2856950: Add a possibility to disable inline form errors for a complete form
#2848507: Indicate that grouping elements have child element errors for ux and a11y

Problem/Motivation

Functions like t() are not bad and working around the availability for unit tests is a pain. We can include bootstrap.inc using composer and then tests etc will work without having to fake t().

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Connection::query can overload the $query argument to be either a string or an already prepared statement. This is a bit confusing, since the logic of potentially calling query to get a statement and then query again with the statement as input is weird. Normally in PHP world you would prepare a statement, execute it and iterate to fetch the results - then execute it again with different $args if you want to reuse.

Also the current status will prevent in the future to typehint the $query argument, which is now possible in PHP 7+.

Proposed resolution

- Deprecate passing a StatementInterface as $query argument to Connection::query.
- Move processing of the results of StatementInterface::execute from Connection::query to StatementInterface::execute.
- When a database operation is started with a Connection::prepareStatement, follow suit with StatementInterface::execute and StatementInterface::fetch.
- Keep Connection::query as a convenience helper that prepares the statement and executes it in one go.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Sample entity value generation generates long strings for text fields. This can cause the layout to break, as noted in #3016507: Break long text strings in layout edit

Proposed resolution

Rather than use \Drupal\Component\Utility\Random::word, which often generates very long words, use \Drupal\Component\Utility\Random::paragraphs, which uses words from a selection of shorter words.

Remaining tasks

Write a patch.

User interface changes

None-ish.

API changes

None

Data model changes

None

Problem/Motivation

#2272801: Allow blocks to be context aware. allows classes extending BlockBase to also be context-aware.
However, this shouldn't be needed, since many different plugins should be able to opt into context without breaking their parent class relationship

Proposed resolution

Figure out a way to make a ContextAwarePluginTrait.

Remaining tasks

The main problem here is the differences between \Drupal\Component\Plugin\ContextAwarePluginBase and \Drupal\Core\Plugin\ContextAwarePluginBase

User interface changes

N/A

API changes

API additions only.

I'm migrating content from a Joomla SQL source. The images are stored inside of the text as inline images.

This is how my source data looks like:

Here is my Source:

    /**
     * Source plugin for image content.
     *
     * @MigrateSource(
     *   id = "image"
     * )
     */
     class Image extends SqlBase {

       /**
        * {@inheritdoc}
        */
       public function query() {
         $query = $this->select('jos_content', 'content');
         $query->fields('content', array(
           'id',
           'introtext',
         ));

         $query->condition('content.state', 1);
    
         $query->condition('content.introtext', '%<img%', 'LIKE');

         return $query;
       }

       ...

But this query does not produce one Row per Match, it produces one row for each source row where are at least is one image. I don't know if it's possible to process this in my migration .yml file:

    id: image
    label: Images migration
    migration_group: joomla
    migration_tags:
      - Images
    source:
      plugin: image
      constants:
        file_source_uri: 'public://import'
        file_dest_uri: 'public://imported'
        status: 1
    destination:
      plugin: 'entity:file'
    process:
      file_source:
    -
      plugin: concat
      delimiter: /
      source:
        - constants/file_source_uri
        - path
      file_dest:
        -
          plugin: concat
          delimiter: /
          source:
            - constants/file_dest_uri
            - filename
      filename: filename
      uri:
        plugin: file_copy
        source:
          - '@file_source'
          - '@file_dest'
      status: constants/status
    migration_dependencies:
      required: {  }
      optional: {  }
    dependencies:
      enforced:
        module:
          - migrate_content

This configuration works only if there is one image per Migration Row, but there are multiple items per row.

So basically I have a source node with inline images inside the main text (so I only have an src to the image, nothing else). But I want to import these images not as inline images in the new Drupal node, I want to import them in a new media image field inside the new node.

I would appreciate any help, thank you!

Problem/Motivation

AssertLegacyTrait::assertFieldById() is deprecated in drupal:8.2.0 and is removed from drupal:10.0.0. Use $this->assertSession()->fieldExists() or $this->assertSession()->buttonExists() or $this->assertSession()->fieldValueEquals() instead. See https://www.drupal.org/node/3129738

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the comment, node, path, taxonomy 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 content_moderation, workflows 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.

Followup #2999721: [META] Deprecate the legacy include files before Drupal 9

Problem/Motivation

There is already an existing utility Error class. So lets keep things together.
Deprecate legacy errors.inc file functions. Just get rid of errors.inc file in drupal:10.0.x.

Proposed resolution

Convert all error handler related functions to the methods in the Error class.
That will help to work on the next step of modernizing Drupal error handler in #1722694: Replace Drupal's error handling with Symfony/HttpKernel's without carrying out of legacy errors.inc file loading BC layer in Drupal 10.0.0.

Remaining tasks

• Deprecate functions
• Replace usages in the code
• Add legacy tests

User interface changes

-

API changes

• new methods in \Drupal\Core\Utility\Error class
• deprecated error handler related functions

Data model changes

-

Release notes snippet

-

Problem/Motivation

When defining annotations with integer based keys, these values get reset by NestedArray::mergeDeepArray in the plugin constructor because $preserver_integer_keys is not set.

Proposed resolution

Switch from mergeDeep to mergeDeepArray and pass TRUE as the second parameter

Remaining tasks

Write tests

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Hi all,

Could someone pls help me to fix this.

The image style module was creating the images before upgrading to drupal 7.72. The thumbnail images and other image style images are or not created after upgrading to drupal 7.72 version. It started working after downgrading to drupal 7.70 version.

Any help is much appreciated

Regards,
Suganya M

When creating a view with a relationship to an entity reference field (to join the referred-to entity in the query), duplicates will be produced if the entity reference field is multi-valued (i.e. cardinality > 1). Users assume that checking the box at Advanced -> Query settings -> Distinct will solve this problem, but it doesn't.

This is because from a database perspective, the records actually aren't duplicates. Each different entity reference in the multi-valued field will produce a different row as the target IDs are different, even though this isn't necessarily reflected in the view itself if not all fields are included. Said another way, the view results may look the same on the front-end, even though they're not on the back-end.

It should be noted that this affects all entity types, whether it be taxonomy terms, nodes, paragraphs, custom entities, etc. There are several duplicates of this issue in various other queues that should be marked as such, with all efforts directed here.

Proposed solution

If the Distinct box is checked in the view configuration, after the query has executed, remove results whose entity IDs are already in the list.

Remaining tasks

1. Produce a patch to solve the basic problem.
2. Add support for pagers (as per #12).
3. Add support for aggregation (as per the D7 version of Views Distinct).
4. Add tests.

Original report

If you have a content type with a multivalue taxonomy term field and add a relationship based on that field in a view (in my case I want to use the term name as an argument) the resulting views result has duplicates if one or more of the nodes has multiple terms in that field.

The DISTINCT keyword does not help, since the tid is added as a field in the SELECT part of the query.

I have the following query:

SELECT DISTINCT node_field_data.sticky AS node_field_data_sticky, node_field_data.created AS node_field_data_created, node_field_data.nid AS nid, taxonomy_term_field_data_node_field_data.tid AS taxonomy_term_field_data_node_field_data_tid
FROM 
{node_field_data} node_field_data
LEFT JOIN {taxonomy_index} taxonomy_index ON node_field_data.nid = taxonomy_index.nid
LEFT JOIN {taxonomy_term_field_data} taxonomy_term_field_data_node_field_data ON taxonomy_index.tid = taxonomy_term_field_data_node_field_data.tid
WHERE (node_field_data.promote = '1') AND (node_field_data.status = '1')
ORDER BY node_field_data_sticky DESC, node_field_data_created DESC

.. which produces duplicates, even though the DISTINCT keyword is present, because the taxonomy_term_field_data_node_field_data.tid makes the duplicate nodes in the results 'distinct'.

Ideally the query should just exclude the field from the SELECT part like this:

SELECT DISTINCT node_field_data.sticky AS node_field_data_sticky, node_field_data.created AS node_field_data_created, node_field_data.nid AS nid
FROM 
{node_field_data} node_field_data
LEFT JOIN {taxonomy_index} taxonomy_index ON node_field_data.nid = taxonomy_index.nid
LEFT JOIN {taxonomy_term_field_data} taxonomy_term_field_data_node_field_data ON taxonomy_index.tid = taxonomy_term_field_data_node_field_data.tid
WHERE (node_field_data.promote = '1') AND (node_field_data.status = '1')
ORDER BY node_field_data_sticky DESC, node_field_data_created DESC

which works an nodes with multiple terms in the field are now only appearing once.

I have couldn't find a way to actually omit the field in the SELECT part of the query, and I'm also not sure, if it could create other issues if removed. But the tid in the select the DISTINCT keyword is useless..

Steps to reproduce.
1. add multivalue taxonomy term field to node type, and add a node with multiple terms selected
2. add a view which uses that field to add a relationship to the term (needed to use the term name as argument)
3. make the view results DISTINCT
4. optionally add the argument (contextual filter) that uses the relationship to filter the views result on the term name.
5. if no argument is given, the node with multiple terms in the field will appear multiple times

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

Drupal\Core\Entity\EntityStorageBase->loadMultiple(Array) (Line: 396)
Drupal\taxonomy\Plugin\views\filter\TaxonomyIndexTid->calculateDependencies() (Line: 51)
Drupal\views\Plugin\views\display\DisplayPluginBase->getPluginDependencies(Object) (Line: 69)
Drupal\views\Plugin\views\display\DisplayPluginBase->calculatePluginDependencies(Object, 7)
array_walk(Array, Array) (Line: 960)
Drupal\views\Plugin\views\display\DisplayPluginBase->calculateDependencies() (Line: 51)
Drupal\Core\Config\Entity\ConfigEntityBase->getPluginDependencies(Object) (Line: 69)
Drupal\Core\Config\Entity\ConfigEntityBase->calculatePluginDependencies(Object) (Line: 290)
Drupal\views\Entity\View->calculateDependencies() (Line: 341)
Drupal\Core\Config\Entity\ConfigEntityBase->preSave(Object) (Line: 300)
Drupal\views\Entity\View->preSave(Object) (Line: 471)
Drupal\Core\Entity\EntityStorageBase->doPreSave(Object) (Line: 426)
Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 263)
Drupal\Core\Config\Entity\ConfigEntityStorage->save(Object) (Line: 390)
Drupal\Core\Entity\Entity->save() (Line: 635)
Drupal\Core\Config\Entity\ConfigEntityBase->save() (Line: 989)
Drupal\views_ui\ViewUI->save() (Line: 326)
Drupal\views_ui\ViewEditForm->save(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 589)
Drupal\Core\Form\FormBuilder->processForm('view_edit_form', Array, Object) (Line: 318)
Drupal\Core\Form\FormBuilder->buildForm('view_edit_form', Object) (Line: 48)
Drupal\Core\Entity\EntityFormBuilder->getForm(Object, 'edit', Array) (Line: 226)
Drupal\views_ui\Controller\ViewsUIController->edit(Object, 'page_3')
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
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: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Fatal error: Call to a member function url() on null in drupal8\core\modules\rdf\rdf.module on line 237

Repro:

1. Enable Testing module
2. Open admin/reports.
3. See bottom of page.

When installing from scratch (with softaculous), a new installation of Drupal 8.9.1 crashes after saving a new default language (in my case Dutch). As from then, all admin links report error-500. Therefore no more administration acts are possible anymore.
I encountered this issue several times, as I have tried to re-install (upon re-install) until I quit trying. PHP version is 7.3.

Problem/Motivation

While triaging #2703713: core link field and token, @larowlan, @xjm, @pameeela and I agreed that we are missing some test coverage for the link field.

For example cases like:

http://www.example.com/?name=ferret&color=purple
http://www.example.com/page?name=ferret&color=purple
http://www.example.com?a=&b[]=c&d[]=e&d[]=f&h==

and

/page?name=ferret&color=purple
/page?a=&b[]=c&d[]=e&d[]=f&h==

Proposed resolution

Update the test coverage in \Drupal\Tests\link\Functional\LinkFieldTest::testURLValidation() add missing cases mapping to $valid_external_entries or $valid_internal_entries

Remaining tasks

Create a patch.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

N/A

When adding a callback in an included file, can error if the function hasn't already been included.

TypeError: Argument 1 passed to Drupal\Core\Batch\BatchBuilder::addOperation() must be callable, string given...

To fix Drupal\Core\Batch\BatchBuilder::setFile() needs to include the file that contains the callback function.

Problem/Motivation

A batch builder object was added in #2401797: Introduce a batch builder class to make the batch API easier to use. The Drupal core should be updated to use the batch builder.

The code to update can most easily be found by looking for the uses of batch_set(). Example usage is in the class comment for \Drupal\Core\Batch\BatchBuilder.

Proposed resolution

Use BatchBuilder in the following core modules:

• config - #2875283: Update config module to use the new batch builder
• locale - #2875288: Update locale module to use the new batch builder
• migrate_drupal_ui - #2875291: Update migrate_drupal_ui module to use the new batch builder
• node - #2875292: Update node module to use the new batch builder
• simpletest - #2875295: Update simpletest module to use the new batch builder
• system - #2875296: Update system module to use the new batch builder
• update - #2875300: Update update module to use the new batch builder
• user - #2875307: Update user module to use the new batch builder

Remaining tasks

• Fix remaining test failures/code review items in the following core modules:
  • simpletest
  • system
  • update
• Review patch

List of contributors

overall: john@johncook.me.uk, mradcliffe
- config: rajeshwari10 at Valuebound, RajeevK at Sirius, Yogesh Pawar at QED42, James.Shee
- locale: lcngeo
- migrate_drupal_ui: rajeshwari10 at Valuebound, RajeevK at Sirius, Yogesh Pawar at QED42
- node: rajeshwari10 at Valuebound, RajeevK at Sirius, borisson_
- simpletest: time2buzzthetower, RajeevK at Sirius
- system: ccasals at Portland Webworks
- update: kavo
- user: ccasals at Portland Webworks

Problem/Motivation

When the batch API was converted into OO syntax the functionality was left as it was in Drupal 8.3 and before. Because of this an error can happen if the file passed into setFile() does not exist.

Proposed resolution

Update the the code in core/lib/Drupal/Core/Batch/Batch.php, as well as other files, to ensure the file exists and log the problem and throw an exception if it does not.

Remaining tasks

• Update the code

User interface changes

None

API changes

None

Data model changes

None