HI,

There should be an option for hook_form_alter for install_settings_form. if anyone want to change the installation time "Database configuration" (step 4 ) form change (i.e add more databases with drupal project) and want to save it in settings.php as per drupal way.

There is no method to do above expect change in drupal core code.

Thanks
Lalit

Problem/Motivation

When adding a new Content type (/admin/structure/types/add), the "Publishing options" for the "Published" and "Create new revision" options are as follows:

Published
Description: null

Create new revision
Description: Users with sufficient access rights will be able to override these options.

When adding a new Media type (/admin/structure/media/add), the "Publishing options" for the "Published" and "Create new revision" options are as follows:

Published
Description: Media will be automatically published when created. 

Create new revision
Description: Automatically create new revisions. Users with the "Administer media" permission will be able to override this option. 

Proposed resolution

Make the descriptions for the "Published" and "Create new revision" options consistent

Add new Content type:

Published
Description: Content will be automatically published when created.

Create new revision
Description: Automatically create new revisions. Users with the "Administer content" permission will be able to override this option.

Add new Media type:

Published
Description: Media will be automatically published when created. 

Create new revision
Description: Automatically create new revisions. Users with the "Administer media" permission will be able to override this option.

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--checkbox-radio.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

The only browser requests made by TokenReplaceTest are for setting up terms, and these could be done as APi calls.

Therefore, the whole test could be converted to a kernel test.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Media entities are revisionable but it's not possible to:

• view a revision
• revert to a revision
• delete a specific revision
• see a diff of revisions, if the contrib Diff module is enabled.

Proposed resolution

Introduce the revisions tab, like we have it for node.

Remaining tasks

Also introduce 'view all revisions', 'revert all revisions' and 'delete all revisions' permission.

User interface changes

API changes

Data model changes

This meeting takes place every Friday at 14:00 UTC (currently 7:00am PT, 10:00am ET). See Time.is to see what that is in your timezone.

The meetings are held using Zoom, and a link is posted in the #ux Slack channel 10 minutes before the meeting. Agenda is first come, first serve and set by attendees. Use the Needs usability review issue tag for issues that need review and/or suggest issues in comments here.

List of Slack users to ping 10 minutes before the meeting:
@Gábor Hojtsy (he/him), @worldlinemine, @lauriii, @AaronMcHale, @anmolgoyal74, @Antoniya, @Ravi, @shaal, @ckrina, @simohell, @gauravvv, @penyaskito, @Mike Gifford (CivicActions), @April, @Quynh, @yoroy, @EricRubino

Go to the issue for the next meeting to add/remove yourself to/from the list.

Recording of this week's meeting: https://youtu.be/OIoLpSlCcw0

Rough transcript of this week's meeting: Drupal Usability Meeting - 2023-06-23.txt

We discussed the following issues:

• #3318112: [PP1] Move "Block layout" from Structure to Appearance
• #2755613: Restructure the admin interface Information Architecture
• #3366986: Card Sorting survey

NR and RTBC issues marked Needs usability review.

Problem/Motivation

If an entity has a datetime field with a time component, the 'date' property returns a DrupalDateTime object. This is handled by the DateTimeComputed class.

When an entity is first loaded, this returns a DrupalDateTime with the timezone set to UTC.

However, if the current user has a personal timezone set, viewing the field pollutes this value and subsequent accessing of it has its timezone set to the user timezone.

This does not occur if the user is set to UTC and the site is set to a specific timezone. This DOES occur if the user has a specific timezone and the site timezone is the same as this.

Steps to reproduce

1. Create a datetime field on a node type
2. Create a node of this type and set the field value
3. Run this code:

    $node = $this->entityTypeManager->getStorage('node')->load(NID);
    dsm($node->my_date_field->date->getPhpDateTime());
    $node->my_date_field->view();
    dsm($node->my_date_field->date->getPhpDateTime());

Both datetimes should be in UTC.

4. Set the user's timezone to something else.
5. Run the code again. The second dsm() produces a datetime in the user's timezone.

Proposed resolution

Data should not be changed by the act of viewing it!

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In #3366083: Method attributes to implement hooks (hux style) we proposed to provide a new way to implement hooks, using object methods with attributes.
A similar system already exists in contrib: https://drupal.org/project/hux

In this issue we will do proof-of-concept implementation and experiments.

Once this is done, we can split out real implementation issues that can then be developed and merged one by one.
E.g. perhaps there will be separate refactoring issues as preparation for the new system.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In #3084983: Move all the code related to path aliases to a new (required) "path_alias" module and #3092090: Remove legacy Path Alias subsystem we moved the Path Alias subsystem to the path_alias module. The module was marked as required (and hidden) to avoid BC issues, however there is no technical requirement for this to be the case, in fact the original goal was the make the Path Alias logic optional.

Proposed resolution

Make path_alias module optional. In #3084983-10: Move all the code related to path aliases to a new (required) "path_alias" module @amateescu said:

\Drupal\system\Form\SiteInformationForm

We need to remove the alias bits from that form and alter it in the path module.

\Drupal\system\Plugin\Condition\RequestPath

We need to remove the alias bits from this plugin and override the plugin class in the path module to re-add the path alias functionality.

\Drupal\views\Plugin\views\argument_default\Raw

Not sure about this one, maybe the easiest option would be to add the path module as a dependency for the views module.

Remaining tasks

• Validate the proposed solution
• Write a patch
• Reviews

User interface changes

None

API changes

TBD

Data model changes

None

Release notes snippet

TODO

Problem/Motivation

Background: We currently do most of our development against the "Most recently opened Development Branch", and when the first alpha of that minor is released, we open a new branch, which then logically changes what the "Most recently opened Development branch". Anything that's eligible to apply to either the currently supported minor or previous minor (security patches) is then cherry picked to those lower branches.

Problem: This means that our "logical HEAD" of core is a moving target that changes every six months, and perhaps more frequently when we add in Major version branch openings as well.

This causes a couple of problems:

1. Issues are assigned to a specific branch, like "9.3.x" that then have to be re-assigned to the new logical HEAD. In the vast majority of cases these issues aren't actually targeting the specific branch, they are trying to chase the logical HEAD, and when that HEAD changes labels (i.e. from 9.3.x->9.4.x) we have to go through a process to manipulate all of the issue metadata to move them.
2. Now that we have merge requests, those MRs also need to be migrated to be filed against the latest logical HEAD. We currently do not have a programmatic way to accomplish this, and the permissions on gitlab only allow the opener of the MR to do it, so even manual community issue grooming is onerous, and sometimes demands a new MR be opened to move branches.
3. A new user to the project doesn't have an obvious signpost where development happens. They have to look at all the open branches, and deduce that the highest numbered one is where all the momentum is happening. -> it is more common in projects for main is the place where work happens.

Proposed resolution

Ideally we would switch our logical HEAD to main asap, however Drupal.org does not have support for non-numeric branches out of the box.

Instead, we can implement an interim step on Drupal.org which should work with minimum or zero d.o changes and only minor core changes:

• Branch 11.x instead of 10.2.x now (i.e. 10.1.0-alpha/beta period).
• 11.x will follow 10.x minor release commit rules for the time being, no 11.x-specific patches yet and no 10.2.x branch.
• When we are ready to tag 10.2.0-alpha1, we would then branch 10.2.x and tag all 10.2 releases from there. The 11.x branch then continues as HEAD.
• When we need to diverge 11.x and 10.x, we would branch 10.LAST.x. 11.x would then start to get 11.x-specific commits
• When we're ready to tag 11.0.0-alpha1 we would branch 11.0.x and tag all releases from that branch.
• Continue with 11.x minor branches branched off 11.x when they reach alpha
• Hopefully, by the time we're working on 12.x, we'll be able to branch 'main' and work from that indefinitely.

Advantages:
One bulk issue update from 10.1.x to 11.x, and eventually a bulk issue update to 'main' in two or so years, instead of every six months. Same with branch retargeting.

DIsadvantages:
It is weird and non-semantic to use 11.x as the target for 10.x commits and release branches, however this will only be the case for a few months, then it will fold into sync with the 11.x release cycle anyway.

Original Proposal: Change our logical HEAD to main. All of our current existing policies would still apply, with one exception: instead of opening "the next branch for development" when we release an alpha, we instead open the release branch for that release at the time the alpha is released. (Do nothing with d7 and leave it as it is)

Example

(Now out of date in terms of current version, but still conveys the idea)

The current regime:
All of our commits happen to 9.3.x and:

The proposed strategy:
(rename current 9.3.x to main)
All of our commits happen against the main branch

