Problem/Motivation

When an error in PoStreamWriter occurs an exception is supposed to be thrown. The exception class does not exist, however, which then fatals directly and additionally masks the error.

Proposed resolution

Throw a \RuntimeException.

Additionally the patch fixes 3 code style issues in PoStreamWriter:

1. Using {@inheritdoc}
2. Documenting an undocumented variable
3. Remove unnecessary use statements

Problem/Motivation

Toolbar is not very well tested.

Steps to reproduce

Proposed resolution

Add as much tests as possible.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

PathMatcher::isFrontPage does not work with aliased paths, causing the front page path to not redirect to the root path if an aliased path is used. Internal paths like /node/1 work fine.

Steps to reproduce

1. Create a page node with alias /homepage
2. Configure the front page path to be /homepage
3. Visiting the front page will result in the /homepage path, instead of the root path

Proposed resolution

Change PathMatcher::isFrontPage to check both internal and aliased paths.

Remaining tasks

We are migrating from a D7 installation. The migrate scripts are all working well in dev. I have set up a staging server and am attempting to run the same migration there, but when I try to run it, I get the following error:

In Connection.php line 150:

SQLSTATE[HY000] [2002] php_network_getaddresses: getaddrinfo failed: Tempor
ary failure in name resolution

In Connection.php line 150:

PDO::__construct(): php_network_getaddresses: getaddrinfo failed: Temporary
failure in name resolution

The database declarations for the migration look like this in the settings.staging.php:

$databases['default']['default'] = array(
'driver' => 'mysql',
'host' => '127.0.0.1',
'username' => 'username',
'password' => 'password',
'database' => 'stagingdb',
'prefix' => '',
);
$databases['legacy']['default'] = array(
'driver' => 'mysql',
'host' => '127.0.0.1',
'username' => 'username',
'password' => 'password',
'database' => 'legacydb',
'prefix' => '',
);

Running drush commands on the staging site works, so wherever the name resolution problem is coming from, it seems to be related to the legacy database.

drush sql-cli it connects fine. drush sql-sli --database legacy it also connects fine, which suggests to me that the name resolution issue is related to migrate. Am I wrong?

I have also tested by connecting to a remote database and I get exactly the same result.

Can anyone suggest where I go from here? Thank you in advance.

Problem/Motivation

