Problem/Motivation

During migration of a customer's website, the following error occurred:

[error] The "i18n_taxonomy_term_reference_plain" plugin does not exist. Valid plugin IDs for Drupal\Core\Field\FormatterPluginManager are: comment_permalink, ...

After doing a quick research, we found a comment mentioning "i18n_taxonomy_term_reference_link". Searching through Drupal core, I found the according migration mapping inside "web/core/modules/taxonomy/src/Plugin/migrate/field/TaxonomyTermReference.php", where it seems "i18n_taxonomy_term_reference_plain" just got overlooked!

Proposed resolution

Add a mapping inside "web/core/modules/taxonomy/src/Plugin/migrate/field/TaxonomyTermReference.php" for "i18n_taxonomy_term_reference_plain"

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Unable to drop fields in an empty area from the display mode.

Steps to reproduce

Using a clean Drupal 9.4 install

1. Choose a content type to edit (I am using Article content type).
2. Go to manage display mode.
3. Turn on the display mode: "Search result highlighting input" and navigate there.
4. If there are fields already enabled, drag them in the disabled section.

When you trying to drag a single field for example "Links" into other section above, the mouse pointer stays on dragging mode and doesn't let you drop the field. Also this produces a console log error message.

field_ui.js?v=9.4.2:173 Uncaught TypeError: Cannot read properties of undefined (reading 'value')
    at Drupal.fieldUIDisplayOverview.field.regionChange (field_ui.js?v=9.4.2:173:122)
    at Drupal.tableDrag.onDrop (field_ui.js?v=9.4.2:99:40)
    at Drupal.tableDrag.dropRow (tabledrag.js?v=9.4.2:493:12)
    at HTMLDocument.<anonymous> (tabledrag.js?v=9.4.2:95:19)
    at HTMLDocument.dispatch (jquery.min.js?v=3.6.0:2:43064)
    at v.handle (jquery.min.js?v=3.6.0:2:41048)

I have included screenshots as well

Problem/Motivation

The code assumes that page is a string, passing in an array results in a warning on PHP 7 and a fatal error on PHP 8. We discovered this because a security scanner on one of our websites triggered a lot of those errors.

Steps to reproduce

Visit /node?page[foo]=bla:

The website encountered an unexpected error. Please try again later.
TypeError: explode(): Argument #2 ($string) must be of type string, array given in explode() (line 58 of core/lib/Drupal/Core/Pager/PagerParameters.php).

explode() (Line: 58)
Drupal\Core\Pager\PagerParameters->getPagerQuery() (Line: 49)
Drupal\Core\Pager\PagerParameters->findPage() (Line: 304)
Drupal\views\Plugin\views\pager\SqlBase->setCurrentPage() (Line: 929)
Drupal\views\ViewExecutable->initPager() (Line: 1444)
Drupal\views\Plugin\views\query\Sql->build() (Line: 1321)
Drupal\views\ViewExecutable->build() (Line: 392)

Proposed resolution

Ignore non-string page query parameters.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Seems like some quite significant changes have been encountered in #3220021: [meta] Ensure compatibility of Drupal 9 with PHP 8.1 (as it evolves).

Steps to reproduce

Try testing D7 core with PHP 8.1

Proposed resolution

Make tests pass.

Remaining tasks

?

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Release notes snippet

tbc

Problem/Motivation

When a base field (e.g. entity path) properties are changed (e.g. it is made non-translatable), it's isInternal() method is inherited from FieldConfigBase, so that any computed field becomes internal though initially the field might be non-internal. This, for example, will remove the field from JSON:API results and might have other undesired consequences.

Steps to reproduce

1. Create node and set up JSON:API for the node to be exposed via API.
2. Make sure the path is exposed in the attributes section.
3. Mark URL Alias as untranslatable and clear caches.
4. See that the path has disappeared from the JSON:API response.

Proposed resolution

The correct approach is to inherit the internal property from the base field definition like other properties like "computed" and "read only" are.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

An important part of single directory components (or SDC) is the component metadata. The component metadata is the information about the component that is not directly used to render the component. This includes information about the component type, the component status, the library dependencies, etc.

This issue aims to define the required metadata and the format in which developers will need to provide it. The resulting patch will create a JSON schema document that will describe such format. This JSON Schema will be used to validate the component-name.component.yml

Originally we considered the possibility to leverage the manifest definition of the W3C custom elements. However, we discovered that this document contains a lot of implementation-specific details that do not translate to a Drupal implementation.

Required metadata

The required fields that all components should specify are:

• Machine name: this identifies a component uniquely. Multiple plugins can share the same machine name for replacement reasons.
• Name: this is a human readable name that will be used to represent the component in the various user interfaces that deal with components.
• Component status: a value from an enum. Possible values are: WIP, alpha, beta, RC, stable, deprecated. This will comunicate the different stages of readiness and the contract between the provider, and the consumer. It aims to provide additional flexibility to component development in Drupal core. It could also be used by the automated updates bot to detect that a theme is using a deprecated component.
• Component type: value from an e mum. Possible values are: atom, molecule, organism. Taken from Pattern Labs terminology, this field aims to provide semantics about how the component is intended to be used.
• Prop schemas: the JSON Schema definition for component props this will be used to validate prop input during the render process. Additionally it will describe the props in a way that other systems can interpret and provide integrations for.This is one of the key points. Examples of such integrations include: generating forms automatically for humans providing values for the components (low code tools), compatibility assessment of mapping options lean my custom field map to this component?), similarity analysis (can I replace this component with this other?), templatability (editors get a list of compatible components for a given field type, custom block, etc.). Even though all these options are possible, Drupal core will only use this information to ensure that the data passed to the component is valid. Other features belong to contrib. Prop schemas will also provide example data for their props to showcase components in isolation.
• Library dependencies: additional libraries that should be included when adding a component to the page. Technically, this is not required, unless there is a library needed for the correct functioning of the component.

Optional metadata

• Description: a description used in UIs showing components.
• Custom: an optional object with free-form metadata.This is useful for projects extending the component functionality.

Example

$schema: https://git.drupalcode.org/project/cl_components/-/raw/1.x/src/metadata.schema.json
machineName: my-banner
name: Banner
componentType: organism
description: Banner with title and a CTA link
status: READY
variants:
  - tall
schemas:
  props:
    type: object
    properties:
      heading:
        title: Heading
        description: The title for the banner text.
        examples:
          - Join us at The Conference
        type: string
      ctaText:
        title: CTA Text
        type: string
        examples:
          - Click me!
      ctaHref:
        title: CTA Href
        type: string
        examples:
          - 'https://www.example.org'
      ctaTarget:
        title: CTA Target
        type: string
        enum:
          - ''
          - _blank
      image:
        title: Media Image
        description: Background image for the banner.
        type: string

Considered alternatives

It has been suggested that all the metadata could be derived from the twig template file name. It is hard to accommodate all the information we want to record in a single filename.

Another suggestion is to have metadata as part of the Twig template front matter. This has the limitation of binding a component to a template, and just one.This will prevent having component variants (discussed separately), among other potentially desirable features.

Another suggestion was to include a metadata.json file. This has the drawback of not being idiomatic with other plugin definitions. Drupal developers are already used to the id-name.feature.yml files.This argument also applies to the front matter alternative.

Problem/Motivation

Executing something like this

      $test = \Drupal::service('image.factory')->get(NULL, 'gd');
      $test->createNew(20000, 20000);

leads to a fatal error

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 80000 bytes) in /[...]/core/modules/system/src/Plugin/ImageToolkit/Operation/gd/CreateNew.php on line 94

and WSOD.

This is because GD imagexxx functions do not return gracefully in case of memory allocation failures.

Proposed resolution

Take cues from the preliminary memory availability check done in the color module, and from this comment on PHP site, and introduce a memory checking method that can be called on load, create_new, and rotate operations before invoking imagexxx functions.

Remaining tasks

User interface changes

