Problem/Motivation

At now Drupal Media entities can be inserted into CKEditor, using Media Library widget, only as block element. So there are no ways to insert inline image (eg small icon image into text), or document (inline link to download file inside text paragraph).

Proposed resolution

Add "Inline" variant to widget align property, and convert CKEditor widget from block to inline, if selected.

Remaining tasks

Discuss the UX, finish the patch.

User interface changes

Added "Inline" option to media align property.

API changes

None.

Data model changes

None.

Release notes snippet

TBD

Problem/Motivation

When a user creates a field unlimited and makes it required. When the user clicks in add more an error appears on the text button, like adding a red border input text like the image below.

But also expected an error message that doesn't happen.

Actual result:

Expected result:

Steps to replicate the issue.

1. Create a field in content type with cardinality unlimited and make it a required field.
2. Create a node for the same content type.
3. Do add more without filling in the data, it will block add more by highlighting the field, but there won't be a status message.
3. Fill a decimal value and do add more, it will be a success.
5. remove value from the first delta and try to add more again.
6. with the above trigger and two fields, you will see both error message and the text field will also be highlighted.

Proposed Solution

TBD

API changes

None

Data model changes

None

Release notes snippet

None

Problem/Motivation

\Drupal\Component\ProxyBuilder\ProxyBuilder::build creates an @see \Drupal\Component\ProxyBuilder in the proxy class PHPDoc.

This is incorrect and should be @see \Drupal\Component\ProxyBuilder\ProxyBuilder

Steps to reproduce

Proposed resolution

- Change @see link to correct namespace
- Rebuild all proxy classes.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

AnnotatedClassDiscovery::getPluginNamespaces() description is inaccurate and unclear.

   * Gets an array of PSR-4 namespaces to search for plugin classes.
   *
   * @return string[]

But the caller does this:

    foreach ($this->getPluginNamespaces() as $namespace => $dirs) {

Documentation states "Returns an array of PSR-4 namespaces."

In reality, it returns an associative array with:
Keys representing namespaces.
Values representing directories.

$namespace variable in the loop stores each namespace key.
$dirs variable in the loop stores the associated directory for each namespace.

Steps to reproduce

Proposed resolution

Remaining tasks

19.2 Wrap to 80 characters

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

If you have any kind of form element without a title and it's required you will not see that it's actually required on form validation.

Proposed resolution

The problem is, that form_get_error() returns an empty string which is implicitly casted to boolean in the following statement:
if (isset($element['#parents']) && form_get_error($element))
In _form_set_class(), check for !== NULL.

Remaining tasks

This is no longer an issue in D8.

User interface changes

n/a

API changes

n/a

Original report by @dawehner

If you have any kind of form element without a title and it's required for example you will not see that it's actually required.

The problem is that #required uses

        if (isset($elements['#title'])) {
          form_error($elements, $t('!name field is required.', array('!name' => $elements['#title'])));
        }
        else {
          form_error($elements);
        }

So form_error set's a error = '';

Now in _form_set_class

  if (isset($element['#parents']) && form_get_error($element)) {
    $element['#attributes']['class'][] = 'error';
  }

But '' is a boolean false so there is no error message.

Problem/Motivation

If SDC get stable status it should integrate into the core namespace. This issue is to decide where the Component should go.

Proposed resolution

I propose we move the Component namespace to Core\Theme\Component.

Remaining tasks

Create a merge request against this branch which is the meta issue for these changes.

Summary

In #3121340: Fix up minor copy problems in help topics, we've collected a number of issues related to updating help topics. That issue has been turned into a "plan" with separate issues being created.

Original report from #3121340: Fix up minor copy problems in help topics:

• On #3150364: Add a description for the language toolbar button to the CKEditor help page some text is being added to the CKEditor hook_help about the Language button that can be added to the toolbar. We need to make sure that information is also in our CKEditor topic or in an appropriate multilingual topic, or both, once that issue is finalized.

  In looking into the above, I noticed that there is a lot of info in ckeditor5's hook_help() implementation (its module overview) that is not covered adequately -- or at all -- by any existing help topic.

• On #3150364: Add a description for the language toolbar button to the CKEditor help page they also made a list of accessibility features and a section about making accessible text. I'm not sure we covered that well in our topic on Accessibility, so we should check. See this screenshot of the output of one of the patches:
  

Problem/Motivation

CKEditor's hook_help() implementation in core/modules/ckeditor5.module creates a module overview that covers:

1. An overview of the module including its uses
2. Migrating an Existing Text Format to CKEditor 5
3. Additional migration considerations for text formats with restricted HTML

Currently, we have 1 topic, editor.overview, which provides steps to configuring CKEditor5 as a text editor. There is a lot of information in ckeditor.module implementation of hook_help() that is not covered by this topic or any other.

We need to look at CKEditor5's module overview (viewable in the UI at admin/help/ckeditor5 or in code at core/modules/ckeditor5/ckeditor5.module in function ckeditor5_help()) and ensure that all of the information provided in this module overview is covered in relevant existing topics or new topics.

Note that depending on the state of Help Topics' merge into Help module and moving topics into respective module's, help topics may exist in the following locations:

• core/modules/help_topics/help_topics
• core/modules/help/help_topics
• core/modules/MODULE/help_topics

Steps to reproduce

(These are more like steps to view help topics or module overviews.)

Note: To view help topics at admin/help, Help Topics module must be enabled, or if it has been merged into Help module, Help module must be enabled.

1. Install the latest version of Drupal
2. Install CKEditor5 module (built in to Drupal 10)
3. Install Help and Help Topics (if it is still a separate experimental module)
4. Read the CKEditor5 Module Overview (go to admin/help or from the Manage menu, click on Help; look in the Module Overviews section; click on the link text CKEditor 5)
5. To view help topics, look under the Topics section.
6. To search for help topics, configure search for Help (see the help topic admin/help/topic/help.help_topic_search)

Proposed resolution

Review CKEditor 5's module overview (admin/help/ckeditor5) and make a plan for creating or updating topics.

It looks like at least 2 topics will need to be created: 1) a top-level ckeditor5.overview which describes the module and its uses; 2) a task topic with steps that covers "Migrating an Existing Text Format to CKEditor 5".