So essentially: we develop in main untilwe open a release branch, at the same time that we make that branch's first release.

Question: The one part of this change that I'm unfamiliar with is what we do around major version branch releases:

If we are opening 9.4.x and 10.0.x at different times, then with this change in place we would open the 9.4.x branch when we are ready to start committing '10.0.x only' changes to main

Implementation considerations:

• Add main as a 'dev' release?
• Do we need both a 'main' and a 'next'?
• Allow main to exist in the version selector for issues
• Look at places where 'branch' might be standing in for a version.
• disable force pushes to main - at least for core.

Remaining tasks

• Finalize decision
• Identify all places where there are hard coded assumptions about 'branch' and 'version'
• Choose an appropriate transition window in an upcoming version cycle
• Documentation changes, including wiki pages and policy

User interface changes

Release notes snippet

Problem/Motivation

Single directory components (SDC) is a new way to theme Drupal. Instead of scattering related files around your theme, they're contained to one directory. The primary issue for SDC is at #3313520: Single directory components in core.

The Demo Umami team has decided that their theme can depend on an experimental module like SDC. This allows us to have the work in this ticket merged even when #3352256: [META] Move code from the experimental SDC module to core is not committed.

Hi Team,

The current version of Drupal is 9.5.9, and I get an error when I upgrade to Drupal 10.0.9 using Composer.

PHP - 8.1.14
Core - 9.5.9
Composer - 2.2.9

After getting the 100% score on Upgrade Status, I run the below comments, - https://www.drupal.org/docs/upgrading-drupal/upgrading-from-drupal-8-or-...

Command 1 - composer require 'drupal/core-recommended:10.0.7''drupal/core-composer-scaffold:10.0.7''drupal/core-project-message:10.0.7' --update-with-dependencies --no-update

Command 2 - composer update -W --dry-run

And the Error Message:

Your requirements could not be resolved to an installable set of packages.
Problem 1
- Root composer.json requires pantheon-upstreams/upstream-configuration dev-drupal10 -> satisfiable by pantheon-upstreams/upstream-configuration[dev-drupal10].
- pantheon-upstreams/upstream-configuration dev-drupal10 requires drupal/core-composer-scaffold ^9 -> found drupal/core-composer-scaffold[9.0.0-alpha1, ..., 9.5.x-dev] but it conflicts with your root composer.json require (10.0.7).
Problem 2
- drupal/core 10.0.7 requires php >=8.1.0 -> your php version (7.4; overridden via config.platform, actual: 8.1.3) does not satisfy that requirement.
- drupal/core-recommended 10.0.7 requires drupal/core 10.0.7 -> satisfiable by drupal/core[10.0.7].
- Root composer.json requires drupal/core-recommended 10.0.7 -> satisfiable by drupal/core-recommended[10.0.7].
Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

composer.json