None.

API changes

Introduce 1 public method specific for GDToolkit, ::isMemoryAvailable(), that throws a \RuntimeException if not enough memory is available.

Data model changes

None

Problem/Motivation

Views currently does not show theme suggestions, due to a bug in core: #2118743: Twig debug output does not display all suggestions when an array of theme hooks is passed to #theme
Mark Carver though pointed out in #2118743-167: Twig debug output does not display all suggestions when an array of theme hooks is passed to #theme that views could also use hook_theme_suggestions

Proposed resolution

Use hook_theme_suggestions() instead of arrayed theme hooks.

Remaining tasks

Postponed till #2511548: Add a "context" array variable to all theme hooks and "#context" array property to all elements to provide optional contextual data is finished.

User interface changes

None

API changes

Deprecates ViewsPluginInterface::themeFunctions and ViewExecutable::buildThemeFunctions and replaces them with equivilent themeSuggestions methods.

Data model changes

None

Problem/Motivation

CKEditor 5 has now resolved all its stable blockers, with the exception of one upstream accessibility bug that will block Drupal 10.0.0-rc1 and 9.5.0-rc1.

Proposed resolution

Mark the module stable in core and make any other changes necessary for this (e.g., moving templates and CSS around, etc.)

Remaining tasks

TBD

User interface changes

CKEditor 5 becomes a stable module on the Extensions page.

API changes

CKEditor 5 is stable in 9.5 and above, and therefore subject to stable code policies.

Data model changes

None.

Release notes snippet

CKEditor 5 module added as a new experimental replacement for CKEditor 4

CKEditor 4 will reach end-of-life in 2023. A separate core module supporting CKEditor 5 is now stable.

CKEditor 5 differs significantly from CKEditor 4, so sites and modules should update to it now in preparation for the release of Drupal 10.0.0 on December 14, 2022.

Problem/Motivation

When I run
drush migrate:import upgrade_d7_field_instance --migrate-debug
upgrade_d7_field_instance yml is generated by migrate upgrade without any modification,
I have the following errors:

In DiscoveryTrait.php line 53:

  The "" plugin does not exist. Valid plugin IDs for Drupal\migrate\Plugin\Mi  
  gratePluginManager are: addressfield, block_plugin_id, block_region, block_  
  settings, block_theme, block_visibility, field_type, process_field, field_f  
  ormatter_settings_defaults, d6_field_instance_defaults, d6_field_instance_o  
  ption_translation, d6_field_field_settings, field_instance_widget_settings,  
   d6_field_option_translation, field_settings, d6_field_type_defaults, field  
  _bundle, d7_field_instance_defaults, d7_field_instance_option_translation,   
  d7_field_instance_settings, d7_field_option_translation, d7_field_settings,  
   d7_field_type_defaults, d7_field_permission_settings, d6_field_file, file_  
  uri, filter_id, filter_settings, filter_format_permission, geofield_d7d8, g  
  eofield_field_settings, geofield_latlon, geofield_wkt, google_analytics_vis  
  ibility_pages, google_analytics_visibility_roles, d6_imagecache_actions, in  
  line_entity_form_field_instance_settings, field_link, link_options, link_ur  
  i, d6_nodewords_entities, d7_metatag_entities, array_build, callback, conca  
  t, default_value, download, entity_exists, explode, extract, file_copy, fla  
  tten, format_date, get, log, machine_name, make_unique_entity_field, menu_l  
  ink_parent, migration_lookup, null_coalesce, route, skip_on_empty, skip_row  
  _if_not_set, static_map, sub_process, substr, urlencode, debug, node_comple  
  te_node_lookup, node_complete_node_revision_lookup, node_complete_node_tran  
  slation_lookup, array_pop, array_shift, default_entity_value, dom, dom_appl  
  y_styles, dom_migration_lookup, dom_remove, dom_select, dom_str_replace, en  
  tity_generate, entity_lookup, entity_value, file_blob, gate, merge, multipl  
  e_values, service, single_value, skip_on_value, str_replace, transliteratio  
  n, transpose, node_update_7008, path_set_translated, d6_url_alias_language,  
   d6_path_redirect, d7_path_redirect, d7_redirect_source_query, search_confi  
  guration_rankings, system_update_7000, timezone, forum_vocabulary, convert_  
  tokens, profile_field_settings, user_langcode, user_update_8002, d6_profile  
  _field_option_translation, user_update_7002, field_collection_field_instanc  
  e_settings, field_collection_field_settings, paragraphs_field_instance_sett  
  ings, paragraphs_field_settings, paragraphs_lookup, paragraphs_process_on_v  
  alue

Steps to reproduce

There can be various reasons like core or contrib module bugs or migration misconfigurations causing this error message.
The problem is, that the error message is useless as it contains no helpful information WHAT went wrong WHERE.

Proposed resolution

Add more details to the error message, so the message is helpful and allows finding the root cause of the error.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Problem/Motivation

During an upgrade from 8.6.16 to 8.7.3, I ran into an issue with taxonomy_post_update_make_taxonomy_term_revisionable() .

The following error is thrown during processing of the update.

Base table or view not found: 1146 Table 'drupal.tmp_ed8154taxonomy_term_r__ff793441e7' doesn't exist: ...

.

Through some debugging, I determined that the temporary table, tmp_ed8154taxonomy_term_r__ff793441e7 was related to a custom field, field_default_access, an entity reference field on my Vocabulary. The default tempary table name, tmp__taxonomy_term_revision__field_default_access, turns out to be 49 characters, and is replaced with the hash format tmp table name, see DefaultTableMapping::generateFieldTableName() . While tracing the code for the EntityDefinitionUpdateManager::updateFieldableEntityType() , I discovered that this table was actually being created, but with a different sha255 has, resulting in the table name tmp_ed8154taxonomy_term_r__d348111e42.

Further discovery determined that SQLContentEntityStorage::saveToDedicatedTables() doesn't use the "$field_storage_definitions" used through out the update code, but calls $field_definition->getFieldStorageDefinition(); , which results in a different instance of the storage definition, with a different ( getUniqueStorageIdentifier() ), and as a result the table name isn't mapped correctly.

The issue here may be related to #3056539: Updating an entity type from non-revisionable to revisionable fails if it has non-revisionable fields stored in dedicated tables, however it doesn't appear the missing table in that issue is the result of the incorrect hashed table id, but it may be the result of not using the current table mapping correctly.

Proposed resolution

Changes the entity storage to use its internal definitions instead of the ones provided by the entity field manager.

Remaining tasks

#26.2
Review
Commit

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

I am migrating from a Drupal 7 site hosted on Pantheon to Drupal 8.8.4. I am using the migrate upgrade module and running the commands through drush.

