Problem/Motivation

From #2350939: Implement a generic revision UI, mentioned in summary/96/103/108/109/110.

To reduce duplicate code and maintenance burden, we should aim to rework Node's revision UI so it extends generic entity UI implemented in #2350939: Implement a generic revision UI

A generic revision UI is being implemented in #2350939: Implement a generic revision UI, this issue exists to deprecate/remove Node's revision UI in favor of the generic solution.

Proposed resolution

Remaining tasks

• Replace Node' revision UI code, extending generic revision UI.
• Can we remove Node test coverage which already exists for generic revision UI?
• Specific enhancements between generic UI and existing Node UI need to be identified, and add tests for this functionality.
• Decide whether to keep yellow highlight, see #23 and linked comments
• Move use admin theme out of node and into system. migrate config/schema. update _admin_route setoption in \Drupal\Core\Entity\Routing\RevisionHtmlRouteProvider::getVersionHistoryRoute to use the config value.

User interface changes

Issue aims to replicate existing interface.

API changes

Class names should be maintained, but extend generic classes.
Format of node render arrays and forms will change.

Data model changes

None?

Release notes snippet

-

Problem/Motivation

Executing a query within a where condition in the Drupal database connection class with PHP 8.1 generates deprecation warnings:

Deprecated function: stripos(): Passing null to parameter #1 ($haystack) of type string is deprecated en Drupal\Core\Database\Query\Condition->compile()

Deprecated function: strpbrk(): Passing null to parameter #1 ($string) of type string is deprecated en Drupal\Core\Database\Query\Condition->compile()

Deprecated function: strtoupper(): Passing null to parameter #1 ($string) of type string is deprecated en Drupal\Core\Database\Query\Condition->mapConditionOperator()

Steps to reproduce

In a Drupal 9.5.x project with PHP 8.1 and MariaDB 10.4.13 initiate a database connection (\Drupal\Core\Database\Connection) and an unexecuted query. Create another database connection that only contains an unexecuted condition. To the first query, add a where clause with the second query inside. Execute the first query and check the logs.

Example with the database inside a custom class:

/**
 * Database connection service.
 *
 * @var \Drupal\Core\Database\Connection
 */
  protected $database;

/**
 * Constructor.
 *
 * @param \Drupal\Core\Database\Connection $database
 *  Database connection service.
 */
  public function __construct(Connection $database) {
    $this->database = $database;
  }

  $query = $this->database->select('table', 't');
  $query->fields('t', ['column_1', 'column_2']);

  $query2 = $this->database->condition('t.field', 'value', '=');

  $query->where($query2);

  $query->execute()->fetchAll();

Proposed resolution

Force data types passed to functions to be strings.

Problem/Motivation

This is a child of #3324398: [META] Update Claro CSS with new coding standards and part of #3254529: [PLAN] Drupal CSS Modernization Initiative.

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.

@todo: Add clear testing instructions to test this manually on the UI.

Proposed resolution

• Use CSS Logical Properties where appropriate.
• Use CSS nesting where appropriate.
• Use existing variables (variables.pcss.css) where appropriate. Follow the proposed Drupal CSS coding standards to name the variables.
• Add a comment when there's a value where there is not a variable like font-size: 1.23rem; /* @todo One off value. */
• When possible, set variables at the root of the component and then map them to global theme variables:
  

  .entity-meta {
            --entity-meta-title-font-size: var(--font-size-h5);
  
            ... more style
          }
  
          .entity-meta__title {
            font-size: var(--entity-meta-title-font-size);
          }

Out of scope

• Changing CSS classes
• Drupal 9 patches

User interface changes

None. There should be no visual differences.
Please post before/after screenshots and make sure they look the same.

Problem/Motivation

This is part of the CSS modernization initiative, and intended to be worked on by our Google Summer of Code student only.

Steps to reproduce

The stylesheet at https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/themes/claro/css/components/dialog.pcss.css 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 and remove IE specific style definitions.

User interface changes

None. There should be no visual differences.

Problem/Motivation

This is a child of #3324398: [META] Update Claro CSS with new coding standards and part of #3254529: [PLAN] Drupal CSS Modernization Initiative.

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.

@todo: Add clear testing instructions to test this manually on the UI.

Proposed resolution

• Use CSS Logical Properties where appropriate.
• Use CSS nesting where appropriate.
• Use existing variables (variables.pcss.css) where appropriate. Follow the proposed Drupal CSS coding standards to name the variables.
• Add a comment when there's a value where there is not a variable like font-size: 1.23rem; /* @todo One off value. */
• When possible, set variables at the root of the component and then map them to global theme variables:
  

  .entity-meta {
            --entity-meta-title-font-size: var(--font-size-h5);
  
            ... more style
          }
  
          .entity-meta__title {
            font-size: var(--entity-meta-title-font-size);
          }

Out of scope

• Changing CSS classes
• Drupal 9 patches

User interface changes

None. There should be no visual differences.
Please post before/after screenshots and make sure they look the same.

Problem/Motivation

This is part of the CSS modernization initiative.

Steps to reproduce

The stylesheet at https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/themes/claro/css/components/form--managed-file.pcss.css 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 and remove IE specific style definitions.

User interface changes

None. There should be no visual differences.

Problem/Motivation

This is a child of #3324398: [META] Update Claro CSS with new coding standards and part of #3254529: [PLAN] Drupal CSS Modernization Initiative.

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.

@todo: Add clear testing instructions to test this manually on the UI.

Proposed resolution

• Use CSS Logical Properties where appropriate.
• Use CSS nesting where appropriate.
• Use existing variables (variables.pcss.css) where appropriate. Follow the proposed Drupal CSS coding standards to name the variables.
• Add a comment when there's a value where there is not a variable like font-size: 1.23rem; /* @todo One off value. */
• When possible, set variables at the root of the component and then map them to global theme variables:
  

  .entity-meta {
            --entity-meta-title-font-size: var(--font-size-h5);
  
            ... more style
          }
  
          .entity-meta__title {
            font-size: var(--entity-meta-title-font-size);
          }

Out of scope

• Changing CSS classes
• Drupal 9 patches

User interface changes

None. There should be no visual differences.
Please post before/after screenshots and make sure they look the same.

Problem/Motivation

This is a child of #3324398: [META] Update Claro CSS with new coding standards and part of #3254529: [PLAN] Drupal CSS Modernization Initiative.

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.

@todo: Add clear testing instructions to test this manually on the UI.

Proposed resolution

• Use CSS Logical Properties where appropriate.
• Use CSS nesting where appropriate.
• Use existing variables (variables.pcss.css) where appropriate. Follow the proposed Drupal CSS coding standards to name the variables.
• Add a comment when there's a value where there is not a variable like font-size: 1.23rem; /* @todo One off value. */
• When possible, set variables at the root of the component and then map them to global theme variables:
  

  .entity-meta {
            --entity-meta-title-font-size: var(--font-size-h5);
  
            ... more style
          }
  
          .entity-meta__title {
            font-size: var(--entity-meta-title-font-size);
          }

Out of scope

• Changing CSS classes
• Drupal 9 patches

User interface changes

None. There should be no visual differences.
Please post before/after screenshots and make sure they look the same.

Problem/Motivation

Error when adding a custom block entity to the block layout when no block description have been added (i.e., the field base was hidden from the form).

Error stack:

Deprecated function: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in Drupal\Component\Transliteration\PhpTransliteration->transliterate() (line 135 of core/lib/Drupal/Component/Transliteration/PhpTransliteration.php).
Drupal\Component\Transliteration\PhpTransliteration->transliterate(NULL, 'x-default', '_') (Line: 254)
Drupal\Core\Block\BlockBase->getMachineNameSuggestion() (Line: 390)
Drupal\block\BlockForm->getUniqueMachineName(Object) (Line: 137)
Drupal\block\BlockForm->form(Array, Object) (Line: 106)
Drupal\Core\Entity\EntityForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 534)
Drupal\Core\Form\FormBuilder->retrieveForm('block_form', Object) (Line: 281)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 48)
Drupal\Core\Entity\EntityFormBuilder->getForm(Object) (Line: 27)
Drupal\block\Controller\BlockAddController->blockAddConfigureForm('block_content:9252e0db-83d7-421b-b410-60cfa0629557', 'olivero')
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 163)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 74)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 686)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Steps to reproduce

1. Create or edit a custom block
2. Hide the 'Block Description' field
3. Go to `/block/add` and choose the custom block you just edited
4. Fill it as required and then press `Save`
5. The error should have been triggered when on the block form.

You can also trigger it when adding an existing custom block entity through the Block Layout UI.

Proposed resolution

Handle cases when the `Block Description` is hidden and no value has been set.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Amongst the current suppressions found in the PHPStan level 1 baseline is: Call to method foo() on an unknown class Bar\Baz..

This issue exists to fix all of those.

Steps to reproduce

- Run PHPStan on level 1 and see the above issue amongst all others.

Proposed resolution

- Solve all of the reported issues for the above mentioned.
- Run PHPStan on level 1 and don't see the above issue any more.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

WAI-ARIA 1.1 introduces a useful new property: aria-current.

One place where we can use this is on pagination links. Currently, the pager styles in Seven and Bartik have a visual indication of the current page, together with a .visually-hidden span to say it is the current page (which screen readers announce). It's working fine at the moment, but we can modernize this.

The idea behind the aria-current="page" is to indicate this in a machine-readable way that can be conveyed to assistive technology though the platform-level accessibility APIs. The advantage is that screen readers, etc., can present the information in a way that is more consistent with native applications on host platform, such as:

• Announce it with a platform-localized string (from assistive tech on the host OS), instead of an author-localized string (from Drupal translations).
• Decide how/when to announce the fact, possibly based on user preferences in the host OS or assistive tech (e.g. screen reader verbosity prefs).

Demo page:http://design-patterns.tink.uk/aria-current/ (includes test results for various devices)

Proposed resolution

• Add aria-current="page" to the current page link in the pager.
  Important: this should go on the <a> element, not the <li>wrapper.
• Remove the visually-hidden phrase "current page" from inside the current-page link. Just use<span class="visually-hidden">Page: </span> like all the other numbered links.

From #94 we will try and use theme_preprocess_page() to add this variable.

Remaining tasks

• Assess: is there sufficient support for aria-current="page" across various browsers, assistive tech, and OS? Ask around the wider accessibility community. In particular, we'd like to know where it isn't supported yet, to assess the regression risk.
  • DONE: support looks good in general (comment #3). iOS + macOS Safari work, and there are several browser/screen-reader combinations working on Windows.
  • DONE: ChromeVox + desktop Chrome Browser. Not currently working, see comment #7.
  • TODO: monitor Android Talkback, not working yet (comment #6).
  • TODO: monitor support with MS Edge + JAWS. Watch this bug report: No support for aria-current in Edge.
  • DONE: Monitor support for MS Edge + Narrator. WAI-ARIA 1.1 is support is "in development" according to MS Edge Platform Status. See comment #57
  • DONE: Test in ChromeVox on ChromeOS. See comment #7 and #50
  • DONE: test macOS Voiceover with Chrome. See comment #50
• Assess: does this impact on a template in the Stable and Classy themes?
• Write a patch.
• Update using hook vs twig templates
• Tests

Sign-offs needed

IMPORTANT: Possible regression risk - get sign-off from an accessibility maintainer, @andrewmacpherson or @mgifford.
Don't commit this until we're confident there's enough support across various OS, browsers, and assistive tech. It can wait until the time is right, and go in any minor release.

User interface changes

• Improved semantics for assisitive technology. Replace an invisible text span with machine readable attribute.
• No changes to visual design, or CSS.

API changes

None.

Data model changes

None.

Commit Credits needed

@RachelOlivero - researched Android Talkback support, comments #6 and #38.

Problem/Motivation

Empty sections create unnecessary markup. Also, if you've styled the sections with a background/padding you'll get some unwanted bars.

Proposed resolution

Remove empty sections while preserving their cache metadata.

Remaining tasks

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

It would be keen if Drupal core were nice enough to alert you if you tried to register a module and theme of the same name... but it doesn't.

If you name your theme and a module the same name you get name space collisions. E.G samename_block(..) will conflict if you have it declared in both module and theme.

It would save a lot of new Drupal developers frustration if Drupal didn't let you register a theme and active module by the same name.

Also noted here http://drupal.org/node/143020

Problem/Motivation

The comments attached to the entity has the attributes 'status' which controls whether comments can be seen/posted. But seems like no possibility to show that status in the views and not possibility to filter on that status.
P.S. It's very strange that I cannot find the issue related to this. Maybe I'm missing something.

Testing steps

1. Apply the patch.
2. Clear cache.
3. Add/Edit the comment field of node.
4. On Node Manage Display for the Comment field a new formatter should be available in the select list ("Comment Status").
5. On selecting and saving the settings, this should show the comment status for each of the comment.

Proposed resolution

Seems like the filter plugin is already created but is not used anywhere. I propose to create field plugin which displays that status and add both plugins (field and filter) to field_views_data.

Seems like InOperator plugin feels very bad when options are instances of TranslatableMarkup. So for now I'm casting options to string. Maybe in the future it will be possible to find better solution.

Remaining tasks

Reviews needed.

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

BlinkMacSystemFont was a non-standardised value of system-ui which only worked in older browsers.

In Drupal 10 we only support modern browsers so we can standardise on system-ui.

Steps to reproduce

See https://caniuse.com/font-family-system-ui

Proposed resolution

-  --font-family: BlinkMacSystemFont, -apple-system, "Segoe UI", Roboto, Oxygen-Sans, Ubuntu, Cantarell, "Helvetica Neue", sans-serif;
+  --font-family: system-ui;

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The Layout builder module does not protect against recursion. If a Block Plugin which renders an entity is placed inside the same entity's layout, you will receive "Maximum function nesting level" errors. This was originally reported in #2976152: Don't allow placing a Custom Block in the layout override for itself or a default layout, and is being mitigated in that issue by hiding known Block Plugins that cause this issue.

Steps to reproduce

We can work over the default "basic page" content type
1. Create a node for basic page content type.
2. Enable the core module "Layout Builder"
3. Create a view to show basic pages as a block:
- With contextual filter by "content ID"
- With a show as "content" and display as "default"
4. Alter the basic page "manage display" to show "default" as "layout builder"
5. Add to layout builder the block that you created at 3 step.
6. Show the node that you created at 1 step and should get the error "The website encountered an unexpected error. Please try again later." and at drupal log this is "Error: Xdebug has detected a possible infinite loop, and aborted your script with a stack depth of '256' frames in Drupal\Component\Plugin\PluginBase->__construct() (line 53 of /var/www/html/contributedrupal10/core/lib/Drupal/Component/Plugin/PluginBase.php)."

Proposed resolution

The mitigation is fine for now, but the Layout builder should have higher level recursion protection, similar to what the Entity Reference formatter does today.

Remaining tasks

Write a patch and tests.

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation & Steps to reproduce

Drupal core comes with several Media entities; audio, file, image, external video and local video.

When a content editor uses the local video entity, it only allows you to upload the video. There is no default option to include a poster image or transcript.

Proposed resolution

Extend the possibility to map fields on a media entity.

1. a mapping field for the poster
2. a mapping field for the transcript

Remaining tasks

Now, the idea is to offer the possibility to display a poster image using content from the field_local_image_file for the HTML5 video.

It would be nice if this feature could be managed by {{ attributes }} but I cannot figure how to implement this.

Thank you!

Gilles

User interface changes

2 extra mapping fields at the local video media entity

API changes

-

Data model changes

-

article is the default role of an<article> and thus the attribute can be removed.

To test this, copy this snippet into the W3 validator: https://validator.w3.org/nu/#textarea

<!DOCTYPE html>
<html lang="en">
<head>
<title>test</title>
</head>
<body>
<article role="article">
<h1>test</h1>
</article>
</body>
</html>

Also see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/article

While using CKeditor 4 I can resize table, but not on CKE5.

On 2 colums table, even when I put Image with 600x275px and choose CKE5 image size to 100%, Drupal will resize to smaller size while there is long text on another column.

This CK5 behavior makes WYSIWYG editor useless. To meet my need, I must manually add CSS styles to table in CKE5 .
So, I must reactived CKE4 to have WYSIWYG behavior in Drupal 9/10.

Problem/Motivation

Layout builder provides the option to create inline blocks.

In core, LB is only used for nodes, so there's a quite specific use case. However, LB is nice :_) and people is extending it. There is the dashboards contrib module, the dashboard initiative to bring LB based dashboards in core, and some other modules extending and using the LB ecosystem.

Layout builder restrictions is a contrib popular module that allows to restrict which blocks are available, including restricting inline blocks, or some of them. But for that, it needs to override two controllers from LB. That makes it incompatible with other solutions that might want to do a similar thing, as they compete for the controller swap.

E.g. Dashboard initiative is considering controlling the allowed blocks based on the section_storage type (see https://www.drupal.org/project/3327580/issues/3351705#comment-14993944). That might make it incompatible with layout_builder_restrictions.

Proposed resolution

Provide a way so ChooseBlockController::build/::inlineBlockList allow custom/contrib to opt-out from inline blocks (or some of their bundles) based on whatever conditions (e.g. the section_storage for dashboard, a setting for layout_builder_restrictions)

Remaining tasks

Discuss if it's the way forward.

Add a new method in SectionStorageInterface::inlineBlocksAllowedInContext() (taken directly from layout_builder_restrictions, but rename suggestions appreciated).

From \Drupal\layout_builder\Plugin\SectionStorage\SectionStorageBase::inlineBlocksAllowedInContext call a new hook hook_layout_builder_inline_blocks_allowed_in_context (as well we might find a better name)

Implement tests for the new hook.

Make a preliminar MR to layout_builder_restriction to ensure the approach works.

User interface changes

None.

API changes

TBD. Probably API additions. Shouldn't be API changes. Definitely no BC changes.

Data model changes

None.

Release notes snippet

TBD