{
    "name": "pantheon-upstreams/drupal-project",
    "description": "Install Drupal 9 with Composer on Pantheon.",
    "type": "project",
    "license": "MIT",
    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        },
        {
            "type": "path",
            "url": "upstream-configuration"
        }
    ],
    "require": {
        "drupal/admin_toolbar": "^3.4",
        "drupal/autologout": "^1.4",
        "drupal/bamboo_twig": "^6.0",
        "drupal/better_exposed_filters": "^6.0",
        "drupal/color": "^1.0",
        "drupal/components": "^3",
        "drupal/core-composer-scaffold": "10.0.7",
        "drupal/core-project-message": "10.0.7",
        "drupal/core-recommended": "10.0.7",
        "drupal/ctools": "^4.0",
        "drupal/easy_breadcrumb": "^2.0",
        "drupal/entity_reference_revisions": "^1.10",
        "drupal/field_group": "^3.4",
        "drupal/geolocation": "^3.12",
        "drupal/jquery_ui": "^1.6",
        "drupal/jquery_ui_datepicker": "^1.4",
        "drupal/jquery_ui_touch_punch": "^1.1",
        "drupal/media_entity_file_replace": "^1.1",
        "drupal/menu_block": "^1.10",
        "drupal/menus_attribute": "^1.3",
        "drupal/metatag": "^1.25",
        "drupal/paragraphs": "^1.15",
        "drupal/password_policy": "^4.0",
        "drupal/pathauto": "^1.11",
        "drupal/quickedit": "^1.0",
        "drupal/rdf": "^2.0",
        "drupal/recommended-project": "^10",
        "drupal/redirect": "^1.8",
        "drupal/schema_metatag": "^2.4",
        "drupal/seckit": "^2.0",
        "drupal/session_limit": "^2.0@beta",
        "drupal/simple_mobile_menu": "3.x-dev@dev",
        "drupal/stable": "^2.0",
        "drupal/token": "^1.11",
        "drupal/upgrade_status": "^4.0",
        "drupal/username_enumeration_prevention": "^1.3",
        "drupal/xmlsitemap": "^1.4",
        "drush/drush": "^12",
        "pantheon-upstreams/upstream-configuration": "dev-drupal10"
    },
    "conflict": {
            "drupal/drupal": "*"
    },
    "minimum-stability": "dev",
    "prefer-stable": true,
    "extra": {
        "installer-paths": {
            "web/core": ["type:drupal-core"],
            "web/libraries/{$name}": ["type:drupal-library"],
            "web/modules/composer/{$name}": ["type:drupal-module"],
            "web/profiles/composer/{$name}": ["type:drupal-profile"],
            "web/themes/composer/{$name}": ["type:drupal-theme"],
            "drush/Commands/contrib/{$name}": ["type:drupal-drush"],
            "web/private/scripts/quicksilver/{$name}/": ["type:quicksilver-script"]
        },
        "composer-exit-on-patch-failure": true,
        "patchLevel": {
            "drupal/core": "-p2"
        },
        "enable-patching": "true",
        "patches": {
            "drupal/paragraphs": {
            "Deprecated function": "https://www.drupal.org/files/issues/2022-09-22/3310161-11.patch"
            },
            "drupal/jquery_ui_slider": {
            "Deprecated function": "https://www.drupal.org/files/issues/2022-06-16/jquery_ui_slider.1.x-dev.rector.patch"
            }
        },
        "drupal-scaffold": {
            "allowed-packages": [
                "pantheon-systems/drupal-integrations"
            ],
            "locations": {
                "web-root": "./web"
            },
            "file-mapping": {
                "[project-root]/.editorconfig": false,
                "[project-root]/pantheon.upstream.yml": false,
                "[project-root]/.gitattributes": false,
                "[web-root]/robots.txt": {
                    "append": "web/sites/default/my-robots-additions.txt"
                }
            }
        }
    },
    "config": {
        "preferred-install": "dist",
        "sort-packages": true,
        "platform": {
            "php": "7.4"
        },
        "allow-plugins": {
            "zaporylie/composer-drupal-optimizations": true,
            "drupal/core-composer-scaffold": true,
            "cweagans/composer-patches": true,
            "composer/installers": true,
            "drupal/core-project-message": true
        }
    },
    "require-dev": {
        "drupal/core-dev": "^10",
        "phpstan/phpstan": "^1.10",
        "phpunit/phpunit": "^9.6"
    }
}

Command 3: composer prohibits drupal/core:^10

Info from https://repo.packagist.org: #StandWithUkraine
drupal/core-recommended            9.5.9       requires          drupal/core (9.5.9)                                      
drupal/jquery_ui_slider            1.1.0       requires          drupal/core (^8 || ^9)                                   
drupal/core                        10.0.9      requires          php (>=8.1.0 but 7.4 is installed)                       
drupal/core                        10.0.9      requires          symfony/console (^6.2)                                   
pantheon-upstreams/drupal-project  dev-master  does not require  symfony/console (but v4.4.49 is installed)               
drupal/core                        10.0.9      requires          symfony/dependency-injection (^6.2)                      
pantheon-upstreams/drupal-project  dev-master  does not require  symfony/dependency-injection (but v4.4.49 is installed)  
drupal/core                        10.0.9      requires          symfony/event-dispatcher (^6.2)                          
pantheon-upstreams/drupal-project  dev-master  does not require  symfony/event-dispatcher (but v4.4.44 is installed)      
drupal/core                        10.0.9      requires          symfony/http-foundation (^6.2)                           
pantheon-upstreams/drupal-project  dev-master  does not require  symfony/http-foundation (but v4.4.49 is installed)       
drupal/core                        10.0.9      requires          symfony/http-kernel (^6.2)                               
pantheon-upstreams/drupal-project  dev-master  does not require  symfony/http-kernel (but v4.4.50 is installed)           
drupal/core                        10.0.9      requires          symfony/mime (^6.2)                                      
pantheon-upstreams/drupal-project  dev-master  does not require  symfony/mime (but v5.4.13 is installed)                  
drupal/core                        10.0.9      requires          symfony/routing (^6.2)                                   
pantheon-upstreams/drupal-project  dev-master  does not require  symfony/routing (but v4.4.44 is installed)               
drupal/core                        10.0.9      requires          symfony/serializer (^6.2)                                
pantheon-upstreams/drupal-project  dev-master  does not require  symfony/serializer (but v4.4.47 is installed)            
drupal/core                        10.0.9      requires          symfony/validator (^6.2)                                 
pantheon-upstreams/drupal-project  dev-master  does not require  symfony/validator (but v4.4.48 is installed)             
drupal/core                        10.0.9      requires          symfony/process (^6.2)                                   
pantheon-upstreams/drupal-project  dev-master  does not require  symfony/process (but v4.4.44 is installed)               
drupal/core                        10.0.9      requires          symfony/yaml (^6.2)                                      
pantheon-upstreams/drupal-project  dev-master  does not require  symfony/yaml (but v4.4.45 is installed)                  
drupal/core                        10.0.9      requires          twig/twig (^3.4.3)                                       
pantheon-upstreams/drupal-project  dev-master  does not require  twig/twig (but v2.15.5 is installed)                     
drupal/core                        10.0.9      requires          guzzlehttp/guzzle (^7.5)                                 
pantheon-upstreams/drupal-project  dev-master  does not require  guzzlehttp/guzzle (but 6.5.8 is installed)               
drupal/core                        10.0.9      requires          guzzlehttp/psr7 (^2.4)                                   
pantheon-upstreams/drupal-project  dev-master  does not require  guzzlehttp/psr7 (but 1.9.1 is installed)                 
drupal/core                        10.0.9      requires          asm89/stack-cors (^2.1)                                  
pantheon-upstreams/drupal-project  dev-master  does not require  asm89/stack-cors (but 1.3.0 is installed)                
drupal/core                        10.0.9      requires          psr/log (^3.0)                                           
pantheon-upstreams/drupal-project  dev-master  does not require  psr/log (but 1.1.4 is installed)

Error Message :

Your requirements could not be resolved to an installable set of packages.

Problem 1
- Root composer.json requires pantheon-upstreams/upstream-configuration dev-drupal10 -> satisfiable by pantheon-upstreams/upstream-configuration[dev-drupal10].
- pantheon-upstreams/upstream-configuration dev-drupal10 requires drupal/core-composer-scaffold ^9 -> found drupal/core-composer-scaffold[9.0.0-alpha1, ..., 9.5.x-dev] but it conflicts with your root composer.json require (^10).
Problem 2
- drupal/core-recommended 10.0.x-dev requires drupal/core 10.0.x-dev -> satisfiable by drupal/core[10.0.x-dev].
- drupal/core-recommended 10.1.x-dev requires drupal/core 10.1.x-dev -> satisfiable by drupal/core[10.1.x-dev].
- drupal/core-recommended 10.0.0-alpha1 requires drupal/core 10.0.0-alpha1 -> satisfiable by drupal/core[10.0.0-alpha1].
- drupal/core-recommended 10.0.0-alpha2 requires drupal/core 10.0.0-alpha2 -> satisfiable by drupal/core[10.0.0-alpha2].
- drupal/core-recommended 10.0.0-alpha3 requires drupal/core 10.0.0-alpha3 -> satisfiable by drupal/core[10.0.0-alpha3].
- drupal/core-recommended 10.0.0-alpha4 requires drupal/core 10.0.0-alpha4 -> satisfiable by drupal/core[10.0.0-alpha4].
- drupal/core-recommended 10.0.0-alpha5 requires drupal/core 10.0.0-alpha5 -> satisfiable by drupal/core[10.0.0-alpha5].
- drupal/core-recommended 10.0.0-alpha6 requires drupal/core 10.0.0-alpha6 -> satisfiable by drupal/core[10.0.0-alpha6].
- drupal/core-recommended 10.0.0-alpha7 requires drupal/core 10.0.0-alpha7 -> satisfiable by drupal/core[10.0.0-alpha7].
- drupal/core-recommended 10.0.0-beta1 requires drupal/core 10.0.0-beta1 -> satisfiable by drupal/core[10.0.0-beta1].
- drupal/core-recommended 10.0.0-beta2 requires drupal/core 10.0.0-beta2 -> satisfiable by drupal/core[10.0.0-beta2].
- drupal/core-recommended 10.0.0-rc1 requires drupal/core 10.0.0-rc1 -> satisfiable by drupal/core[10.0.0-rc1].
- drupal/core-recommended 10.0.0-rc2 requires drupal/core 10.0.0-rc2 -> satisfiable by drupal/core[10.0.0-rc2].
- drupal/core-recommended 10.0.0-rc3 requires drupal/core 10.0.0-rc3 -> satisfiable by drupal/core[10.0.0-rc3].
- drupal/core-recommended 10.0.0 requires drupal/core 10.0.0 -> satisfiable by drupal/core[10.0.0].
- drupal/core-recommended 10.0.1 requires drupal/core 10.0.1 -> satisfiable by drupal/core[10.0.1].
- drupal/core-recommended 10.0.2 requires drupal/core 10.0.2 -> satisfiable by drupal/core[10.0.2].
- drupal/core-recommended 10.0.3 requires drupal/core 10.0.3 -> satisfiable by drupal/core[10.0.3].
- drupal/core-recommended 10.0.4 requires drupal/core 10.0.4 -> satisfiable by drupal/core[10.0.4].
- drupal/core-recommended 10.0.5 requires drupal/core 10.0.5 -> satisfiable by drupal/core[10.0.5].
- drupal/core-recommended 10.0.6 requires drupal/core 10.0.6 -> satisfiable by drupal/core[10.0.6].
- drupal/core-recommended 10.0.7 requires drupal/core 10.0.7 -> satisfiable by drupal/core[10.0.7].
- drupal/core-recommended 10.0.8 requires drupal/core 10.0.8 -> satisfiable by drupal/core[10.0.8].
- drupal/core-recommended 10.0.9 requires drupal/core 10.0.9 -> satisfiable by drupal/core[10.0.9].
- drupal/core-recommended 10.1.0-alpha1 requires drupal/core 10.1.0-alpha1 -> satisfiable by drupal/core[10.1.0-alpha1].
- drupal/core-recommended 10.1.0-beta1 requires drupal/core 10.1.0-beta1 -> satisfiable by drupal/core[10.1.0-beta1].
- drupal/core-recommended 10.1.0-rc1 requires drupal/core 10.1.0-rc1 -> satisfiable by drupal/core[10.1.0-rc1].
- drupal/core-recommended 10.1.0 requires drupal/core 10.1.0 -> satisfiable by drupal/core[10.1.0].
- drupal/core[10.0.0-alpha2, ..., 10.1.x-dev] require php >=8.1.0 -> your php version (7.4; overridden via config.platform, actual: 8.1.3) does not satisfy that requirement.
- drupal/core 10.0.0-alpha1 requires php >=8.0.2 -> your php version (7.4; overridden via config.platform, actual: 8.1.3) does not satisfy that requirement.
- Root composer.json requires drupal/core-recommended ^10 -> satisfiable by drupal/core-recommended[10.0.0-alpha1, ..., 10.1.x-dev].

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

Problem/Motivation

As mentioned in the parent issue #3238306: [META] Where possible, refactor existing jQuery uses to vanillaJS to reduce jQuery footprint, we are working towards reducing our jQuery footprint. One of the ways to accomplish this is to reduce the number of jQuery features used in Drupal core. We have added eslint rules that identify specific features and fail tests when those features are in use.

There are (or will be) individual issues for each jQuery-use eslint rule. This one is specific to jquery/no-css, which targets the jQuery css function.

Steps to reproduce

Proposed resolution

Remaining tasks

• In core/.eslintrc.jquery.json Change "jquery/no-css": 0, to "jquery/no-css": 2, to enable eslint checks for uses of jQuery css(). With this change, you'll be able to see uses of the undesirable jQuery feature by running yarn lint:core-js-passing from the core directory
• Add the following lines to core/scripts/dev/commit-code-check.sh so the DrupalCI testing script can catch this jQuery usage on all files, not just those which have changed
  

  # @todo Remove the next chunk of lines before committing. This script only lints
  #  JavaScript files that have changed, so we add this to check all files for
  #  jQuery-specific lint errors.
  cd "$TOP_LEVEL/core"
  node ./node_modules/eslint/bin/eslint.js --quiet --config=.eslintrc.passing.json .
  
  CORRECTJQS=$?
  if [ "$CORRECTJQS" -ne "0" ]; then
    # No need to write any output the node command will do this for us.
    printf "${red}FAILURE ${reset}: unsupported jQuery usage. See errors above."
    STATUS=1
    FINAL_STATUS=1
  fi
  cd $TOP_LEVEL
  # @todo end lines to remove

  Add the block about 10 lines before the end of the file, just before if [[ "$FINAL_STATUS" == "1" ]] && [[ "$DRUPALCI" == "1" ]]; then, then remove it once all the jQuery uses have been refactored.

