Problem/Motivation

Currently the MediaLibraryWidget uses a static call to \Drupal\media_library\MediaLibraryUiBuilder::dialogOptions which means that altering these dimensions is really hard.

Proposed resolution

By just using the media_library.ui_builder instead of the static call a developer can influence the dimensions by overriding the service.

I know the service says:
* This service is an internal part of the modal media library dialog and
* does not provide any extension points.

But sheesh how un-Drupal can you get and there doesn't seem to be another way to alter these options either.

Remaining tasks

Decide if this is the best way to do this

User interface changes

None

API changes

Constructor for Drupal\media_library\Plugin\CKEditorPlugin\DrupalMediaLibrary updated to accept and eventually require the media_library.ui_builder service as an argument.

Data model changes

None

Release notes snippet

TBD

Problem/Motivation

The module uninstall form lists all modules in alphabetical order, this means that non-stable modules are mixed in with stable modules.

In #3266397: Highlight non-stable modules on the admin/modules/uninstall form we are introducing the non-stable statuses for modules on the uninstall form.

During a UX calls it was identified that grouping such modules together at the top of the list would be preferable as it would draw more attention to them. This is particularly important for obsolete modules where immediate action may be required.

In #3266397-7: Highlight non-stable modules on the admin/modules/uninstall form it was agreed to push that change to a follow-up issue, this is that issue.

Steps to reproduce

Proposed resolution

For non-stable modules in the module uninstall list, promote those modules to the top of the list so that they appear first, then all other stable modules appear below in the list.

Remaining tasks

User interface changes

Before

Image may be NSFW.
Clik here to view.

After

Image may be NSFW.
Clik here to view.

API changes

None.

Data model changes

None.

Release notes snippet

Not needed.

Currently, theme_fieldset() uses empty() to determine whether or not to display a title for the fieldset. This means that a #title such as a zero will not be displayed. The attached patch converts #title to a string and displays the title unless the string is the empty string.

Steps to reproduce: Create a fieldset with a title of zero. It will not appear, but it should.

Problem/Motivation

Discovered at #3259593-17: Alignment being available as separate buttons AND in dropdown is confusing.

Steps to reproduce

See failing test in #2.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Symfony 6.1.0 is out.

https://github.com/symfony/symfony/releases/tag/v6.1.0

Steps to reproduce

Proposed resolution

Post a patch here which updates core to 6.1.0, and see what breaks.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Drupal 8/9 ship with CKEditor 4's StylesCombo plugin/feature: https://ckeditor.com/docs/ckeditor4/latest/features/styles.html

This shipped with the original CKEditor 4 issue: #1890502: WYSIWYG: Add CKEditor module to core. It provides a configuration UI:
Image may be NSFW.
Clik here to view.

When talking to the CKEditor developers:

We didn’t work on a replacement yet. We’re not even sure whether it’s needed and what’d be the use cases.
There’s a very old ticket: https://github.com/ckeditor/ckeditor5/issues/648 where we started some discussion. There’s also https://github.com/ckeditor/ckeditor5/issues/5700. But in general it’s unclear for us what would this feature be for.

What use cases do you see for it?

My response:

Well … how do we provide an automatic upgrade path in Drupal? 🤔

StylesCombo in CKE4 can only be mapped to heading.Heading in CKE5 as long as it’s only touching <h*>— but StylesCombo allowed much more. How do we automatically take any arbitrary StylesCombo configuration and make it work in CKE5?

It’s fine if it maps to multiple plugins but we do need to provide an upgrade path.

To which they responded:

Yeah, from the upgrade path perspective, there’s certainly a clear reason to do something on our side. What was blocking us so far is that we don’t want to create again a feature that duplicates a big part of the headings dropdown functionality. Thus, product-wise, it’s tricky.

Proposed resolution

Wait for https://github.com/ckeditor/ckeditor5/pull/11349 to ship with the April 6 release of CKEditor 5.

It shipped: #19. 👍

Remaining tasks

