Problem/Motivation

Because of #2807145: [policy, no patch] Allow contrib projects to specify multiple major core branches Drupal 9 may need to retrieve modules that start with 8.x-.

These maybe compatible with Drupal.

Proposed resolution

1. Do not send \Drupal::CORE_COMPATIBILITY(8.x) in update requests. Replace this with 'all'
2. Determine if more information needs to be returned from the update server to determine if the module is compatible with the current version of Drupal. It may need the new core_dependency key added in #2313917: Core version key in module's .info.yml doesn't respect core semantic versioning

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

The Drupal AJAX system automatically attaches behaviors to newly inserted content. The most common way of inserting content is via #ajax['callback'], which inserts new form elements into a form.

Whenever the Drupal.AjaxCommands.insert() command is fired, it attaches behaviors on the new content. But almost immediately afterwards, behaviors are attached again, but this time to the entire form. This results in the same DOM elements getting behaviors attached a second time.

The documentation states helpfully:

    // Reattach behaviors, if they were detached in beforeSerialize(). The
    // attachBehaviors() called on the new content from processing the response
    // commands is not sufficient, because behaviors from the entire form need
    // to be reattached.
    if (this.$form) {
      const settings = this.settings || drupalSettings;
      Drupal.attachBehaviors(this.$form.get(0), settings);
    }

Which means, if we're attaching behaviors on the entire form, there's no need to attach behaviors on the individual elements. Adding a check to prevent this is easy and can save substantial processing client-side.

Problem/Motivation

The only use of AccessCheckInterface::applies in core is in CheckProvider::applies which treats the return value as boolean. Every implementation of this method in core, that being CsrfRequestHeaderAccessCheck::applies happens to return a boolean. AccessManagerTest::testSetChecksWithDynamicAccessChecker has a mock and it returns a boolean. All contrib I can see http://grep.xnddx.ru/search?text=AccessCheckInterface&filename= returns a boolean. If it quacks like a duck and walks like a duck ... is it a duck?

Proposed resolution

Change the doxygen to say it's a boolean.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

The Book module does not fully use the new translation features we have. It doesn't translate the node titles in the different menus it generates.

Steps to reproduce:

• Configure Book content type for translation
• Enable a second language
• Create a book outline in English
• Translate each node in the outline
• Navigate the book in the second language

The nodes get loaded correctly, in the correct language. However, the navigation in the node footer, as well as the Book block, display the node titles in English, which is incorrect.

I'm the maintainer of the Book Translation module. D8 will make much of the module obsolete (which is great). However, it misses this small part.

In Drupal 8, now we can create entity reference fields for configurations such as blocks. I created an entity field and selected "block" for entity type. When i reference a block, it is visible in the node view. But if I try to create a view and add a relationship for this field, it throws an SQL error. This is true for any kind of config reference field. It doesnt happen for node reference or term reference etc.

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'careers._node__field_block' doesn't exist: SELECT node_field_data.nid AS nid FROM {node_field_data} node_field_data LEFT JOIN {node__field_block} node__field_block ON node_field_data.nid = node__field_block.entity_id AND node__field_block.deleted = :views_join_condition_0 LEFT JOIN {} _node__field_block ON node__field_block.field_block_target_id = _node__field_block.id WHERE node_field_data.status = :db_condition_placeholder_1 LIMIT 1 OFFSET 0; Array ( [:db_condition_placeholder_1] => 1 [:views_join_condition_0] => 0 )

Right now when you run a config import and have a storage conflict you get an error that says

"Cannot change the field type for an existing field storage."

While this might be clear when working on one field at a time, it is not specific enough when working with many fields. I propose changing the error message to say something like

"The field storage forcurrent_field_name is already set to current_field_type. Cannot change the field type for an existing field storage"

to make development easier.

Occasionally, I see

Notice: Undefined offset: 1 in drupal_http_request() (line 984 of includes/common.inc).
Notice: Undefined offset: 1 in _drupal_parse_response_status() (line 1113 of includes/common.inc).

from cron, and I've tracked this down to requests made by update.module, such as

http://updates.drupal.org/release-history/security_review/7.x?site_key=Hy1qd02i3Wlx5c3ifmLj18Ex6e9Khk6rJvhEDWcdY-A&version=7.x-1.0&list=security_review

Indeed, I can sometimes get these notices also by clicking on the Check Manually link on admin/modules/update, and that page will show "Failed to get available update data for one project.", not always for the same project though.

What's happening is that $response is empty in line 984:

  list($response, $result->data) = preg_split("/\r\n\r\n|\n\n|\r\r/", $response, 2);

This is a special case that requires separate treatment, and since even a d.o site can return an empty $response, it's not an obscure case.

Note: This error has been reported multiple times on d.o against various projects, but it is NOT a duplicate of #205969: drupal_http_request() assumes presence of Reason-Phrase in response Status-Line.

PHP 7.1 and Drupal commerce, navigating to /admin/commerce/orders to view orders generates the following warning:

Warning: A non-numeric value encountered in theme_pager() (line 329 of /includes/pager.inc).

This is directly the result of the new warnings in php 7.1 performing arithmetic operations on variables that are empty or not integer. While I found this in Drupal commerce, the file generating the warning is in core so I suspect the same would occur outside diurnal commerce.

The code causing the problem is:

$pager_middle = ceil($quantity / 2);

and will generate the warning if $quantity is empty. To fix the problem, I replace the line where $quantity is set :

$quantity = $variables['quantity'];

with

$quantity = empty($variables['quantity']) ? 0 : $variables['quantity'];

I have attached the patch. This is the first time I submit a patch for core, apologies if I'm not following the correct protocol.

Updated #65

Problem/Motivation

• Install content_moderation
• Apply the "Editorial" workflow to articles.
• Create an article node in the published workflow state.
• Goto /admin/content
• Use the bulk action "Unpublish content" on the article node.
• You will see this validation error:
  

Proposed resolution

• Remove the publish/unpublish action
• Provide action plugins for every state
• Dynamically create/update/delete action instances when workflow settings are changed.
• Update moderation_content admin view with the state actions.

Remaining tasks

Dynamically create/update/delete action instances when:

• create/update/delete operation happens on a workflow entity by implementing hook workflow (insert|update|delete).
• changes to the workflow entity happen during config import.
• changes to the workflow entity are done hook_update_N.

Update moderation_content admin view with the state actions.
Add functional test for both cases.

User interface changes

moderation_content admin view will have state change actions.

API changes

No API change only addition.
Adds new moderation state change action and deriver.

Data model changes

None.

Additional People to Credit

There were several issues that had patches that were combined into this one. Additional people to credit, who worked on the other issues:
#3043460: Convert automated_cron module hook_help() to topic(s)
vadim.hirbu
BramDriesen
shwetaneelsharma

#3047585: Convert ban module hook_help() to topic(s)
lisagodare@gmail.com

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the automated_cron, ban, dblog, syslog, system, update, and user modules

Exception: Functionality in the System module that is related to themes should go in #3055055: Convert appearance-related modules: breakpoint, color, layout_builder, layout_discovery, field_layout module hook_help() to topic(s) instead.

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

in #1730874: Add support for loading multiple revisions at once we deprecated doLoadRevisionFieldItems(), but left its use in doLoadMultipleRevisionsFieldItems(). In #3069043: Trigger an error on direct access of ContentEntityStorageBase::doLoadMultipleRevisionFieldItems() and mark it to be set abstract in Drupal 9 We deprecated calling ContentEntityStorageBase::doLoadMultipleRevisionsFieldItems directly and triggered an error, declaring the method would be abstract in Drupal 9

Proposed resolution

Remove the logic and make the method abstract

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

There's a new SF version out.

Run composer update "symfony/*"

Drupal 9 should be handled by #3094007: Update the 9.0.x branch to Symfony 4.4-beta2 as that will require code changes due to new deprecations.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Drupal 8.8:

All Symfony dependencies have been updated to version 3.4.35

Drupal 8.7 and 8.6:

Symfony http-foundation has been updated to version 3.4.35

(maybe):
This includes an upstream security release which does not impact Drupal core.

Problem/Motivation

The 7.x Date module allowed the field to specify which parts of the date to collect (Year, Month, Day, Hour, Minute, and Second):

For parts of the date that are not collected, those are stored as 00. For instance, if one choses to not collect seconds, then the date is stored as 2016-04-03 12:15:00.

Proposed resolution

Add this functionality to the date form widgets.

Remaining tasks

User interface changes

API changes

Data model changes

This shouldn't impact field storage, but would add an option to the field definition config.

Problem/Motivation

As shown in #2699895: Allow configurable date attributes to collect, the Drupal 7 date module allowed the site builder to configure which granularity to collect:

For example, on my personal site, I have a projectNodeType which has a "time range"date field that only cares about year + month granularity. Example: https://wimleers.com/work/project/cdn-far-future-expiration-drupal-7 and https://wimleers.com/work/project/ledgrid.

There are some values like 2008-00-00T00:00 and 2006-10-00T00:00 in the D7 datatabase, which cause a hard failure during migration:

Proposed resolution

Make \Drupal\migrate\Plugin\migrate\process\FormatDate::transform() detect -00-00T and -00T ISO8601 timestamps and transform to valid values.

This then results in the following DB tables in D8:

Remaining tasks

TBD

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

TBD

Problem/Motivation

In the core-recommended package, as well as the core-dev-pinned metapackages we use self.version to represent the desired version of drupal/core.

self.version can be *very* problematic in several situations, leading to a frustrating situation where your site cannot be updated unless you are updating multiple things at a time, or at all if you happen to be on a branch that may or may not resolve properly to a composer version.

Now that we're generating the packages inside of core itself, we can generate the exact version declaration.

Proposed resolution

Change the generators to use the version as declared in core/lib/Drupal.php

Remaining tasks

Release process changes

When a release is being tagged, we must regenerate the metapackages to reflect the tag, and return them to their original -dev state after the release is pushed.

User interface changes

none

API changes

none

Data model changes

none

Release notes snippet

The core version in the core-recommended and core-dev-pinned metapackages will now be pinned to exact versions, and not rely on composer to extrapolate the version.

FAPI #states do not update properly after AJAX requests.

Steps to reproduce

To replicate the bug, you need a content type with a field that makes an AJAX request and another field that has a state dependent on that field. In my use case, I have a content type with an image field and a text field that should only show when an image has been uploaded.
1. Have a content type with an image and a text field
2. Create a custom module that adds a state to your text field to only display when the image field has value. It would look something like this:

use Drupal\Core\Form\FormStateInterface;

function mymodule_form_alter(&$form, FormStateInterface $form_state, $form_id) {
  if ($form_id == 'node_page_form' || $form_id == 'node_page_edit_form') {
    $form['field_my_text_field']['#states'] = [
      'visible' => [
        ':input[name="files[field_my_image_field_0]"]' => ['filled' => TRUE],
      ],
    ];
  }
}

3. Go to your content type and upload an image. You would expect to see field_my_text_field because the image field has an image and the state should react to the AJAX call. However, you won't see field_my_text_field. Save your node, and go back to edit your node. Now you should see field_my_text_field.
4. Apply the patch from #80 and go through the steps again. Now on step 3, you should see field_my_text_field immediately after you upload an image.

Original report

I use a custom module which makes heavy use of the Forms API to do mathematical calculations.

The form which you can see at http://linsenrechner.de/node/27 is rendered with the #states attribute. each line uses a container to display two fields. When these fields are filled, a new line should appear.
This works perfect, BEFORE the calculation button is pressed and the ajax request is done.
After this, the behaviour of the form changes: When two fields of a specific line are filled not only one new line appears. In this case, all lines, which are defined in the form, appear at the same time.

The author of the custom module, sukr_s (http://drupal.org/user/554988) wasn't able to exactly locate the bug, but believes it's in states.js

Here are the form arrays, which are used to create the form at http://linsenrechner.de/node/27

$form['container0'] = array(
   '#type'   => 'container',
   '#weight'        => -53,
); 

$form['container0']['markup0'] = array(
   '#weight'        => -52,
   '#markup' => "<div id='ocalc_header_33'></div>
                 <div id='ocalc_header_33'>$ocalc_sag_height</div>
                 <div id='ocalc_header_33'>$ocalc_zone</div>",
); 


$form['container0'][$wrapper]['sag0'] = array(
    '#type'          => 'textfield',
    '#title'         => $ocalc_sag_height." 0",
    '#title_display' => 'invisible',
    '#weight'        => -51,
    '#maxlength'     => 4,
    '#size'          => 4,
    '#prefix'  => "<div class='form-item-sag0'>$ocalc_zone 0</div>",
    '#field_suffix'  => "mm",
  );

$form['container0'][$wrapper]['zone0'] = array(
    '#type'          => 'textfield',
    '#title'         => $ocalc_zone." 0",
    '#title_display' => 'invisible',
    '#weight'        => -50,
    '#maxlength'     => 4,
    '#size'          => 4,
    '#field_suffix'  => "mm",
  );

$form['container1'] = array(
   '#type'   => 'container',
   '#weight'        => -43,
   '#states' => array('visible' => array(
		':input[name=sag0]'  => array ('filled' => TRUE),
		':input[name=zone0]' => array ('filled' => TRUE),
    ),
  ),
); 


$form['container1'][$wrapper]['sag1'] = array(
    '#type'          => 'textfield',
    '#title'         => $ocalc_sag_height." 1",
    '#title_display' => 'invisible',
    '#weight'        => -42,
    '#maxlength'     => 4,
    '#size'          => 4,
    '#field_suffix'  => "mm", 
    '#prefix' => "<div class='form-item-sag1'>$ocalc_zone 1</div>",
  );
  
 $form['container1'][$wrapper]['zone1'] = array(
    '#type'          => 'textfield',
    '#title'         => $ocalc_zone." 1",
    '#title_display' => 'invisible',
    '#weight'        => -41,
    '#maxlength'     => 4,
    '#size'          => 4,
    '#field_suffix'  => "mm",                   
  );
 
$form['container2'] = array(
   '#type'   => 'container',
   '#weight'        => -33,
   '#states' => array('visible' => array(
		':input[name=sag0]'  => array ('filled' => TRUE),
		':input[name=zone0]' => array ('filled' => TRUE),
		':input[name=sag1]'  => array ('filled' => TRUE),
		':input[name=zone1]' => array ('filled' => TRUE),
    ),
  ),
); 


$form['container2'][$wrapper]['sag2'] = array(
    '#type'          => 'textfield',
    '#title'         => $ocalc_sag_height." 2",
    '#title_display' => 'invisible',
    '#weight'        => -32,
    '#maxlength'     => 4,
    '#size'          => 4,
    '#field_suffix'  => "mm", 
    '#prefix' => "<div class='form-item-sag1'>$ocalc_zone 2</div>",
  );
  
 $form['container2'][$wrapper]['zone2'] = array(
    '#type'          => 'textfield',
    '#title'         => $ocalc_zone." 2",
    '#title_display' => 'invisible',
    '#weight'        => -31,
    '#maxlength'     => 4,
    '#size'          => 4,
    '#field_suffix'  => "mm",                 
  );

 
$form['container3'] = array(
   '#type'   => 'container',
   '#weight'        => -23,
   '#states' => array('visible' => array(
		':input[name=sag0]'  => array ('filled' => TRUE),
		':input[name=zone0]' => array ('filled' => TRUE),
		':input[name=sag1]'  => array ('filled' => TRUE),
		':input[name=zone1]' => array ('filled' => TRUE),
		':input[name=sag2]'  => array ('filled' => TRUE),
		':input[name=zone2]' => array ('filled' => TRUE),
    ),
  ),
); 


$form['container3'][$wrapper]['sag3'] = array(
    '#type'          => 'textfield',
    '#title'         => $ocalc_sag_height." 3",
    '#title_display' => 'invisible',
    '#weight'        => -22,
    '#maxlength'     => 4,
    '#size'          => 4,
    '#field_suffix'  => "mm", 
    '#prefix' => "<div class='form-item-sag1'>$ocalc_zone 3</div>",
  );
  
 $form['container3'][$wrapper]['zone3'] = array(
    '#type'          => 'textfield',
    '#title'         => $ocalc_zone." 3",
    '#title_display' => 'invisible',
    '#weight'        => -21,
    '#maxlength'     => 4,
    '#size'          => 4,
    '#field_suffix'  => "mm",                 
  );

$form['container4'] = array(
   '#type'   => 'container',
   '#weight'        => -13,
   '#states' => array('visible' => array(
		':input[name=sag0]'  => array ('filled' => TRUE),
		':input[name=zone0]' => array ('filled' => TRUE),
		':input[name=sag1]'  => array ('filled' => TRUE),
		':input[name=zone1]' => array ('filled' => TRUE),
		':input[name=sag2]'  => array ('filled' => TRUE),
		':input[name=zone2]' => array ('filled' => TRUE),
		':input[name=sag3]'  => array ('filled' => TRUE),
		':input[name=zone3]' => array ('filled' => TRUE),
    ),
  ),
); 


$form['container4'][$wrapper]['sag4'] = array(
    '#type'          => 'textfield',
    '#title'         => $ocalc_sag_height." 4",
    '#title_display' => 'invisible',
    '#weight'        => -12,
    '#maxlength'     => 4,
    '#size'          => 4,
    '#field_suffix'  => "mm", 
    '#prefix' => "<div class='form-item-sag1'>$ocalc_zone 4</div>",
  );
  
 $form['container4'][$wrapper]['zone4'] = array(
    '#type'          => 'textfield',
    '#title'         => $ocalc_zone." 4",
    '#title_display' => 'invisible',
    '#weight'        => -11,
    '#maxlength'     => 4,
    '#size'          => 4,
    '#field_suffix'  => "mm",                   
  );

After updading a Drupal site from 8.6.16 to 8.7.1 (PostgreSQL 9.6.13 , Nginx) I get this error in almost every operation (creating a view , installing a module, importing feeds, ....) with diferent plugins

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "{whatever}" plugin does not exist.
Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, any, float, string, boolean, timespan,[...]
in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 de /"
"/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

I use the drupal-project composer template so my update process was:

composer update --with-dependencies webflo/drupal-core-require-dev drupal/* "symfony/*" -d /<path/to/site> --no-interaction ;
cd /<path/to/site>
drush updb
drush cron
drush cr

It was not successfull, so I do this:

rm -rf vendor/*
composer update

and run again previous commands which It worked.

I though that I could be a problem with PHP version so I update from PHP 7.0 to PHP 7.3, but the error still remains.
I also thought that it could be related with a feeds module installation so delete all feeds content, feeds types, etc .. and unistall and reinstall the module several times (also run drush devel-entity-updates because drupal status report warned of a feeds field that needed to be deleted)

After see that the problem was related with multiples plugins I start looking for a more generic issue (config?, permissions?, ...) but I don't find cause/solution.

EDIT 1

Looking for a stack trace I try using drupal console:

drupal site:mode dev -v

and get this:

In DiscoveryTrait.php line 53:

  [Drupal\Component\Plugin\Exception\PluginNotFoundException]                                                                                                                                               
  The "system.performance" plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, any, float, string, boolean, timespan, language_reference, language, map  
  , binary, timestamp, list, datetime_iso8601, uri, integer, duration_iso8601, email, field_item:comment, field_item:datetime, field_item:daterange, field_item:file_uri, field_item:file, field_item:font  
  awesome_icon, field_item:image, field_item:link, field_item:list_integer, field_item:list_float, field_item:list_string, field_item:path, field_item:telephone, field_item:text, field_item:text_long, f  
  ield_item:text_with_summary, field_item:time_range, field_item:time, field_item:webform, field_item:email, field_item:uri, field_item:entity_reference, field_item:uuid, field_item:timestamp, field_ite  
  m:string_long, field_item:language, field_item:password, field_item:changed, field_item:float, field_item:decimal, field_item:map, field_item:boolean, field_item:integer, field_item:created, field_ite  
  m:string, entity, entity:block, entity:block_content_type, entity:block_content, entity:block_content:basic, entity:captcha_point, entity:comment, entity:comment:comment_forum, entity:comment_type, en  
  tity:contact_form, entity:contact_message, entity:contact_message:feedback, entity:contact_message:personal, entity:editor, entity:field_config, entity:field_storage_config, entity:file, entity:filter  
  _format, entity:image_style, entity:imce_profile, entity:language_content_settings, entity:configurable_language, entity:media_type, entity:media, entity:media:audio, entity:media:file, entity:media:i  
  mage, entity:media:remote_video, entity:media:video, entity:node_type, entity:node,[...], entity:node:page, entity:node:position, entity:rdf_mapping, entity:responsive_image_style, entity:rest_resource_config, entity:rules_reaction_rule, entity:rules_component, entity:s  
  earch_page, entity:shortcut_set, entity:shortcut, entity:shortcut:default, entity:action, entity:menu, entity:taxonomy_vocabulary, entity:taxonomy_term, entity:taxonomy_term:badge_type, entity:taxonom  
  y_term:categories, entity:taxonomy_term:forums, entity:taxonomy_term:materials, entity:taxonomy_term:nivel, entity:taxonomy_term:tags, entity:toolbar_menu_element, entity:tour, entity:user, entity:use  
  r_role, entity:webform_options, entity:webform, entity:webform_submission, [..], entity:menu_link_content, entity:pathauto_pattern, entity  
  :view, entity:base_field_override, entity:entity_view_mode, entity:entity_view_display, entity:entity_form_mode, entity:entity_form_display, entity:date_format, entity_reference

Exception trace:
 () at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php:53
 Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryCachedTrait.php:25
 Drupal\Core\Plugin\DefaultPluginManager->getDefinition() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/TypedData/DataDefinition.php:195
 Drupal\Core\TypedData\DataDefinition->getClass() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/TypedData/TypedDataManager.php:86
 Drupal\Core\TypedData\TypedDataManager->createInstance() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/TypedData/TypedDataManager.php:103
 Drupal\Core\TypedData\TypedDataManager->create() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/TypedConfigManager.php:394
 Drupal\Core\Config\TypedConfigManager->createFromNameAndData() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/StorableConfigBase.php:134
 Drupal\Core\Config\StorableConfigBase->getSchemaWrapper() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/StorableConfigBase.php:179
 Drupal\Core\Config\StorableConfigBase->castValue() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/Config.php:212
 Drupal\Core\Config\Config->save() at /home/"<user>"/www/"<site>"/vendor/drupal/console/src/Command/Site/ModeCommand.php:150
 Drupal\Console\Command\Site\ModeCommand->overrideConfigurations() at /home/"<user>"/www/"<site>"/vendor/drupal/console/src/Command/Site/ModeCommand.php:87
 Drupal\Console\Command\Site\ModeCommand->execute() at /home/"<user>"/www/"<site>"/vendor/symfony/console/Command/Command.php:255
 Symfony\Component\Console\Command\Command->run() at /home/"<user>"/www/"<site>"/vendor/symfony/console/Application.php:987
 Symfony\Component\Console\Application->doRunCommand() at /home/"<user>"/www/"<site>"/vendor/symfony/console/Application.php:255
 Symfony\Component\Console\Application->doRun() at /home/"<user>"/www/"<site>"/vendor/drupal/console-core/src/Application.php:184

EDIT 2

looking at the database I found two tables from feeds module (supposed to be uninstalled)

feeds_feed feeds_subscription

running drupal console commnand drupal debug:module feeds appears as the only module uninstalled with a schema version defined

ID     Name   Package  version      schema version  status      origin
...
feeds  Feeds  Feeds  8.x-3.0-alpha5    8001         Uninstalled no core
...

EDIT 3

After enable debugging (https://drupal.stackexchange.com/questions/127182/how-do-i-enable-develo...)

I got new clues about the error ( trying to create a view) but my lack of drupal core knowledge stops me from understanding where final cause is:

</br></br><em class="placeholder">Drupal\Component\Plugin\Exception\PluginNotFoundException</em>: The &quot;views.view.*&quot; plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, any, float, string, boolean, timespan, [...], entity:entity_form_display, entity:date_format, entity_reference in <em class="placeholder">Drupal\Core\Plugin\DefaultPluginManager-&gt;doGetDefinition()</em> (line <em class="placeholder">53</em> of <em class="placeholder">core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php</em>). <pre class="backtrace">Drupal\Core\Plugin\DefaultPluginManager-&gt;getDefinition(&#039;views.view.*&#039;) (Line: 195)
Drupal\Core\TypedData\DataDefinition-&gt;getClass() (Line: 86)
Drupal\Core\TypedData\TypedDataManager-&gt;createInstance(&#039;views.view.*&#039;, Array) (Line: 103)
Drupal\Core\TypedData\TypedDataManager-&gt;create(Object, Array) (Line: 394)
Drupal\Core\Config\TypedConfigManager-&gt;createFromNameAndData(&#039;views.view.test2&#039;, Array) (Line: 134)
Drupal\Core\Config\StorableConfigBase-&gt;getSchemaWrapper() (Line: 179)
Drupal\Core\Config\StorableConfigBase-&gt;castValue(&#039;uuid&#039;, &#039;c2f6326b-a77f-4f1e-9698-cb96154252cb&#039;) (Line: 212)
Drupal\Core\Config\Config-&gt;save() (Line: 284)
Drupal\Core\Config\Entity\ConfigEntityStorage-&gt;doSave(&#039;test2&#039;, Object) (Line: 449)
Drupal\Core\Entity\EntityStorageBase-&gt;save(Object) (Line: 263)
Drupal\Core\Config\Entity\ConfigEntityStorage-&gt;save(Object) (Line: 394)
Drupal\Core\Entity\EntityBase-&gt;save() (Line: 613)
Drupal\Core\Config\Entity\ConfigEntityBase-&gt;save() (Line: 993)
Drupal\views_ui\ViewUI-&gt;save() (Line: 191)
Drupal\views_ui\ViewAddForm-&gt;submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter-&gt;executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter-&gt;doSubmitForm(Array, Object) (Line: 590)
Drupal\Core\Form\FormBuilder-&gt;processForm(&#039;view_add_form&#039;, Array, Object) (Line: 319)
Drupal\Core\Form\FormBuilder-&gt;buildForm(Object, Object) (Line: 93)
Drupal\Core\Controller\FormController-&gt;getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer-&gt;executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel-&gt;handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel-&gt;handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle-&gt;handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache-&gt;pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware-&gt;handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware-&gt;handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel-&gt;handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel-&gt;handle(Object) (Line: 19)
</pre>

Problem/Motivation

Given that alignable elements are:

• Media Embeds aligned-left or aligned-right
• Media Embeds with captions aligned-left or aligned-right
• Images aligned-left or aligned-right
• Images with captions aligned-left or aligned-right
• Blockquote text aligned-left or aligned-right

Alignable elements can be aligned-right or align-left (as well as aligned-center or not aligned). When align-right or aligned-left, there is an implicit assumption that there will be space opposite of the alignment.

• If aligned-right, it makes sense to allow space to the left of the alignable element.
• If aligned-left, it makes sense to allow space to the right of the alignable element.

This is arguable essential within the text editor to allow:

• a visual representation of the alignment
• space to edit the text wrapping around the aligned embed
• to prevent bizarre squished text

Text without much horizontal space for editing:

Text with the words exploded into letters:

This from feedback from @effulgentsia here #2801307-54: [META] Support WYSIWYG embedding of media entities:

[...] add CSS along the lines of max-width: 75% on media that's aligned left or right. It's fine for the media to be smaller. It's just that if you're explicitly choosing to align it left or right, then you're choosing to put something else beside it, which means leaving some amount of room for that something else.

Proposed resolution

• Must-have: Add a max-width for embedded media in CKEditor when aligned-left or aligned-right (only).

Additional suggested improvements:

• Add a max-width for alignable elements when aligned-left or aligned-right in Classy theme and themes that extend Classy.
• Add some margin between alignable elements and the elements opposite in the CKEditor.
• Add some margin between alignable elements and the elements opposite in the Classy theme and themes that extend Classy.

Remaining tasks

1. Review
2. Test coverage
3. Commit.

User interface changes

TBD

API changes

None.

Data model changes

None.

Release notes snippet

Draft Change record:
https://www.drupal.org/node/3085749

Problem/Motivation

The twig.engine is manually included for BC reasons in Drupal\Core\Template\TwigEnvironment. See #2591515: Move twig_without() to the TwigExtension where all the other filters are and deprecate for more information.

Proposed resolution

Remove the manual inclusion in Drupal 9.0.0 release, as we can then know for sure that the deprecated functions in twig.engine aren't being used.

Remaining tasks

Problem/Motivation

This is step one of #3087227: [META] Split up and refactor MediaLibraryTest, to make the very large and disruptive MediaLibraryTest more manageable and docile.

Proposed resolution

Split MediaLibraryTest into several smaller tests that make sense, sharing a common base class containing helper methods. The actual testing business logic should NOT be changed in this issue.

Remaining tasks

The thing I just said.

User interface changes

None.

API changes

None. MediaLibraryTest is not an API.

Data model changes

None.

Release notes snippet

None.