Using nested paragraphs we ran into the the issue that the weights were calculated wrong, after drag and dropping a paragraph that contained other paragraphs. What was wrong about the weights was, that they had the same values.
This occurred because of
first, how the updateField behavior in tabledrag.js is handling ordering, assigning the max value when running out of values

        case 'order':
          {
            var siblings = this.rowObject.findSiblings(rowSettings);
            if ($(targetElement).is('select')) {
              var values = [];
              $(targetElement).find('option').each(function () {
                values.push(this.value);
              });
              // only takes into account the values count on one level
              var maxVal = values[values.length - 1];
              
              // targetClass is field_name-delta-order and this function takes into account all values on every level
              $(siblings).find(targetClass).each(function () {
                if (values.length > 0) {
                  this.value = values.shift();
                } else {
                  this.value = maxVal;
                }
              });

and second, of how the order class is set in theme.inc inside the template_preprocess_field_multiple_value_form function

function template_preprocess_field_multiple_value_form(&$variables) {
  $element = $variables['element'];
  $variables['multiple'] = $element['#cardinality_multiple'];
  $variables['attributes'] = $element['#attributes'];

  if ($variables['multiple']) {
    $table_id = Html::getUniqueId($element['#field_name'] . '_values');
    // setting it up like doesn't take into account that multiple values on the same content could have the same field name
    $order_class = $element['#field_name'] . '-delta-order';

this leaves room for same name order errors, because we choose a popular name like 'field_body' for a paragraph field that contained other paragraphs.

Proposed resolution

Assigning a unique name to the order class using the unique table id instead of the field_name only, like

  if ($variables['multiple']) {
    $table_id = Html::getUniqueId($element['#field_name'] . '_values');
    $order_class = table_id . '-delta-order';

The reason behind this approach is that the table id already contains the field_name and also adds a unique part if the content is already on the view.

Remaining tasks

Is this a good approach or have I missed something similar in the issue queue?

Problem/Motivation

config.image.resizeUnit to '%' not working in the backend editor after changes to images were made and saved.
Front end working as expected, but when going back to the editor to make more updates, images sizes not showing properly.
When inspecting element image, style width has both % and px added to the width number.

Steps to reproduce

1. add image
2. resize image
3. save
4. check in the front end. It should look good
5. go back to the editor. Image is not shown in the correct size. when inspected: style="width:50%px;"
6. Image in the front end saved and shown correctly style="width:50%;"
7. problem only in the editor. in the backend

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Steps to reproduce: /claro/css/components/form.css

1. go to /claro/css/components/form.css file
2. we have written IE11 specific css for placeholder. :-ms-input-placeholder {color: var(--color--gray-30) !important; } which is not required. Because yarn compiles the ::placeholder to :-ms-input-placeholder for IE11 support.
3. Adding screen-recording to better understanding.

Resolution:

::placeholder {
  color: var(--color--gray-30);
}

/* IE 10 and 11 needs this set as important. */
:-ms-input-placeholder {
  color: var(--color--gray-30) !important;
}

This code compiles to

:-ms-input-placeholder {
  color: #7e96a7;
}

::placeholder {
  color: #7e96a7;
}

/* IE 10 and 11 needs this set as important. */

:-ms-input-placeholder {
  color: #7e96a7 !important;
}

So we can remove this extra line of code.

/* IE 10 and 11 needs this set as important. */
:-ms-input-placeholder {
  color: var(--color--gray-30) !important;
}

Problem/Motivation

Bulk operations lists all available actions for the entity without checking access to that action.

web/core/modules/system/src/Plugin/views/field/BulkForm.php:

  /**
   * {@inheritdoc}
   */
  public function init(ViewExecutable $view, DisplayPluginBase $display, array &$options = NULL) {
    parent::init($view, $display, $options);

    $entity_type = $this->getEntityType();
    // Filter the actions to only include those for this entity type.
    $this->actions = array_filter($this->actionStorage->loadMultiple(), function ($action) use ($entity_type) {
      return $action->getType() == $entity_type;
    });
  }

This appears to be because the action access is tied to access for the particular entity but not whether or not the user has access to do that type of action in general or not. ActionInterface::access() described here.

For example:

1. Create a new role 'editor'
2. Grant editor role 'view user information' but not 'administer users'
3. Change /admin/people view access to 'view user information'
4. As an editor, view /admin/people and all actions like cancel user accounts are listed as bulk action options

Proposed resolution

Creating a sample entity of the current type and passing it to the action::access() method to determine whether to show it in the bulk actions. I am not sure if creating a sample entity is a feasible approach.

Alternatively, we could provide a method like bulkAccess() on the action and allow the action to define when it is appropriate to be shown.

Or we could make the assumption that access to the confirm route means show it as a bulk action since we have this information:

@Action(
  id = "user_cancel_user_action",
  label = @Translation("Cancel the selected user accounts"),
  type = "user",
  confirm_form_route_name = "user.multiple_cancel_confirm"
)

Remaining tasks

Decide how to approach this.

User interface changes

Only show bulk action operations that the user has access to.

API changes

None (depending on route chosen to solve this).

Data model changes

None.

Problem/Motivation

Reviewing the Migration object there are a bunch of properties that are unreachable and dead. They mostly seem to be remnants of the fast refactoring and churn early in the D8 Migration project and have never been connected to anything.

Steps to reproduce

Its just dead code.

Proposed resolution

remove it. We should be able to remove it from both D10 and D9 without any consequence because its never been connected to anything in Core or Contrib. Custom code that might have been extending Migration can add the properties back in their custom classes if such a thing exists.

Remaining tasks

User interface changes

API changes

None, code has never been used.

Data model changes

Release notes snippet

In #1184272: Remove deprecated $conditions support from entity controller we removed $conditions from entity_load_multiple(). Interestingly though, instead of actually removing it after it has already been marked as @deprecated in D7 we added a new method to EntityStorageControllerInterface called EntityStorageControllerInterface::loadByProperties() as well as another wrapper called entity_load_multiple_by_properties(). Additionally, this comes with another utility method named ->buildPropertyQuery(). So, to summarize: Instead of curing the problem with $conditions we actually just moved it to somewhere else by introducing a new method as well as a wrapper, which, by the way is just a wrapper for entity_query() itself anyways (which itself is a wrapper for the DIC)...

CMI currently has a custom work-around for this to bypass EFQ but once #1846454: Add Entity query to Config entities we should remove this stuff altogether and simply tell people to use EFQ for loading things by properties.

Also related:
#1893442: Move BlockStorageController::loadByProperties() into ConfigStorageController

Problem/Motivation

The uid field on media entities is not set to required, but the database field is set to NOT NULL.

To reproduce:

- go to /media/add/image
- fill in the required form elements
- delete the contents of the Authored by form element
- save the form

The site crashes with a storage exception because the uid database field may not be NULL.

Steps to reproduce

Proposed resolution

Ideally, deal with #3260173: EntityOwnerTrait does not define the owner field as required, but the DB field is NOT NULL so it's fixed for all entities.

As an interim, copy the code from Node::preSave() to Media::preSave():

      // If no owner has been set explicitly, make the anonymous user the owner.
      if (!$translation->getOwner()) {
        $translation->setOwnerId(0);
      }
    }

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When not using the `search-block-form-2` search block olivero causes JS an uncaught TypeError:
Uncaught TypeError: Cannot read properties of null (reading 'addEventListener') at search.js?v=9.3.4:58:73

Steps to reproduce

Remove the search block with the selector data-drupal-selector="search-block-form-2".

Proposed resolution

Add check before accessing the element.

Remaining tasks

Review branch

Problem/Motivation

@alexpott said on #3187577: FunctionalJavascript tests should fail when ChromeDriver is not running

> > Honestly I don't think anyone outside of DrupalCI should be using run-tests.sh

I haven't used it in years either -- running directly with phpunit is much simpler.

But the documentation in the file says:

> * This script runs Drupal tests from command line.

So unsurprisingly people are using it.

The docs should be changed to say it's only intended for DrupalCI.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Follow-up for #3202664: CKEditor 5's UI language should match Drupal's interface translation to provide API for contrib projects to load CKEditor translations. This requires identifying which translation files exist, an associating them to the related library. Once the translation file is associated to the correct library, CKEditor 5 module is able to load the correct translation files based on the current UI language.

Proposed resolution

Add a key to the plugin configuration that allows defining directory for loading translations. We could potentially make a guess on the directory and add a default value for the config item.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

RequirementsException accepts requirements array as a second argument, which is supposed to expose requirements data to the caller via ::getRequirements method. Currently, this array is not consistent across core source plugins. Sometimes, they use different array keys, sometimes they're just missing.

Some examples:
1) Drupal\comment\Plugin\migrate\source\CommentType:

throw new RequirementsException('The node module is not enabled in the source site.', [
  'source_module_additional' => 'node',
]);

Missing module is added as source_module_additional key.

2) Drupal\migrate_drupal\Plugin\migrate\source\DrupalSqlBase:

throw new RequirementsException('The module ' . $this->pluginDefinition['source_module'] . ' is not enabled in the source site.', ['source_module' => $this->pluginDefinition['source_module']]);

Missing module is added as source_module key.

3) Drupal\comment\Plugin\migrate\source\d7\CommentEntityTranslation:

throw new RequirementsException('The module node is not enabled in the source site');

Missing module is not added at all.

Proposed resolution

1) Add requirements array to all usages of RequirementsException in migrate plugins;
2) Make array keys consistent. Here is a proposed list:
source_module: {module name}
source_table: {table name}
minimum_version: {minimum module version}
migrations: {migration ids}
database_connection: {connection key (i.e. `migrate`)}

Remaining tasks

1) Submit a patch;
2) Review;

Problem/Motivation

Migrate source plugins use checkRequirements() method and throw RequirementsException to notify migration runners that migration requirements are not met.

However, if I run drush ms for migration that doesn't meet the requirements, it won't show up in the list and I won't see any additional messages. If I add -vvv flag, it's getting better:
[debug] Migration 'foo' is skipped as its source plugin has missed requirements: . [0.13 sec, 24.65 MB]

As we can see, it says the requirements are missing. By why? 🤷‍♂️

I looked at Drush code. They do this:

foreach ($migrations as $migrationId => $migration) {
    try {
        $sourcePlugin = $migration->getSourcePlugin();
        if ($sourcePlugin instanceof RequirementsInterface) {
            $sourcePlugin->checkRequirements();
        }
    } catch (RequirementsException $exception) {
        $this->logger()->debug("Migration '{$migrationId}' is skipped as its source plugin has missed requirements: " . $exception->getRequirementsString());
        unset($migrations[$migrationId]);
    }
}

To get the details, they use only $exception->getRequirementsString(). But according to Drupal\migrate\MigrateExecutable, they should use $exception->getMessage() as well:

$this->message->display(
        $this->t(
          'Migration @id did not meet the requirements. @message @requirements',
          [
            '@id' => $this->migration->id(),
            '@message' => $e->getMessage(),
            '@requirements' => $e->getRequirementsString(),
          ]
        ),
        'error'
      );

It should be fixed in Drush. Here is the issue: https://github.com/drush-ops/drush/pull/5052

Looks good so far, but do we really need to print @requirements array in that case? Here is current message:
Migration foo did not meet the requirements. The module bar is not enabled in the source site. source_module: bar

Why would we need to print source_module: bar if there is a message that explains what is missing?
I think this should be enough: Migration @id did not meet the requirements. @message.

It was introduced in #2321609: Provide a helpful message in case requirements are not met with the following comment:

I've put the requirements into the message in MigrateExecutable but it doesn't seem to be any additional information other than what the message already gives us at this point.

The author confirmed this list does not provide any additional data. Let's remove it then :)

Proposed resolution

1) Change the requirements message pattern from:
Migration foo did not meet the requirements. The module bar is not enabled in the source site. source_module: bar
To:
Migration foo did not meet the requirements. The module bar is not enabled in the source site.
2) Apply the same format in Drush: https://github.com/drush-ops/drush/pull/5052

Remaining tasks

Review / commit.

Problem/Motivation

Version negotiation is only supported on node and media entities. This is because there was no generic revision access checker in core when #2992833: Add a version negotiation to revisionable resource types landed, but is now available since 9.3.0 as per #3043321: Use generic access API for node and media revision UI. We should support version negotiation for any entity type.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Error: Call to a member function getStorage() on null in Drupal\basic_auth\Authentication\Provider\BasicAuth->applies() (line 77 of core\modules\basic_auth\src\Authentication\Provider\BasicAuth.php).

Steps to reproduce

After upgrade to drupal 9.2.6 from 8.9.17 getting above issue

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

For multibyte languages (in this case malayalam), the length of the comment subject line is too short and truncates the subject line. A fix to increase the length of subject fiels is as follows:

The length of th esubject line is defined in the comment table:

subject varchar(64) NOT NULL default '',

You can use phpmyqdmin or the mysql commandline to change this to something higher. Maximum is 255.

You will maybe also need to increase the number of chars you can put into the forms. Look for form_textfield in comment.module.

This problem exists for 4.6.* versions also.

Thanks Gerhard Killesreiter for the above fix!

Problem/Motivation

Drupal 10 will drop support for Internet Explorer 11: #3155358: [policy, no patch] Drop IE11 support from Drupal 10.0.x. Drupal ship with number of polyfills to accommodate JScripts lack of modern features supported by other JavaScript engines.

Proposed resolution

Based on comments in the core/misc/polyfills files, it seems like all of the polyfills in that folder could be deleted. On top of that, we have couple of polyfills in package.json. From the package.json, we could remove following packages:

• core/css.escape
• core/drupal.array.find
• core/drupal.nodelist.foreach
• core/es6-promise
• core/picturefill
• core/drupal.element.closest
• core/drupal.element.matches
• core/drupal.string.includes
• postcss-calc

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet