Problem/Motivation

This issue has been created as a follow up for #3220437-36: Empty breadcrumb at node/add and node/add/{content_type} when frontpage view is enabled

In issue #3220437: Empty breadcrumb at node/add and node/add/{content_type} when frontpage view is enabled, we have added a Breadcrumb Builder service. This was designed to be only a backwards-compatibility layer.

Proposed resolution

Remove the backwards compatibility layer introduced in #3220437: Empty breadcrumb at node/add and node/add/{content_type} when frontpage view is enabled (including the Breadcrumb Builder), and move the node/add/{content type} paths to sit under admin/content.

Remaining tasks

1. Remove the breadcrumb builder;
2. Change node creation paths such that it sits under admin/content;
3. Get approval from UX team.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

See #3228355: PHP warning when saving text format with CKE5. For details about my current theory: #3228355-20: PHP warning when saving text format with CKE5.

This is testing that theory in Drupal core :)

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When a theme didn't have a base theme property in their info metadata, exception will thrown with following message:

Missing required key ("base theme") in themes/custom/my_theme/my_theme.theme/my_theme.theme, see https://www.drupal.org/node/3066038

The correct path should be themes/custom/my_theme/my_theme.info.yml

Steps to reproduce

• Create custom theme
• Omit base theme property in info.yml
• Clear drupal cache

Proposed resolution

Use getPathname to get the correct path

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Olivero's currently stacks Views exposed filters. Other themes inline them. We should do the same.

Problem/Motivation

Some migration sources require multiple IDs e.g. node revisions (nid, vid, language).

It'd be nice to be able to specify just the nid and allow it to apply the update against the nid, and if you still require a specific entry, you can specify the full entry including the vid and language.

I believe this is currently blocked by #2780839: Optimize migration of specific source IDs for SQL sources as we don't have an API for specifying the idLists.

Proposed resolution

Provide support for querying only a subset of the source ID if specified.

Remaining tasks

Provide a patch or issue fork MR.

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Problem/Motivation

The file .ht.routeter added in #1543858: Add a startup configuration for the built-in PHP server that supports clean URLs to fix build-in web-server issue https://bugs.php.net/bug.php?id=61286 but since PHP 8.0 there's no such issue, so PR to fix it was closed.

Steps to reproduce

TBD

Proposed resolution

- Get rid of the file and add a test
- Update docs about new PHP_CLI_SERVER_WORKERS env variable (does not work on Windows) that allows more then one child worker in server - it's no longer single threaded

Remaining tasks

- add test and remove the file
- test the behavior on PHP 8.1/7.4
- commit and CR

User interface changes

no

API changes

no

Data model changes

no

Release notes snippet

Removed startup configuration for the built-in PHP server

Problem/Motivation

During the Drupal 9 development process, we've discovered that setting platform requirements (PHP version, supported databases, etc.) is best done early during the major branch development process. Setting these to "obvious" minima as soon as possible and then increasing them more afterward was also valuable.

Proposed resolution

• Continue adding PHP dev environments annually as soon as PHP alphas become available, and stable environments as soon as stable releases are available.
• Ensure that testing environments are available for the latest database versions before 10.0.x is opened.
• Require at least PHP 8.0 as soon as 10.0.x is opened. See #3173787: [policy] Require PHP 8 for Drupal 10 (up from 7.3 in Drupal 9).
• Determine similar obvious minima for supported databases based on support cycles, distro support, and hosting provider support as of when 10.0.x will be opened.
• Further increase the requirements as feasible.
• Set a deadline 1-2 months ahead of the initial 10.0.0-beta1 target deadline for finalizing platform requirement policies. (The final implementations can still be beta blockers.)

Remaining tasks

Problem/Motivation

Currently text fields can either be restricted to plain text, or the user may select between all accessible text formats independently of the context. This means that a privileged user who needs access to a permissive text formats (for example, to put tables or embedded remote content in basic pages) will get access to that format on every formatted text field (for example on a comment field).

There are three problems with this approach, and most experience Drupal developers have faced at least one of those in the past:

Consistency

At the moment you have to count on competence, good will and diligence of privileged users not to put certain markup in certain places. It would be convenient if a text field could be forced to use a specific text format (other than plain text). For example, you may want to make sure that comments only allow a very limited set of HTML tags ("filtertered HTML" for example) independently of the user's role, even if the same user has access to less restrictive formats in other places.