• ✅ add @ckeditor/ckeditor5-style package
• ✅ basic functionality
• ✅ TEST: unit
• ✅ TEST: kernel: SmartDefaultSettingsTest expectations should be updated
• ✅ TEST: functional JS for plugin settings
• ✅ TEST: functional JS for using the plugin
• ✅ Upgrade path
• ✅ Additional validation constraints to ensure config always is valid
• ✅ TEST: kernel: new test cases in ValidatorsTest:
  Validator test coverage, which conveys just how precise validation is, which is extra important because as described in #46, the CKEditor 5 Style plugin itself does not do any validation:
  1. INVALID: Style plugin with no styles→ when no styles are configured, having the toolbar item enabled is pointless (this is the only one already passing because it's the only one already implemented)
  2. INVALID: Style plugin configured to add class to unsupported tag→ it does not make sense to allow adding a class to a tag that cannot actually be generated!
  3. INVALID: Style plugin configured to add class that is supported by a disabled plugin→ it does not make sense to allow adding specific classes through a Style that can be supported by enabling a disabled plugin (for example "Alignment")
  4. INVALID: Style plugin configured to add class that is supported by an enabled plugin→ it does not make sense to allow adding specific classes through a Style that are already supported by another plugin (for example "Alignment")
  5. INVALID: Style plugin has multiple styles with same label→ without unique labels, it'd have terrible usability and accessibility
  6. INVALID: Style plugin has styles with invalid elements→ not possible to configure this through the UI, but … it is possible if you modify the configuration directly.
  7. VALID: Style plugin has multiple styles with different labels→ the sole example of a sane configuration, and hence the only not resulting in a validation error

User interface changes

New plugin settings form.

API changes

None.

Data model changes

None.

Problem/Motivation

Currently if you try to go to /batch?id=123 you get redirected to the homepage with a message stating "No active batch".

Beta phase evaluation

Proposed resolution

Since the batch doesn't exist Drupal should just emit a 404 instead.
Display an error message to the user.

Remaining tasks

A usability review since this is adding user facing text.

User interface changes

Error message displayed, "The requested batch ({ID}) could not be found."

Before
Image may be NSFW.
Clik here to view.

After
Image may be NSFW.
Clik here to view.

API changes

If you try to go to /batch?id=123 Drupal emit a 404.

Problem/Motivation

As part of #2884601: Add a Layout Builder to core we want to add a drag-and-drop interface for arranging block layouts spatially.

This should be accessible, but so far it isn't very clear what behaviours we need in order to achieve this. So we need to research approaches for making it accessible. The layout builder is our initial use-case, but we may find others.

Proposed resolution

1. Find some drag-and-drop interfaces, assess them for accessibility. These could be:
   • JS libraries, jquery plugins, web components
   • Web applications in general (even if they are not re-usable components)
   • Drag-and-drop interfaces in desktop applications
   • Drag-and-drop interfaces in mobile applications
   • Accessibility reference material, tutorials, etc.
2. Use the things we learn to define what features (behaviours) an accessible drag-and-drop interface will need.
3. Decide whether it's worth having a re-usable component or library in core, versus building drag-and-drop interfaces on a case-by-case basis.

Approaches which we can review

Drag-and-drop interfaces to assess (code):

• DragonDrop (demo). Reviewed in comment #2 - see Smashing Magazine article below
• jQuery.ui.sortable - has a relevant bug - https://bugs.jqueryui.com/ticket/9633. TODO the range of configuration options and demos need further study.
• Dragula - 5 min review in comment #4, not very accessible. TODO a more thorough review
• hootsuite/grid (demo) - accessibility unknown. Has a pull request for keyboard controls.
• gridstack.js (demo)
• GrapesJs (demo)
• johnny/jquery-sortable (demo).
• dbushell/Nestable (demo).
• Drag and Drop: aria-activedescendant
• Shopify/draggable
• benetech DragAndDrop
• React Beautiful DND Example& React Beautiful DND Code
• The upcoming CSS Spatial Navigation Level 1 specification — being worked on in https://github.com/WICG/spatial-navigation
• W3C's Draft CSS Spatial Navigation Level 1
• Sitepoint Drag & Drop& GitHub Code
• Scalable Accessible Drag and Drop by Bryan Garaventa& Whatsock Drag Template
• Discord's react-dnd-accessible-backend

Reference documentation to review:

• Smashing Magazine: Enter The Dragon (Drop): Accessible List Reordering
• Salesforce UX: 4 Major Patterns for Accessible Drag and Drop
• Grace Noh: Drag and Drop for Design Systems
• W3C ARIA Authoring Practices
• Other docs from the W3C WAI-ARIA suite
• The AccDc training + reference material from whatsock.com
• The article by Bruce Lawson. TODO find link.
• HTML 5.3 Draft
• Screen readers and drag-and-drop, part 1: draggable elements

Analysis method

Comparison points and questions to consider. (TODO: any more?)

• Library dependencies
• License
• Support status and release process
• Is it 1-dimensional (up/down) or 2-dimensional (up/down/left/right)
• By what means are allowed movements or destinations computed? (When, how, ...)
• What are the scope of the accessibility claims for each approach? (e.g. implemented keyboard control, but haven't addressed informing screen reader users of action outcomes)
• Similarly, how do these work in practice?
• What constitutes "grabbed"? When a grab-handle button has focus? Or when a grab-handle button is pressed (toggle to grab/drop)? This point may have a big impact for speech control.

TODO: Analysis results

TBD.

User interface changes

This is a research task, initially to support draggable layout builder in core.

Original mockups for #2995689: Allow reordering blocks without a pointer device:

Image may be NSFW.
Clik here to view.

API changes

This is research, which may eventually lead to a new JS component in core.

Data model changes

Unknown. A new API may have some configuration options.

Problem/Motivation

Even when access is denied to a widget, the value submitted propagates to the entity built from the sum of widgets.

Steps to reproduce

1. Enable at least content translation and content moderation modules and some entity providing module, node is typical.
2. Set Hide non translatable fields on translation forms on the content translation admin form.
3. Create an entity.
4. Now add a nontranslatable field with a non-null default value.
5. Try to add a non-default revision translation of the entity.
6. Kaboom courtesy of EntityUntranslatableFieldsConstraint as the non-null value changes to the default. (error message "Non-translatable fields can only be changed when updating the original language.")

Proposed resolution

Don't let widgets pass their values when access is denied to them.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Original report by pavlosdan

We use *Paragraphs + Content Moderation + Translations*. We have a lot of content that is moderated and translated. We've added a new field in one of the paragraphs that did not need to be translatable (it's a checkbox that should be the same across translations) but we noticed that if a user attempts to edit existing published translated content holding said paragraph type prior to the original having a value for that field then the system throws a "Non translatable fields can only be changed when updating the current revision" error.

So far the only workarounds we could think of was to make the field translatable even though it didn't need to be.

Another possibility would be to remove the constraint as suggested here: https://www.drupal.org/project/drupal/issues/2955321#comment-12541730 but we didn't test this.

Your thoughts on this would be greatly appreciated. :)

When adding a new entity to the system, the ability to log a revision message makes very little sense, and in some cases, e.g. media, the visual prominence is overwhelming and takes attention away from the task at hand.

Image may be NSFW.
Clik here to view.

Proposal from @rlnorthcutt: Let's only show this on content/media/etc. edit instead.

Before / After

Nodes

Before

Image may be NSFW.
Clik here to view.

After

Image may be NSFW.
Clik here to view.

Custom Blocks

Before

Image may be NSFW.
Clik here to view.

After

Image may be NSFW.
Clik here to view.

Media entities

Before

Image may be NSFW.
Clik here to view.

After

Image may be NSFW.
Clik here to view.

Problem/Motivation

There are several tests that have references to Bartik and Seven:

6 core/modules/media_library/tests/src/Functional/MediaLibraryDisplayModeTest.php

These tests should be updated to either use Olivero, Claro, or System module's test_theme so we can deprecate Bartik #3249109: Deprecate Bartik in core once Olivero is the default theme and Seven #3084814: Deprecate Seven theme as mentioned at #3278124: Convert various tests that use bartik/seven to olivero/claro.

Steps to reproduce

git grep -E '(bartik)|(seven)' -- 'core/modules/media_library/tests' | awk -F: '{print $1}' | sort | uniq -c should return no results when this work is complete.

Remaining tasks

Update the tests.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

I don't think we need release notes or a change record.

Problem/Motivation

There are several tests that have references to Bartik and Seven:

         1 core/tests/Drupal/FunctionalTests/Installer/DistributionProfileExistingSettingsTest.php
   1 core/tests/Drupal/FunctionalTests/Installer/DistributionProfileTest.php
   1 core/tests/Drupal/FunctionalTests/Installer/DistributionProfileTranslationQueryTest.php
   1 core/tests/Drupal/FunctionalTests/Installer/DistributionProfileTranslationTest.php
   1 core/tests/Drupal/FunctionalTests/Installer/InstallerTest.php
   2 core/tests/Drupal/FunctionalTests/Installer/MultipleDistributionsProfileTest.php
   1 core/tests/Drupal/FunctionalTests/Installer/StandardInstallerTest.php

These tests should be updated to either use Olivero, Claro, or System module's test_theme so we can deprecate Bartik #3249109: Deprecate Bartik in core once Olivero is the default theme and Seven #3084814: Deprecate Seven theme as mentioned at #3278124: Convert various tests that use bartik/seven to olivero/claro.

Steps to reproduce

git grep -E '(bartik)|(seven)' -- 'core/tests/Drupal/FunctionalTests/Installer' | awk -F: '{print $1}' | sort | uniq -c should return no results when this work is complete.

Remaining tasks

Update the tests.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

I don't think we need release notes or a change record.

Problem/Motivation

There are several tests that have references to Bartik and Seven:

      3 core/modules/taxonomy/tests/src/Functional/Rest/TermResourceTestBase.php
   6 core/modules/taxonomy/tests/src/Functional/ThemeTest.php

These tests should be updated to either use Olivero, Claro, or System module's test_theme so we can deprecate Bartik #3249109: Deprecate Bartik in core once Olivero is the default theme and Seven #3084814: Deprecate Seven theme as mentioned at #3278124: Convert various tests that use bartik/seven to olivero/claro.

Steps to reproduce

git grep -E '(bartik)|(seven)' -- 'core/modules/taxonomy/tests' | awk -F: '{print $1}' | sort | uniq -c should return no results when this work is complete.

Remaining tasks

Update the tests.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

I don't think we need release notes or a change record.

Problem/Motivation

There are several tests that have references to Bartik and Seven:

   2 core/modules/settings_tray/tests/src/FunctionalJavascript/SettingsTrayBlockFormTest.php
   3 core/modules/settings_tray/tests/src/FunctionalJavascript/SettingsTrayTestBase.php

These tests should be updated to either use Olivero, Claro, or System module's test_theme so we can deprecate Bartik #3249109: Deprecate Bartik in core once Olivero is the default theme and Seven #3084814: Deprecate Seven theme as mentioned at #3278124: Convert various tests that use bartik/seven to olivero/claro.

Steps to reproduce

git grep -E '(bartik)|(seven)' -- 'core/modules/settings_tray/tests' | awk -F: '{print $1}' | sort | uniq -c should return no results when this work is complete.

Remaining tasks

Update the tests.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

I don't think we need release notes or a change record.

Problem/Motivation

There are several tests that have references to Bartik and Seven:

      3 core/modules/help_topics/tests/src/Functional/HelpTopicTest.php
   3 core/modules/help_topics/tests/src/Functional/HelpTopicTranslatedTestBase.php
   1 core/modules/help_topics/tests/src/Functional/HelpTopicsSyntaxTest.php

These tests should be updated to either use Olivero, Claro, or System module's test_theme so we can deprecate Bartik #3249109: Deprecate Bartik in core once Olivero is the default theme and Seven #3084814: Deprecate Seven theme as mentioned at #3278124: Convert various tests that use bartik/seven to olivero/claro.

Steps to reproduce

git grep -E '(bartik)|(seven)' -- 'core/modules/help_topics/tests' | awk -F: '{print $1}' | sort | uniq -c should return no results when this work is complete.

Remaining tasks

Update the tests.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

I don't think we need release notes or a change record.

Disable Javascript and try to install HEAD. You will likely get something like this:

Image may be NSFW.
Clik here to view.

Boombatower figured out that you can get to the next step by removing "&op=start&id=1" from the URL. When you do, you'll get the configure site screen where you enter your admin password etc. Move on from there and you're rewarded with the following error:

Fatal error: Class 'DrupalQueue' not found in /home/katherine/public_html/head2/modules/update/update.install on line 13 Call Stack: 0.0040 473844 1. {main}() /home/katherine/public_html/head2/install.php:0 0.0067 738268 2. install_drupal() /home/katherine/public_html/head2/install.php:1735 0.1847 8575064 3. install_run_tasks() /home/katherine/public_html/head2/install.php:87 0.3045 11296528 4. install_run_task() /home/katherine/public_html/head2/install.php:343 0.3045 11296528 5. drupal_build_form() /home/katherine/public_html/head2/install.php:393 0.7572 14071348 6. drupal_process_form() /home/katherine/public_html/head2/includes/form.inc:198 0.7680 14219104 7. form_execute_handlers() /home/katherine/public_html/head2/includes/form.inc:560 0.7681 14219104 8. install_configure_form_submit() /home/katherine/public_html/head2/includes/form.inc:915 0.7738 14222964 9. drupal_install_modules() /home/katherine/public_html/head2/install.php:1695 0.9243 14563116 10. module_enable() /home/katherine/public_html/head2/includes/install.inc:580 0.9243 14563116 11. array_filter() /home/katherine/public_html/head2/includes/module.inc:199 0.9243 14563116 12. _drupal_install_module() /home/katherine/public_html/head2/includes/install.inc:0 0.9389 14772108 13. module_invoke() /home/katherine/public_html/head2/includes/install.inc:600 0.9389 14772108 14. call_user_func_array() /home/katherine/public_html/head2/includes/module.inc:487 0.9389 14772108 15. update_install() /home/katherine/public_html/head2/includes/module.inc:0

We discovered this as a result of trying to make changes to Batch API over at #517688: Initial D7UX admin overlay.

Problem/Motivation

There are several tests that have references to Bartik and Seven:

   7 core/modules/shortcut/tests/src/Functional/ShortcutLinksTest.php
   5 core/modules/shortcut/tests/src/Kernel/ShortcutSevenIntegrationTest.php

These tests should be updated to either use Olivero, Claro, or System module's test_theme so we can deprecate Bartik #3249109: Deprecate Bartik in core once Olivero is the default theme and Seven #3084814: Deprecate Seven theme as mentioned at #3278124: Convert various tests that use bartik/seven to olivero/claro.

Steps to reproduce

git grep -E '(bartik)|(seven)' -- 'core/modules/shortcut/tests' | awk -F: '{print $1}' | sort | uniq -c should return no results when this work is complete.

Remaining tasks

Update the tests.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

I don't think we need release notes or a change record.

In Views on D7 there's code in views_many_to_one_helper as follows:

    while ($r_join->left_table != $base_table) {
      $r_join = views_get_table_join($r_join->left_table, $base_table);
    }

Problems can arise if $r_join is invalid for some reason, e.g. a table becomes invalid or the join definition is incorrect.

In D7 the solution was to just add a check that $r_join was valid.

Must-haves prior to tagging 10.0.0-beta1

We can eventually file child metas for these, but a list is sufficient for now.

1. Fully support PHP versions above the Drupal 10 minimum, including PHP2 when adding support becomes possible.
   • PHP 8.2:
     • #3283358: [META] Make Drupal 9/10 compatible with PHP 8.2
   • Update or decouple/remove PHP (Composer) dependencies.
   • Symfony:
     • [DONE] Resolve Drupal 10 only fixes from #3161889: [META] Symfony 6 compatibility and then do #3252757: Update Drupal 10 to depend on Symfony 6.0 before the beta.
     • #3264918: Update symfony/console to Symfony 6
     • #3275864: [META] Symfony 6.1 compatibility Address any forward-compatibility issues with Symfony 6.1
     • (Issue needed) Update 10.0.x to Symfony 6.1.0-beta1 as soon as it is available.
     • (Issue needed) Update 10.0.x to Symfony 6.1.0-rc1 as soon as it is available.
     • (Issue needed) Update 10.0.x to Symfony 6.1.0 as soon as it is available.
   • PHPUnit:
     • [DONE] Require PHPUnit 9
     • Remove PHPUnit 8 compatibility layers
     • Monitor PHPUnit 10 and add compatibility/upgrade when possible:
       • #3217904: [meta] Support PHPUnit 10 in Drupal 10
       • https://github.com/sebastianbergmann/phpunit/milestone/35
   • [DONE]#3210486: Remove typo3/phar-stream-wrapper and associated code
   • psr/log:
     • #3266017: Update psr/log to v2
     • Add forward-compatibility for psr/log 3 typehints
     • Require psr/log 3 if/when upstream blocker with symfony/console is resolved.
   • Laminas:
     • Remove Laminas feed in #3188549: [Meta] Tasks to deprecate both Aggregator and our dependency on Laminas Feed
   • EasyRDF:#3267267: [Meta] Tasks to deprecate RDF
   • (Other leftover issues from the Drupal 9 cycle to decouple/remove dependencies, etc.?)
2. Composer 2:
   • Remove any code paths that are Composer 1 specific (needs issue)
   • #3215870: Require Composer 2.2 on the CLI for Drupal 10
   • #3253059: Upgrade to composer/installers 2
3. Shift incorrect production dependencies to dev:
   • None at present
4. [DONE] Re-evaluate other backend dependencies in early to mid-2021.
5. Update or decouple/remove frontend dependencies.
   • #3238507: Drupal 10 JavaScript dependency plan
   • CKEditor: Replace CKEditor 4 with CKEditor 5. See #3238333: Roadmap to CKEditor 5 stable in Drupal 9
   • jQuery UI:
     • #3265652: Unfork jQuery UI
     • [DONE] Finish deprecations: #3113400: Deprecate more jQuery UI library definitions
   • jQuery: Monitor jQuery 4 and add compatibility/upgrade when possible. https://github.com/jquery/jquery/milestone/7
   • [DONE] Re-evaluate other frontend dependencies in early to mid-2021.
6. Remove all deprecated code, libraries, and BC layers.
   • #3213858: [META] Remove deprecated modules and themes from the Drupal 10 branch
   • #3213895: [META] Remove deprecated classes, methods, procedural functions and code paths outside of deprecated modules on the Drupal 10 branch
   • [DONE]#3097889: Remove deprecated theme functions
   • #3179048: [meta] Remove dead code/unneeded compatibility layers now that PHP 8.1 is required
7. Ensure that 10.0.0-beta1 ships with logic for warnings about future security coverage EOLs (both for the LTS version of Drupal itself, and for PHP versions, with dates hardcoded as needed). #3223443: [policy, no patch] Process for dealing with EOL PHP versions during the Drupal 10 and future release cycles
8. Resolve critical 9.x -> 9.x upgrade path bugs.
9. [DONE] Remove old upgrade paths up to 9.3.0 #3261486: Remove core updates added prior to 9.3.0 and adjust test coverage and add new database dumps.
10. Resolve any significant outstanding bugs for new requirements (PHP 8.1/8.2, Composer 2, etc.)
    • #3258987: Class "Drupal\Core\Utility\Error" not found in _drupal_error_handler_real() due to bug in PHP 8.1.0-8.1.5 (looks like composer autoloader + apcu + PHP 8.1 + fpm)
    • #3162228: Composer 2 Fatal error Call to undefined method Composer\DependencyResolver\Operation\UpdateOperation::getJobType() in /home/mysite/public_html/core/lib/Drupal/Core/Composer/Composer.php:170 (not exactly D10 only, but a potential blocker for sites when we require Composer 2.2).
    • #3258987: Class "Drupal\Core\Utility\Error" not found in _drupal_error_handler_real() due to bug in PHP 8.1.0-8.1.5
11. Resolve any 10.0.x-only security or data integrity issues.
12. Resolve other D10-only upgrade blockers.
13. Define the Drupal 10 theme API. #2659890: [Plan] Drupal 9 and 10 markup and CSS backwards compatibility
14. Update all dependencies (backend and frontend) to their latest versions immediately before tagging 10.0.0-beta1.

Should-haves prior to tagging 10.0.0-beta1

These become beta targets if they are not completed by the deadline, and may contribute to other adjustments to the schedule (TBD).

1. (Possibly a must-have; TBD) Stabilize Starterkit, ensure a Drupal 10 version of the starter theme is generated, and move Classy and Stable 8 to contrib.
2. Update backend and frontend development dependencies.
3. Clean up outdated code related to the D9 core_version_requirement key, core schema versions, etc.
   • #3077703: Remove pre-8.7.7 core compatibility checks in extension parsing
   • Locate other related issues.
4. Other issues TBD.

Problem/Motivation

PHP has deprecated dollar brace string interpolation in version 8.2 https://wiki.php.net/rfc/deprecate_dollar_brace_string_interpolation

There is a very small usage of the deprecated ${} (dollar-outside) string interpolation method in core, about ~20 instances from a quick search. Most are in NumberFieldTest, and doc blocks.

Proposed resolution

We should update these to use either braces-outside or sprintf interpolation.

Remaining tasks

Update
Tests dont need to be updated

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

None