Problem/Motivation

The critical need

As documented in #3051352: [Plan] Remove unused jQuery UI components and replace with a suite of contrib packages for the continuous upgrade path, jQueryUI is deprecated in Drupal9 core. In Drupal 9, contrib themes dependent on jQueryUI should be satisfying their jQueryUI requirements via the contrib jQueryUI modules. It needs to be possible for these themes to declare these contrib modules as dependencies.

Additional motivation

Parsing .info files for dependency information is already implemented on the modules administration page. Adding support for the same dependencies in theme.info files, and implementing the same behavior on the admin/build/themes page, would allow designers building heavily customized themes to make safer assumptions about their target sites.

A theme might require the existence of imagecache to auto-generate variations of a header image. This would be a nice compromise between systems like Wordpress and Joomla!, which give themes much greater control over the functionality of the site, and Drupal's module-centric approach.

Proposed resolution

• Allow themes to add the dependencies to .info.yml files
• Show these dependencies on /admin/appearance and make it impossible to install without the requirements via UI or command line
• Install dependencies automatically on API level.Moved to followup #3100374: Make it possible to install dependent modules when installing theme
• Validation is added to prevent installing themes that depend on uninstalled modules, and prevent uninstalling modules that are depended upon by installed themes. This is implemented at a level that prevents these installs/uninstalls from occurring programatically or via cli (Drush/Drupal Console).

Follow-ups

1. #3100374: Make it possible to install dependent modules when installing theme
2. Update #3005229: Provide optional support for using composer.json for dependency metadata to read composer.json theme's also

User interface changes

Themes listed in admin/appearance will list the modules they depend on and the ability to install that theme will not be available unless those module dependencies are met.
The module descriptions found at admin/modules and admin/module/uninstall will include themes in their "Required By" description.

API changes

Themes will be able to define modules dependencies in their info.yml via the dependencies key.

Release notes snippet

Pending.

Original report by [eaton]

Issue Summary
Parsing .info files for dependency information is already implemented on the modules administration page. Adding support for the same dependencies in theme.info files, and implementing the same behavior on the admin/build/themes page, would allow designers building heavily customized themes to make safer assumptions about their target sites.

A theme might require the existence of imagecache to auto-generate variations of a header image. This would be a nice compromise between systems like Wordpress and Joomla!, which give themes much greater control over the functionality of the site, and Drupal's module-centric approach.

Problem/Motivation

The migration UI re-uses the installation database form to gather db credentials from the user. This works great apart from the fact that we do:

    $db_prefix = ($profile == 'standard') ? 'drupal_' : $profile . '_';
    $form['advanced_options']['prefix'] = [
      '#type' => 'textfield',
      '#title' => t('Table name prefix'),
      '#default_value' => empty($database['prefix']) ? '' : $database['prefix'],
      '#size' => 45,
      '#description' => t('If more than one application will be sharing this database, a unique table name prefix – such as %prefix – will prevent collisions.', ['%prefix' => $db_prefix]),
      '#weight' => 10,
    ];

The description makes no sense in the migrate case (it does during installation).

This was found in #3086374: Make Drupal 8 & 9 compatible with PHP 7.4 due to the global $install_state not being set and new errors being emitted from PHP. Running Drupal\Tests\migrate_drupal_ui\Functional\d6\MultilingualReviewPageTest showed the error.

Proposed resolution

We should change the description for this form field in \Drupal\migrate_drupal_ui\Form\CredentialForm::buildForm() and perhaps rework the logic in \Drupal\Core\Database\Install\Tasks::getFormOptions so we don't set a nonsense one for migrate in the first place.

Remaining tasks

User interface changes

New UI text on migrate credentials form.

API changes

None

Data model changes

None

