Problem/Motivation

As noted in #3156881-35: Various methods of \Drupal\Core\Database\StatementInterface have changed their signature for PHP 8, the database Statement class is extending from PDO, and is therefore exposed to the changing winds of new PHP versions.

We should have our own Statement envelope instead, encapsulating a PDO (or, potentially, other) lower-level Statement object.

In https://github.com/mondrake/drudbal/blob/master/src/Driver/Database/dbal..., I have an example: the Statement object implemented for the DruDbal driver encapsulates a doctrine/dbal Statement (which is not a PDO Statement).

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

If there is a view that has exposed filters and then you place multiple of those views on a page, the filters apply to all of the views, instead of the one instance.

Steps to reproduce

Create a view with exposed filters, and place more than one on a page.

Before going any further, know this:

Much of the work on this task took place here: #2346973: Improve usability and accessibility of long select lists. It eventually became apparent that this needed its own issue

• Are you looking for the issue regarding a drop-in replacement for jQuery UI autocomplete, for stuff like entity reference fields? this is that issue
• Are you looking for the issue regarding UX improvments to <select> elements, making it easier to deal with long lists of options? That is a different issue, and it is here: #2346973: Improve usability and accessibility of long select lists

Problem/Motivation

We are in the process of deprecating jQuery UI in core. jQuery UI's autocomplete is among the components that need to be removed/replaced.
As mentioned in the parent issue: #3067261: [Plan] Remove jQuery UI components used by Drupal core and replace with a set of supported solutions
The OpenJS Foundation lists jQuery UI as an Emeritus project in https://openjsf.org/projects/ which is described as:

Emeritus projects are those which the maintainers feel have reached or are nearing end-of-life

Well before the need to deprecate jQueryUI emerged in mid-2019, there has been interest in replacing jQueryUI with something with better UX and accessibility (which is evident in this issue being created several years prior to mid-2019).

Proposed resolution

Replace jQuery autocomplete with the Awesomplete library. Awesomplete was one of ten libraries evaluated as a replacement for jQueryUI autocomplete. The full evaluation (with a prototype that can be used with taxonomy fields) is in comment on the issue this originated from: #223. This was chosen over the others for several reasons, including

• It was the only library reviewed to not have any glaring accessibility issues
• Unlike most candidates, the functionality is applied to the existing text field. Most of the other options require select elements or hide the text field and create pseudo-inputs from other elements, creating entirely new markup that could result in broken forms and frustrated contrib developers.
• Awesomplete is in the Joomla 4 alpha, which means another large project has vetted it and has interest in its continued support
• A review of its Github suggests that important issues actually get addressed

(in other words, it's easily the most accessible, least disruptive option chosen so far)

Steps taken prior to the proposed resolution

Several other options were evaluated. Note that all links to evaluations go a separate issue: #2346973: Improve usability and accessibility of long select lists, the issue that this originated from.

• https://github.com/jshjohnson/ChoicesEvaluation (#189)
• https://harvesthq.github.io/chosen/Evaluation (#194)
• https://github.com/Mobius1/SelectrEvaluation (#195)
• https://github.com/alphagov/accessible-autocomplete (prototype at #182, great accessibility but not considered as it does not support select/multiselect It is strictly for providing suggestions to single-value text fields)
• https://github.com/HemantNegi/jquery.sumoselectEvaluation (#201)
• http://ivaynberg.github.io/select2 (of which https://github.com/woocommerce/selectwoo is a fork of, created to improve accessibility) Evalulation (#193)
• Custom library based on https://react-select.comEvaluation (#200)
• https://selectize.github.io/selectize.js/Evaluation (#199)
• https://leaverou.github.io/awesomplete/Evaluation and prototype (#223)
• https://github.com/github/auto-complete-elementEvaluation (#222)

Other than Awesomplete, nontrivial accessibility problems identified in each evaluation. These problems were discovered from general accessibility testing. In each case, enough issues were found that it wasn't worth devoting additional time to strictly checking against W3 specs.

Remaining tasks

• Accessibility review
• JS review
• FE Manager review
• UX review
• Product Manager review
• (probably more reviews, this is a major change)

Unlike most experimental module additions, this is an allowed change in 8.9.x/9.0.x because it's not just a feature; it's also a critical security hardening task.

User interface changes

Yes.

API changes

Yes.

Problem/Motivation

jQueryUI has reached end of life so it is being deprecated for removal in Drupal. The drupal.tabbingmanager library depends on jqueryUI.

Proposed resolution

According to the comment in core.libraries.yml, jquery ui is only needed because it # Supplies the ':tabbable' pseudo selector.

We should find a way to achieve this functionality without jQuery UI and implement it.

Remaining tasks

Confirm that tabbingmanager only needs jquery.ui for ':tabbable'
Confirm there are existing tests that would fail if tabbingmanager didn't use jQueryUI -- if not, these should be added.
Find an alternative solution - ideally this could leverage an existing library instead of something custom to Drupal.
Implement the solution.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Repeated 'settings' word in multiple files

Hi, I'm using Layout Builder Modal + Layout builder admin theme. When I use the default D8 administration theme (seven) everything works fine.

If I enable "Claro" as admin theme I've a bug: I've created a custom block type with a multivalue field. The "Add another item" button related to this field is rendered after the form submit button. This happens only with Claro so I'm reporting this bug here.

The "Add another item" should be near the field, the submit button instead should be on the bottom.

The update from alpha to beta1 appears to introduce an issue with the LEFT margin of vertical tabs. Basically, the left margin of 15em is no longer overwritten by claro/css/dist/components/vertical-tabs.css line 4:

.vertical-tabs{
  margin-top:0.75rem;
  margin-bottom:0.75rem;
  border-top:1px solid transparent;
}

commit: https://git.drupalcode.org/project/claro/blob/f49e9194f3cc8b91f4414a6796...

Previously, it was

.vertical-tabs {
  position: relative;
  overflow: hidden;
  margin: 10px 0;
  border: 1px solid #bdbdbd;
  border-radius: 4px;
  background: #e6e5e1;
}

See: https://git.drupalcode.org/project/claro/blob/8fb8f5dae19a25b24fec053d19...

This code overwrote this:

.vertical-tabs {
  margin: 1em 0 1em 15em; /* LTR */
  border: 1px solid #ccc;
}

found in core/misc/vertical-tabs.css.

I have also added two images to show the difference. I can override this in my child theme, but since it looks like the change also involves variables, I can't easily do a pull request.

Problem/Motivation

We are now able to create inline blocks from the Layout Builder but they are always set to non-reusable. It would be nice to have a checkbox to decide of the block should be reusable or not, similar to functionality in FPP for Drupal 7. This would allow editors to create reusable blocks while editing layouts for individual pieces of content, rather than having to jump to the "Block layout" section.

Proposed resolution

• Add a "Reusable" checkbox to inline_block plugins in Layout Builder
• If checked, it'll expose an "Admin title" field for naming the reusable block
• Once saved, it'll convert the underlying content block entity to reusable, and convert the inline_block plugin on the Section to a block_content plugin
• Allow editing the content block referenced by block_content plugins, and include a warning that let's editors know that their changes will be reflected globally

Remaining tasks

• Determine if this is something we should tackle in core
• Write tests

User interface changes

• Adds checkbox and admin title field when editing inline_block in Layout Builder:
  
• Adds content block fields and warning when editing block_content in Layout Builder:
  

API changes

None.

Data model changes

None.

Release notes snippet

TODO

Problem/Motivation

One major piece of functionality from the D7 Entity Reference module was left out entirely in #1801304: Add Entity reference field: the ability to render exposed views filters as a select list or autocomplete of available entities.

Proposed resolution

Create a new Views Entity Reference filter plugin to be available for all entity reference fields and migrate the existing taxonomy filters to be based on the new generic filter plugin.

How to use

1. Add on an entity type / bundle an entity reference field, ex field_test_reference.
2. Create a view displaying this entity type.
3. Add a filter on the view for field_test_reference.
4. Configure the entity selection mode and the widget display mode.
5. Configure the filter behavior (ex: required, multiple, etc.)
6. Finally use the filter field for filtering the results based on the selected entity from the autocomplete or select list.

Remaining tasks

• ☑ support for content entity reference
• ☑ support for configuration entity reference
• ☑ support for content with and without bundles
• ☑ taxonomy filter rebased on generic entity reference
• ☑ settings forms to configure the filter
• ☑ display widget in select or autocomplete
• ☑ filter values based on reference view
• ☑ filter values based on bundles
• ☑ maximum filter values in select list for performance concerns
• ☑ sort for filter values when in bundle selection handler mode
• ☑ argument support for when view selection handler is used
• ☑ views configuration schema update
• ☐ existing configuration migration (no longer needed if we create a new filter only)
• ☐ fix select option (#208, #215)
• ☑ tests
• ☐ get framework manager approval
• ☐ write change record

Post tasks

• ☐ follow-up task to have TaxonomyIndexTid use this entity reference plugin
• ☐ conversion of the "authored by" filter to use the entity reference filter
• ☐ extract selection handler form logic in separate plugins that will specialize for rendering and validating the filter selection config form
• ☐ caching of the value form?
• ☐ documentation updates

User interface

Known issues

• CANNOT REPRODUCE ATM sometimes when switching between widget it gets stuck on the previous selected one
• FIXED when switching between the widget types the previous value is left in the exposed form and it's incompatible with the other widget type
• FIXED triggering ajax requests on the extra options form right after adding the filter brings you back to the add handler form fixed

API changes

None.

Problem/Motivation

In #2962525: Create a field widget for the Media library module a new field widget is being added to core that lets you visually select media in a view. When media is selected, it's rendered inside the field widget in a specific view mode.

This view, nor the view mode is configurable right now, but they should be to enable re-use of the widget and configuration for users.

Proposed resolution

Add tests, configuration, and a configuration form to the Media library field widget that allows these settings to be configured.

Remaining tasks

Write a patch.

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

It's follow-up to #3156880-16: \Drupal\Core\Access\CsrfTokenGenerator::validate() - ensure $token is a string before calling hash_equals()

enforce scalar typehints on this method

Steps to reproduce

Comment #3156880-9: \Drupal\Core\Access\CsrfTokenGenerator::validate() - ensure $token is a string before calling hash_equals() points that test

Proposed resolution

- throw deprecated when non-string passed to validate()
- refactor test \Drupal\Tests\Core\Access\CsrfTokenGeneratorTest::testInvalidParameterTypes()

Remaining tasks

- create patch, discuss
- commit

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Found this deprecation message burried in a log. It's interesting, as we won't ever actually trigger it against SF5, because tests with @expectedDeprecation are legacy and will ignore deprecations, but seems like this will break hard when we try to run against SF6.

Steps to reproduce

Proposed resolution

• use Symfony\Bridge\PhpUnit\ExpectDeprecationTrait in Drupal base (unit, kernel, build, functional) test classes
• change @expectedDeprecation annotations to $this->expectDeprecation() calls

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Quoting @Berdir from #1642526-16: Add upgrade path from for generating UUIDs for all core entities:

PostgreSQL for example seems to have native support for that (http://www.postgresql.org/docs/9.1/static/datatype-uuid.html) and there's quite some discussion what exactly the best and fastest type for MySQL is.

Seeing suggestions such as BINARY(36), while you're currently using varchar(128), which I'm not sure why but that seems like a considerable overhead.

Problem/Motivation

EntityRepository::loadEntityByUuid() is documented with the following documentation comment.

  /**
   * Loads an entity by UUID.
   *
   * Note that some entity types may not support UUIDs.
   *
   * @param string $entity_type_id
   *   The entity type ID to load from.
   * @param string $uuid
   *   The UUID of the entity to load.
   *
   * @return \Drupal\Core\Entity\EntityInterface|null
   *   The entity object, or NULL if there is no entity with the given UUID.
   *
   * @throws \Drupal\Core\Entity\EntityStorageException
   *   Thrown in case the requested entity type does not support UUIDs.
   */

EntityRepository::loadEntityByUuid() doesn't check for invalid nor unexisting UUIDs.

Proposed resolution

Let's return NULL, in case we have a wrong UUID.

Remaining tasks

User interface changes

API changes

Beta phase evaluation

When you use the "printer friendly version" link for exporting a book hierarchy to HTML, the individual nodes do not use the node template. That is due to this line in BookExport.php function bookNodeExport():

unset($build['#theme']);

Since it is just rendering the contents of the node without using the template, you get 3 problems:

1) The author and created date are always displayed. See #2871251: printer-friendly (always) includes Author username and publish date
2) You get duplicate titles. See #3020279: Book child page titles appear duplicated in printer-friendly version
3) There is no way to fix these problems or make any customizations to the node itself because it does not use the template.

