Issues for Drupal core

Problem/Motivation

Many platforms and development environments use Basic Auth configured on the server to provide a Site Lock. This allows making sites available to select people via the public web without exposing the site to the public in general. For example, https://pantheon.io/docs/lock-environment/.

This might manifest if you are not thinking about it as though the user/login form itself is throwing an access denied, or on further investigation and confirmation of permissions that all pages are mysteriously throwing an access denied.

Per http://drupal.stackexchange.com/a/212800/394 and an examination of the Basic Auth provider code, what's happening is that if you use Basic Auth headers, PHP will pick them up and the Basic Auth module in core will be "triggered' to attempt authentication with those credentials. If it fails, the response will be redirected to access denied. After all, a login attempt just failed.

The frustration level this issue can cause makes it a major DX issue when the stars align, and while I marked it as a bug, you could argue it's a support request.

Proposed resolution

This issue is complicated because it could be considered a feature, not a bug. However, there is a common expectation that a "site lock" can be configured without regard for the application configuration.

One solution could be a simple configuration option that allows checking to see if the user account does not exist, and if not treat it as an anonymous request.

Another possibility would be supporting the Drupal site issuing Basic Auth challenges, allowing the site itself to provide the "lock UI".

Remaining tasks

Decide if this is a problem that should be solved. If not solved, this becomes a documentation problem to explain what's going on and recommended workarounds.

User interface changes

API changes

Data model changes

Problem/Motivation

When using the Claro theme, custom classes added to pager links do not appear. Claro defines its own class for pager links but does not add any custom classes. Normally, custom classes can be added to themes using template hooks.

Steps to reproduce

Install fresh Drupal setup
Enable Claro theme
Create a view with pager enabled
Add a template_preprocess_pager hook and add a test class (see example below)
Go to the view and inspect the pager markup
Result: The test class is not added to the pager
Expected: The test class is added to the pager

Example test Hook:

/**
 * Implements template_preprocess_pager().
 */
function claro_preprocess_pager(&$vars) {
  if (isset($vars['pager'])) {
    if (count($vars['items'])) {
      foreach ($vars['items'] as $key => $value) {
        // print_r('<pre>');
        // var_dump($value);
        if (!empty($value['attributes'])) {
          $vars['items'][$key]['attributes']->addClass('test-pager-class');
        }
        else {
          if (count($value) > 3) {
            foreach ($value as $subKey => $subValue) {
              if (!empty($subValue['attributes'])) {
                $vars['items'][$key][$subKey]['attributes']->addClass('test-pager-class');
              }
            }
          }
        }
      }
    }
  }
}

Screenshots

Before:

After:

Proposed resolution

Update pager.html.twig to inject custom classes. See other themes for examples.

Remaining tasks

~~Create patch~~
~~Test patch~~
~~Review patch~~
Commit

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When a new node is created BaseField definitions are statically cached in ONE language.
There are however use cases where you'd want more than one language for an entity type (E.g. Dutch & English node).

Some more context how I ran into this:

Our default language is English (we don't want to export Dutch config) and we have a language negotiator with a fallback to Dutch (/nl, /fr, /en, /de).

The first time we run this Behat test all is green, the second time it's failing because "Title" appears (instead of "Titel"):

  Scenario: Webmaster can create a promopage
    Given I am logged in as a "webmaster"
    And group content:
      | title      | moderation_state  | langcode |
      | Test group | published         | nl       |
    When I go to "/nl/node/add/promopage"
    Then I should see the text "Titel"

Strangely, the following test is always green:

  Scenario: Webmaster can create a promopage
    Given I am logged in as a "webmaster"
    When I go to "/nl/node/add/promopage" # <= added this
    Then I should see the text "Titel" # <= added this
    And group content:
      | title      | moderation_state  | langcode |
      | Test group | published         | nl       |
    When I go to "/nl/node/add/promopage"
    Then I should see the text "Titel"

When using another role or a specific test user or change a permission the test succeeds (only the first time). Something is caching wrong config translations.

The error only seems to apply only for basefield overrides. EntityFieldManager::getFieldDefinitions() somehow contains their translations in the wrong language.

We can workaround the issue with drush -y config-set language.negotiation url.prefixes.nl ''

Proposed resolution

After some investigation I discovered that EntityFieldManager::getBaseFieldDefinitions caches the definitions in a class property with labels and their translations) only once (for all languages):

  /**
   * {@inheritdoc}
   */
  public function getBaseFieldDefinitions($entity_type_id) {
    // Check the static cache.
    if (!isset($this->baseFieldDefinitions[$entity_type_id])) {
      // Not prepared, try to load from cache.
      $cid = 'entity_base_field_definitions:' . $entity_type_id . ':' . $this->languageManager->getCurrentLanguage()->getId();
      if ($cache = $this->cacheGet($cid)) {
        $this->baseFieldDefinitions[$entity_type_id] = $cache->data;
      }
      else {
        // Rebuild the definitions and put it into the cache.
        $this->baseFieldDefinitions[$entity_type_id] = $this->buildBaseFieldDefinitions($entity_type_id);
        $this->cacheSet($cid, $this->baseFieldDefinitions[$entity_type_id], Cache::PERMANENT, ['entity_types', 'entity_field_info']);
      }
    }
    return $this->baseFieldDefinitions[$entity_type_id];
  }