Look at the module overview's section "Additional migration considerations for text formats with restricted HTML" and see if that information can be integrated into an existing topic.

See if any other topics should be updated with information from CKEditor 5's module overview.

Update the issue summary, once a plan is decided upon.

Remaining tasks

1. Make a plan for moving info from ckeditor5's module overview into topics
2. Create a merge request with the new and updated topics (be sure to have a fresh pull of the latest version of Drupal and the correct locations of the help topics)
3. Review, approve, commit.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

The information in CKEditor 5's module overview (its hook_help() implementation) has been integrated into new and existing help topics. The following help topics have been created and/or updated...

Problem/Motivation

Olivero: submit button is the top dialog box is too wide.

Can be seen on the live preview. https://tugboat-aqrmztryfqsezpvnghut1cszck2wwasr.tugboat.qa/dialog

Steps to reproduce

Proposed resolution

Remaining tasks

1. Review Patch #15 and upload screenshots.
2. Update Issue summary as suggested in #15

Issue summary update, see Write an issue summary for an existing issue.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

On #3095737: Convert internationalization modules: config_translation, content_translation, locale, language module hook_help() to topic(s) we created a help topic, core/modules/help_topics/help_topics/language.detect.html.twig, which includes a list of the commonly-used language detection methods.

It would be good if that list could be generated from the code instead of being hard-wired in the template.

This issue is about seeing whether this is possible. Some questions to explore:

a) The list in the current help topic was curated and ordered. It doesn't include all detection methods. Is it OK to include all or just confusing? And does the order matter?

b) The descriptions in the help topic -- is there some place we can take them from in the code?

Steps to reproduce

The topic has this in it (in patch format):

+<h2>{% trans %}What language detection methods are available?{% endtrans %}</h2>
+<p>{% trans %}The available detection methods depend on what modules you have installed. Some of the most commonly-used language detection methods are:{% endtrans %}</p>
+<dl>
+  <dt>{% trans %}URL{% endtrans %}</dt>
+  <dd>{% trans %}Use the language from the URL, which can either be in a path prefix like <em>example.com/fr/page_path</em> for French (fr) language, or in a domain like <em>fr.example.com/page_path</em>.{% endtrans %}</dd>
+  <dt>{% trans %}User{% endtrans %}</dt>
+  <dd>{% trans %}For logged in users, use the language they have set in their profiles.{% endtrans %}</dd>
+  <dt>{% trans %}Browser{% endtrans %}</dt>
+  <dd>{% trans %}Use the language preferences from the user's browser.{% endtrans %}</dd>
+  <dt>{% trans %}Selected language{% endtrans %}</dt>
+  <dd>{% trans %}Use the language most recently selected from a <em>Language switcher</em> block.{% endtrans %}</dd>
+  <dt>{% trans %}Session{% endtrans %}</dt>
+  <dd>{% trans %}Use the language from a session parameter or a request parameter; for example, adding <em>?language=fr</em> to the end of the URL.{% endtrans %}</dd>
+</dl>

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Once #3340712: Add Single Directory Components as a new experimental module has landed this issue will track the necessary work to get the module to beta and then a stable state.

Proposed resolution

Current status

- Currently (as of Drupal 10.0.x), Single Directory Components is proposed for core inclusion with experimental status and located in core/modules/sdc.
- Issues with SDC are still tracked and addressed in https://www.drupal.org/project/sdc first, then carried to the open MR.
- Drupal 10.1's first alpha release is scheduled for the week of Week of April 24, 2023. We are hoping to get #3340712: Add Single Directory Components as a new experimental module merged before that.
- Consensus to add SDC as an experimental module is gathered in #3313520: Single directory components in core.

Release Plan

In terms of the release schedule for Drupal 10, if this module is not included as an experimental module by May 2023 (when 10.1.0-beta1 will be released), then it will need to wait until 10.2. This will also delay the schedule for a future stable version. Normally for Experimental modules, the module gets to Beta, which triggers including it in a release as an Experimental module. Then at a later date, it becomes Stable and gets the Experimental status removed.

Roadmap for Beta (experimental status)

Here is a list of sub-issues that we currently have for that phase, all of which are must-haves to make "Beta" quality, so we can keep it as a live Experimental module in a full Drupal release:

• #3345924: Move schema validation library to require-dev
• #3345925: Fix issues reported by drupal-check
• This is a placeholder to link issues derived from a review on the MR in #3340712: Add Single Directory Components as a new experimental module.

Tasks originally proposed for this phase that made it into the patch before initial commit, or have since been finished:

• #3328636: Make schema props / slots optional
• #3328248: Allow classes and interfaces in the prop types metadata
• #3321150: [META] Increase automated test coverage
• #3320239: String props are improperly encoded/decoded
• #3319704: Allow overriding the library in the component definition
• #3319619: Restrict asset collection
• #3319616: Move components to "/components" from "/templates/components"
• #3317134: Always namespace components during usage and negotiation
• #3317173: Unable to use {% extends %} due to added code
• #3317158: Validate component props at rendering time

Roadmap for Stable

The schedule for stable release is not planned until SDC is in core as experimental.

To get this module to be ready for a stable release, here are some issues we'll need to resolve/finish, all of which are must-haves to make "Stable" quality:

• Olivero uses at least one SDC component - #3364672: [META] Create Single Directory Components for the Olivero theme
• #3352256: [META] Move code from the experimental SDC module to core
• #3352257: [SDC] Validate and improve developer experience and helpfulness of error messages
  • #3365480: [SDC] Improve error handling during prop validation errors
• #3352258: [META] SDC: Improve and extend documentation
  • #3352262: Create SDC "Quick start" documentation / code - We want this done by DrupalCon Pittsburgh!
  • #3352272: SDC: Move the documentation from markdown to Drupal.org
• #3352260: If needed, create automated tests to validate SDC's use of Drupal escaping and Twig sandboxing
• #3352858: Move isRenderArray from SDC to Drupal\Core\Render\Element
• #3354389: [PP-1] Move single directory components API in \Drupal\Core\Render namespace
• #3356722: [PP-1] Remove schema references from contrib in SDC tests in core
• #3357382: Unable to override library auto-definition to add external CSS & JS
• #3357383: _locale_parse_js_file cannot open SDC JavaScript files
• #3374901: SDC Stylesheets are output in the wrong order (relating to normal libraries)
• #3365458: [Policy] SDC backwards compatibility policy
• #3385283: Components without props throw error
• #3375843: Allow other Twig node visitors to modify 'display_start' and 'display_end'

Non-stable-blocking issues

• Umami uses more SDC components - #3364673: [META] Create Single Directory Components for the Umami theme
• #3352261: SDC: Prevent unwanted context passing with Twig include/embed functions
• #3362132: SDC: sdc_theme_test_enforce_schema test theme contains invalid schema definition
• #3365605: [Meta] Convert core UI components to use single directory components
• Allow schema references - #3352063: [PP-1] Allow schema references in Single Directory Component prop schemas
• #3365682: [SDC] Add a test for multiple *.component.yml in the same directory

To be triaged

• #3365480: [SDC] Improve error handling during prop validation errors
• #3365455: Unhelpful error message with SDC when a optional variable is missing

I can able to create new nodes, but couldn't able to update the existing nodes. Also, couldn't able to disable the enable the menus.
While doing so, The site throws error as

Drupal\Core\Entity\EntityStorageException: Field status is unknown. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 815 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

drush entup, drush updb, core update doesn't help

Problem/Motivation

I came across an intriguing bug in Drupal 10 views when configuring pager options. If the offset field is left empty, it triggers a PHP type error. In Drupal 10, the expected value for the offset field is 0, but when it is empty, it becomes offset: null instead.

TypeError: Cannot assign null to property Drupal\views\Plugin\views\query\QueryPluginBase::$offset of type int in Drupal\views\Plugin\views\query\QueryPluginBase->setOffset() (line 152 of core/modules/views/src/Plugin/views/query/QueryPluginBase.php).

Steps to reproduce

1. Enable views and views_ui module with D10.
2. Pick a views then set the `pager` - items to display (leave it as default), offset (default is 0, remove it so that the field is empty)
3. Save it (Click 'Apply'))
4. The PHP TypeError can be found in PHP logs.

Proposed resolution

Strictly type the $offset parameter in setOffset to int
Update all places that call setOffset to cast the offset to an integer

Remaining tasks

Agree on approach
Tests

User interface changes

None

API changes

setOffset requires an integer

Problem/Motivation

During the usability sessions, some participants struggled with fill out the menu link add page. It has an overwhelming number of options, some are really important, some aren't important or commonly used.

Proposed resolution

We can reuse some of the design conventions introduced in #1510532: [META] Implement the new create content page design. Placing the important fields in the main column and the less important fields in the secondary column.

The form should be organised to have data in the main part and metadata on the sidebar. The most important or frequently edited stuff should go at the top in each section.
Metadata elements include Parent link, 'enabled' and 'show as expanded' checkboxes, description and weight.

Except for the "Parent link," all the sidebar elements should be tucked away in collapsed sections by default. This makes the form look neater and less cluttered.
Suggested grouping and order:
1. Parent link (no details element)
2. Checkboxes ("Enabled" and "Show as expanded"). To be decided: the label for this details element.
3. Description
4. Weight

Remaining tasks

Implement the suggestions
Design review
Test

User interface changes

Before:

After:

API changes

None

Data model changes

None

Problem/Motivation

#3278493: Make it easier for theme builders to enable Twig debugging and disable render cache really lives up to its name. It's a huge improvement to not have to go through all the steps, and still maybe need to clear cache.

@mherchel asked at one point, which is a great suggestion:

Use case. If we rebuild the environment, we don’t want to have to re-check this form. Can we override these settings in settings.php or have a drush command?

Proposed resolution

Add support for enabling Twig debugging and disable render cache via:

• ✅ Drush: See Debugging Twig templates > Enabling Twig debugging via Drush
• settings.php

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The "Combine Fields Filter" for Drupal Views is causing two issues on our site:

• The [reset] button that appears next to the filters after executing a search does not clear the "?combine=" section of the url parameters.
• When attempting to navigate to a views page whose filters include the Combine Fields Filter, when including parameters in the url, but omitting the combine fields filter parameter, the user is served a 502 error. Ex:
  • https://my-base-url.com/page-with-a-view<== This type of url works fine
  • https://my-base-url.com/page-with-a-view?param1=X&param2=Y<== This type of url returns a 502
  • https://my-base-url.com/page-with-a-view?param1=X&param2=Y&combine=keyword<== This type of url works fine

Deleting the combine fields filter does not remediate this issue.

Steps to reproduce

1. Create a view page and populate it with fields as you normally would
2. Create a list of filters including the Combine Fields Filter
3. Execute a search on the completed view page using the view filters just created
4. Click the [reset] button

Someone who properly reproduces this issue will see that the "?combine=" parameter in their view's url does not get cleared out of the url, nor does the text box that they entered their keywords into clear out.

Problem/Motivation

Olivero provide theme customisation settings for the header regions, specifically "Enable mobile menu at all widths" and "Header site branding background color", however it does not currently provide settings to control the behaviour of the header with respect to whether it is fixed to the top of the screen or not, and whether it will collapse or always stay expanded.

Specifically, it would be useful if the theme settings to:

1. Enable or disable whether the header is fixed to the top of the screen while the user scrolls.
2. Enable or disable the behaviour of the header collapsing and expanding as the user scrolls. Additionally, some sites may want to completely remove the button/link next to the site branding which expands and collapses the header, or they may want to keep this but just stop the automatic expanding/collapsing behaviour.

Having control over these behaviours would be a nice addition.

Steps to reproduce

Proposed resolution

Remaining tasks

Decide if these options should be provided, if so whether it is one toggle or multiple toggles, then implement.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

asm89/stack-cors added support for using regex patterns to match the origin header. That allows to do partial-wildcard matching for CORS, which is very useful.

Steps to reproduce

N/A

Proposed resolution

Add default entry for cors.config.allowedOriginsPatterns in default.services.yml.

Remaining tasks

• Update tests

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

default.services.yml now includes allowedOriginsPatterns, which allows to use regex patterns for CORS matching. No pattern is set by default, so existing sites will continue working the same, honoring allowedOrigins (whether customized or not).

Problem/Motivation

Error accessing property of undefined, when resizing page with a dialog opened.

caught TypeError: Cannot read properties of undefined (reading 'settings')
 at HTMLDocument.resetSize (dialog.position.js?v=10.0.8:85:32)
 at later (debounce.js?v=10.0.8:37:23)

Steps to reproduce

1. Open a page and open a dialog: in my case, I use Layout Builder and can reproduce this problem when configuring a block in page node layout
2. With the dialog opened, resize the window
3. Error shows up in console

Proposed resolution

By looking into the function 

resetSize(event) {…
}

So it looks like the events parameter passed in this function are not the same. 
When resizing, they can be of type resize or type drupalViewportOffsetChange (called by debounce.js).

And if event is of type drupalViewportOffsetChange, data attribute is undefined, causing the error accessing event.data.settings

Remaining tasks

None

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

We've long desired the ability for core to easily produce a "correct" schema for a given entity type/bundle. The concept of "schematic" normalizers will get us closer.

While this issue/concept was originally blocked by an inability to cache the outcome of a "supports" query on a normalizer, that was fixed in #3252872: Use CacheableSupportsMethodInterface for performance improvement in normalizers thanks in large part to changes upstream in Symfony.

Proposed Solution (originally authored by @gabesullice):

Add a SchematicNormalizerInterface with a ::getNormalizationSchema() method.

Initial thoughts on a method signature:

• $type is a supported interface or class.
• $format is the encoding format.
• $refinements is a parameter bag of anything that is required to return a correct schema. For example, ResourceObjectNormalizer::getNormalizationSchema() would need $refinements->get('resource_type'). Best practice would be for refinements to be documented on the method and then asserted in the method. It's imperfect, but the best I can think of.

I think under this system, every normalizer would be required to return a complete schema. Meaning that the JsonApiDocumentTopLevelNormalizer would be responsible for returning a schema that included schema for any child resource object(s). Alternatively, we could allow normalizers to return placeholder objects and resolve them separately. That might end up as an over-engineered solution though.

Finally, I think that we would put this method on the Serializer service so that normalizers will not need to specifically know which child normalizer services will be applied.

Problem/Motivation

Entity IDs can be either a string or an int. Both are acceptable, and even tested for (EntityTestStringID.php). Postgres cannot join across different datatypes. So, when a View lists a relationship between two tables, and the shared identifier stores one as a string and the other as an integer, the query causes an error:

SQLSTATE[42883]: Undefined function: 7 ERROR: operator does not exist: bigint = character varying

Proposed resolution

Cast both condition values to strings.