Problem/Motivation

Follow up from #1845546-121: Implement validation for the TypedData API

Maybe also improve how we deal with multiple-bundle metadata here?

Steps to reproduce

N/A

Proposed resolution

See #20 + #23.

Remaining tasks

Determine if this change should be made see #1845546-121: Implement validation for the TypedData API and #35

User interface changes

None.

API changes

Passing a string value to the Bundle constraint's bundle option is no longer allowed; it triggers a deprecation in Drupal 10.3 and will trigger an error in Drupal 11.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

I am trying to update drupal core from 8.2.8 to 8.3.1 alongwith lightning from 2.0.1 to 2.1.0. I've created the sub profile for lightning and executed all the manual steps mentioned here - https://github.com/acquia/lightning/blob/2.1.0/UPDATE.md. When running travis, I'm getting the below error

Error: Call to a member function getColumns() on boolean in /docroot/core/lib/Drupal/Core/Entity/Query/Sql/Tables.php, line 228

After a bit of debugging I found that the error is coming from the below line and the reason for the error is that $field_storage is setting to FALSE here

$columns = $field_storage->getColumns();

System information before update:

• Drupal Version: 8.2.8
• Lightning Version: 2.0.1

System information after updating:

• Drupal Version: 8.3.1
• Lightning Version: 2.1.0

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

Method getMockForAbstractClass() of class PHPUnit\Framework\TestCase is deprecated in PHPUnit 10.

Some uses were removed as part of #3217904: [meta] Support PHPUnit 10 in Drupal 11, but there's a relevant number of places where this is still used.

Proposed resolution

replace in class KeyValueEntityStorageTest

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Media derive their thumbnail images and alt text for those images from their media source plugins. For image-based media, that's the "Image" media source plugin. When the plugin is asked to present the alt text for its thumbnail image, it returns the alt text stored in the image field of the media entity. This works great, unless the alt text is an empty string. The Image plugin treats this as a "falsey" value and ends up returns NULL for the alt text instead of the empty string.

An empty string value for the alt text attribute (alt="") has important meaning for accessibility. It instructs assistive tech that the image is decorative and should be ignored by screen readers. Drupal's image formatter template will correctly output the alt="" attribute on the image element in this case. If the alt is NULL, then Drupal's image formatter template won't print the alt attribute at all. This is very problematic as assistive tech may instead announce the image filename when it comes upon the image, because it's assuming the missing alt attribute is a mistake and the image may be important for the user to know about.

Steps to reproduce

1. Install media module.
2. Edit the image field on the Image media type and uncheck the Alt text required checkbox and save.
3. Add an Image media entity - upload an image and leave empty alt text field.
4. Visit the media library page: /admin/content/media and inspect the thumbnail image. Observe that the alt attribute is missing.
5. Then inspect image tag. you 'll notice if nothing pass in alt text field then alt tag 'll not display.

Proposed resolution

This is a simple fix. Modify the getMetadata method of the Image media source plugin so that it if the alt text of the associated media entity is an empty string, return the same empty string.

Remaining tasks

User interface changes

API changes

Data model changes

No. Could have an update function to update all existing media thumbnails to swap NULL thumbnail alt values with an empty string instead, but that's probably not worth it. Some sites will have tens of thousands of media items and I guess this update function could take a while to run.

Release notes snippet

Problem/Motivation

Avoid writing invalid data to the fast backend.

Only relevant if/when someone calls getMultiple() with invalid == TRUE.

Marking issue NOVICE ONLY for creating a patch out of the below code.

Steps to reproduce

- Call getMultiple() with $allow_invalid = TRUE.
- See that fastBackend is happily setting invalid data, which will never be useful

Proposed resolution