Release notes snippet

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/3110843`
➤*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

PHP 5.6 introduced constant expressions (see https://www.php.net/manual/en/migration56.new-features.php). This is something the JSON:API module wanted to use, but could not, because it had to support PHP 5.5 too. Drupal 8.8.0 having dropped support for PHP 5.5 allows us to use it after all.

Release notes snippet

JsonApiSpec::RESERVED_QUERY_PARAMETERS has changed from a string to an array.

Problem/Motivation

At /admin/config/media/responsive-image-style, the machine name data is included in the table. However, this is the only table that includes machine name data, which leads to UX inconsistency.

Proposed resolution

For consistency, remove the machine name data from the table at /admin/config/media/responsive-image-style so that the machine name is only visible on the edit form (i.e. /admin/config/media/responsive-image-style/narrow). Alternatively, add the machine name data to all other applicable tables, which would probably be a rather large undertaking.

Remaining tasks

If proposed resolution is justified/reasonable, write patch.

User interface changes

Above

API changes

None

Data model changes

None

Problem/Motivation

We have \Drupal\node\ContextProvider\NodeRouteContext that can be used in ConditionPlugin(for example).
But we haven't analogs to another entities. Taxonomy term is very essential page/route and this Context can be useful for Drupal DX.

Proposed resolution

Provide new service in taxonomy module.

Remaining tasks

1. Write code
2. Write tests

User interface changes

No.

API changes

New service.

Data model changes

No.

Release note snippet

Using the Views Row style options UI for a Block display, the inline fields separator help advises "... You can use HTML in this field. "

The output renders HTML markup as literal characters/plain text regardless of theme.

Steps to reproduce

1. Make a view (in my case, it's a block, not page)
2. Add several fields of a content type.
3. Click Settings for Fields format.
4. Scroll to bottom of pop-up window, and where the “Separator” field is, add a break tag. < / br >
(Just below this field, you’ll see the note leading people to believe they can simply add html)
5. Save your view, add the block to a page and go to that page.

Problem/Motivation

Accessing (as admin) a non-existing event details at admin/reports/dblog/event/ returns an empty page, it should return the 404 error page.

Proposed resolution

Throw NotFoundHttpException at the dblog controller for non-existing events.

Remaining tasks

Review path.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

TBD.

Problem/Motivation

Like Classy #3050389: Remove dependency to Classy from core themes, we'll be decoupling Bartik/Seven/Claro/Umami from Stable. This will make it easier for these themes to receive improvements as they are no longer beholden to BC, and will facilitate easier major version updates from Drupal 10 onward.

Proposed resolution

• Create tests that identify which stable templates/css are different from the module code they originate from.
• For each css file/template that differs, determine if the Core theme should receive a copy of Stable's asset, or if it's acceptable for the core theme to use the updated version.
• Provide theme specific copies of these assets where needed.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Drupal 8 introduced Stable theme as a backwards compatibility layer. This enabled us making disruptive markup and CSS changes in core and modules without breaking production themes. According to our original plan, all markup changes take place when a new major release gets released.

Since that plan was created, we’ve decided to make changes to our policies to make upgrading between major releases easier. Because there’s no defined way for following deprecations, testing markup and CSS changes can be hard.

Proposed resolution

Before 8.8.0-beta1

1. #3065545: Deprecate base theme fallback to Stable
   Deprecate stable as the default base theme, and instead require themes to always specify their base theme. This is important so that in each major version themes can explicitly adopt the new stable base theme when they're ready to, without any unexpected BC break and with clear advanced warning. Since this is a new deprecation, it needed to be completed by 8.8.0-beta1.
2. #2352949: Deprecate using Classy as the default theme for the 'testing' profile
   Deprecate the testing profile dependency on Classy. Many tests rely on Classy's markup. During Drupal 8's Twig and "Consensus Banana" initiatives, Classy was added as the default base theme in the testing profile, in order to save time fixing test failures where the tests had relied on theme markup. (See #2350823: Use the Classy theme in the Testing profile for the history there.) This was intended as a temporary fix until tests that were incorrectly coupled to markup could be adjusted to not rely on said markup.
3. #3110855: Plan for removing dependency to Stable in Bartik/Seven/Claro/Umami

Before Drupal 9.0.0-beta1

1. #3050374: Create Drupal 9 stable theme

   This will allow themes not supporting Drupal 9 optionally depend on Drupal 8 markup. This could be almost all themes build during Drupal 8 life cycle and we might want to recommend depending on this for everyone.

2. #3050389: Remove dependency to Classy from core themes

   (Stretch) This will allow removing dependency from core themes on Classy. This will make it easier to deprecate Classy during Drupal 9 lifecycle.

Before Drupal 10.0.0-beta1

1. #3050378: Replace Classy with a starterkit theme

   This will allow Drupal 8 themes depending on Classy on the Classy project in contrib. We will encourage using the starterkit approach for new themes but Classy will continue to exist in contrib.

2. #3050386: Allow loading CSS and JavaScript directly from templates

   This will move the frontend to a direction where we wouldn't necessarily need a separate backwards compatibility layer.

Remaining tasks

-

User interface changes

-

API changes

-

Data model changes

-

If you

1. Install Drupal 8 right now with the drupal/recommended-project composer recipe, which results in Drupal 8.8.1
2. Install a site using browser (standard profile) and using http (doesn't happen with https)

the installation will fail with this error after you fill out the "Configure site" page.

NOTICE: PHP message: Uncaught PHP Exception InvalidArgumentException: "Class "\Drupal\system\Controller\Http4xxController" does not exist." at /var/www/html/web/core/lib/Drupal/Core/DependencyInjection/ClassResolver.php line 24"

If you install via https it doesn't have a problem.

I tested this on Debian Stretch Linux in more than one environment (using ddev).

This is also referenced in https://drupal.stackexchange.com/questions/289480/class-drupal-system-co...

Easy to do with ddev with this technique:

1. mkdir d8recommended && cd d8recommended &&. ddev config --project-type=drupal8 --docroot=web --create-docroot
2. ddev start
3. ddev composer create drupal/recommended-project
4. ddev config --project-type=drupal8
5. Tail logs with "ddev logs -f"
6. Visit the *http* URL (for example, http://d8recommended.ddev.site) and do the web-based installation. You'll get these errors when you finish configuration on the final page.

Problem/Motivation

At the moment every contrib module that needs to add/alter tree manipulators require to override Drupal\system\Plugin\Block\SystemMenuBlock (or implement their own).

The only possible solution for contrib now is to override block class via hook_block_alter() but when more then one module installed only last override wins.
This collisions affects following contrib modules:
- https://www.drupal.org/project/superfish
- https://www.drupal.org/project/menu_multilingual
- https://www.drupal.org/project/menu_block
- https://www.drupal.org/project/domain_entity to incorporate https://github.com/skilld-labs/domain_menu_access
- https://www.drupal.org/project/menu_per_role
- https://www.drupal.org/project/menu_item_visibility
- https://www.drupal.org/project/menu_manipulator

Proposed resolution

Implement a new hook that allows menu tree manipulators to be altered.

Remaining tasks

- Decide on hook name - hook_system_menu_tree_manipulators_alter()
- File change record
- Commit

User interface changes

No

API additions

Adds hook_system_menu_tree_manipulators_alter to alter manipulators used in menu blocks

Data model changes

No

This is a Drupal core issue.

Problem/Motivation

Based on conversation in #3057420: [meta] How to deprecate Simpletest with minimal disruption, it's likely that we'll move simpletest module out of core, to be a contrib module. Since that meta is basically accomplished, we have flexibility in what we decide to do with the simpletest module. That is to say we can remove it and the testing system will still work, so the question is: Should we remove it, and if we do, should we make a contrib module out of it?

Making it a contrib module would allow some flexibility for those who wish to use simpletest's WebTestBase framework, and/or also use the UI test runner.

Proposed resolution

• Remove simpletest module from Drupal core
• Open a beta-blocking tracking issue to ensure that contrib modules with simpletests can have them run via DrupalCI (with some or no changes). If that's not complete by beta, we'd need to revert the removal commit or discuss further
• In a follow-up, decide whether run-tests.sh should support running TestBase-based tests, either as a supported feature, or as a short-term scaffolding while the contrib module is being developed. But leave that support in for now

Remaining tasks

How to deprecate and remove the module while not ruining people's day?

• run-tests.sh (at least for now) will run simpletest tests if simpletest module is installed.
• Can DrupalCI automatically install simpletest module or does it need to be an explicit dependency?
• If it's an explicit dependency can we prompt somehow?
• The contrib module will need manual testing for the simpletest UI and run-tests.sh to ensure they actually work as part of making a stable release.

Related non-core issues:

• #3093621: [META] Plan to get a stable D8/D9 release of the SimpleTest module
• #3093460: Make tests pass for 8.x-3.x (D9)
• #3077428: Modules that have a composer namespace of project-modulename cannot be patched

User interface changes

API changes

Data model changes

Release notes snippet

Dear SimpleTest, thank you for all the years of service. You helped drag Drupal from the depths of the untested to its almost test driven state now. You have watched over us as we went from no passed tests to over 25000 passed tests. We owe you much, you will be remembered. The time has come to rest in the pastures of contrib, you have earned it.

We've accumulated a fair number of BC layers in the hal.module component. In this issue, we maintain an up-to-date patch that removes all BC layers, which allows us to track how much of a difference this would make.

Problem/Motivation

Spin-off from #3063887: Support PHPUnit 8 in Drupal 9, drop support for PHPUnit 7.

In order to make the test codebase forward compatible with PHPUnit 8, the big problem is that PHPUnit 8 is changing the signature of the main test methods that test classes extend - above all setUp() and tearDown, adding a void return typehint.

In this issue we explore the option 1 of #3063887: Support PHPUnit 8 in Drupal 9, drop support for PHPUnit 7, i.e. Change the signatures of the methods in Drupal test code according to PHPUnit 8.

While this is not a problem for Drupal 9 core, that supports PHP 7.3+, this will have the impact of forcing testing for contrib/custom modules only on PHP 7.1+ (the minimum that allows specifying a void return typehint to methods).

Setting to critical since per @xjm at #3063887-39: Support PHPUnit 8 in Drupal 9, drop support for PHPUnit 7

If anything I'd want to make the break in 9.0 rather than 9.1 because that's a massive change.

Proposed resolution

Change all the implementations of

• setUp()
• tearDown()
• setUpBeforeClass()
• assertPostConditions()

in test classes to have a void return typehint.

Remaining tasks

Discuss.
Patch.

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. DONE: #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 following PHP 7.2 requirement
• #3099876: Establish a packaging pipeline queue
• DONE: #3104265: Update Composer dependencies on Doctrine components in 9.0.x
• DONE: #3106075: Bump minimum PHP for Drupal 9 to PHP 7.3

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

For the release of Drupal 9.0.0-beta1 we must take a decision what the minimum version will be for SQLite.
The current minimum version for Drupal 8 is SQLite 3.6.8. Which was released on 12th january 2009. That is over 11 years ago. For more release dates of SQLite see : https://sqlite.org/chronology.html.

Distros

• Debian
  • Debian 9: Ships with 3.16.2
  • Debian 10: Ships with 3.27.2
• Ubuntu
  • 16.04: Ships with 3.11.0
  • 18.04: Ships with 3.22.0
  • 20.04:
• Red Hat Enterprise Linux
  • 6: Ships with 3.7.9
  • 7: Ships with 3.7.17
  • 8: Ships with 3.26.0

SQLite

• 3.7.9 released on 1st november 2011
• 3.7.17 released on 20th may 2013
• 3.11.0 released on 15th february 2016
• 3.16.2 released on 6th january 2017
• 3.22.0 released on 22nd january 2018
• 3.26.0 released on 1st december 2018
• 3.27.2 released on 25th february 2019

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

We currently have simpletest module in contrib (dev version) and simpletest module in core (fully deprecated).

While simpletest is in core, it is hard to confidently say that modules can run simpletest tests with the contrib module, since every install gets simpletest.

Additionally, there may still be issues getting the contributed module working, and some may involve conflicts with the core version (composer? autoloading?).

Proposed resolution

1. Commit a patch that does rm -rf on the simpletest module.

2. Leave run-tests.sh support for simpletest in core for now.

3. Open a new beta blocking tracking issue to ensure the contrib module works.

4. Any further refactoring like moving run-tests.sh to contrib would be non-release-blocking.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet