Problem/Motivation

According to the documentation of \Drupal\Core\Entity\EntityTypeInterface::getHandlerClass() the method should return NULL if a handler class is not set.

We never test for this outcome.

Proposed resolution

Add a test case to Drupal\Tests\Core\Entity\EntityTypeTest to ensure that a NULL result is possible.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Right now, d7_rdf_mapping is a monolithic migration. It would be nice to derive these migrations per entity type and per bundle, and skip those rdf mappings whose destination entity (type) is missing.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

#3013276: [META] Remove deprecated modules on the Drupal 9 branch deals with removing deprecated modules. This plan issue is to deal with all the rest of the deprecated code to be removed that are outside of deprecated modules: classes, methods, procedural functions and code paths that are not in wholly deprecated modules.

Some of these can just be deleted when 9.x opens, which might even be scriptable.

Proposed resolution

• Open issues only if you are going to submit a patch for them. (We don't want hundreds of stub issues with no activity.) Look carefully for duplicates.
• Tag the issues with Deprecation Removal and file them against the 9.0.x branch.
• For large APIs, a single issue to remove the whole API is best. While we don't usually recommend scoping issues by module instead of concept, in this case, the API provided by a module can be considered a single API, especially for smaller modules. Issues can also be grouped by core subsystem namespace (e.g. things in core/lib/Drupal/Core/Foo/).
• Remove only:
  • The module's own API.
  • Legacy tests of the removed API.

  Remaining tasks

  Sub-issues until done!

  User interface changes

  None.

  API changes

  Deprecated APIs will be removed.

  Data model changes

  None.

Problem/Motivation

The $configDirectories property in FunctionalTestSetupTrait was deprecated as per https://www.drupal.org/node/3018145

Proposed resolution

Remove references to $configDirectories

Remaining tasks

Patch, test, commit

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Drupal 8 can send HTTP headers up-to 16kb.
https://www.drupal.org/docs/8/api/cache-api/cache-tags

Downstream systems are being updated to support this. If Drupal sends a request that exceeds 16k the downstream systems will fail with inconclusive errors. For example Varnish will return "HTTP/1.1 502 Bad Gateway." Very few people will be able to debug this sort of situation. We recently encountered a situation with a 50k header!

If a request has too many cache-tags associated with it the header size could exceed 16kb. When this occurs Drupal should provide feedback. Some possible approaches:

1. Throw a 50x error.
2. Log an error but allow the request through.

My gut is that this should be treated like an out of memory exception at PHP and be made obvious? Thoughts?

Problem/Motivation

Classy will be moved to contrib during Drupal 9. After we have ensured that core themes (Bartik, Claro, Seven, Umami) are not using Classy templates or libraries, we can remove Classy as a base theme of these themes.

Proposed resolution

Change base theme from Classy to Stable. These themes will be made not dependent on Stable in a follow-up #3110855: Plan for removing dependency to Stable in Bartik/Seven/Claro/Umami.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

As part of #3094468: [plan] Update core JavaScript (and CSS) dependencies prior to 9.0.0-beta1 we need to update Normalize.css to the most recent version - 8.0.1

Proposed resolution

Update it. Then, evaluate the changes (which are considerable) and determine which would cause regressions in core and provide customizations that address the regressions.

User interface changes

The goal is for there to not be any

Previous issue summary (to help make sense of the first 3 years of comments)

Problem/Motivation

Firefox 49 is out and has support for <details> which means our polyfill doesn't kick in. Normalize.css sets <details> and <summary> element as display:block which means Firefox won't display the marker, they fixed this in 5.0.0 (https://github.com/necolas/normalize.css/issues/604).

Checkout comparison aligned by @droplet: (removed comments & unchanged rules, re-reordering to match v3)
https://www.drupal.org/files/issues/diff-manual-aligned-by-%40droplet.patch

Here are the change logs for Normalize.css, starting at 4.0.0 (scroll up): https://github.com/necolas/normalize.css/blob/f06565fe8e0e1ad1b88f273271.... There are a lot of changes due to reorganization/sectioning of the code as well as comment changes.

There is one notable change that causes a regression in, at least, Seven: https://github.com/necolas/normalize.css/commit/02c5c7adbbec1707900fde86..., see the attached screenshot.

There may be regressions upgrading from 3.0.3 to the most recent normalize.css.

Proposed resolution
Upgrade core's Normalize to most recent version.
Normalize 3.0.3 should be copied to Stable. Stable needs to continue using 3.0.3 for BC.

Problem/Motivation

Postponed on #2821525: Update normalize.css to the most recent version, which is also the issue where this was discovered. In that issue, Normalize.css was updated from 3.0.3 to 8.0.1. This rule was present in normalize.css 3.0.3 but has since been removed as they correctly concluded it was preventing access to legitimate functionality (and several libraries were overriding this rule because of it):

input[type="search"]::-webkit-search-cancel-button {
  -webkit-appearance: none;
 }

When this rule is removed in Drupal, however, it breaks styling for search inputs in Safari (and possibly other browsers) when using Seven, while Bartik and Umami are also changed, but it will require discussion before we can conclude if it's an acceptable change. Examples:
Bartik
With search cancel hidden, it looks like we expect

With search cancel not hidden

Seven
Is more subtle, but still changes things:
With search cancel hidden

With search cancel not hidden, the button and input top/bottom are no longer perfectly aligned

Umami
The version with the rule removed is on top. The input is slightly taller and the cancel button is slightly not aligned with the search button text.

Claro
The version with the rule removed is on the left -- the input is slightly wider as a result.

Because of these styling changes, this rule has been added back to all core themes despite its removal in normalize.css. Ideally, this rule should not be present as the search cancel button is functionality users should have access to.

Proposed resolution

- Remove instances of the rule mentioned above (it will be accompanied by a @todo for this issue).

- Correct any styling differences that can be categorized as problems due to this un-hiding the webkit search cancel button. It's possible some of these will be considered acceptable changes.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

The webkit search cancel button was previously not displayed by core themes. This button is now displayed and will appear in the search input when text is entered when viewed by a webkit browser that supports this functionality.

The ultimate goal of this issue is to remove \Drupal\Core\Messenger\LegacyMessenger entirely (which is deprecated and scheduled for removal prior to 9.0.0) and solely rely on the Messenger service.

If possible, 3rd party code should use the Messenger service or find alternative solutions that don't involve using this deprecated class.

If there is any 3rd party code that provides a legitimate use case for keeping this around, we may have to re-think how messages work (highly unlikely, but currently a complete unknown).

This is partially due to the fact that the drupal_set_message() and drupal_get_messages() proceedural functions have been around for over 14 years and usage of these functions was heavy throughout core, contrib and 3rd party code alike.

Thus, this issue also serves as a way to track usage of this deprecated class.

Use cases:

• Drush - Used when creating a new site and the container is not yet initialized. Unclear if this is a hard dependency or its code can be fixed, needs research

Problem/Motivation

When I display a custom block using the block layout configuration the block prints using the block.html.twig template. However if I have a custom block view, each row is just the rendered fields, not the whole rendered block. The same problem occurs displaying a rendered block content entity in an ER field or displaying it programmatically like a normal content entity. It causes problems for themers and is inconsistent with similar row formats like "Show: Content" for nodes, and also means that contextual links don't show.

The problem is that block_content entities explicitly have no defined #theme/template because they were expected to always be rendered as a block (core, page_manager, .. doesn't matter, but it has to be a block).

Steps to reproduce:

1. Create a custom block
2. Create a view showing custom blocks
3. For the view format select Show = Custom block

Available workarounds

• Twig Tweak v2 has a Twig tag that lets you render blocks including block content.
• Block content template adds a new template for block content entities and restores contextual links.

Proposed resolution

So the answer to this might simply be that this is on purpose, if you want to display something with views or references or ..., then don't use block_content but either a node type or custom entity type. I'm not sure I see an alternative for keeping it working correctly and efficiently (=no double-render caching of the same content, for example) also within a block. However it's a major DrupalWTF moment when you realize this. It's also a while since D8 was released, there's no documentation about this and there's functionality available in core to trigger this bug.

The following exception occurs when using the "Content: Created month" contextual filter in a view.

InvalidArgumentException: The timestamp must be numeric. in Drupal\Component\Datetime\DateTimePlus::createFromTimestamp() (line 198 of /app/web/core/lib/Drupal/Component/Datetime/DateTimePlus.php).

Steps to reproduce

• Create a view for content (nodes)
• Use a block as display type
• Add a contextual filter for "Created Month"
• Select 'Provide default value'
• Select 'Query parameter' as type
• Name the query parameter 'month'
• Enter 'all' as fallback value
• Enter 'all' as exception value under exceptions
• Save the view
• Creates some nodes to fill the view
• Place the view block on a page you can visit
• Go to the page without the query parameter in the URL

Expected behavior

Following above steps but with the "Content: Created year" contextual filter instead results in the block being shown with all results. This is because the filter is ignored due to the exception value matching the fallback value. The filter for month should also be ignored if the query parameter is missing or containing ?month=all

I'm not sure if this is a bug or I'm just doing something wrong so I've tagged it as support for now.

I'm trying to make a custom views filter plugin that uses ajax in the form. It's a multi-vocabulary term select - the user selects a vocabulary then selects a term from that vocabulary from an ajax-populated list.

However, I'm encountering several bizarre issues while trying to set it up. If I provide the ajax callback as [$this, 'updateTerms'] it gives me this ajax error in preview:

A fatal error occurred: Recursion detected

Ajax never even runs in the full view. In this case the widget is not rendered at all and the error occurs even on the first load of the widget.

If I provide the ajax callback as either '::updateTerms' or 'Drupal\de_vocabulary_level_views_filter\Plugin\views\filter::updateTerms' it gives me this error in the views preview:

A fatal error occurred: The specified #ajax callback is empty or not callable.

and, inexplicably, this error on the full view:

An unrecoverable error occurred. The uploaded file likely exceeded the maximum file size (8 MB) that this server supports.

This issue occurs even on a fresh minimal install of Drupal 8 core with no extra modules or configuration besides enabling taxonomy, views, views_ui and the custom module itself and adding the filter to a view.

The form is pretty simple and works outside of views.

The form is provided in the valueForm function (though I've had the same results inside buildExposedForm) which is overridden like so:

  /**
   * {@inheritdoc}
   */
  protected function valueForm(&$form, FormStateInterface $form_state) {
    $vocabularies = $this->vocabularyStorage->loadMultiple();
    $vocab_options = array();

    foreach ($vocabularies as $voc) {
      $vocab_options[$voc->id()] = $voc->label();
    }

    $form['value'] = [
      'vocab' => [
        '#title' => $this->t('Vocabulary'),
        '#type' => 'select',
        '#options' => $vocab_options,
        '#empty_option' => $this->t('- Any -'),
        '#empty_value' => NULL,
        '#default_value' => !empty($form_state->get('vocab')) ? $form_state->get('vocab') : NULL,
        '#ajax' => [
          'event' => 'change',
          'callback' => 'Drupal\de_vocabulary_level_views_filter\Plugin\views\filter::updateTerms',
          'wrapper' => 'de-vocabulary-level-views-filter-terms-wrapper'
        ],
      ],
      'de_vocabulary_level_views_filter' => [
        '#title' => $this->t('Term'),
        '#type' => 'select',
        '#empty_option' => $this->t('- Any -'),
        '#empty_value' => NULL,
        '#default_value' => !empty($form_state->get('term')) ? $form_state->get('term') : NULL,
      ],
      '#prefix' => '<div id="de-vocabulary-level-views-filter-terms-wrapper">',
      '#suffix' => '</div>',
    ];

    if (!empty($form_state->getValue('vocab'))) {
      $term_query = $this->entityQuery->get('taxonomy_term')
        ->condition('status', 1)
        ->condition('vid', $form_state->getValue('vocab'));
      $term_query_result = $term_query->execute();
      $terms = $this->termStorage->loadMultiple($term_query_result);
      $term_options = [];
      foreach ($terms as $term) {
        $term_options[$term->id()] = $term->label();
      }
      $form['value']['de_vocabulary_level_views_filter']['#options'] = $term_options;
    }
  }

There's a small ajax callback:

  public function updateTerms(&$form, FormStateInterface $form_state) {
    return $form[$this->options['expose']['identifier']];
  }

Currently it reloads a section of the form from the base of the filter form but the same results occur treating it as if it was just the bit from valueForm.

We've run into an issue where we are getting an error on a link field:

Error: Unsupported operand types in /core/modules/link/src/Plugin/Field/FieldFormatter/LinkFormatter.php on line 245

I don't know if it's possible to reproduce this error with just core. The error seems to be coming from a translation issue in Paragraphs where the "options" property isn't getting set right. This patch is a work-around to that but it's just checking that $options is an array and making it one if it's not so it won't hurt anything to have it in there as a failsafe.

Problem/Motivation

I can no longer save changes to the layout after any kind of form has been added to the layout.

Steps to reproduce:
1. Enable layout builder on a content type, then open layout builder.
2. Add 'Search Form' block to a section
3. Save the layout
4. Re-open the layout builder, and make some change (e.g. reorder blocks)
5. Attempt to save the layout

The page refreshes, but still shows unsaved changes. At this point, it is no longer possible to save the layout until the search form is removed.

Proposed resolution

Replace all FORM tags with DIV tags when in Layout Builder's preview mode.

Remaining tasks

Write tests

User interface changes

Layout Builder UI will no longer break when rendering forms

API changes

N/A

Data model changes

N/A

Release notes snippet

Problem/Motivation

Classy will be moved to contrib during Drupal 9. In preparation to that, we have to remove dependencies on Classy from all core themes.

Proposed resolution

Use this spreadsheet of Core Theme's use of Classy as reference

Create theme-specific versions of all libraries that are not already overridden by the theme.

Copy all remaining Templates and CSS that are not already overridden by the theme and remove dependency to Classy. Some templates in Classy are identical to Stable and can be removed instead of copied. This is covered by #3098150: Add test coverage to ensure Classy templates that have identical versions in Stable are kept in sync

Themes subtheming Classy should not depend on preprocess/alters in classy.theme. The issue for this is: #3109287: Decouple Classy-inheriting themes from Classy's preprocess functions

Theme specific issues:
Claro: #3084810: Decouple Claro from Classy, #3108109: Decouple Classy libraries from Claro
Umami: #3096014: [META] Make Umami theme non-dependent on Classy
Seven: #3107872: Decouple Classy libraries from Seven
Bartik #3108181: Decouple Classy libraries from Bartik

Remaining tasks

• Determine directory structure for copied templates: #3095713: Create classy directory with README, in the templates and css directories for all themes subtheming Classy
• Create test process for copying libraries: #3096203: Create Classy library dependency tests that can be used for all themes, and verify by providing an Umami-specific classy/dropbutton
• Create test process for copying templates: #3096349: Create test for confirming Themes do not depend on Classy templates (currently blocked on #3106600: Decouple Classy libraries from Umami and other yet-to-be-created issues for decoupling Classy libraries from themes)
• Copy templates from Classy: #3113608: Add copies of Classy templates to core themes
• Remove Classy templates with identical copies in Stable: #3098150: Add test coverage to ensure Classy templates that have identical versions in Stable are kept in sync
• Make core themes depend on Stable instead of Classy: #3115088: Remove Classy as a base theme of core themes

Once the test procedure and directory naming is settled, create multiple issues for moving templates/libraries to themes. Consider grouping similar templates in an issue to reduce the total number of issues, but the scope should remain reasonable for each.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

We create the key_value table on the installation of the system module.
Let's make that lazy like for example the cache system.

Proposed resolution

The patch from #67 was committed (5571193) and then reverted (eaaea5d for two reasons:

1. This breaks saving config entities without UUIDs (#73).
2. There are test failures with PHP7 and some database drivers (#74).

The first problem is addressed in #77 and more recent patches. Some patches (up to #94) addressed the second problem, but not in a satisfactory way, so that problem was split off into #2847855: Incorrect statement class caused by race condition when closing and opening the connection.

Remaining tasks

This issue is postponed on #2847855: Incorrect statement class caused by race condition when closing and opening the connection.

User interface changes

API changes

Data model changes

Problem/Motivation

Drupal 9 uses popper v1, popper v2 is out - should we update before D9 is out?

https://dev.to/fezvrasta/smarter-tooltips-and-popovers-with-popper-2-44bh

Proposed resolution

Update to Drupal core's use of popper to be compatible with popper v2 for Drupal 9.

Add polyfills for array.find and object.assign, which are used by Popper.js v2 but not supported by IE11 or Opera Mini

Remaining tasks

User interface changes

Steps for testing changes:

• Install Drupal with Umami demo
• Ensure you are logged in as an admin
• Navigate to /articles/give-it-a-go-and-grow-your-own-herbs
• Click quick edit from a contextual link on the main content
• Ensure that the positioning of the editor toolbar is smooth when scrolling and editing various fields

Release notes snippet

The Popper.js library has been updated to version 2.0.6. This migration guide is available for anyone that needs to convert their Popper.js 1.x compatible code to 2.x.

Problem/Motivation

Theme suggestions for a custom block type generate a duplicate of block--block-content.html.twig.

FILE NAME SUGGESTIONS:
* block--example.html.twig
* block--block-content--e81b663b-5755-4daf-889d-7ea1c9857b3d.html.twig
x block--block-content.html.twig
x block--block-content.html.twig
* block.html.twig

See core/modules/block/block.module.

/**
 * Implements hook_theme_suggestions_HOOK().
 */
function block_theme_suggestions_block(array $variables) {
  $suggestions = [];

  $suggestions[] = 'block__' . $variables['elements']['#configuration']['provider'];
  // Hyphens (-) and underscores (_) play a special role in theme suggestions.
  // Theme suggestions should only contain underscores, because within
  // drupal_find_theme_templates(), underscores are converted to hyphens to
  // match template file names, and then converted back to underscores to match
  // pre-processing and other function names. So if your theme suggestion
  // contains a hyphen, it will end up as an underscore after this conversion,
  // and your function names won't be recognized. So, we need to convert
  // hyphens to underscores in block deltas for the theme suggestions.

  // We can safely explode on : because we know the Block plugin type manager
  // enforces that delimiter for all derivatives.
  $parts = explode(':', $variables['elements']['#plugin_id']);
  $suggestion = 'block';
  while ($part = array_shift($parts)) {
    $suggestions[] = $suggestion .= '__' . strtr($part, '-', '_');
  }

  if (!empty($variables['elements']['#id'])) {
    $suggestions[] = 'block__' . $variables['elements']['#id'];
  }

  return $suggestions;
}

$variables['elements']['#configuration']['provider']; is equal to "block-content" and $variables['elements']['#plugin_id'] contains "block-content" (e.g. "block-content:e81b663b-5755-4daf-889d-7ea1c9857b3d:example").

Proposed resolution

Clean duplicates in core/lib/Drupal/Core/Theme/ThemeManager.php after invoke hook_theme_suggestions_alter() and hook_theme_suggestions_HOOK_alter().

$suggestions = array_unique($suggestions);

Problem/Motivation

We want to incentivize people to use layout builder to build bespoke pages. Most of the time, when building using the existing components provided (e.g. custom blocks on the site) you don't actually want to see the title. Most of the time, we find ourselves unchecking that checkbox.

Proposed resolution

Let's uncheck the checkbox by default for people.

Remaining tasks

Review the patch.

User interface changes

When adding a block via layout_builder_add_block form, the label_display is set to "false".

API changes

n/a

Data model changes

n/a

Release notes snippet

?

Original report by [username]

Originally filed as a Demo Framework issue on github. https://github.com/acquia/df/issues/145

Problem/Motivation

The entity.autocomplete_matcher service is handled by EntityAutocompleteMatcher class which doesn't implement any interface. Because of that the EntityAutocompleteController's constructor accepts only instances of that class. That causes problems when trying to decorate the entity.autocomplete_matcher with a class that doesn't extend the original one.

Proposed resolution

Add the EntityAutocompleteMatcherInterface.

Remaining tasks

None.

User interface changes

None.

API changes

EntityAutocompleteMatcherInterface present.

Data model changes

None.

Release notes snippet

EntityAutocompleteMatcherInterface has been added, so the entity.autocomplete_matcher service can be decorated.