Usability

The ability to select text formats is a common source of confusion. By limiting the available text formats we also remove confusing user interface elements.

Security

If a privileged user account is taken over (for example, through social engineering), the attack surface is large due to the fact that every single text field can be used for XSS injections. By limiting where a dangerous text format can be used, we restrict the possibilities to inject malicious content.

Proposed resolution

Add an optional setting to the text field types that lets the site-builder determine if the text formats should be restricted. This setting is then used in the default textfield and textarea widgets to remove any non-allowed text formats. If nothing is set, the current behavior is unchanged.

Note that as it uses the underlying '#allowed_formats' form API property, the settings can't be used to give access to text formats that the user wouldn't have access to otherwise.

Remaining tasks

Needs follow-up to "kill" the formatted/unformatted text fields differentiation. (See #154)

User interface changes

Checkboxes on list of available formats on text field configuration. Reduced set of allowed formats on content edit forms, where used. No fields use the new setting by default, so the patch doesn't affect the user interface for those who don't do anything with this functionality.

API changes

None

Data model changes

One setting is added to the field settings. The structure of the field data is unchanged.

Beta phase evaluation

Postponed on #2283977: Create a new ConfigEntity type for storing bundle-specific customizations of base fields, which is introducing the BaseFieldOverride class described in this issue.

Problem/Motivation

• When a new 'base_field_override' config entity is created, BaseFieldOverride::preSave() calls the target entity type's storage handler's onFieldDefinitionUpdate() method, passing it the base field definition as the "previous" definition. And similarly, when the override config entity is deleted, BaseFieldOverride::postDelete() calls onFieldDefinitionUpdate, passing it the base field definition as the "new" definition.
• However, if it happens that a base_field_override config entity is being added to or deleted from a site that also implements an override via ContentEntityInterface::bundleFieldDefinitions(), then the above behavior is incorrect, since the previous definition prior to base_field_override insertion and the new definition after base_field_override deletion is the one returned by ContentEntityInterface::bundleFieldDefinitions(), rather than the base definition.
• The above might be an extreme edge case, because using ContentEntityInterface::bundleFieldDefinitions() rather than config to override base field definition is specifically intended for when you need you content entity type completely decoupled from config, in which case there shouldn't be code adding and removing base_field_override config entities for it.
• Also, it's not really clear what FieldableEntityStorageDefinitionInterface::onFieldDefinitionUpdate() is even for. The only implementation of it in HEAD is a completely empty function, even after #1498720: [meta] Make the entity storage system handle changes in the entity and field schema definitions. Perhaps we should consider removing it? Do storage handlers need to be notified of non-storage-related changes to field definitions?

Proposed resolution

Discuss the above and figure out what to do.

Remaining tasks

User interface changes

API changes

Problem/Motivation

Several modules, including Media, have integration tests for QuickEdit, but the module is slated to be removed from core and moved to contrib.

List of known tests:

core/modules/layout_builder/tests/src/FunctionalJavascript/LayoutBuilderQuickEditTest.php
core/modules/layout_builder/tests/src/Functional/LayoutBuilderQuickEditTest.php
core/modules/inline_form_errors/tests/src/FunctionalJavascript/FormErrorHandlerQuickEditTest.php
core/modules/image/tests/src/FunctionalJavascript/QuickEditImageEditorTestTrait.php
core/modules/image/tests/src/FunctionalJavascript/QuickEditImageTest.php
core/modules/image/tests/src/Functional/QuickEditImageControllerTest.php
core/modules/settings_tray/tests/src/FunctionalJavascript/QuickEditIntegrationTest.php
core/modules/editor/tests/src/Functional/QuickEditIntegrationLoadingTest.php
core/modules/editor/tests/src/Kernel/QuickEditIntegrationTest.php
core/modules/media/tests/src/Kernel/MediaEmbedFilterDisabledIntegrationsTest.php

Proposed resolution

Move these tests (or the appropriate test cases from them) into QuickEdit's test namespace to facilitate the core removal.

Remaining tasks

NR

API changes

QuickEditImageEditorTestTrait is moved from the Image module namespace to the QuickEdit module namespace.

Data model changes

N/A

Release notes snippet

Not needed per release managers.

While creating a NODE, MENU SETTINGS section to have a 'Enabled' checkbox like it has at /admin/structure/menu/manage/, to prevent landing to unpublished node (if node is been NOT published while creating it).

Problem/Motivation

Like commerce's order,It use 'any' type data to store object:Adjustment, But the TypedDataNormalizer just return the Adjustment object, It cause it can't be encode, So it can't be serializad

First(laravel): Let's look at laravel's serialization
laravel's serialization has two steps:

1. toArray() ====> corresponds to druapl's normalize
2. toJson() ====> corresponds to drupal's encode

laravel's toArray() is recursive，it will recurs to check whether the child value is Arrayable
https://github.com/illuminate/database/blob/5.5/Eloquent/Model.php#L918
https://github.com/illuminate/database/blob/5.5/Eloquent/Concerns/HasAtt...

Second(symfony):
https://github.com/symfony/serializer/blob/3.2/Serializer.php#L138

    public function normalize($data, $format = null, array $context = array())
    {
        // If a normalizer supports the given data, use it
        if ($normalizer = $this->getNormalizer($data, $format)) {
            return $normalizer->normalize($data, $format, $context);
        }
        if (null === $data || is_scalar($data)) {
            return $data;
        }
        if (is_array($data) || $data instanceof \Traversable) {
            $normalized = array();
            foreach ($data as $key => $val) {
                $normalized[$key] = $this->normalize($val, $format, $context);
            }
            return $normalized;
        }
        if (is_object($data)) {
            if (!$this->normalizers) {
                throw new LogicException('You must register at least one normalizer to be able to normalize objects.');
            }
            throw new UnexpectedValueException(sprintf('Could not normalize object of type %s, no supporting normalizer found.', get_class($data)));
        }
        throw new UnexpectedValueException(sprintf('An unexpected value could not be normalized: %s', var_export($data, true)));
    }

symfony's Serializer->normalize() has the ability to recursive normalize object and array too

Both laravel and symfony has the ability to recursive normalize object or array

Then(Drupal):
Let's see TypedDataNormalizer used by normalizing 'any' type data
core/modules/serialization/src/Normalizer/TypedDataNormalizer.php#n21

  public function normalize($object, $format = NULL, array $context = []) {
    return $object->getValue();
  }

We can see TypedDataNormalizer Just return the value
Drupal use symfony's serializer, But it dosn't follow or take full advantage of the symfony's serializer's design

Proposed resolution

1. make TypedDataNormalizer flow and use symfony's serialize->normalize()'s design. (solve here)
2. Map type data has similar trouble too: But Map have other more base problem, It can't be normalized when it has no propertydefinition , But if TypedDataNormalizer's problem is solved, Two kind of https://www.drupal.org/node/2895532's the patch(two kind of controversial solution) will work good with no change needed

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

When building a configuration package, a common need is to alter configuration provided by another package or extension. This need occurs with extension-provided configuration. For example: module B modifies the label of a field provided by module A. It can also occur with other types of configuration packages such as those provided in the Config Split module; see a current proposal for Config Split that introduces a suggested "quasi-patch" format.

In Drupal 7 contrib, "exportables" like Views could be altered through default alter hooks like hook_views_default_views_alter(). Loss of alters was a regression that was identified early in the Configuration Management Initiative. At the time - January, 2012 - the then CMI lead noted:

As for overrides, when we have talked about them, our hope has always been that we can make this mechanism work as diffs that get merged in. Our only currently planned level of overrides is that we would have a directory somewhere that would contain these diffs, for things like database information. When config is loaded, the main config is loaded and then these overrides get merged in. We have talked about more advanced situations where you have a hierarchy of overrides and merges that can happen. For instance, having a default config in sites/default with site-specific overrides in sites/ or the like. We could potentially do the same with profiles, the config they supply gets merged in. This really needs to be talked through carefully. The code has the potential to become extremely hairy and the hierarchy of which sets of config override which other sets needs to be really well defined.

However, such work was never completed in core and the regression remains unaddressed.

So far there are multiple competing frameworks in contrib, including Configuration Rewrite and Config Actions. While focused on the update use case, Update Helper also accomplishes its work through alters and is in principle very similar to Config Actions, with the very attractive addition of programmatically generating diffs rather than requiring manual editing. Update Helper defines a "configuration update definition (CUD)", stored in config/update directory. Config Actions defines an "action", stored in config/actions. Configuration Rewrite defines a "rewrite", stored in, you guessed it, config/rewrite. Work in Config Split could potentially introduce a fourth format and storage location.

Beyond the ability to manually write default alter hook implementations, in Drupal 7 you could programmatically generate and export alters through the Features Override module. That's the piece that's particularly lacking in Drupal 8+. It's there in Update Helper, but so enmeshed in the update use case it can't be used independently; see #3101832: Spin CUD management and tracking into a separate module. #3224762: Any way to exclude specific role permissions from being exported/causing a "changed" status? is a typical comment from a Drupal user understandably surprised at the lack of support for programmatic alter generation:

Override yaml files need to be created manually (there's no export feature GUI and/or drush)?

Handling alters is a challenging piece when merging in configuration updates from extensions. See Config Actions Provider and related work in Configuration Synchronizer for relevant approaches.

Providing an API in core, parallel to the existing one for dynamic/"temporary" config overrides, could help to reduce duplication in contrib while improving

Proposed resolution

An API would probably define a configuration alter format, similar to those used in Config Actions, Configuration Rewrite, and Update Helper and proposed for Config Split, and provide methods for both generating and applying such alters.

To facilitate more complex alters, parallel to #2991683: Move configuration transformation API in \Drupal\Core\Config namespace, we could additionally dispatch an event that modules can subscribe to. In this approach, a configuration transformation API would also apply at extension install time, allowing just-installed extensions to transform config in the active storage (config which may have been provided by previously-installed extensions). Core itself would subscribe to the event, applying extension-provided config alters per the defined format.

There are existing instances in core that could be upgraded to a new API, such as various config alters that currently are done programmatically in standard_install().

We could evaluate contrib modules for the strongest fit as a basis for this work. Update Helper appears to be a promising candidate, but would need to be decoupled from the update use case; see #3101832: Spin CUD management and tracking into a separate module. Proposed work in Config Split is also promising.

Remaining tasks

User interface changes

API changes

Data model changes

When using token replacement for a value coming from a view argument in a view area, for example if passing field_tags as an argument, both possible tokens produce the passed term id. The documentation says:
{{ arguments.field_tags_target_id }} == Content: Tags (field_tags) title
{{ raw_arguments.field_tags_target_id }} == Content: Tags (field_tags) input

To reporoduce:
New installation with the standard profile
create a node with a few tags
create a content view, add field_tags as an argument.
create a text area header block, choose to use Use replacement tokens from the first row, then add both proposed tokens to the text area
{{ arguments.field_tags_target_id }} {{ raw_arguments.field_tags_target_id }}

in the preview area, supply 1 as argument, you should get the title of the tag, and the ID. You get two IDs.

Problem/Motivation

Spinning off from #3227033: [Investigation] Try removing quickedit from core. There are a handful of places where we're currently leaning on quickedit data attributes as selectors for various test assertions in places that have nothing to do with testing quick edit functionality.

The main culprit are tests of stable / stable9, where there are no classes to target something specific. For example:

core/modules/node/tests/src/Functional/NodeDisplayConfigurableTest.php

It's trying to do this in assertNodeHtml():

$assert->elementTextContains('css', $created_selector, \Drupal::service('date.formatter')->format($node->getCreatedTime()));

So we need a selector to find exactly where the timestamp is appearing. But without quickedit enabled, the markup for this node in stable and stable9 looks something like this:

<article role="article" about="/drupal-9_1/node/1">
      <footer>
      <article typeof="schema:Person" about="/drupal-9_1/user/2">
  <div class="js-form-item form-item js-form-type-item form-item- js-form-item- form-no-label">
        <h4 class="label">Member for</h4> 24 seconds
        </div>
</article>
      <div>
        Submitted by <span><a title="View user profile." href="/drupal-9_1/user/2" lang="" about="/drupal-9_1/user/2" typeof="schema:Person" property="schema:name" datatype="">eMHCSGYOuJAkD2</a></span>
 on <span>Fri, 08/06/2021 - 11:09</span>
      </div>
    </footer>
  <div>
            <div><p>vJUMtKdL7e4hG5MdElsfGh0ucpCuPhDY</p>
</div>
  </div>
</article>

I'm not sure how we're supposed to find this needle: <span>Fri, 08/06/2021 - 11:09</span> in that haystack, without any classes or anything to distinguish it from every other <span>.

Proposed resolution

Figure out a way to test stable* without relying on quickedit attributes as selectors. The following tests need help:

• core/modules/node/tests/src/Functional/NodeDisplayConfigurableTest.php
  • Works for all core themes that provide field classes.
  • Needs a solution for stable + stable9
• core/modules/settings_tray/tests/src/FunctionalJavascript/SettingsTrayBlockFormTest.php
• core/modules/settings_tray/tests/src/FunctionalJavascript/SettingsTrayTestBase.php

Remaining tasks

1. Come up with a solution.
2. Implement it.
3. Confirm tests are all still passing.
4. Reviews / refinements.
5. RTBC.
6. Commit.
7. Unblock parent and friends.

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Release notes snippet

n/a

The 'weight' property of a taxonomy term is not translatable, so you are unable to order the terms differently in each language. This makes it impossible, for example, to have the terms alphabetically sorted in each language.

If the weight property were translatable then each language could be ordered independently - a big win.

Problem/Motivation

Quick Edit has usability issues, accessibility issues, and several challenges which make it hard to integrate with other parts of core and a number of unresolved bugs.

Technical issues

• It's incompatible with content moderation or workspaces #2903524: Don't add quickedit to displays where entities have a forward revision. and #2815221: Add ability to use Quick Edit to the latest_revision route, we just disable it on entities that have a forward revision.
• Additionally it's the most challenging part of removing our dependency on backbone and would require hundreds of hours to decouple: #3204016: Replace Quickedit BackboneJS usage with VanillaJS equivalent. Decoupling from Backbone is a Drupal 10 requirement.

Maintenance issues

• There are over 50 open issues, several more relating to integration with the entity system (revisions, translations), and most haven't been touched for more than six months:

  https://www.drupal.org/project/issues/search/drupal?project_issue_follow...

• The only updates to QuickEdit in the past several years are test and dependency updates.

Usability issues

• The user interactions of QuickEdit are clunky and unfinished, with usability bugs that have not been fixed after many years.
• QuickEdit is not well-integrated with existing UI patterns from more finished core elements like Layout Builder and CKEditor.
• The basic use-case - of being able to edit content or configuration via the front end of the website, is already served by contextual links, which while it's not as seamless, is a lot more reliable.

Accessibility issues

• #1844220: Make in-place editing keyboard and aurally accessible
• QuickEdit is known to cause motion sickness in numerous people, with at least one report of severe nausea after prolonged use of it. (See also #2270269: Reduce animation delays).

Usage

• The usage data we have on QuickEdit is not necessarily correct. Since the module is in the Standard profile, many site owners probably don't think or know to disable it, but also don't use the feature. In #3158669: By default deprecate non-experimental modules that are used by less 5% of sites before the next major version, QuickEdit has 73.8% usage, which is one of lowest usages of any module in Standard, and less than the usage of Standard itself. This indicates that site owners are actively turning it off. Unlike modules like Comment, which are valuable in Stnadard because useful to many sites but also not appropriate to many sites, QuickEdit should theoretically be used by content authors as much as (e.g.) CKEditor. But it's not.
• Multiple individuals and Drupal organizations report deliberately never using it in their builds, including:
  • Lullabot
  • 1x
  • Agora Design
  • Debug Academy
  • Unic
  • OpenPlus
  • FFW
  • Urban Institute

  See specific comments in #26 and in the Twitter thread: https://twitter.com/gaborhojtsy/status/1415035764975484931

  Proposed resolution

  Move Quick Edit to contrib.

  Remaining tasks

  Find a contrib maintainer.

  User interface changes

  API changes

  Data model changes

  Release notes snippet

Problem/Motivation

While #3222947: [policy, no patch] Decide whether to move Quick Edit to contrib discusses deprecating the QuickEdit module for removal from core in 10.0.x, a smaller first step is to remove QuickEdit from the Standard profile, which is a backwards-compatible change that can be made in 9.3.x.

Proposed resolution

Remove QuickEdit from the Standard profile.

Remaining tasks

TBD

User interface changes

N/A aside from title.

API changes

TBD

Data model changes

TBD

Release notes snippet

The Quick Edit module is slated for removal from core in Drupal 10. To this end, Quick Edit has been removed from the Standard profile in Drupal 9.3.0. This change does not affect existing sites, only new sites installing the Standard profile for the first time. For more information, see the change record on Quick Edit's removal from the Standard profile.