The public files all imported correctly, including the files in subdirectories. But I can't get any of the private files to work. I can't tell if the issue is the private files or the subdirectories (all of the private files are in subdirectories so it's hard to isolate).

When I run drush migrate:import upgrade_d7_file_private and check the migrate messages I get errors such as Cannot read from non-readable stream (http://[hostname]/sites/default/files/private/subdirectory/file.pdf)

I see the MigratePrivateFileTest.php test passes, so I assume it's not just private files only that are the problem. The test sets the private directory at sites/default/private, but Pantheon requires it to be at sites/default/files/private. Maybe that is the problem?

I tried creating a test for that scenario (file_private_path set to sites/default/files/private, no further subdirectories) and it fails. But I also tried creating a test for public files in subdirectories (which works on my site migration) and that test fails too so something is not correct about my test.

I'm attaching a patch with those two tests. If anyone has advice on making the MigrateFileSubdirectoryTest.php pass (since I believe the functionality is working) then I can make a tests that shows my problem better.

Installed and enabled CKEditor 5 (35.1.0) Experimental in Drupal 9.4.8.

After changing CKEditor to CKEditor 5 in my existing text formats (e.g. Full html) and trying to save I get "The website encountered an unexpected error".

In Recent Log Messages I read:
Drupal\Component\Plugin\Exception\InvalidPluginDefinitionException: The "ckeditor5_imageUpload" CKEditor 5 plugin definition has a "drupal.admin_library" key whose asset library "ckeditor5/admin.imageupload" does not exist. in Drupal\ckeditor5\Plugin\CKEditor5PluginDefinition->validateDrupalAspects() (regel 235 van /var/www/vhosts/daproverb.be/httpdocs/core/modules/ckeditor5/src/Plugin/CKEditor5PluginDefinition.php).

Had to go back to CKEditor 4 because CKEditor 5 cannot work.

PHP 8.0.3 - Apache webserver

Problem/Motivation

Providing a UI for an entity type involves a lot of boilerplate code.

In particular, three YML files have to be provided:

- MODULE.links.menu.yml
- MODULE.links.task.yml
- MODULE.links.action.yml

These contain repetitive boilerplate code, where furthermore it's very easy to make a mistake and match up the route names incorrectly.

Proposed resolution

Add a new handler type for entities, 'link_provider'. This defines menu, task, and action links for an entity type.

Provide two link provider handlers in the Entity component that follow the standard admin UI pattern (for example, as used by Media module's entity types):

- DefaultContentEntityLinkProvider
-- defines a local task link for the collection under admin/content, alongside the Content admin listing
-- defines a menu link for the collection as well, so it appears in the admin toolbar
-- defines the 'add new entity' action link on the collection page
-- defines a set of local tasks link for view/edit/delete for a single entity

- DefaultConfigEntityLinkProvider
-- defines a menu link for the collection under admin/structure
-- defines the edit form local task link, which allows Field UI to attach its own tasks for the case that this config entity is the bundle for a content entity.

Both of these link provider handler classes expect to find the route names created by core's route_provider classes.

Entity types that customize their route provider to change or add routes would need to use their own link_provider handler (or keep using hardcoded link plugins of course).

Note that contextual links aren't provided by these, because they're part of Core-core, and contextual links are in a core module.

Remaining tasks

- Get a review from one of the managers of the plugin system. YAML plugins are not discoverable in core/lib (unlike annotation-based plugins), and so the current patch declares the plugin derivatives that are in core/lib/Core/Entity in system module's YAML files. This approach needs framework manager review.

Follow-ons

Convert core's entity types to use these handlers. This is left as as follow-up, because changing an entity type to use a link provider handlers will cause the plugin IDs of the link plugins to change. It's not clear whether the BC policy on plugin IDs applies to menu plugins, and there is no policy or defined way on how to handle YAML plugin ID changes -- see #2922451: [policy no patch] Make it possible to mark plugins as deprecated.

User interface changes

None.

Problem/Motivation

When doing a site clean install for some reason there's several of tens files that can't be imported in that time and I receiving the following messages (this is just few of them):
[warning] The "block_content:3e9e5e58-6407-41b9-92ac-c67246f11478" was not found
[notice] Missing required data for configuration: purge.logger_channels
[notice] Missing required data for configuration: purge.plugins
[notice] Missing required data for configuration: core.entity_form_mode.paragraph.date
[notice] Missing required data for configuration: facets.facet.content_type
[notice] Missing required data for configuration: field.field.user.user.field_picture
[notice] Missing required data for configuration: flag.flag.follow
[notice] Missing required data for configuration: language.entity.bg
[notice] Missing required data for configuration: pathauto.pattern.group_content
[notice] Missing required data for configuration: views.view.watchdog
[notice] Missing required data for configuration: views.view.who_s_new
[notice] Missing required data for configuration: views.view.who_s_online

While debugging I found that it comes from here the message: core/lib/Drupal/Core/Config/StorageCopyTrait.php from the replaceStorageContents function. Further checking this I've found that in the core/lib/Drupal/Core/Config/CachedStorage.php file the following code segment

  public function read($name) {
    $cache_key = $this->getCacheKey($name);
    if ($cache = $this->cache->get($cache_key)) {
      // The cache contains either the cached configuration data or FALSE
      // if the configuration file does not exist.
      return $cache->data;
    }
    // Read from the storage on a cache miss and cache the data. Also cache
    // information about missing configuration objects.
    $data = $this->storage->read($name);
    $this->cache->set($cache_key, $data);
    return $data;
  }

is being executed, where the cache returns an object, but the data in the object is empty. While if I run in that time the $this->storage->read($name); I get back the file contents actually.

My current best guess is that the warning has the solution. The only problem is that the contents are created in the hook_site_install_finished when the site should have all the config in place. But it doesn't. Still doesn't explain that a drush cr why does not fix this, why I have to enable any module to be able to import the missing configs.

Steps to reproduce

Unsure if it's reproducible on other installations, yet. But it should be something like this:
1. Have an already working site.
2. Try to do a clean install from config.
3. While it does the install from config I receive these messages and the configs are not installed or imported, and sometimes I can't do it even after the install as its shows like everything is imported. While enabling another module suddenly changes something and I can import the rest of the configs without an issue.

drush cr does not solve the issue, drush en and some module does...

Proposed resolution

On clean install, it should read the files instead of some cached values.

Remaining tasks

n/a

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Release notes snippet

n/a

Problem/Motivation

1. Create a content type with a Datetime field
2. Create some sample data with the content type
3. Create a simple view that has one exposed filter for selecting the Date
4. The exposed filter will force you on the 'is equal to' operator to make an exact match on specific datetime fields prior to listing

Cases:
1. Site allows users to create specific meeting times but the client wants search by month or day
2. Views does not allow the user to select the granularity of the search against the Datetime field, you can select the between operator, however if you have separate start/end dates it becomes more complicated since you would have to have the operator work between 4 specific dates... ugh.

Proposed resolution

Add simple form element to date exposed filter to allow the user to select the granularity of their date input

Remaining tasks

1. Land #2648950: [PP-2] Use form element of type date instead textfield when selecting a date in an exposed filter which is itself blocked on these 2:
   • #2625136: Fix label visibility and add wrapper container for exposed numeric/date filters with multiple form elements
   • #2419131: [PP-1] #states attribute does not work on #type datetime
2. More robust tests (see #57, #61.
3. If underlying date field is NOT a datetime field, but instead just a date field, then don't present granularity options for hours/min/second (from #61). Fixed in #79.
4. Sort out timezone bugs from #66.
5. Update summary with screenshots of the current UI, and flesh out "User interface changes" section in more detail.
6. Decide if we want granularity to work on timestamp fields, too. If so, implement the required changes to core/modules/views/src/Plugin/views/filter/Date.php.

User interface changes

Add a new form element to the views exposed filter

API changes

Data model changes

Original report by generalconsensus

Problem/Motivation

Currently in Content language and translation settings doesn't allow you to quickly navigate to the selected entity type, you have to manually scroll down. This quickly becomes tedious as configured entity types grow in number.

Steps to reproduce

1. Enable the Language module
2. Navigate to /web/admin/config/regional/content-language and enable translation for several entity types

Proposed resolution

The attached patch appends links to each enabled entity type checkbox. Clicking on the link will scroll the page to the selected entity settings.

Problem/Motivation

When placing block on a page, you can set the block machine name. But the configuration of this block depends on the theme you place your block in.

On the same websites, if there are multiple themes, you can't place the same block on another theme with the same machine name because it is already used.

Proposed resolution

A best practice would be to prefix block machine name by the machine name of the theme it is in.

For example: block.block.bartik_help.yml

Remaining tasks

• Complete the feedback mentioned in #3061266-39: Prefix block machine name suggestions with the theme machine name and apply it to the latest version.

Subsequent tasks

• Coder patch had been prepared: #3061184: Add a rule on block machine name
• Alter the autogenerated machine name in the form to add a block to prefix automatically by the theme machine name (this issue)
• Update all the existing block config in core to respect this new standard: #3061267: Update blocks machine name to be prefixed by the theme machine name