I'm not sure which component this relates to, so I just put other. Someone please feel free to update if you know the offending component.

For the sake of a simple example, lets say we have a view 'people/owners/%' with default title "Profile" and a Contextual Filter on field "last_name". The Contextual Filter has configuration "Override Title" checked with override value of "{{ title }}". The view is configured so that going to "/people/owners" returns 404, for no results. So, the default "Profile" title should always be overriden, as the view only works when a valid last_name is provided. When we go to /people/owners/johnson, the title is accurately overridden to say "Jeffrey Johnson" on the page. However, the breadcrumb shows "People / Owners / Profile" instead of "People / Owners / Jeffrey Johnson". I've tried changing the Default title from "Profile" to "{{ title }}", but this doesn't work, as I don't believe that field accepts twig input.

I've checked configurations on the Breadcrumb block, as well as the breadcrumb settings in bootstrap sub-theme's COMPONENT >> BREADCRUMBS sections, and don't see anything pertaining to title overrides.

I've searched for similar issues, but haven't found any. If this is a duplicate, I apologize, I must have missed something and would greatly appreciate someone pointing me in the right direction. Or, if this sounds like it's not a core issue, but rather a theme issue, just let me know and we can close this and I'll open a new issue on Bootstrap theme.

Problem/Motivation

Migration is very slow when there are lots of rows in the message table. I saw this with file migration (~500K files). I tracked it down to slow queries involving WHERE clause on the table message.

I spent a lot of time to debug this, it's not easy the migration begin with correct ratio and slown down after 1 hour...

At the first of migration i have a ration of import ~ 100 files/s and after ~70K ration slown down to 15 files/s.

You can reproduce this scenario with a migration that write lot of row to message table, in my case i have a lot of message like date not valid or file don't exist. (The source data was not correctly valid.)

Exemple query :

DELETE FROM migrate_message_json_images
WHERE source_ids_hash = 'a03cf05d5026350fa2fd9650fd78d3879aad366235eee7df9af35e268957c90e';

Time Migration without patch : 13 hours.
Time Migration with patch : 1,5 hour.

This is possibly related to #2688297: File migration slows down and eats more and more memory.

Proposed resolution

Add indexes to migrate_message_* table on column source_ids_hash.

Data model changes

No changes to data model but indexe are added. Since this is not done at install, there shouldn't be much of a change.

Problem/Motivation

$this->renderer->addCacheableDependency($form, $field_definition->getConfig($entity->bundle())); is called from CommentForm. Because bundle entity fields (defined via code) are not config backed (or currently in 8.8 support overrides), this leads to throwing \Exception('Field definitions do not currently have an override config entity.')

Proposed resolution

instanceof check the field definition.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

See #3110954: Paragraphs field translatability checked by default when reusing fields.

I think this is a bug/inconsistency in Field UI.

New fields added in the UI default to not-translatable, per #2143291: Clarify handling of field translatability that is done so explicitly, with a comment.

However, when re-using an existing storage then that line is missing and those fields are then translatable by default.

This is especially awkward when translation is not enabled for a bundle, as then the checkbox is disabled and it can't be changed.

This was last touched by #1963340: Change field UI so that adding a field is a separate task, didn't check if that introduced this problem or just moved things around.

This has been like this for a long time, but I think this is a bug that we should fix.

Proposed resolution

Also set translatable => FALSE when creating a field for an existing field storage.

Remaining tasks

Tests

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Tests were added to D8 for the new RequestSanitizer in #2969053: Add unit tests for SA002 and SA004

However, D7 has no test coverage for its version of this code.

This makes touching the RequestSanitizer code somewhat risky - see e.g. #3084935: element_children() and DrupalRequestSanitizer::stripDangerousValues() should not use integer keys as array

Proposed resolution

Not sure if we can do a fairly straight backport of the D8 tests, but that would be ideal.

Remaining tasks

Backport test coverage, or implement our own for D7 if necessary.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A?

Problem/Motivation

The current situation is the all contrib database driver directories must be copied to the directory DRUPAL_ROOT/drivers. This must be done because it is the only location that Drupal core looks in for contrib drivers.
The Drupal project is switching to the use of the composer tool and copying driver directories is very bad for the workflow with composer.

The current workflow with contrib database drivers is as follows

There are 2 kinds of contrib database drivers:
- the first has only a driver directory. Lets call them type A;
- the second one has a driver directory and a module part. Lets call those type B.

I am working on creating a fallback driver for PostgreSQL and lets take that as an example. At the moment it only has a driver directory and therefor its a type A. When the by core supported driver for PostgreSQL starts using the pg_trgm extension, the contrib driver will need to undo that and therefor needs a module part and becomes a contrib driver of type B.

The workflow of installing a contrib database driver

Installing the contrib driver is as follows:
1. Download/require the contrib driver;
2. Copy the contents of the "drivers" directory from the module to the root of the Drupal project/installation.
3. If the contrib driver has a module part, the module must be enabled.

I am not sure when working with composer if this can be automated from the contrib driver or does the site builder/owner has to use scaffolding in their composer.json to copy the "drivers" directory them self.

The workflow of updating a contrib database driver

Updating the contrib driver is as follows:
1. Downloading the updated contrib driver;
2. Copy the contents of the "drivers" directory from the module to the root of the Drupal project/installation and replacing the existing one.
3. Running the site updates script.

Site builders/owner are not used to coping files after they have run the command composer update. If they forget they will still be working with the old version of the driver directory. If they have a type B contrib driver they will be using 2 different versions. One for the driver directory and one for the module part of the contrib driver. If a site builder/owner runs the update script before copying the update to the "drivers" directory, a lot can go wrong.

The workflow of moving from using a contrib driver to using a by core supported driver

Moving to using the by core supported driver (with the current patch):
1. Running the update process that will be provided by the contrib driver (creating the pg_trgm indexes);
2. Deleting the contents of the "drivers" directory in the root of the Drupal project/installation;
3. Disabling the contrib module (if type B).

Testing the transition is for a site builder/owner not very easy to do.
If somebody wants to know if a site is using a contrib driver, the only way to check for that is looking if the "drivers" directory in the root of the Drupal project/installation is used or not. The driver setting in the settings.php will be the same for contrib and the by core supported drivers.

Moving to using the by core supported driver (without the current patch):
1. Running the update process that will be provided by the contrib driver (creating the pg_trgm indexes);
2. Change the driver setting from "pgsql-fallback" to "pgsql" in the settings.php file.

Proposed resolution

The basic solution as it was proposed by @alexpott is as follows:
- Make every contrib database driver a module;
- Within that module have default location where the driver directory must be. a.k.a. that is where Drupal core will look for it. The suggested default location would be src/Driver. It can be because we are looking for the existence of the file src/Driver/Install/Tasks.php

Remaining tasks

(reviews needed, tests to be written or run, documentation to be written, etc.)

User interface changes

None

API changes

(API changes/additions that would affect module, install profile, and theme developers, including examples of before/after code if appropriate.)

Data model changes

None

Release notes snippet

Updated: Comment #6

Problem/Motivation

SQLite has a variable limit of 999 which is not configurable and which makes this database driver unusable for medium sized sites.
See #2028713: Menu router does "too many SQL variables" on SQLite resulting in silent nondisplay of menu items but this can bite us in any other place too.

A first patch that set PDO::ATTR_EMULATE_PREPARES on the connection (proposed by Damien Tournoud) did not work out probably due to a bug in the underlying driver. This can be reproduced as outlined in #2028713-18: Menu router does "too many SQL variables" on SQLite resulting in silent nondisplay of menu items:

php > $options = array(
php (   PDO::ATTR_EMULATE_PREPARES => true,
php (   PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
php ( );
php > $dbh=new PDO('sqlite:dummy.sqlite', NULL, NULL, $options);
php > $dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES, true); // Give it another try.
php > $values = range(1,1111);
php > $placeholders = implode(',', array_fill_keys(array_keys($values), '?'));
php > $query = "select v from (select 0 v) where v not in ($placeholders);";
php > $stmt = $dbh->prepare($query);
PHP Warning:  Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 1 too many SQL variables' in php shell code:1

Proposed resolution

PDO::ATTR_EMULATE_PREPARES tells the driver to not use prepared statements and instead fill in all placeholder values themself.
As the driver seems not to support this, we do it ourself in userland. The driver already contains code that does this for numeric values (to workaround some other problem) and we can simply extend that code.

Related Issues

Original report by @axel.rutz

SQLite performance Optimization: PDO::ATTR_EMULATE_PREPARES

Like we've done on Mysql and Postgres we should also do on Sqlite.
See #827554: PostgreSQL performance Optimization: PDO::ATTR_EMULATE_PREPARES.

(As suggested by Damien Tournoud in #2028713-11: Menu router does "too many SQL variables" on SQLite resulting in silent nondisplay of menu items)

Tests for this issue

The patch from comment #54 should be used to test if any fix will solve the problem from this issue.

Workaround

If you are experiencing this problem there is a workaround. You can recompile SQLite with an increased value for SQLITE_MAX_VARIABLE_NUMBER. The default setting for this value is 999. Versions of SQLite that are compiled for ac OSX have the default value set to 500000 for SQLITE_MAX_VARIABLE_NUMBER. Ubuntu has compiled SQLite with a default value of 250000 for SQLITE_MAX_VARIABLE_NUMBER.

After upgrading to 8.8 i keep getting errors related to path_alias

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal.path_alias' doesn't exist: SELECT 1 AS expression FROM {path_alias} base_table WHERE (base_table.status = :db_condition_placeholder_0) AND (base_table.path LIKE :db_condition_placeholder_1 ESCAPE '\\') LIMIT 1 OFFSET 0; Array ( [:db_condition_placeholder_0] => 1 [:db_condition_placeholder_1] => /node% ) in Drupal\Core\Path\AliasRepository->pathHasMatchingAlias() (line 111 of core/lib/Drupal/Core/Path/AliasRepository.php).

I'm running pathauto 1.6 so that should be ok according to the release notes.

Am I missing anything?
---
Others are getting errors when attempting database updates;
[error] Update aborted by: system_update_8803
[error] Update aborted by: system_update_8804

Problem/Motivation

The migrate initiative succeeded in stabilizing Drupal 6 and Drupal 7 to Drupal 8. The last remaining parts were finalized in #2966856: Hide and disable Drupal Migrate Multilingual. It "officially" started in October 10, 2013 at BADCamp per https://groups.drupal.org/imp?page=4. In the 6+ years of its life, the initiative went through several maintainers and many hundreds of contributors and 2050 issues.

Here is a full list of contributors:
TBD

Proposed resolution

Remove from drupal.org as an active initiative.

Remaining tasks

Do it.

User interface changes

None.

API changes

None.

Data model changes

None.

OK so I bumped into a real strange bug with Drupal views today. I was debugging a view which had the machine name deals__page (note the double underscore), which wasn't working with AJAX exposed filters.

Anyway, so turns out I can replicate that having a machine name with double underscores eg. page__1 breaks AJAX on a view when using exposed filters.

Steps to replicate on a clean Drupal 8.8.1 install:

1. Create a new view with a page display.
2. Add an exposed filter.
3. Ensure the "Use AJAX" setting is set to "Yes".
4. By default the machine name will be "page_1", leave it like this for now.

Load the page and confirm the exposed filter works correctly and uses AJAX to update the exposed filter results.

Now change the machine name to "page__1" with a double underscore, clear caches and reload the form. For some reason AJAX is now disabled on the form when using the exposed filters.

Clearly there is a very easy workaround in the meantime, just don't use a machine name with double underscores. But this should still work with any valid machine name in my opinion.

Problem/Motivation

When adding sub-forums (taxonomy terms), the forum list cache entries are not invalidated which causes stale content to be visible on the page.

Proposed resolution

Add taxonomy term list cache tag.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Modules that have gone through a lot of changes can accumulate a lot of update hooks and post update hooks over time. This can result in the module.install and module.post_update.php files becoming quite lengthy. After a certain amount of time it may be considered acceptable to remove some of those legacy update hooks (e.g. during major version updates)

There is already a mechanism in core to deal with hook_update_N() functions: hook_update_last_removed().

However, there does not seem to be a corresponding function for hook_post_update_NAME() functions, and I don't seem to see any issues suggesting one in the issue queue.

What this means is you either can't ever delete these post update hooks, or you risk people adding in a post_update hook with the same name that was used previously (which could cause inconsistencies between people who had triggered that old post_update hook before and those who had not).

Proposed resolution

I propose creating a hook_removed_post_updates() function that could be added to a module.post_updates.php file, implemented like this:

function mymodule_removed_post_updates() {
  return [
     'mymodule_post_update_one_i_removed' => '8.x-3.0',
  ];
}

Remaining tasks

• Needs maintainer feedback
• Publish the change record

User interface changes

If an unexecuted removed post update is found, a requirements error will be shown on update.php preventing updates from being run.

In rare cases, a module will have removed post updates from two different releases (while also not having removed any hook_update_N(), in this case we show a different message with multiple versions. A follow-up has been opened to resolve this down to the lowest version, taking into account contrib semver etc.

API changes

New hook hook_removed_post_updates()

Data model changes

None

Release notes snippet

Added hook_removed_post_updates() for module maintainers to indicate when old post updates have been removed.

Problem/Motivation

To support the model of deployable configuration, views configuration with filters on taxonomy terms (or any entity reference field for that matter) should use the uuid of the entity chosen.

For example, creating a view which has a filter on a term from a node field should export to configuration with uuid filter values rather than term ids.

Proposed resolution

Add a checkbox to the filter configuration form to allow users to use the uuid of the term as the filter value rather than the tid.

As a stop-gap until this is implemented in core, I implemented it as a custom filter which extends the current taxonomy term id filter. This may help in determining which parts of the code need to be touched when implementing https://gist.github.com/acbramley/1127c4698a9ae86885e03716f47e3281

Problem/Motivation

#2550717: [JS] Replace jQuery.cookie with JS-cookie and provide a BC layer switches us from jquery.cookie to js.cookie 2.

js.cookie 3.0.0-rc.0 was just released, so we should look into upgrading to that version once it is stable.
https://github.com/js-cookie/js-cookie/releases

Need to evaluate whether there are breaking API changes that would force us to wait unto Drupal 10 or not.

Major Changes

Summary: The recommended and safe way of using setting and getting cookies should remain the same across v2 and v3. The way that an implementation would override default behaviors has changed.

• 3.0.0-beta.0
  • getJSON and JSON handling is changed. The change record for js-cookie has been updated with examples of how to do this.
  • Setting the path is exposed in js-cookie API. This doesn't really affect us, but may make the shim easier to implement.
  • Which characters that are encoded/decoded have changed. This may affect the return output from using Cookies directly rather than the shim, which already uses a converter to be backwards-compatible with jquery.cookie.
• 3.0.0-beta.1
  • Changes how we can override the Cookies object. The jquery.cookie shim hides this implementation, but people using Cookies directly and wanting to override defaults will need to use the withAttributes factory method.
  • Also, changing the options on an instantiation of Cookies is no longer possible. This mainly would affect the tests. We could mitigate risk by recommending creating new instances of the api.
  • Converters will always need to take an object. Currently the shim does pass a function rather than an object with a read property, but that could easily be changed without affecting backwards-compatibility. We can mitigate risk by recommending that users not use the deprecated functionality in js-cookie v2 when using withConverter.
  • Also, converters should call the default converter within their functions rather than relying on the internal mechanism to call it as that has been removed. Further comparison of how this works between v2 and v3 needs to be done.
  • Creating an instance overriding both defaults and using converters would be a breaking change for implementations, but not for anyone using the jquery.cookie shim.

Proposed resolution

Remaining tasks

Review any API changes and document them.

Decide whether this should target 9.0.0, a minor release, or 10.0.0.

A patch updating to the beta for testing.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

update_fix_compatibility() is just remove modules and themes that don't exist.

Steps to replicate

1. delete a module from the modules folder
2. run updates
3. restore the module and try to enable it

You can't enable nor uninstall. But it does point to the process of disabling the module leaving things in a corrupt state.

Proposed resolution

Add an requirement error when the module list or theme list is wrong. We can't fix things really because at least in the case of modules we have no idea what to do. With themes potentially we could force an uninstall with no code present but then again we're making changes without really knowing what the user wants.

Looks something like:

Steps to test:

• Install standard
• Enable stark theme
• Remove dblog, page_cache and stark
• Set update free access in settings.php
• Visit update.php

Remaining tasks

User interface changes

Screenshots

API changes

update_fix_compatibility will no longer attempt to fix incompatibility, and is deprecated. This is necessary because it's the 'fixing' that puts sites into an unrecoverable state.

Data model changes

Release notes snippet

update_fix_compatibility() has been deprecated. Sites with incompatible or missing modules or themes will need to correct the issue in the codebase prior to running database updates. See update.php will no longer attempt to automatically remove modules for more information.

Problem/Motivation

• Let's assume a Drupal 9 EOL of Nov. 2023 to coincide with Symfony 4's EOL, unless we decide something different in #3018653: Decide on Drupal 9's EOL date range (and therefore, Drupal 10's release date range).
• As far as we know, all minimum database versions required by the core database drivers other than MariaDB will be security supported until approximately then:
  • MySQL 5.7 Community Server is supported by Oracle until October 2023.
  • PostgreSQL 10 is EOL by PostgreSQL after November 2022. However, RHEL/CentOS 8 will continue providing security backports until May 2024.
  • SQLite 3.26 is part of RHEL/CentOS 8 core (not an app stream), so as far as we know, will receive security backports until 2029.
• However, MariaDB 10.2 goes EOL in May 2022, and there aren't any major Linux distros providing freely accessible security backports beyond that. SUSE 15 SP1 ships with MariaDB 10.2, but SUSE 15 SP2 will ship in June 2020 with MariaDB 10.4, and SP1 will go out of mainstream support 6 months later. One can purchase up to 3 years of additional SP1 support beyond that, but that's not free.
• Because people can purchase extended support for MariaDB 10.2 (from MariaDB or from SUSE), it would be disruptive for core to raise the platform requirement in a Drupal minor release. Therefore, if we need to do it during D9's lifetime, it's better to do it prior to 9.0.
• At the same time, we shouldn't require core contributors or maintainers to install software with publicly known security vulnerabilities in order to work on, test, or review issues. Nor should we require them to purchase extended support from anyone in order to get a secure build.
• MariaDB 10.3 is EOL by MariaDB in May 2023, but it will ship with Ubuntu 20.04, so Ubuntu will provide freely available security backports until April 2025.

Proposed resolution

• Raise the minimum MariaDB version required by core to 10.3. If we want to pick a patch version within the 10.3 series, then 10.3.7 is a logical choice, since that's the first stable (GA) release.
• For people still stuck on 10.2, create a contrib driver for it similar to the one for MySQL 5.6 and PostgreSQL 9.6.

Note that I was against this in #3107113-28: [policy] Decide on MySQL/MariaDB/Percona Server version support status for Drupal 9, but that was before SUSE upgraded their MariaDB version in 15 SP2.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In #3107113: [policy] Decide on MySQL/MariaDB/Percona Server version support status for Drupal 9 the general direction of raising MySQL requirements to 5.7 and MariaDB requirements to 10.2 was agreed on.

Proposed resolution

Raise version requirements.

It was discussed that this may require resolving #2985788: Add a separate MariaDB driver first, but that does not seem to be the case.

Remaining tasks

Raise version requirements.
Update documentation.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

Raised the minimum MySQL version to 5.7 and MariaDB version to 10.2 in Drupal 9. See https://www.drupal.org/node/3119156

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.

Distros

• Debian
  • 9 (17th june 2017): Ships with MariaDB 10.1.41 & MySQL 5.6.47
  • 10 (6th july 2019): Ships with MariaDB 10.3.18 & MySQL 5.7.29 and 8.0.19
• Ubuntu
  • 16.04 (21 th april 2016): Ships with MariaDB 10.0.24 & MySQL 5.7.29 and 8.0.19
  • 18.04 (26th april 2018): Ships with MariaDB 10.1.29 & MySQL 5.7.29 and 8.0.19
  • 20.04:
• Red Hat Enterprise Linux
  • 6 (10th november 2010): Ships with No MariaDB & MySQL 5.5.73
  • 7 (10th june 2014): Ships with MariaDB 5.5.64 & MySQL 5.6.47
  • 8 (7th may 2019): Ships with MariaDB 10.3.17 & MySQL 8.0.19

Databases

• MySQL (https://endoflife.software/applications/databases/mysql)
  • 5.6 released on 5th february 2013 and EOL February 5, 2021
  • 5.7 released on 21th october 2015 and EOL October 21, 2023
  • 8.0 released on 19th april 2018 and EOL April, 2026
• MariaDB (https://mariadb.com/kb/en/mariadb-server/ and https://mariadb.org/about/#maintenance-policy)
  • 5.5 released on 25th february 2012 (already EOL)
  • 10.1 released on 30th june 2014 and EOL October 2020
  • 10.2 released on 18th april 2016 and EOL May 2022
  • 10.3 released on 16th april 2017 and EOL May 2023
  • 10.4 released on 9th november 2018 and EOL June 2024

Proposed resolution

• Require MySQL/Percona 5.7.
• Encourage the development of a contrib driver for MySQL 5.6.
• Require at least MariaDB 10.2.
• Discuss requiring MariaDB 10.3 since 10.2 is EOL at the end of 2022 with no distro/etc. providing support. This would in turn depend on providing a separate MariaDB testing environment and driver.

Remaining tasks

Discuss.

User interface changes

None.

API changes

TBD.

Data model changes

TBD.

Release notes snippet

TBD.

Problem/Motivation

jquery.cookie is no longer a maintained library. A replacement should be found.

> git grep core/jquery.cookie core\core.libraries.yml | wc -l
      3
	    
> git grep -l cookie -- "*.js"
core/assets/vendor/jquery-joyride/jquery.joyride-2.1.min.js
core/assets/vendor/jquery.cookie/jquery.cookie.min.js

This is used in jquery.joyride and the only real usage I have found. Also, jquery.joyride is not hard dependency on cookies.
https://github.com/zurb/joyride/blob/v2.1.0/jquery.joyride-2.1.js#L32

Proposed resolution

Replace jquery.cookie with js-cookie library adding a backwards-compatibility layer. We can model the BC layer off of js-cookie v1.5.1 as well as the js-cookie v2.0.0 release notes (#26).

This approach was originally reviewed by droplet and confirmed by _nod in 2017. There is now a major version 3 in js-cookie that has a beta release. This is being evaluated in #3118726: Evaluate/upgrade to js.cookie 3.

jquery.cookie, js-cookie, and the object.assign polyfill are correctly loaded when using Internet Explorer 11. See #153 and #154.

jquery.joyride will no longer depend on jquery.cookie because tour module does not use the functionality that uses cookies.

Remaining tasks

• Add more tests
• Review approach by JavaScript subsystem maintainers

API changes

Yes, with backwards-compatibility layer.

Dependency evaluation

1. Maintainership of the package: Maintained by the excellent carhartl, who also maintained jQuery cookie. It is actively maintained and the issue queue is very clean. I reviewed closed issues over the past several months and the response time is quite fast.

2. Security policies of the package: A documented security policy is not available online. Since this library is essentially a successor to jquery.cookie, the security approval granted to that library may extend to this one, but this is a judgement best suited to someone from the security team. In particular I'm not sure if 2.x will be supported once 3.x is out of beta. Issue to ask the maintainer opened at: https://github.com/js-cookie/js-cookie/issues/614

3. Expected release and support cycles: The release schedule is irregular based on the maintainer's availability and need, but there tend to be a few releases a year. The releases are available at https://github.com/js-cookie/js-cookie/releases. The maintainer follows semver strictly insofar as one can with a JavaScript library. (Dots are used in tags for pre-release versions which differs from Drupal but is valid semver.

4. Code quality: > 2800 dependents, available in all popular package managers. It's trusted by many and any concerns will likely be assuaged by quickly reviewing the 163 lines (including whitespace) .

5. Other dependencies it would add, if any: no dependencies, only dev dependencies that Drupal never pulls in.

Release notes snippet

jquery.cookie has been replaced with js-cookie version 2. The core/js-cookie library is introduced, and a backwards-compatible shim is provided as core/jquery.cookie for Drupal 9. We may upgrade to js-cookie 3 if it is available before 9.0.0-rc1.

Meeting will happen in #d9readiness on drupal.slack.com.

Hello and welcome to this Drupal 9 readiness meeting!

This meeting:
➤ Is for core and contributed project developers as well as people who have integrations and services related to core. Site developers who want to stay in the know to keep up-to-date for the easiest Drupal 9 upgrade of their sites are also welcome.
➤ Usually happens every Monday at 19:00 UTC.
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to: `https://www.drupal.org/project/drupal/issues/3120130`
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

:zero: Who is here today? Comment in the thread below to introduce yourself.

:one: Do you have suggested topics you are looking to discuss? Post in this thread and we'll open threads for them as appropriate.

:two: TBD