We should make this language aware.

Problem/Motivation

I tried to rewrite a field's output in a view's field display mode. I'm tied to the display mode "fields" because I use https://www.drupal.org/project/search_api_solr and here I can't use the content display mode for the view.

Anyway I need to have control over the markup generated for a certain field. So I used the "rewrite result" feature and included my twig template there using "include()".

The one thing not working is that Drupal/Component/Utility/Xss is stripping out my responsive images (picture html tag). The allowed tags are defined in this class and I don't want to add a patch extending these tags since that's dirty coding.

So is there any way to extend the list of allowed tags for the filterAdmin() function in the Xss class? Or would that be a new feature?

Steps to reproduce

1. Create a view.
2. Assign field output mode.
3. Create a field and rewrite the result.
4. Place a picture tag in there (or any other non-allowed tag).
5. The tag is stripped out (as designed in the core, currently).

Proposed resolution

Add a hook to extend the list of allowed tags.

Any help is highly appreciated!

Bye Defcon0

Problem/Motivation

Once #2301239: MenuLinkNG part1 (no UI or conversions): plugins (static + MenuLinkContent) + MenuLinkManager + MenuTreeStorage is in, it would be possible to no longer hardcode the maximum depth of menus: MenuTreeStorage::MAX_DEPTH

Proposed resolution

Generate the schema using a configured maximum length
Try to not allow lowering the size

Remaining tasks

User interface changes

API changes

Postponed until

#2256521: [META] New plan, Phase 2: Implement menu links as plugins, including static admin links and views, and custom links with menu_link_content entity, all managed via menu_ui module

Currently in the Appearance section of Bartik, a live preview of a chosen color scheme is displayed as an image. This section uses Latin placeholder text, "Lorem ipsum . . . ." The problem is getting users to understand the Latin is JUST A PLACEHOLDER. Participants in a Drupal usability study at the University of Minnesota in 2011 expected it to be the live preview of the site with THEIR content. Looking at the Latin text, one participant in the study said, "What's this? French?"

In this thread from May 2011 to December 2014, contributors have narrowed in on recommending a patch to change the Latin text to repetitions of the English words "Sample text." Other suggestions have been to make the text translatable or to embed the content of the actual site as an iFrame. Placing "sample text" is the most simple of the solutions and would look like this:

Sample text

