I think there is a performance problem when views are displayed on every site page and when there is a lot of content (node, term, etc) modification.

The problem appears on the following circumstances :

1. There is (for example) 3 nodes updated every minute
2. There is a view which list nodes on the homepage
3. There is a views which list nodes on a sidebar on every page
4. The page_cache module is enabled

Views will add a "node_list" tag on every views (cf https://git.drupalcode.org/project/drupal/blob/8.7.x/core/modules/views/...).

Pages with view (so every page here) will have the "node_list" tag because tags are bubbled on the entire page.
So every minute all page cache will be invalidated 3 times (after each node update) and it will be like there is no cache at all.

This problem occurs even if the nodes updated are not displayed in these views because the tag "[entity_type]_list" is too generic.

The issue https://www.drupal.org/project/drupal/issues/2145751 introduce a new cache tag per bundle we can use in Views to avoid to invalidate the whole cache site on each node save.

Problem/Motivation

In #3074043: Move simpletest.module DB-related functions to TestDatabase, deprecate we're trying to deprecate top-level simpletest module functions by moving them to Drupal\Core\Test\TestDatabase.

It so happens that we can't test many of our changes, because TestDatabase is mostly static and thus can't be mocked.

Proposed resolution

• Test runners (simpletest.module and run-test.sh) run tests opening TestRun objects that have state and an execution log.
• TestDatabase objects only cares about setting up the SUT database, not the results logging.
• Each TestRun object is associated with a TestRunResultsStorageInterface object, which responsibility is to store permanently the state and execution log of each test run. This interface is storage agnostic, implementations could use a database or anything else.
• SimpletestTestRunResultsStorage is at the moment the only implementation of TestRunResultsStorageInterface, which is using the database and the legacy {simpletest} and {simpletest_test_id} tables for the purpose.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The current implemented placeholder color does not meet the 4.5:1 minimum color contrast specified by WCAG 2.0 AA guideline 1.4.3. as pointed on comment #7.

Image may be NSFW.
Clik here to view.

Proposed resolution

Change the design to convey with WCAG 2.0 AA guideline 1.4.3.

Remaining tasks

• Determine the new design solution
• Accessibility review

User interface changes

All form element styles with placeholders will be changed, no functional differences.

Test Pages

@todo

Problem/Motivation

I want to build a website displaying content in Italian if no path prefix is used and in English if "en" path prefix is used. Following the documentation I configured the "Selected language configuration" to "Italian" and this solution works unitl I try to un-publish a content in English. This is how i configured Drupal on a clean installation (this minimal configuration is tested on https://simplytest.me):

1. Enable content_translation module
2. Add a language in /admin/config/regional/language, in my case Italian
3. In /admin/config/regional/language/detection/selected set Italian as fall-back language
4. In /admin/config/regional/language/detection/url in "Path prefix configuration" set "en" as prefix for "English (en) path prefix (Default language)" and nothing as "Italian (it) path prefix"
5. In /admin/config/regional/content-language enable translation for "article" content type
6. Create a published article in Italian
7. Translate the article in English
8. Set the English version of the article as un-published

As a guest i expect to see the article in Italian but not the one in English.
Instead the article in Italian is visible in the front page but if I try to open the node i get an "access denied" error. The English version is not available as expected.

I'm not sure this is a bug or my configuration is wrong.

I tried setting as prefix for the two languages "en" for English and "it" for Italian. This allows to access the Italian version and blocks the English one as expected. When requesting a resource without prefix is served the English version (when available). I'm not sure this is the expected response.

Proposed resolution

Unknown.

Remaining tasks

Unknown.

User interface changes

Unknown.

API changes

Unknown.

Data model changes

Unknown.

Problem/Motivation

As part of #3094468: [plan] Update core JavaScript (and CSS) dependencies prior to 9.0.0-beta1 we need to update modernizr.

Proposed resolution

Update it

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The block system has but one permission: "Administer blocks", creating an all-or-none situation where granting a user any permission to the subsystem entails giving them god powers there. Especially now that we have custom blocks, I expect people will want more of the flexibility they currently have with nodes to restrict access to different operations by bundle. I know I have for a long time!

Proposed resolution

I propose adding more granular permissions. Update block's permissions as compared to node's:

Marking the above items as 'x' (or deferred to separate issue) because:

• Revisions: there is no revisions ui (#1984588: Add a UI for viewing/reverting custom block revisions)
• Published/unpublished: no status field (#2820848: Make BlockContent entities publishable)
• The ’own’ permissions: no author field (can be handled as separate issue)

Remaining tasks

• Decide if and what permissions to add.
• Write a patch.
• Add tests.
• Review and commit.
• Write a change notice.

User interface changes

TBD.

API changes

TBD.

Undoubtedly, this situation is caused by some combination of contrib (likely Decoupled Auth) or even custom code, but still my question to core is: should it cause a fatal error? Looking at ValidReferenceConstraintValidator later on in the same class it does not assume the existence of $item->entity and instead uses $item->getEntity() (which in my situation, happens to work).

Here's the log of the error, which happens when trying to re-save a user:

Error: Call to a member function isNew() on null in Drupal\Core\Entity\Plugin\Validation\Constraint\ValidReferenceConstraintValidator->validate() (line 74 of /var/www/drupal/web/core/lib/Drupal/Core/Entity/Plugin/Validation/Constraint/ValidReferenceConstraintValidator.php)

(To reproduce, one can install the Find It Program Locator and Event Discovery platform's development environment, but i'm looking for more generic advice on whether Drupal core should be more robust, until i track down the cause of the user entity's username item not having the whole entity on it.

Problem/Motivation

The current UI for Workspaces has various shortcomings, mostly coming from the fact the initial designs were not completely implemented. It also falls short in regards to compatibility between different browsers, both for the desktop and mobile experience.

Proposed resolution

Fix the following problems, identified in various issues:

• #3093032: Workspaces has a confusing UI when opening the link on top of pages - add a "Other workspaces" label on the top left corner, above the links that can be used to switch to a different workspace
• #2988101: Distorted workspace list in Canvas tray and #3090904-25: Workspace drawer CSS fix for better consistency - make the UI look the same across all supported desktop and mobile browsers in Standard, Minimal and Umami
• Always show the "View all workspaces" label and alight it to the right above the workspace tabs in the drawer
• Implement the hover/highlight effect from this screen: https://marvelapp.com/14027i8/screen/17754081
• Change the "Manage workspaces" link shown below the active workspace to "Manage workspace" and direct it to the workspace edit form for now, until we create a dedicated screen for this action

Remaining tasks

Review.

User interface changes

Desktop

Before
Image may be NSFW.
Clik here to view.

After
Image may be NSFW.
Clik here to view.

After RTL
Image may be NSFW.
Clik here to view.

Mobile

Before
Image may be NSFW.
Clik here to view.

After
Image may be NSFW.
Clik here to view.

API changes

Nope.

Data model changes

Nope.

Release notes snippet

Nope.

Problem/Motivation

Drupal 9 will come with a new version of Stable. Initially, the plan was to replace the old Stable with a new Stable theme, which essentially would force all themes to upgrade to the next Stable theme as part of the major version upgrade. Upgrading Stable can be cumbersome. Given that upgrading to the next Stable theme comes with very little benefits, it seems unlikely that themes would be interested in upgrading unless they are forced to do so.

Proposed resolution

1. Make base theme a require property in themes: #3065545: Deprecate base theme fallback to Stable
2. Copy current Stable to contrib project so that it can be used with Drupal 9. There's already a namespace reserved for this.
3. Create a new Stable theme with a new name for Drupal 9, following almost the same steps used to create Drupal 8 Stable in #2575737: Copy templates, CSS, and related assets to Stable and override core libraries' CSS
   1. Automated test for library overrides to ensure completeness
   2. Automated test for template overrides to ensure completeness
   3. Copy all the CSS, changing image paths as necessary
   4. Copy all the images, no changes No benefit to this step, they'll get copied when it becomes contrib, though.
   5. Add all the libraries-override needed to stable's .info.yml
   6. Copy all the templates, with appropriate doc changes
4. Deprecate the Drupal 8 Stable theme in Drupal 9 to be removed in Drupal 10.

Remaining tasks

• Agree on maintainers of the contrib project
• Copy code from Stable to the new project
• Decide what happens to Classy which depends on Drupal 8 Stable
• Agree on a name for the Drupal 9 Stable: #3094440: [policy, no patch] Agree on name for Drupal 9's Stable theme
• Create the Drupal 9 Stable theme and copy all the templates and assets to the new theme
• Write change record
• Deprecate Drupal 8 Stable (needs follow-up)

User interface changes

API changes

Data model changes

Release notes snippet

This proposed policy comes from a discussion in #3050374: Create Drupal 9 stable theme

In Drupal 8 the stable theme includes copies of all image assets from modules and core/misc. In the process of creating the Stable 9 theme, @lauriii and @bnjmnm wondered if this copying of images is necessary or helpful as multiple copies of the same image is confusing for developers and adds to Drupal's download size. Plus, in the case of Drupal 9, this would result in three copies of the same image assets, the originals, copies for the deprecated Stable (8), and copies for Stable 9. Sincere attempts were made to track down the rationale for copying all images, but nothing more detailed than #2575737: Copy templates, CSS, and related assets to Stable and override core libraries' CSS could be found, which approached the image copying as a given.

The proposed solution is:

• Do not add copies of image assets to Stable 9 or future versions of stable
• When a Stable theme is moved to contrib, the images should be copied to the theme
• In the event that an image in misc or modules is changed, the original version of that image should be added to Stable to ensure backwards compatibility. Based on a git history review this occurs infrequently at most, but needs to remain an option.

With this solution we hope to reduce the overhead of multiple copies of identical files, while still preserving backwards compatibility. This will inform how the Stable 9 theme is created.

Problem/Motivation

As mentioned in #3050389: Remove dependency to Classy from core themes, Classy will be moved to contrib before Drupal 9 and we have to remove dependencies on Classy from all core themes. Part of removing these dependencies includes providing each theme their own copies of templates that previously belonged to Classy.

There's considerable potential for error when copying ~100 templates to four different themes, so we need a test that removes some of the uncertainty from the process.

Proposed resolution

Create a test that confirms that themes do not inherit templates from Classy, and that none of the templates they use include/extend Classy templates or attach Classy libraries.

The test will include a per-theme ignore-list of templates that do not need to be included as part of the test. At first, the ignore-lists will be very large, and will shrink with each template-copying issue filed. When a new template-copying issue is filed (for example, copy aggregator templates to Bartik), the first patch will be this test, but with aggregator's templates removed from Bartik's ignore list. This way, the test won't pass until the templates are properly copied.

Every Classy-inheriting core theme currently extends, includes or attaches something from Classy, so these tests will not pass at first.

Remaining tasks

Write the test, configured it to ignore templates that still need to be copied.

Create issues to address existing attach_library() calls to Classy libraries in Bartik/Seven/Claro/Umami, as these will cause the test created here to fail.

• Umami calls {{ attach_library('classy/node') }} in node--article--full.html.twig, node--card--common.html.twig, node--card.html.twig, node.html.twig
• Bartik calls {{ attach_library('classy/node') }} in node.html.twig
• Claro calls {{ attach_library('classy/file') }} in file-link.html.twig
• Seven calls {{ attach_library('classy/image-widget') }}in image-widget.html.twig

These library-copying followup issues can't be created until #3096203: Create Classy library dependency tests that can be used for all themes, and verify by providing an Umami-specific classy/dropbutton is complete.

The Classy template include/require's should be addressed in the scope of this issue as this is where the test exists to verify they were done properly. This needs to be addressed with the following:

• Bartik {% extends ""@classy/block/block--search-form-block.html.twig"" %} in block--search-form-block.html.twig
• Bartik {% extends "@classy/block/block--system-menu-block.html.twig" %} in block--system-menu-block.html.twig
• Bartik {% extends "@classy/content/page-title.html.twig" %} in page-title.html.twig
• Bartik {% extends "@classy/misc/status-messages.html.twig" %} in status-messages.html.twig
• Seven {% include '@classy/content-edit/image-widget.html.twig' %} in image-widget.html.twig
• Claro {% extends '@classy/form/form-element-label.html.twig' %} in form-element-label.html.twig

The template copying can't happen until #3095713: Create classy directory with README, in the templates and css directories for all themes subtheming Classy is complete

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Release notes snippet

n/a

Problem/Motivation

We already decided in [another issue which I can't find right now] that 8.8.x is the last place where we'll deprecate code for removal in Drupal 9.

This means that new deprecations in 8.9.x will be removed in Drupal 10, but this raises some issues. We want modules to remove 8.x deprecations asap, and particularly in the next ~8 months in the run up to the 9.0.0 release, Drupal 10 deprecations on top of this mean extra work to get a module passing against 8.9.x/9.0.x that isn't necessary right now.

Proposed resolution

There are a handful of option each with their own drawbacks:

1. Add new deprecations in 8.9.x and 9.0.x to be removed in 10.0.0 and don't change anything else. Modules using this deprecated code will see warnings about them in test runs, phpstan reports, IDEs same as they would for deprecation messages.

Pros:
- no changes to our deprecation policy (except the version)
- Enforces that Drupal core will remove usages
- contrib doesn't start building up Drupal 9 technical debt before it's even released

Cons:
- noise for people who are just trying to do the minimum to get their modules compatible with 9.0.x
- modules that update for these deprecations won't be compatible with 8.8.x

2. Same as #1 except additionally suppress all 10.0.x deprecation messages in test runs

Pros:
- No changes in the deprecation code
- Contrib can pass against 8.9.x (and 9.0.x if we make the same change there) without fixing these deprecations

Cons:
- core test runs won't flag usages of suppressed deprecations
- deprecations will still show up in automated tools (phpstan might be adjustable to ignore them) and IDES (probably not adjustable).

3. Add the deprecations to 9.0.x as normal, but don't actually deprecate anything in 8.9.x - while adding the new code anyway.

Pros:
- Modules will be able to get clean runs of everything against 8.9.x without addressing these at all, but the new APIs will be available.

Cons:

- still warnings on 9.0.x
- potentially confusing for new developers since there will be duplicated APIs without a clear indication of which to use
- Requires two versions of patches.

4. Don't commit the patches to 8.9.x at all, leave them in 9.0.x

Pros:
- easy for modules to update to 8.9.x

Cons:
- Modules that update against 9.0.x will introduce incompatibilities with 8.9.x quicker
- divergence between 9.0.x and 8.9.x

5. Don't commit the patches to either 8.9.x or 9.0.x, hold them until 9.1.x

Pros:
- no noise or tooling changes

Cons:
- some critical or major bugs (or Drupal 9 readiness issues) will require new deprecations, what about them?
- accumulation of technical debt and RTBC/postponed issues.

6. Add the new code to 8.9.x and 9.0.x, without deprecating the old code. Post follow-ups to deprecate in 9.1.x

Pros:
- Modules will be able to get clean runs of everything against 8.9.x and 9.0.x without addressing these at all, but the new APIs will be available.

Cons:
- potentially confusing for new developers since there will be duplicated APIs without a clear indication of which to use
- Requires follow-up issues and patches against 9.1.x

7. Add the new code to 8.9.x and 9.0.x, without deprecating the old code. Deprecate immediately in 9.1.x

Pros: all the best bits of the above

Cons: more core branches to maintain than ever before in the history of Drupal

Remaining tasks

Pick one.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Opening the Drupal 9 branch allows a few things to happen.

1. We can upgrade Drupal's PHP requirements to require Symfony 4 or higher (and Twig etc.)
2. Contrib modules can test against the Drupal 9 branch to ensure they still work
3. We can begin removing deprecated code, and backwards compatibility layers

In order for the Drupal 9 branch to be useful, we need to be able to do the below things soon after the branch is opened.

Proposed resolution

The 9.0.x branch opened alongside 8.9.x according to the normal release schedule.

Must-haves prior to tagging Drupal 9.0.0-alpha1

1. DONE: Contrib modules must be able to test against Drupal 9 without having to make an entire new code branch. #2807145: [policy, no patch] Allow contrib projects to specify multiple major core branches and #2313917: Core version key in module's .info.yml doesn't respect core semantic versioning enable this
2. DONE: Make 9.0.x installable without depending on the core compatibility constant and resolve any other test failures: #3087874: [meta] Make 9.0.x branch pass testbot
3. DONE: #3079791: Bump Drupal's minimum PHP version to 7.2 as soon as 9.0.x is branched (a higher version may be required later)
4. Update Drupal's major PHP dependencies:
   1. DONE: #3088369: Update Drupal 9 to Symfony 4.4-dev
   2. DONE: #3094007: Update the 9.0.x branch to Symfony 4.4-beta2
   3. DONE: #3088754: Update to Drupal 9 to Symfony 4.4.0
   4. DONE: #3041076: Update Drupal 9 to Twig 2
   5. DONE: #3094146: Update Drupal 8 to the latest stable/compatibe Symfony 3.x versions
5. Remove deprecated dependencies:
   • DONE: #3087685: Remove deprecated jQuery UI components and fork remaining source code into core
   • DONE: #3067216: [meta] Deprecate (in 8.8) and remove (in 9.0) polyfills that are no longer needed
6. DONE: #3016471: Make localization file download major version agnostic
7. #3074993: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates

Once these issues are resolved, a Drupal 9 branch becomes useful, because it allows for contrib testing of the upgrade path and updated dependencies. The release notes for the alphas will specify that deprecated code has not yet been removed entirely and that any use of deprecated code by contrib/sites will be incompatible by beta1.

Requirements for beta1 are at #3079680: [META] Requirements for tagging Drupal 9.0.0-beta1.

Should-haves

• DONE: #3094007: Update the 9.0.x branch to Symfony 4.4-beta2
• ANNOUNCED: #3088246: [policy, no patch] How to handle Drupal 8.9.x deprecations (Announcement at https://groups.drupal.org/node/535670)
• DONE: #3091418: Update composer dependencies on 9.0.x
• #3099876: Establish a packaging pipeline queue
• DONE: #3104265: Update Composer dependencies on Doctrine components in 9.0.x
• #3106075: Bump minimum PHP for Drupal 9 to PHP 7.3

Remaining tasks

User interface changes

API changes

Data model changes

In a test version of 8.8.1, when attempting to add multiple media items (see attached file), if you add more than one file, the second file gets "attached" to the first media item you added. So, instead of having two media items, you now have one media item and that media item contains two images.

Then, if you go to ckeditor and embed the the two media items, it contains both images. And if you later browse the media library only the first of the two images within that media item is shown ... the second is sort of "hidden" behind it I think.

I don't know whether to classify this as a bug, or a feature request, or a support request. Perhaps it could even be covered in the documentation ... though somehow the input screen should give the user a better indication of what's happening: "one media item with n image files will be created".

I can see where it would be, in some cases, a cool capability to include several images in a single media items. But intuitively that's not what I'd expect from looking at the add media item screen or reading the documentation.

Problem/Motivation

Classy will be moved to contrib during Drupal 9. In preparation to that, we have to remove dependencies on Classy from all core themes.

Proposed resolution

Use this spreadsheet of Core Theme's use of Classy as reference

Create theme-specific versions of all libraries that are not already overridden by the theme.

Copy all remaining Templates and CSS that are not already overridden by the theme and remove dependency to Classy. Some templates in Classy are identical to Stable and can be removed instead of copied. This is covered by #3098150: Add test coverage to ensure Classy templates that have identical versions in Stable are kept in sync

Theme specific parent issues:
Claro: #3084810: Decouple Claro from Classy
Umami: #3096014: [META] Make Umami theme non-dependent on Classy

Remaining tasks

• Determine directory structure for copied templates: #3095713: Create classy directory with README, in the templates and css directories for all themes subtheming Classy
• Create test process for copying libraries: #3096203: Create Classy library dependency tests that can be used for all themes, and verify by providing an Umami-specific classy/dropbutton
• Create test process for copying templates: #3096349: [PP-?] Create test for confirming Themes do not depend on Classy templates (currently blocked on #3106600: Decouple Classy libraries from Umami and other yet-to-be-created issues for decoupling Classy libraries from themes)
• Remove Classy templates with identical copies in Stable: #3098150: Add test coverage to ensure Classy templates that have identical versions in Stable are kept in sync

Once the test procedure and directory naming is settled, create multiple issues for moving templates/libraries to themes. Consider grouping similar templates in an issue to reduce the total number of issues, but the scope should remain reasonable for each.

User interface changes

API changes

Data model changes

Release notes snippet

If you use the Drupal's admin in another language than the default language when enabling module or adding field or making any new translatable config, you risk having different langcode in your exported configuration. Most of the time you don't want that.

I think we can help the user to avoid that. A simple warning?

Or perhaps in the installer we can be clearer about what is the default language, and give an option to force configuration always to be saved first in the default language.

Another way would be to lock the language in administration by default in the default language and warn the user of potential side effect if he wants to change this setting.

For the end user is sometimes hard differentiate between configuration and content.

Peoples that did that by mistake:
https://wunder.io/blog/drupal-8-translations-best-practices
https://drupal.stackexchange.com/questions/223665/how-to-change-default-...

Problem/Motivation

Following alpha releases of Drupal 9 (see #2608062: [META] Requirements for tagging Drupal 9.0.0-alpha1), we have some criteria for when beta releases would be tagged. Postponed on #2608062: [META] Requirements for tagging Drupal 9.0.0-alpha1.

Proposed resolution / Must-haves prior to tagging Drupal 9.0.0-beta1

8.9.x and 9.0.x will enter beta at the same time and will have the same beta stability requirements as a normal minor release. Additionally:

1. There must be no outstanding issues to update PHP and JavaScript dependencies (i.e. they should be on the latest release of the latest branch we intend to ship with). Also unused dependencies should be removed prior to beta. See #3009213: [META] Update / reconsider dependencies for Drupal 9.
    
2. All deprecated code usages and backwards compatibility layers must be removed and deprecations properly documented - we can't remove deprecated code that is called by Drupal core. (see the @deprecated tag). This includes deprecated JavaScript libraries etc.
   See:
   • #2716163: [META] Remove deprecated classes, methods, procedural functions and code paths outside of deprecated modules on the Drupal 9 branch
   • #3007329: [META] Drupal 8 core must not use any deprecated code, must be enforced by automated testing

    

3. Any critical Drupal 8 upgrade path bugsmust be resolved in 8.x so that sites are not stranded on pre-8.9.x versions due to known core bugs.
    
4. Also in 9.0.x, updates from versions prior to Drupal 8.8.x must be removed and hook_update_last_removed() implementations added: #3087644: Remove Drupal 8 updates up to and including 88** This is to minimise the surface area for 8-9 upgrade path bugs. We must also have test coverage for updates added after 8.8.0 which does not depend on pre-8.8 database dumps: #3089900: Drupal 8.8/8.9/9.0 update test coverage.
    
5. Any known 9.0.x-only security or data integrity criticals must be resolved.
    

Should-haves

These issues are not hard blockers to releasing Drupal 9, but there would be significant negative consequences of them not being completed in time for Drupal 9's release. Outstanding should-haves may cause 9.0.0 to be deferred from the June release window to the August window.

1. Any critical API changes, API additions, or data model changes should be completed, as these changes will no longer be allowed during the beta.
    

2. All Drupal 6 and Drupal 7 -> Drupal 8/9 core content migrations should be stable. In practice this mostly means multilingual migrations #2208401: [META] Stabilise Migrate Drupal Multilingual module . If we don't do this, we can't expect people to migrate from Drupal 6 and Drupal 7.

There may be minor configuration translation migrations or contrib -> core migrations still outstanding which would be great to clean up but should not actually block release.
 

3. We should have adopted a policy for PHP 7.x version support, as this needs to be announced as far as possible before the LTS and 9.0.0 release so hosts have time to upgrade. #2917655: [policy] Decide on PHP 7.x support status. Currently working on requiring PHP 7.3 at #3106075: Bump minimum PHP for Drupal 9 to PHP 7.3.
    
4. We should have a policy for MySQL and PostgreSQL version support (needs issue, but see #2846994: Increase minimum version requirement for Postgres to 9.5.x).
    
5. We should provide accurate update recommendations (9.0, not a non-existent minor version of Drupal 8) on the Status Report (/admin/reports/status). #2991207: Drupal core should inform the user of the security coverage for the site's installed minor version including final 8.x LTS releases.
    
6. We should have a proper policy for CSS and markup changes, see #2659890: [Plan] Drupal 9 markup and CSS backwards compatibility.
    

7. Drupal.org should be able to fully handle contributed projects that are compatible with both 8.x and 9.x and not assume core compatibility based on version/branch name:
   #3054433: Support multiple core branch functionality for contributed projects

   This spans multiple projects and areas such as project listing, composer façade, update.xml from drupal.org and localization files.

Problem/Motivation

As stated in #3050389: Remove dependency to Classy from core themes, Classy will be moved to contrib before Drupal 9 and we have to remove dependencies on Classy from all core themes.

Part of this process includes creating theme-specific copies of all Classy libraries to core themes. This ensures Classy can be removed without impacting those themes.

Proposed resolution

- As needed ,copy libraries and assets from Classy to Umami.
- Create new libraries for every copied library, named with the convention "classy.
".
- Override the Classy libraries so they are not loaded by Umami.
- Any Classy libraries-extend: should now be taken care of in Umami.
The end result is no Classy library assets should load, and Umami experience should be unchanged.

Also: add tests that check to see if any of the copied assets from Classy have changed. If they've changed, there should be a failure that provides instructions on moving the altered file out of the /classy subdirectory.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

My testing issue to mess with the bot while not polluting the issue queue.

Problem/Motivation

Drupal requirements list the following MySQL/MariaDB/Percona requirements currently:

Required MySQL 5.5.3/MariaDB 5.5.20/Percona Server 5.5.8 or higher with InnoDB as the primary storage engine, and requires the PDO database extension. MySQL 8 is supported only on Drupal 8.6 or higher.

Decide on Drupal 9 requirements changes if any.

Proposed resolution

TBD.

Remaining tasks

Discuss.

User interface changes

None.

API changes

TBD.

Data model changes

TBD.

Release notes snippet

TBD.