<code>
diff --git a/web/core/lib/Drupal/Core/Cache/ChainedFastBackend.php b/web/core/lib/Drupal/Core/Cache/ChainedFastBackend.php
--- a/web/core/lib/Drupal/Core/Cache/ChainedFastBackend.php
+++ b/web/core/lib/Drupal/Core/Cache/ChainedFastBackend.php
@@ -166,7 +166,10 @@ public function getMultiple(&$cids, $allow_invalid = FALSE) {
         $cache[$item->cid] = $item;
         // Don't write the cache tags to the fast backend as any cache tag
         // invalidation results in an invalidation of the whole fast backend.
-        $this->fastBackend->set($item->cid, $item->data, $item->expire);
+        if (!$allow_invalid || $item->valid) {
+          $this->fastBackend->set($item->cid, $item->data, $item->expire);
+        }
       }
     }

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

locale_config_batch_set_config_langcodes() and locale_config_batch_refresh_name() are batch operation callbacks which are just wrappers around API methods on the LocaleConfigManager.

However, the names don't match up at all which is confusing:

function locale_config_batch_set_config_langcodes(&$context) {
  Locale::config()->updateDefaultConfigLangcodes();

and:

function locale_config_batch_refresh_name(array $names, array $langcodes, &$context) {
  SNIP
  $context['results']['stats']['config'] += Locale::config()->updateConfigTranslations($names, $langcodes);

Steps to reproduce

Proposed resolution

Rename both callbacks to 'locale_config_batch_' + snake case version of the API method it calls.

No BC handling is necessary as batch API callbacks are internal.

Remaining tasks

• Update the merge request to retain the procedural functions that wrap the new methods, and add a deprecation (see #5).
• Fix the coding standards error in the pipeline job (see #16).

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

API page: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Extension...

Some implementations of this don't return a severity level: https://api.drupal.org/api/drupal/core%21modules%21file%21file.install/f...

From a quick look at the code in StatusReport and StatusReportPage, it looks like that's ok. But the docs for the hook don't say that it's optional, or what happens if you omit it.

Steps to reproduce

Proposed resolution

add '(optional)" before severity in the description of the return values.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

Since Drupal 10.2 we're seeing the following error:

LogicException: The complete set of cache contexts for a variation cache item must contain all of the initial cache contexts, missing: languages:language_interface, theme. in Drupal\Core\Cache\VariationCache->set() (line 47 of core/lib/Drupal/Core/Cache/VariationCache.php).

This is caused by the following code:

public function MYMODULE_node_view(array &$build, NodeInterface $node, EntityViewDisplayInterface $display, string $view_mode): void {
  $cache = CacheableMetadata::createFromObject($display);
  $cache->addCacheableDependency($node);
  // Do stuff ...
  $cache->applyTo($build);
}

Prior to 10.2 this worked as expected, and the X-Drupal-Cache-Contexts header includes both the languages:language_interface and theme contexts. These must have been added later in the render pipeline at some point later, as they aren't present in the CacheableMetadata in the hook above. Note that they are present if we change it to CacheableMetadata::createFromRenderArray($build).

If I remove the code that detects missing contexts and throws the LogicException then the page loads correctly and the X-Drupal-Cache-Contexts header contains the expected contexts.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Follow-up from #3442259: Reduce time of Migrate Upgrade tests by not outputting the logs by default. When I was reviewing that, I noted:

Took me a moment to understand why we're moving assertLogError() outside the check for if we've written anything to the logs. But then with grep and looking at more context outside of the MR diff, I see that that function relies on $this->expectedLoggedErrors, which is only set in the two functions where assertLogError() is now found.

At the risk of slowing down this important fix, I have to ask: should that method really be something like:

assertLogErrorCount(int $expected): void

Why bother with the expectedLoggedErrors property at all? It's only set exactly twice with hard-coded ints each time:

./core/modules/migrate_drupal_ui/tests/src/Functional/d7/Upgrade7Test.php:    $this->expectedLoggedErrors = 27;
./core/modules/migrate_drupal_ui/tests/src/Functional/d6/Upgrade6Test.php:    $this->expectedLoggedErrors = 39;

We never increment or anything. It's basically just a constant. Why not pass it directly where we need it?

@catch replied "I think #8's a good idea for follow-up." so here we are. 😂

Steps to reproduce

Proposed resolution

• Rename MigrateUpgradeExecuteTestBase::assertLogError() to assertLogErrorCount(int $expected).
• Remove the expectedLoggedErrors property.
• Update the 2 call sites to pass their values directly instead of setting this property.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In the parent issue #3472008: Move JSON:API validation to a feature flag or separate module we put schema validation for jsonapi behind a feature flag. ComponentValidation does the same. We should investigate if this leads to performance issues the same as with jsonapi.

Drupal\Core\Theme\Component\ComponentValidator

That kinda does the same.

  /**
   * Sets the validator service if available.
   */
  public function setValidator(?Validator $validator = NULL): void {
    if ($validator) {
      $this->validator = $validator;
      return;
    }
    if (class_exists(Validator::class)) {
      $this->validator = new Validator();
    }
  }

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

JSON:API has a soft dependency on justinrainbow/json-schema; validation is performed automatically if the dependency is enabled via a check in \Drupal\jsonapi\EventSubscriber\ResourceResponseValidator:

use JsonSchema\Validator;
...
    elseif (class_exists(Validator::class)) {
      $this->validator = new Validator();
    }

@larowlan has previously noted that this causes severe performance issues at runtime, and the fix is to uninstall the dependency.

However, Experience Builder uses justinrainbow/json-schema at runtime (although at the time of writing this is not explicitly declared): #3469516: Declare explicit runtime dependency on `justinrainbow/json-schema`

In turn this will cause performance issues on sites that want to use both Experience Builder and JSON:API.

Steps to reproduce

Proposed resolution

Move ResourceResponseValidator behind some kind of feature flag instead of magically enabling it when the dependency is present. This could be a development mode flag similar to the Twig debug mode, or a feature flag module.

It may even be preferable to move this out of core to a contrib module, as this doesn't feel like it is necessarily in the core use case. Tagging for product manager review.

Remaining tasks

Discuss the best solution.
Implement.

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

      // For the 'target_bundles' setting, a NULL value is equivalent to "allow
      // entities from any bundle to be referenced" and an empty array value is
      // equivalent to "no entities from any bundle can be referenced".

and

    // If 'target_bundles' is NULL, all bundles are referenceable, no further
    // conditions are needed.

and

      // If 'target_bundles' is an empty array, no bundle is referenceable,
      // force the query to never return anything and bail out early.

This seems weird but there is a reason -- @berdir on Slack writes:

> the null vs empty array situation is due to config dependencies and updates. if you allow a single target bundle, then remove that bundle, the field would now allow any bundle if you weren't making a difference between null and empty array.

This should be documented in the code -- probably added to the comment in defaultConfiguration()

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In core/lib/Drupal/Component/Plugin/Attribute/Plugin.php:

   * @param string $id
   *   The attribute class ID.

This should say the plugin ID.

Proposed resolution

Fix docblock

Remaining tasks

Update docblock
Create MR

Problem/Motivation

The attributes (data-drupal-field-elements, data-help, placeholder) was added for the datepicker pollyfill. Added via #3072906: Deprecate and remove jQuery UI datepicker and removed via #3256549: Deprecate core/drupal.date asset library in 9.4.0.

Steps to reproduce

-

Proposed resolution

Remove attribute.

Remaining tasks

-

User interface changes

-

Introduced terminology

-

API changes

-

Data model changes

-

Release notes snippet

Remove leftover help text for the polyfill for HTML5 date input.

Problem/Motivation

Several methods on EntityDisplayRepositoryInterface - all the get*Modes() - have @return docs that say something like this:

   * @return array
   *   The view mode info for all entity types.

What is the 'info'? What is the array keyed by? The docs should say this.

Steps to reproduce

Proposed resolution

Complete the documentation.

It's probably fine for the entity type-specific flavours to refer to the general method for docs, to avoid repetition.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

With #1921558: Convert file_get_mimetype() to use Symfony MimeTypeGuessers, the function file_mimetype_mapping() was removed. The mapping was placed as a protected property of the ExtensionMimeTypeGuesser class, as its main purpose was for the guesser to use it. But there are cases when the mapping, or just the list of MIME types, should be used in itself, outside the context of guessing. For instance, a form in the File entity module should present known MIME types for the user.

Proposed resolution

Move the default mapping to a new service and class, Drupal\Core\File\MimeType\MimeTypeMapper, with getter/setter methods.

Introduce an alterMapping() method which invokes the mimetype alter hook upon service instantiation to allow modules to play with MIME type<->extension mapping.

Change the ExtensionMimeTypeGuesser class to use the new mapper; deprecate its ::setMapping method.

Deprecate the file_mimetype_mapping alter hook.

Add tests.

Add tests.

Remaining tasks

Commit

User interface changes

None

API changes

A new service file.mime_type.mapper.

Beta phase evaluation

Problem/Motivation

1. I write a module.
2. I add components/image.component.yml
3. Months later, I add many components, and I add component/simple/image.component.yml
4. On some environments, this crashes, on others it does not.

Steps to reproduce

See above.

Proposed resolution

Detect the duplicate plugin ID within an extension, and throw a helpful exception.

Remaining tasks

• Explicit test coverage. (I suggest following the pattern that \Drupal\Tests\ckeditor5\Kernel\CKEditor5PluginManagerTest::testInvalidPluginDefinitions() established.)
• Fix.

User interface changes

None.

Introduced terminology

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A

The current UUID implementation for nodes doesn't support revision UUIDs. This means that when an entity supports revisions, those revisions can't be tracked across environments. There are situations where it is reasonable to expect to be able to update a revision of a node in one environment with the contents from another.

The UUID contrib module supports UUIDs for both the entity (and where supported) revisions. It would be good to see core support this in D8.

Adding the Revision UUID column as a not null required column poses a problem with setting the default values. Previously we've got around this problem by using initial or initial_from_field but that is a little trickier with UUID which need to be unique per row. We have two options:

1. Use initial_from_field as is shown in #48 and then provide a UUID() function for each database layer.
2. Solve #2346019: Handle initial values when creating a new field storage definition so that we can support many different schema migrations.

Problem/Motivation

Amongst the "new" errors found when running PHPStan on level 2 is: Variable $foo in PHPDoc tag @var does not exist.

This child-issue exists to fix the "low hanging fruit" ones.

Steps to reproduce

- Run PHPStan on level 2 and see the above error amongst all others.

Proposed resolution

- Solve all of the the above mentioned reported errors.
- Run PHPStan on level 2 and see less of the above mentioned error.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

I searched the issue queue but didn't see a duplicate. I apologize if I missed one!

D7 core does not seem to pass down #states or #attributes assigned to a parent password_confirm element, to it's children.
I was trying to turn autocomplete off for the password confirm field and add a state.

$form['password_field']['#pre_render'] = array('my_form_process_password_confirm');

function my_form_process_password_confirm($elements) {
  foreach (element_children($elements) as $element) {
    $elements[$element]['#attributes']['autocomplete'] = 'off';
    $elements[$element]['#states'] = array(
      'visible' => array(
      	':input[name="my_checkbox"]' => array('checked' => TRUE),
      ),
    );
  }

return $elements;
}

Steps to reproduce

Create a custom form where password and password confirm are required after selecting another field value e.g.

    $form['autogenerate_password'] = [
      '#title' => $this->t('Autogenerate password'),
      '#type' => 'checkbox',
      '#default_value' => 1,
    ];
    $form['password_confirm'] = [
      '#title' => $this->t('Enter password'),
      '#type' => 'password_confirm',
      '#states' => [
        'visible' => [
          ':input[name="autogenerate_password"]' => ['checked' => FALSE],
        ],
      ],
    ]

On launch the Enter password field will be shown.

Proposed resolution

Add the states data selector to the wrapper attributes