Block of text (re-arrange sentences so line lengths don't repeat)
This is a block of example content. This content is here to demonstrate what actual content would look like in the color scheme you configure. This is an example link, is is here to demonstrate how background colors you configure may affect the readability of links. This content is here to demonstrate what actual content would look like in the color scheme you configure. This is an example link, is is here to demonstrate how background colors you configure may affect the readability of links. This is a block of example content.

This is a followup to #2651716: Entity::getEntityFromRouteMatch() should support bundles, which added partial support for bundle-based entity routes : it only supports them when the bundle is part of the route path, but not when it is a constant parameter, because it only checks using $route_match->getRawParameter() instead of $route_match->getParameter().

Using $route_match->getRawParameter() is needed because some parameters are likely to be upcasted, but to support route-defined (vs request-defined) parameter values, a pair of extra calls to $route_match->getParameter() appears to be required.

Problem/Motivation

While working on #3217531: [PP-2] Deprecate Connection::getDriverClass mechanism, make its callers abstract, and use standard autoloading, we came across the fact that Connection::getDriverClass is also used to resolve overrides to select query extenders. This is not easily solvable with direct autoloading because the to-be-overridden class resides outside of the database driver namespaces; also, while the db driver specific classes are all necessarily extensions of the Core\Database ones, the extenders may be freely added by any module.

Proposed resolution

Try using backend-overrideable services, adding a factory for each extender that will then instantiate extender objects.

Remaining tasks

None

User interface changes

None

API changes

Using the full class name as the parameter value in the method Drupal\Core\Database\Query\Select::extend() has been deprecated. Also the method Drupal\Core\Database\Connection::getPagerManager() has been deprecated.

Data model changes

None

Release notes snippet

Select query extenders are now managed through backend-overrideable services. When extending a query, consuming code need to switch from hardcoding the extension class to calling the extender service with the type of extension required. Contrib and custom database drivers overriding the extenders need to implement their own service. See https://www.drupal.org/node/3218001

It's super frustrating when you want to have a text field (255chars) but the only way to see the entire 255 chars in that field is a really really reeeeally long textfield. Text areas are a thing. We should be able to use them (and not just for longtext text fields).

in Drupal 7, to use a textarea you need to create a whole new field and migrate all your data into it, but the underlying data structure is exactly the same!! This should not be necessary. Let's add the textarea widget as an option for text fields (but leave the existing widget as default)

The problem has been fixed, when sent restapi request to create node.
During investigation I found, thati if to _field_invoke() will come $op = 'form', $entity_type = "node", $entity with field $entity->{$field_name}[$langcode] with string value. For example, $entity->field_category= array("en"=>"1"). $items will be equal to string value "1" in code of _field_invoke():
$items = isset($entity->{$field_name}[$langcode]) ? $entity->{$field_name}[$langcode] : array();
$result = $function($entity_type, $entity, $field, $instance, $langcode, $items, $a, $b);
So $function = 'field_default_form' we call function ield_default_form(), where we see strings with code:

    $field_state = array(
      'field' => $field,
      'instance' => $instance,
      'items_count' => is_array($items) ? count($items) : count(array($items)),
      'array_parents' => array(),
      'errors' => array(),
    );

As a result count($items) we will get TypeError on php8: count(): Argument #1 ($value) must be of type Countable|array, string given in count() ... In 7.4 version on this step count($items) ="1".
I suggest to change formation of $field_state element with key "'items_count'" to:
'items_count' => is_array($items) ? count($items) : count(array($items)),

Problem/Motivation

DateTimeItem and DateRangeItem both have class constants. These should be on interfaces.

Proposed resolution

- Move the DateTimeItem constants onto DateTimeItemInterface as-is.

- Create DateRangeItemInterface, and move DateRangeItem constants as-is.

- Update usages to refer to the interface or static:: as appropriate.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

The Drupal\Core\Field\Plugin\Field\FieldFormatter\StringFormatter checks in its ::settingsForm method on the entity type, whether it has a canonical link template. That is correct.

However, it also checks for canonical link template existence within ::viewElements on the entity type. Since single entity instance are allowed to define whether they have a canonical link template on their own via EntityInterface::hasLinkTemplate, the StringFormatter should respect that accordingly.

Steps to reproduce

Proposed resolution

Replace the check on entity type level within StringFormatter::viewElements by a check on the entity itself.
Meaning changing this line

if ($this->getSetting('link_to_entity') && !$entity->isNew() && $entity_type->hasLinkTemplate('canonical')) {
to
if ($this->getSetting('link_to_entity') && !$entity->isNew() && $entity->hasLinkTemplate('canonical')) {

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

In Drupal 10

In Drupal 11

#3214954: [meta] Set Drupal 11 platform and browser requirements at least six months before the release
Set and address requirements for tagging 11.0.0-alpha1.
#3284879: [meta] Requirements for tagging Drupal 11.0.0-beta1
Additional betas as needed

Must-haves prior to tagging 11.0.0-beta1

We can eventually file child metas for these, but a list is sufficient for now.

Fully support PHP versions above the Drupal 11 minimum
Update or decouple/remove PHP (Composer) dependencies.
- Symfony:
  - Update to Symfony 7
- Shift incorrect production dependencies to dev:
  - None at present
- Re-evaluate other backend dependencies in the year prior to the release.
Update or decouple/remove frontend dependencies.
- jQuery UI:
- jQuery
Remove all deprecated code, libraries, and BC layers.
- (needs issue) [META] Remove deprecated modules and themes from the Drupal 11 branch
- (needs issue) [META] Remove deprecated classes, methods, procedural functions and code paths outside of deprecated modules on the Drupal 11 branch
Resolve critical 10.x -> 10.x upgrade path bugs.
(needs issue) Remove old upgrade paths up to 10.x.0 and add new database dumps.
Resolve any significant outstanding bugs for new platform requirements (PHP, Composer, etc.)
Resolve any 11.0.x-only security or data integrity issues.
Resolve other D11-only upgrade blockers.
Update all dependencies (backend and frontend) to their latest versions immediately before tagging 11.0.0-beta1.

Should-haves prior to tagging 11.0.0-beta1

These become beta targets if they are not completed by the deadline, and may contribute to other adjustments to the schedule (TBD).

Issues TBD.

Problem/Motivation

This is part of the CSS modernization initiative, and intended to be worked on by our Google Summer of Code student only. This is intended to be a straightforward first issue to easily onboard the student.

Steps to reproduce

The stylesheet at https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/themes/clar... needs to be refactored to make use of modern CSS and Drupal core's PostCSS tooling.

Proposed resolution

Use CSS Logical Properties where appropriate
Use CSS nesting where appropriate

Remaining tasks

We need two patches. One for Drupal 9.5.x and one for Drupal 10.0.x
We need a followup issue to refactor this component in Drupal 10.0.x to make use of component-level CSS custom properties.

User interface changes

None. There should be no visual differences.

This lays out what remains to be done after #3231364: Add CKEditor 5 module to Drupal core lands in Drupal core.

This plan was originally taken from the IS at #2966864: Add optional support for CKEditor 5 in D9 so we can remove CKE 4 from Drupal 10, and after that from #3201824: Roadmap to core.

Roadmap to Stable

Ensure that sites can update from using CKE4 to CKE5 safely when using no contributed CKEditor modules
1. #3268306: [upstream] [GHS] Custom/unofficial HTML tags not retained: <drupal-media>, <drupal-entity>, <foobar>
✅ Ensure contrib modules can do everything: translations, automatic upgrade path from CKE4 …
1. Currently none
✅ Ensure CKE5 equivalent plugins of CKE4 generate/support equivalent markup: #3222801: [META] Ensure CKE5 equivalent plugins of CKE4 generate/support equivalent markup
1. Currently none
Ensure CKE5 functionality matches that of Drupal core's CKE4:
1. #3222756: [upstream] Allow using images from external source
2. #3222797: Upgrade path from CKEditor 4's StylesCombo to CKEditor 5's Style
✅ Documentation gates:
1. Currently none
✅ Theming CKEditor 5
1. Currently none
Accessibility
Test coverage, reliability and maintainability matching or exceeding CKEditor 4's:
1. #3268983: [regression] FilterHtml throws Unsupported operand types error when * used in tag attribute
✅ Low-hanging fruit major UX improvements over CKEditor 4:
1. Currently none
Superior configuration UX:
1. #3245967: Messages upon switching to CKEditor 5 are overwhelming
✅ Performance
1. Currently none.

Roadmap after Stable

Upstream Drupal improvements that would simplify or improve CKEditor 5:
Obsoleteness of upgrade path in Drupal 11:
1. #3239012: [late 2023] Deprecate the upgrade path from CKEditor 4
Performance:
1. #3224261: [PP-2] Front-end performance: concatenate CKEditor 5 JS assets for every unique configuration
Media improvements
1. #3196593: Ease the transition to Media: save image uploads in CKEditor 5 as media entities when media is enabled? (or module specific solution if core issue won't land)
2. #3073901: Determine an upgrade path from CKEditor image button to media library (or module specific solution if core issue won't land)
Low-hanging fruit major UX improvements over CKEditor 4:
1. #3227354: Add support for ckeditor5-autoformat
2. #3274635: Use CKEditor 5's native <ol type> and <ul type> UX
Superior configuration UX:
1. #3225033: Whenever "Enable image uploads" is enabled for a text editor, the editor_file_reference filter should be enabled
2. #3227948: Hide incompatible filters
Maintainability:

Completed

This section mimics the structure of the above sections.

💯 Roadmap to Alpha

✅ Create the ckeditor5 module
✅ Create an @Editor PHP plugin with the ID ckeditor5.
✅ Create a Drupal.editors JS plugin with the ID ckeditor5.
✅ Getting CKE5 (CKEditor 5) to load at all on the /node/add/article form.
✅ #3201820: Manually test that CKE 5 can be used in off-canvas
✅ Enable a Drupal + CKE5 ecosystem
1. #3196178: Provide test module to verify contrib can extend CKEditor5
2. #3200008: Validation and editor settings
✅ A CKE5 configuration UI
1. #3198297: Toolbar UI for selecting and sorting buttons
✅ Ensure Quick Edit integration works
1. #3201648: Add test coverage for Quick Edit integration
2. #3205090: Field html not restored when cancelling Quick Edit
✅ Evaluate CK4 plugins and match features
✅ #3201821: Add JavaScript test coverage for CKE 5
✅ #3206686: IE11 warning for CKE5 in Drupal 9

💯 Roadmap to Beta

✅ #3215506: Plugins should be enableable based on toolbar configuration
✅ Ensure filter_html's HTML restrictions are respected inside CKE5 — tackled in #3201637: Figure out how to prevent data loss during upgrade/migration path
✅ #3206687: Toolbar UI accessibility review
✅ #3201641: Improve the HTML filter configuration UX
Enable translation features for CKEditor 5
1. ✅ #3202664: CKEditor 5's UI language should match Drupal's interface translation

Roadmap to Stable

Problem

Form handlers and API code manually calls trim() on values too many times.
It's unclear who is responsible for trimming text values / user input.
The lack of custom trim() calls can trigger error messages that are hard to recognize and resolve by a user, in case a submitted form value contains leading or trailing white-space (which is not visible/apparent).

Proposed solution

Introduce a generic #trim property for all form elements that accept #input.
Make #trim default to TRUE for all form element types that accept text as user input.
Process #trim directly in form_handle_input_element(). If the resulting #value is an empty string, trigger the regular processing flow that would be triggered for no user input - including #required validation.
Allow code that does not want this behavior to opt-out by setting #trim to FALSE. (There's no use-case for that in core, but still...)
Remove all manual calls into trim() from API code. Whoever is calling into APIs is expected to provide proper (trimmed) values.

Original summary:

If the user registers and by mistake includes and extra space before or after their email address, the system will reject the email address with an error message that is difficult to understand (as there is nothing obvious wrong with the email address). I have seen this several times when I paste my email address into the email address box and mistakenly include a trailing space. I just tried it on the Drupal.org site and got the error:

"The e-mail address testaccount@test.org is not valid."

My guess is that this problem might affect 2-3% of all users who ever try to set up Drupal accounts and leave them a bit frustrated.

It would be very easy to have the form on the page user/register trim the spaces off of the email address, to solve this problem.

Problem/Motivation

The core installer in D8 appends the database configuration at the end of the settings.php file, instead of after the $databases structure is documented, currently around line 220. For a person new to setting up Drupal this makes managing the settings file more confusing than it needs to be. For example, the documentation around the $databases variable is near the top of the file whereas the variable is added at the end.

Note: D7 and older used to work that way, so this is a regression.

Steps to reproduce

Run the site installer with a codebase that does not have an existing settings.php file present.

Proposed resolution

Change drupal_rewrite_settings() so that it replaces variables that already exist in the file rather than appending them.

Remaining tasks

Work out a fix to drupal_rewrite_settings() that replaces variables which already exist in the file.
Add test coverage.

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Release notes snippet

TBD

Background

The Olivero theme utilizes CSS variables in a very basic fashion. We declare colors like --color--primary-30, --color--primary-40, --color--primary-50, --color--primary-60,
--color--gray-5, --color--gray-10, --color--gray-20, --color--gray-45, --color--gray-60, etc.

We then utilize these variables directly within the component styles like

.breadcrumb__link {
  color: var(--color--primary-40);
}

Task

This task is to create an abstraction layer between the color custom properties and the component's CSS rules.

So, in the case above, we'd define a new variable scoped to :root something like --color-text-primary-medium and set that to var(--color--primary-40)

Then within the component stylesheet, we'd set the rule to use the new --color-text-primary-medium property.

.breadcrumb__link {
  color: var(--color-text-primary-medium); /* Needs to maintain a 4.5:1 contrast ratio against --color-xyx */
}

To be determined

Still to be determined are all of the variables that we will need to create. We may also have the opportunity to consolidate colors (if we do this, we'll need Olivero designer sign off).

Resources

A list of CSS color properties, selectors, and values is at https://docs.google.com/spreadsheets/d/19zkRfD4CogL8ZUbIirpHpAH2Xh9ma6Va...