I went looking back in git history and found the source of the problem in #607244-33: Decrease performance impact of contextual links. I've read the issue and am still not clear what benefit it was supposed to have. By the discussion, it sounds like it wasn't really agreed upon and yet ended up being committed in comment #50. Even if it might have been useful then, that was 10 years ago and a lot has changed. View modes are well developed and people expect to be able to use them and the associated templates.

I propose we reverse this change so that the book nodes go through the normal, expected, theme process.

Trying to migrate some node revisions using the drupal migration system (Drupal 8.8), I am getting the following error:

Call to a member function getTranslation() on null in Drupal\Core\Entity\ContentEntityBase->hasTranslationChanges

It seems that it cannot get the original entity and call the function getTranslation() on it. So, possibly, a check for the existence of the original entity, could avoid this error, although the root of the problem may be that an original entity should always exist and it should never be null (then there might be a problem with the migrated content).

Problem/Motivation

Even if a role has no Structure related permissions, the "Structure" menu item still appears in the admin toolbar.
Selecting the menu takes the user to a page that simply states: "You do not have any administrative items."

It seems to me, that the top level menu item simply should not be present if there are no pages under it.

Steps to reproduce

To reproduce, using a fresh installation:

1. login as the site's superuser, and create a new role - name it anything you wish
2. On the 'permissions' page for the new role, grant access to 'Use the administration pages and help', 'View the administration theme' and 'Use the administration toolbar'
3. Create a new user for the site, and give this user the newly created role
4. log out as the superuser, and login as the new user, with the new role
5. notice that under 'Manage', you still have "Structure" - clicking it will take you to that page that states that you have no administrative items.

Proposed resolution

Remaining tasks

Tests
Before and after screenshots. Please add them to the 'user interface changes' so they are easy to find.
Review

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

SA-CORE-2019-003 introduced SerializedColumnNormalizerTrait and introduced a usage of methods from there to FieldableEntityNormalizerTrait. However, the latter was not made to explicitly use the former. Therefore using the latter in a class without also using the former can lead to fatal errors, in particular when calling the constructValue() method.

Proposed resolution

?

Problem/Motivation

Drupal 8 is running on CKEditor 4.x. CKEditor 5.x has gone stable and looks like it has enhancements to help improve the authoring experience.

CKEditor 5 also no longer relies on inline JavaScript, which requires a more permissive Content Security Policy due to its use in CKEditor 4 (#2789139: [upstream] CSP requires 'unsafe-inline' because of CKEditor 4).

Proposed resolution

General requirement: the high-level existing features documented at https://www.drupal.org/docs/8/core/modules/ckeditor/overview continue to exist. If there are strong reasons to not have those features anymore, it needs sign-off from Drupal product managers. Those are: structured content, clean markup, integrates with filter system, paste from Word/Google Docs, drag-and-drop text editor configuration UI, strong safety guarantees, contrib extensibility.

Remaining tasks

The plan:

1. ✅ Phase 1: Basic PoC
   1. ✅ Add core/modules/ckeditor5.
   2. ✅ Create an @Editor PHP plugin with the ID ckeditor5.
   3. ✅ Create a Drupal.editors JS plugin with the ID ckeditor5.
   4. ✅ Getting CKE5 (CKEditor 5) to load at all on the /node/add/article form.
2. Phase 2: Critical technical aspects. (These should be tackled first since they come with the highest amount of risk and architectural work.)
   1. Ensure filter_html's HTML restrictions are respected inside CKE5 just like in CKE4's Advanced Content Filter (which CKE4 added specifically for Drupal). Why? [Because it] allows Drupal to guarantee CKEditor generates clean markup, and only markup that is allowed by Drupal's filters, which means CKEditor's markup preview matches the output exactly. (I have no concerns about this thanks to CKE5's model).
   2. Related: ensure that arbitrary HTML is not lost — see https://github.com/ckeditor/ckeditor5/issues/592 and comments #49–#51.
   3. CKE4 uses an <iframe>-based text editor in forms. CKE5 no longer has an <iframe> mode. This means that the admin theme's CSS automatically applies. This also means that there's no obvious way to port the ckeditor_stylesheets feature that enabled the default (front end) theme to make CKEditor instances in the back end to generate previews that approximately or even precisely match the front end (the default theme). (See CKEditor iframe css at https://www.drupal.org/docs/8/api/ckeditor-api/overview.)
3. Phase 3: Critical integration aspects
   1. Enable a Drupal + CKE5 ecosystem, just like we have today for Drupal + CKE4: https://www.drupal.org/documentation/modules/ckeditor/contrib. This means we need Drupal modules to be able to add additional CKEditor plugins to be loaded and configured. See CKEditor Plugin plugins at https://www.drupal.org/docs/8/api/ckeditor-api/overview for the current five PHP interfaces that @CKEditorPlugin plugins are able to implement. Also relevant information in #28 (by CKEditor 5 Lead Developer @Reinmar) and #32 (big meeting with Drupal maintainers & CKEditor maintainers).
   2. A CKE5 configuration UI like /admin/config/content/formats/manage/basic_html. Noteworthy: the current UI is even fully keyboard accessible. This is evidently blocked on the previous bullet. Also relevant information in #28 (by CKEditor 5 Lead Developer @Reinmar) and #32 (big meeting with Drupal maintainers & CKEditor maintainers).
   3. Ensure there is a great authoring experience that still results in structured content. For example Drupal stores <img src=… alt=… data-align=… data-caption=…>, but CKE4 renders something very different than just an <img>, thanks to CKEditor Widgets. In the talks that @Reinmar linked in his comments #50 and #51 it's clear that the structured content is not a problem (just a matter of extending the CKE5 model) nor is the different presentation for the content author (just a matter of extending the CKE5 view).
4. Phase 4: Polish
   1. Evaluate all of Drupal core's CKE4 plugins: DrupalLink, DrupalImage and DrupalImageCaption. For all of these, we should ask ourselves whether we truly need Drupal to maintain custom integration code for them. Do some git and issue queue archeology to assess the rationale for each of them. In short, for DrupalLink it was that CKE4's link plugin was overly complex, offering the end user 37 choices whereas just the one would suffice. For DrupalImage: same. For DrupalImageCaption: CKE4 at the time would always store the <figure>…<figcaption>This is the caption.</figcaption></caption> markup, which was unacceptable to Drupal since it violates our structured content principles. CKE5 evidently is doing much better on that front, so perhaps we can now drop that altogether?
   2. Evaluate all Drupal's choice to not use CKE4's dialogs but our own server-side rendered ones to allow Drupal modules to hook_form_alter(). (This is true for the plugins mentioned in the previous bullet.) Perhaps in Drupal 9 we can choose to not offer Drupal-PHP-alterable forms and require developers to customize their CKE5 build?
   3. Ensure Quick Edit integration works (the PoC already contains InlineEditor)
   4. Evaluate all other existing integration tweaks and assess whether we want to continue to have them. For example: CKE4 felt very constrained and annoying out of the box, so we added autogrow support and tweaked that further — CKE 5 already does this out of the box! 🥳
   5. Ensure CKE4 and CKE5 can co-exist — currently having both instantiated on the same page results in errors (because for example Basic HTML uses CKE5 and Full HTML uses CKE4 since only CKE4 allows entering arbitrary HTML)
   6. Ensure CKE5 continues to work well in the Off-Canvas Dialogs; for CKE4 this required a complex CSS reset.
   7. #1890502: WYSIWYG: Add CKEditor module to core landed on February 8, 2013. A few days shy of 6.5 years ago. #2469713: Step 2: Create a JavaScriptTestBase using PhantomJs Driver/Binary landed on March 15, 2016. About 3 years and 3 months ago. This is why D8 + CKE4 barely has JS test coverage. Let's do better for D9 + CKE5.
5. Phase 5: Update Path

While doing this work to bring CKE5 to D9, we should do two things on every step along the way:

1. git and drupal.org issue queue archeology to understand why certain choices were made in the D8 + CKE4 integration. When D9 + CKE5 wants to deviate from those choices, be explicit about this and have comments explaining why choices should be different now. This will help D11 + CKE7 😜
2. Work with the CKE5 team! They're an awesome, responsive bunch that will try their best to help us use their work 🥳 #32 is a good example of this :)

User interface changes

TBD. Current status:

API changes

A migration guide has been provided from migrating from 4.x to 5.x, covering plugins, skins, and APIs:

• https://docs.ckeditor.com/ckeditor5/latest/builds/guides/migrate.html

Data model changes

None.