• If it's determined to be feasible, refactor those uses of jQuery css() to use Vanilla (native) JavaScript instead.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Testing html5 editor in a modal window throws "Uncaught TypeError: event.target.classList is undefined" in line 15 of core/modules/ckeditor5/js/ckeditor5.dialog.fix.js file.

Steps to reproduce

• Open a modal with a ck5editor5 field inside.
• switch to another window(i.e: CTRL+TAB) and return to the former window
• The error is shown on console. (see attached file)

Note: debugging the case found that event.target variable is equal to an "HTMLDocument" object.
For @Anybody this happened in Firefox 112.0.2

Proposed resolution

Probably improving the condition that causes the error (i.e:
return event.target.classList && event.target.classList.contains('ck') || this._super(event);
)

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Config entities require validation for REST support. Add a generic "machine_name" type and validate the value.

Proposed resolution

Add type: machine_name with validation constraints — with both the regex and length overridable to allow non-standard machine name shapes.

Impact as measured by #3324984: Create test that reports % of config entity types (and config schema types) that is validatable's ConfigSchemaValidatabilityTest (and diff before124.txt after124.txt):

Config entity types

• ⏸️ 0.00% → 0.00% validatable (0 of 30 config types — excludes base types)
• 🆙 24.16% → 31.24% average config type validatability
• 🆙 36.10% → 39.35% validatable property paths (200 → 218 of 554 property paths — this excludes property paths for base types)

Config types

• 🆙 4.61% → 4.76% validatable (29 → 30 of 629 → 630 config types — excludes base types)
• 🆙 25.95% → 26.40% average config type validatability
• 🆙 36.80% → 37.29% validatable property paths (1392 → 1411 of 3783 → 3784 property paths — this excludes property paths for base types)

Remaining tasks

None.

User interface changes

None.

API changes

API addition: machine_name config schema data type

Data model changes

None.

Problem/Motivation

#3357583: [Ignore] In space (and/or this issue), no one can hear patches scream V

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

#2920309: Add experimental module for Help Topics should move the help topics from the experimental module to the correct locations - either core/help_topics or each extension (module/theme)'s help_topics directory.

This can only be done as the last step before going Stable, so it is postponed for the moment.

Proposed resolution

Move the topics to their final spots, and remove the special case that the experimental help_topics module can provide topics for other providers that is in the Discovery class.

Remaining tasks

Postponed on #3037230: Finalize the merge of Help Topics into Help
Make a patch. Don't commit the patch until Help Topics is being made stable.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

None

Problem/Motivation

According to the Claro style guide, only the primary tabs are collapsed on mobile. The secondary tabs are all displayed. However, this could become very overloaded if there are many tabs.

Steps to reproduce

You will find the Claro style guide here or you can look at the screenshot below.

Proposed resolution

Maybe it would make sense to set an upper limit for secondary tabs, where you say that, for example, from 5 secondary tabs, they are also collapsed on mobile.

Problem/Motivation

Most entity types in Drupal have a description (content types, media types, menus, vocabularies, views, roles, etc. For sites built with a lot of custom form modes and view modes to manage how media is displayed on an entity, it would be helpful for site builders to be able to provide a description for each form/view mode to describe why the custom view mode was created.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

With help_topic being merged into core need to add help_search into SearchAdminThemeTest (per #14)

original post

The test added in #3087879: Use admin theme annotation for help topics search
core/modules/help_topics/tests/src/Functional/SearchAdminThemeTest.php
should be merged into
core/modules/search/tests/src/Functional/SearchAdminThemeTest.php

Steps to reproduce

NA

Proposed resolution

Remaining tasks

Review

User interface changes

NA

API changes

NA

Data model changes

NA

Release notes snippet