Problem/Motivation

On October 17, 2013, Internet Explorer version 11 was released to the world.
(In comparison, Chrome browser released 45 versions since then)

Through the years, that pain point of writing additional code and spending numerous amount of hours to add support for IE11 only grew bigger, due to lack of standards and IE11 doing things in its own special way...

CKEditor 5 has dropped support for IE11, meaning that we will either unable to switch from ckeditor4 to ckeditor5 and retain support.

Inspired by https://death-to-ie11.com/ and https://www.swyx.io/writing/ie11-eol/

Latest stats:
https://analytics.wikimedia.org/dashboards/browsers/#all-sites-by-browser
IE usage -
2020-11-29 - 1.0%

https://gs.statcounter.com/browser-market-share#quarterly-200901-202004
IE usage -
2020 Q4 - 1.1%

Additionally, should any organisations wish to continue supporting IE11 past Drupal 10's release date, there is also the possibility to remain on Drupal 9's LTS release, until the end of 2023.

Accessibility

WebAIM does a two-yearly survey of browser usage, and their last survey showed IE11 usage at 10.9%, down from 23.3% in 2017. Their next survey will be in 2021, which may be too late to make a decision for Drupal 10 (although it will give us more data between the decision needing to be made and release). 10.9% is quite high, but dropping from 23.3% in two years is also a fast rate of decline.

miggifford reached out to WebAIM on Twitter, and their response was:

Our official recommendation is that IE die a fast and ignominious death. Nobody should be using it. Period. A new survey early next year will provide more data, but continued support for no longer seems reasonable.

Similar responses were received from anysurfer, the Belgian accessibility organisation: #3155358-34: [policy, no patch] Drop IE11 support from Drupal 10.0.x and the founder of the Blind Institute of Technology in Denver: [#3155358-36: [policy, no patch] Drop IE11 support from Drupal 10.0.x.
The US Web Design System still supports IE11, although it is rapidly approaching their threshold to drop support:

https://github.com/uswds/uswds/issues/3877

Thanks @mgifford! USWDS follows the 2% rule. We officially support any browser above 2% usage as observed by analytics.usa.gov.

Last month IE11 was at 3.6% over the past 90 days. This month it is 2.9%, and we'll continue to monitor it.

Combined this means a fast rate of usage decline amongst accessibility survey respondents, several accessibility organisations explicitly arguing that support should be dropped and discouraging people from using it, and the US federal government on a trajectory to drop support within the next few months if the downwards usage trajectory continues.

Proposed resolution

• Get clarification on Drupal's policy for supported browsers #3080068: [policy, no patch] Define usage heuristics for browser support.
• Create patches to remove IE11-specific code code
• Reconsider what HTML, CSS, and Javascript functionality we've been avoided until now, that we can finally benefit from.
• Update d.o documentation
• Create a CR for all those changes.

Remaining tasks

Let's bring a smile to millions of developers by stop supporting IE11, this could become one of the most exciting new feature of Drupal 10!

♬ Time to say goodbye ♬

User interface changes

API changes

Data model changes

Release notes snippet

Let's try using meta issues to list the priority issues for upcoming bugfix / maintenance releases of D7.

Using the e.g. "Drupal 7.74 target" tags frequently gets messed up by security releases, and it's generally harder to keep track.

For the next release, MySQL 8 support is the main priority, but we may be able to include a few others.

The next release of D7 (2020-12-02) will not be compatible with PHP 8, but work on that will likely be high priority for the following release (2021-06-02).

Please don't go crazy adding issues to this list (there are 32 issues tagged as 7.74 targets); be realistic about what the small team of maintainers is going to be able to work through in the next few weeks. Adding an issue here doesn't guarantee it'll be prioritised by the maintainers.

These are not necessarily in priority order.

todo

• #3170525: Set samesite cookie attribute for PHP sessions Important for commerce offsite payments with php <7.3
• #229825: backport "$_COOKIE['has_js'] must die" patch to 7.x Fixed in D8/9. Recent testing confirms works.
• #106721: Optimize node access query building Important performance improvement. Used in acquia commons distribution with >600 installs.

Issues raised by @mustangGB:

• #2884171: The drupal_render() function could use a bit more protection May need to add logging for developers.
• #3051721: [D7] Remove dead code: progress.upload_callback, progress.error_callback Simple fix. Identical to fix in D8
• #2470619: Do not attempt field storage write when field content did not change Important. Fabianx tagged it as major and commented in #66 just before latest patch. Speeds up some migrations by 50%.
• #2323963: [D7] Rename 'Permissions' tab to 'Roles and permissions' Simple cosmetic fix. Other improvements can come forward after this is committed.

Issues which have had recent activity, and are RTBC. Possibly transfer to next maintenance release:
The issues above have not been added into the following sorting.

Simple Fixes: These may only take a few minutes each to review and commit.

• #674354: CSS selectors get overridden by narrower selector at style.css when using Seven Simple fix, moves inline with D8 having more specific selectors.
• #1079116: Inaccurate text: Images must be smaller than !max pixels. Simple fix, changes wording to simplify user experience.
• #1944246: taxonomy_allowed_values should use entity_label Helpful for taxonomy translation. Fixed in D8. Two lines!
• #1973278: Error in image_styles of image.module on database update Simple fix, does it really need a test?
• #2039709: Forward slash in filter aliases in url alias overview doesn't work Simple fix. Major issue. Fixed in D8. Backport to D7. Re-queued tests
• #2400287: Remove all occurences of sourceMappingURL and sourceURL when JS files are aggregated Simple fix. One line. Regex identical to fix in D8.
• #2768921: Backport server configuration code from SA-CORE-2016-003 to Drupal 7 Simple fix in .htaccess and web.config files. Security improvement, mitigate when using vulnerable libraries and code. Fix in D8. @izmeez: "It looks good and we have been using it for some time without problems."
• #2863786: D7 ThemeRegistry array_key_exists() micro-optimization Simple fix, micro-optimization. Fixed in D8. Fabianx likes this, see comment#18.
• #2959727: drupal_add_html_head_link() needs to allow multiple hreflang tags to point to one URL. Simple fix required for sites using translations.
• #3006123: D7 drupal_array_get_nested_value() array_key_exists() micro-optimization Simple fix, micro-optimization.
• #3007719: Trailing space was added in 7.60 update Simple, trivial fix to cleanup and close.
• #3008166: [D7] Unnecessary looping in Xss::filter when processing attributes. Important simple fix, straight backport from D8
• #3015223: Never use aggregation in maintenance mode. Simple fix, Fabianx marked as RTBC, patch re-rolled. Draft change record exists https://www.drupal.org/node/3018664
• #3023545: [D7] Disable brotli compression of pre-compressed CSS and JS Adds a few lines in .htaccess prevents double compression. Fixed in D8.
• #3181653: Add aria-atomic to autocomplete Simple fix required for some accessibility checkers

Important Fixes:

• #460408: Cannot administer menu item/link if it points to an unpublished node Important fix, tagged as major. Patch by David Rothstein RTBC. Fixed in D8.
• #980144: Issues with "required, multiple" fields in forms Important fix. Fixed in D8
• #1007746: Reordering fails with more than 100 items in a menu Important fix. Patch has tests and is fixed in D8/D9.
• #1705618: Double click prevention on form submission Important to prevent double submission of forms, creating duplicate nodes, etc. Must clear browser cache to take effect.
• #1899126: Add wrappers to fix permission checks Required for POSIX filesystem. Fixed in D8
• #1978176: Build menu_tree without loading so many objects @joseph.olstad: "... the performance improvement is huge! .. After several years I see no credible reports of an issue with this patch"
• #2431283: Cron CSRF vulnerability Security hardening fix. Fixed in D8. Fabianx comment in #31, just before last patch.
• #2508666: Drupal 7 .htaccess rule to prevent backup file access is broken and needs more tests Major, fixed in D8, needs backport to D7.
• #2522002: Do not strip www. from cookie domain by default because that leaks session cookies to subdomains Simple patch, security improvement. Sessions table may need to be emptied. Backport. Fixed in D8. Change record for D8 https://www.drupal.org/node/2523826
• #2637680: Submit buttons for GET forms in search/views are not W3C valid due to empty 'name' attribute Fixed in D8. Has tests that fail as expected.
• #2752783: [D7] file_unmanaged_move() should issue rename() where possible instead of copy() & unlink() Important fix. Mcdruid urging commit. @joseph.olstad: "D8 has this already. It is a good idea."
• #2789723: [D7 backport] drupal_mkdir does not set permissions to directories it created recursively Important fix, includes tests. Backport of D8 fix.
• #2802159: [D7] SQL layer: $match_operator is vulnerable to injection attack Important fix. Backport of D8 fix.
• #2842762: Call to undefined function drupal_get_path_alias() in url() @jenlampton recently "Patch in #14 still applies cleanly to 7.70, 7.71, 7.72, 7.73 and 7.74"
• #2970929: [D7] Support X-Forwarded-* HTTP headers alternates Important backport for reverse proxies and load balance.
• #3008170: [D7] Deleting node type leaves orphan nodes Important, has tests. Backport from D8

Unsorted Fixes:

• #965078: HTTP request checking is unreliable and should be removed in favor of watchdog() calls Needs work and needs CR
• #1328696: Problem with _drupal_wrap_mail_line and attachment files Attachment of docx file or files with long names results in email that is not correct. Fixed in D8, backport for D7 has patch.
• #1835754: Add last 'changed' property to user entity Nice to have. Adds last modified to user table. Has been added to D8/9
• #2128055: Files should be uploaded to per year/month directories by default
• #3002101: Ajax upload with validation throws PHP notice on PHP 7
• #3017522: D7 - Verify peer on HTTPS if cURL available (but be careful of built-in cert bundles in the codebase) Verifies SSL certificates in OpenSSL connections (Critical)
• #3176634: [D7] node_access filters out accessible nodes when node is left joined Issue identified as major. Fixed in D8 with D9 fix pending. Backport to D7 patch from 2016-March-9

done

• #3098058: [D7] Use site name in From: header for system e-mails
• #3074666: [D7] Password reset form has no flood protection
• #2975433: Notices/warnings from attempted exploitation of SA-CORE-2018-002 and SA-CORE-2018-004
• #2946801: [D7] Fix Weight form element behavior
• #2798377: Use PHP_BINARY Constant for run-tests.sh
• #2571711: Notices on locale.module install
• #973436: Overzealous locking in variable_initialize()
• #2978575: Mysql 8 Support on Drupal 7
• #2989985: User module's flood controls should do better logging [D7 backport]
• #3178638: jquery.js has leading whitespace
• #3155357: menu tree output() notice after upgrade to php 7.4 with core 7.72
• #2756297: element_children sort order inconsistent between PHP 5 and PHP 7 [Drupal 7 backport]
• #3172878: Fix SQLite tests in Drupal 7 (and children)
• #3174366: Promote mcdruid to full D7 maintainer

Problem/Motivation

There's a great deal of info about what actually went wrong when you performed a migration, but it's all kept in a table called migrate_message with no mechanism (UI, command-line prompt, etc.) to extract info. Ideally, there would be a searchable/filterable view of this information.

Proposed resolution

Add a new page at admin/reports/upgrade-messages with a summary, and child pages that display the messages in any migrate_message table. Add the ability to filter on the migration and the severity.

The new pages call the fields() method of the related source plugin. Some of these need to be updated to catch exceptions when the source database has not been configured:

• MenuLink.php (There are also a lot of uses of the global t() in fields().)
• Menu.php
• d7/User.php
• d6/User.php (in baseFields())
• d6/ProfileFieldValues.php

Work-around: There is a drush command to view the messages, drush mmsg migration-name available from migrate_tools and migrate_run.

No message tables

With Message tables

D7_menu

Remaining tasks

Review
Agree on wording for the explanation of 'Not available' in some columns.
Agree on names that is align with the changes in #2713327: Provide a way to remove migration tables (ID map etc.).
Potential new issue for the changes here in Menu.php

User interface changes

New form for displaying messages from the migrate_message tables.

API changes

Data model changes

Release notes snippet

Problem/Motivation

Blocking error when trying to upgrade my drupal 8.9.11 site to 9.1.0

Steps to reproduce

- Put site in maintenance mode
- Upgrade the modules "Devel", "Permissions by term", "reCAPTCHA", "Social media share" and "Webform" to it's latests version.
- Upgrade the core and vendor and root files of Drupal
- execute update.php
Results :

Missing or invalid module
The following module is marked as installed in the core.extension configuration, but it is missing:

    kint

Review the suggestions for resolving this incompatibility to repair your installation, and then re-run update.php.

I found out that the module "Kint" has been included in "Devel", so is not available as such for Durpal 9.
I didn't find where that reference is.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Running migrate-import using drush/drush:^10 from a drupal 6 site to drupal 8.8. The drupal 6 site has core search enabled.

An exception is thrown from Drupal\search\Plugin\ConfigurableSearchPluginBase::setConfiguration()

TypeError: Argument 1 passed to Drupal\search\Plugin\ConfigurableSearchPluginBase::setConfiguration() must be of the type array, null given, called in /var/www/sites/abcdef/web/core/modules/search/src/Plugin/migrate/destination/EntitySearchPage.php on line 106 in Drupal\search\Plugin\ConfigurableSearchPluginBase->setConfiguration() (line 46 of /var/www/sites/abcdef/web/core/modules/search/src/Plugin/ConfigurableSearchPluginBase.php)

Backtrace:

#0 /var/www/sites/abcdef/web/core/modules/search/src/Plugin/migrate/destination/EntitySearchPage.php(106): Drupal\search\Plugin\ConfigurableSearchPluginBase->setConfiguration(NULL)
#1 /var/www/sites/abcdef/web/core/modules/migrate/src/Plugin/migrate/destination/Entity.php(173): Drupal\search\Plugin\migrate\destination\EntitySearchPage->updateEntity(Object(Drupal\search\Entity\SearchPage), Object(Drupal\migrate\Row))
#2 /var/www/sites/abcdef/web/core/modules/migrate/src/Plugin/migrate/destination/EntityConfigBase.php(140): Drupal\migrate\Plugin\migrate\destination\Entity->getEntity(Object(Drupal\migrate\Row), Array)
#3 /var/www/sites/abcdef/web/core/modules/search/src/Plugin/migrate/destination/EntitySearchPage.php(86): Drupal\migrate\Plugin\migrate\destination\EntityConfigBase->import(Object(Drupal\migrate\Row), Array)
#4 /var/www/sites/abcdef/web/core/modules/migrate/src/MigrateExecutable.php(226): Drupal\search\Plugin\migrate\destination\EntitySearchPage->import(Object(Drupal\migrate\Row), Array)
#5 /var/www/sites/abcdef/vendor/drush/drush/includes/drush.inc(223): Drupal\migrate\MigrateExecutable->import()
#6 /var/www/sites/abcdef/vendor/drush/drush/includes/drush.inc(214): drush_call_user_func_array(Array, Array)
#7 /var/www/sites/abcdef/web/modules/contrib/migrate_upgrade/src/MigrateUpgradeDrushRunner.php(266): drush_op(Array)
#8 /var/www/sites/abcdef/web/modules/contrib/migrate_upgrade/src/Commands/MigrateUpgradeCommands.php(64): Drupal\migrate_upgrade\MigrateUpgradeDrushRunner->import()
#9 [internal function]: Drupal\migrate_upgrade\Commands\MigrateUpgradeCommands->upgrade(Array)
#10 /var/www/sites/abcdef/vendor/consolidation/annotated-command/src/CommandProcessor.php(257): call_user_func_array(Array, Array)
#11 /var/www/sites/abcdef/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
#12 /var/www/sites/abcdef/vendor/consolidation/annotated-command/src/CommandProcessor.php(178): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#13 /var/www/sites/abcdef/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(302): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#14 /var/www/sites/abcdef/vendor/symfony/console/Command/Command.php(255): Consolidation\AnnotatedCommand\AnnotatedCommand->execute(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#15 /var/www/sites/abcdef/vendor/symfony/console/Application.php(1000): Symfony\Component\Console\Command\Command->run(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#16 /var/www/sites/abcdef/vendor/symfony/console/Application.php(255): Symfony\Component\Console\Application->doRunCommand(Object(Consolidation\AnnotatedCommand\AnnotatedCommand), Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#17 /var/www/sites/abcdef/vendor/symfony/console/Application.php(148): Symfony\Component\Console\Application->doRun(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#18 /var/www/sites/abcdef/vendor/drush/drush/src/Runtime/Runtime.php(118): Symfony\Component\Console\Application->run(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#19 /var/www/sites/abcdef/vendor/drush/drush/src/Runtime/Runtime.php(49): Drush\Runtime\Runtime->doRun(Array, Object(Symfony\Component\Console\Output\ConsoleOutput))
#20 /var/www/sites/abcdef/vendor/drush/drush/drush.php(72): Drush\Runtime\Runtime->run(Array)
#21 /var/www/sites/abcdef/vendor/drush/drush/drush(4): require('/var/www/sites/...')
#22 {main}. 

Proposed resolution

TBD

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

"The value you selected is not a valid choice"

This error sometimes come from uninstalled language. So, please add more detail which SELECT LIST/OPTIONS caused this error.

Problem/Motivation

During the Drupal 9 development process, we've discovered that setting platform requirements (PHP version, supported databases, etc.) is best done early during the major branch development process. Setting these to "obvious" minima as soon as possible and then increasing them more afterward was also valuable.

Proposed resolution

• Continue adding PHP dev environments annually as soon as PHP alphas become available, and stable environments as soon as stable releases are available.
• Ensure that testing environments are available for the latest database versions before 10.0.x is opened.
• Require at least PHP 8.0 as soon as 10.0.x is opened.
• Determine similar obvious minima for supported databases based on support cycles, distro support, and hosting provider support as of when 10.0.x will be opened.
• Further increase the requirements as feasible.
• Set a deadline 1-2 months ahead of the initial 10.0.0-beta1 target deadline for finalizing platform requirement policies. (The final implementations can still be beta blockers.)

Remaining tasks

Not all form elements cant use in vertical_tabs.

Missing #process and #pre_render groups callbacks like processGroup and preRenderGroup

Problem/Motivation

At now there are no ways to edit media, that was inserted into content, using Media Library CKEditor widget. So, if user, for example, want to change name of media item, or replace image to other - he have only long way via searching this media item in library on separate page manually, and edit it.

Steps to reproduce

1. Enable Media Library module, and in CKEditor add Media Library button.
2. In node edit form upload and insert some document file (eg "Exomple one.pdf") in CKEditor via "Add Media from Library" button.
3. See, that file name is bad, then try to find way for edit this media to change name of this media - In "Edit media" modal window you will see only align and other widget settings, but not fields of current media.

Proposed resolution

Allow Media items to be edited from modal dialog in CKEditor.

Remaining tasks

Finish patch, discuss scope.

User interface changes

Add link to media edit page.

API changes

None.

Data model changes

None.

Problem/Motivation

entityQueryAggregate does not escape the field that is argument of the aggregation function, nor of the GROUP BY part.

See example below:

SELECT "entity_test"."id" AS "id", "entity_test"."langcode" AS "entity_test_langcode", MIN(entity_test.name) AS "entity_test_name", MIN(entity_test.id) AS "id_1"\n
FROM\n
{entity_test} "entity_test"\n
GROUP BY entity_test.id, entity_test_langcode\n
LIMIT 10 OFFSET 0

it is mixing up quoted and non quoted identifiers, now all identifiers should be quoted.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem description and motivation

Drupal ships with a standard code structure where the web root contains the usual directories: core, modules, etc. Advanced site-builders might prefer to customise it:

1. Use symbolic links. This worked fine in D7 but is broken in D8.
2. #1672986: Option to have all php files outside of web root. - this issue does not solve that case but is a pre-requisite.

In both of these cases, the site is inoperable because Drupal guesses the application root incorrectly. This issue has been raised a bug not a feature because Drupal includes mechanisms that seem clearly designed to allow a non-standard code structure - but they are bugged.

Proposed resolution

We need to place some simple, minimal restrictions on what can be customised. A few key files will need to remain in the web root without the use of symbolic links - this allows working out the application root by calling __DIR__ within these pages.

• Any file that serves a page: index.php, update.php, authorize.php, rebuild.php, install.php, statistics.php.
• Legacy include files included from these pages in core/include.

Based on these restrictions, we can ensure that there is no use of __DIR__ in any other files.

1. The key files must pass the $app_root parameter to methods on DrupalKernel.
2. All other files must call DrupalKernel->getAppRoot() rather than using __DIR__.

Related tasks

• #3176691: Allow scripts to work with non-standard code structure
• Deprecate using $app_root = NULL.

Original summary

I usually link drupal inside my www directory like seen in the following ls output.
I think symlinking like that is not unusual, as it helps with version controlling of own projects.

core -> ../drupalcheckout/core
.htaccess
../drupalcheckout/index.php
../drupalcheckout/modules
profiles
robots.txt -> ../drupalcheckout/robots.txt
sites
themes -> ../drupalcheckout/themes

i've attached a script which will setup such an environment in the current directory.

With this setup BASE_ROOT in install.php will be set to the drupalcheckout directory.
Install then tries to find a settings.php in ../drupalcheckout/sites/default and not ./sites/default.

same Problem and fix should be considered for update.php and authorize.php

related discussions:
#1055856: Optimize settings.php discovery
#484554: Stop relying on Apache for determining the current path

Problem

This issue covers multiple problems relating to the function EntityViewController->buildTitle(). This issue blocks #2353867: [META] Expose Title and other base fields in Manage Display and has adverse consequences in current vanilla core.

1 Malformed HTML output

In certain scenarios the page title region contains a div or h2 element inside h1, which is invalid markup.

Example scenario:

• Enable the media module.
• Create a media type and manage display to enable the name field
• Create a media entity, and view it at /media/1.
• Actual result: invalid markup div inside h1.
• Expected result: valid markup.

Cause is that buildTitle inserts the rendered output of a field into $page['#title']. In vanilla core:

• the field output comes from field.html.twig and contains a div
• the formatter may add further tags such as h2
• the page title output comes page-title.html.twig and wraps the title in h1

This bug does not affect user entity (no label) or node entity (specific workaround by means of field--node--title.html.twig - but that workaround causes problem 4).

2 Prevents manage display of label field

On the entity own page (such as /media/XX) the settings of manage display are ignored. The label field is missing from the main content, even if the title block is hidden.

This has been split off to a separate issue, #3043592: Allow entity to display label field as normal.

3 Inconsistent, only works selectively

The buildTitle function does not get called if the label field has been disabled by means of manage display. Hence the UX of the title block varies depending on a manage display setting (even though that setting potentially has no effect due to 2).

I analysed the tests that failed when removing buildTitle and discovered that we are relying on it for two unexpected things.

1. HTML tags in page title: buildTitle escapes them, but template_preprocess_html strips them.
2. Wrapper: for nodes field--node--title.html.twig is used and by default it wraps the page header title in a span

However both of these stop happening if the label field is disabled - inconsistency which is confusing and undesirable. For example it means that #2930788: Do not show name by default in media displays has surprising consequences.

4 Node titles missing label

If the site owner has hooked the node title to setDisplayConfigurable, then the title field display is incorrect, for example the label is missing.

Cause is the workaround code added for 1. The template field--node--title.html.twig overrides the normal field template with special case handling applicable if the display is not configurable. However the template gets used for configurable display too.

Overall effect

For any entity (such as core Media Entity) that allows manage display of the label, there is no safe option.

• If display is enabled, then get bad markup from 1).
• If display is disabled, then get potentially missing markup from 3).

There are contrib modules and core patches to extend manage display of label to more entities.

FYI Comment incorrect

The comment in buildTitle claims that the purpose is

allows attributes set on the field to propagate correctly (e.g. RDFa, in-place editing).

However RDFa works handles the title field in rdf_preprocess_node in a way that does not rely on buildTitle.

Proposed Solution

Enhance EntityViewController->buildTitle() to switch between two alternatives.
1) "Legacy" = as existing code: set page title to the rendered title field formatter instead of the default plain text title. This is the default in Drupal 8, but is deprecated and will be removed before Drupal 9. This method has bugs if a module makes the field's display configurable via the field UI by means of of BaseFieldDefinition::setDisplayConfigurable().

2) "Template". Set page title to the output from the entity_page_title template; modules can use hook_preprocess_entity_page_title() to add attributes. Disable output of the label field in the main content. This will be the default in Drupal 9. It's not the default in Drupal 8, because it is not fully back-compatible with modules that rely on hook_preprocess_field() to set attributes on the page title.

Use the new "Template" if the label

• a module makes the field's display configurable via the field UI by means of BaseFieldDefinition::setDisplayConfigurable()
• AND the additional entity type property 'enable_page_title_template' has been set using hook_entity_type_build().

Rejected solution

Continue putting field into page title and fix all the bugs.

Downsides

1. The code for putting field into page title is already somewhat complex and mysterious.
2. We need to add more complex and mysterious code (see patch #26): pass a flag "is page title" into EntityViewController and EntityViewBuilder. That code doesn't really belong as those classes shouldn't care about page titles.
3. We need to add more complex and mysterious code to make an inline field template (see patches in #2993647: Correctly determine when to display fields as inline). This likely forces all theme developers to alter their field template.
4. Even after all this, there is a bug with quickedit. Patch #26 doesn't cover the case when the title is edited, and redrawn. To fix that we would need to make quickedit add an attribute to indicate a page title, and pass that information back on the AJAX request. So more complex and mysterious code.

The sole benefit of putting field into page title is to allow modules to write a preprocess function for all fields, and it 'magically' also works on the page title. However this is a dubious assumption - what works for a normal field isn't necessarily right for a page title - and has zero uses in core. (We will have to fix quickedit_preprocess_field to handle the page title case specially anyway.)

Follow-up to #2263569: Bypass form caching by default for forms using #ajax..

There, in RenderElement::preRenderAjaxForm() we changed the default URL of an AJAX submission from Url::fromRoute('system.ajax') to Url::fromRoute('<current>'). Most of the time, this is the same as $form['#action'], but not always. For example, comment forms sometimes set the action to a separate page.

For the cases where the action is not the current page, let's discuss which one AJAX should submit to, and then add docs and test coverage for that. In most cases, since the AJAX response is built solely out of what's in $form and $form_state at the end of form processing, which route we submit to probably doesn't result in any difference, if both the current route and action route end up calling $form_builder->buildForm() with the same arguments, and if there aren't alter hooks that modify differently based on the route. But, since it is possible to write routes and alter implementations that result in differences, we should take a stance here.

Reasons for AJAX to submit to $form['#action']:

• All #ajax elements fall back to submitting to the form action when JS is disabled, so this would bring more consistency for what server-side form processing code runs, regardless of whether JS is enabled in the browser.

Reasons for AJAX to submit to the current page:

• The purpose of the AJAX response is to update the current page, so shouldn't it do so with content meant for that page? When JS is disabled, an entire new page is returned, so it matters less whether that's the same or different than the current one.

Problem/Motivation

Currently the VendorHarderingPlugin is only able to process packages installed in the vendor directory. That very strongly limits it's usage. It would be nice if it could harden Composer packages in any directories. For instance Drupal core ships with 4 MB demo_umami installation profile. Given it's a demo profile why should any Drupal site have it on production?

Proposed resolution

Process all packages regardless of their location.

$composer = $event->getComposer();
$installation_manager = $composer->getInstallationManager();
$package_path = $installation_manager->getInstallPath($package);

Problem/Motivation

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

Drupal 9 requires MariaDB 10.3+ or MySQL/Percona 5.7.8+.

Decide on Drupal 10 requirements changes if any.

Distros

• Debian
  • 10 (6th july 2019): Ships with MariaDB 10.3.18 & MySQL 5.7.29 and 8.0.19
  • 10.7 (5th december 2020): Ships with MariaDB 10.3.18 & MySQL 5.7.29 and 8.0.19
  • 11 Expected to be released before Drupal 10: Ships with at least MariaDB 10.5.8 & MySQL 5.7.26 and 8.0.22
• Ubuntu
  • 20.04 LTS (april 2020): Ships with MariaDB 10.0.24 & MySQL 5.7.29 and 8.0.19
  • 22.04 LTS (expected april 2022)
• Red Hat Enterprise Linux
  • 8 (7th may 2019): Ships with MariaDB 10.3.17 & MySQL 8.0.19
  • 8.3 (29th october 2020)

Databases

• MySQL (https://endoflife.software/applications/databases/mysql)
  • 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)
  • 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
  • 10.5 released on 24th june 2020 and EOL June 2025

Proposed resolution

• Require MySQL/Percona 8.0.
• Require at least MariaDB 10.3 and hopefully 10.4.

Remaining tasks

Discuss.

User interface changes

None.

API changes

TBD.

Data model changes

TBD.

Release notes snippet

TBD.

Problem/Motivation

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

Drupal 9 requires PostgreSQL 10.0 or higher with the pg_trgm extension

Decide on Drupal 10 requirements changes if any.

Distros

• Debian
  • 10 (6th july 2019): Ships with PostgreSQL 11
  • 11 Expected to be released before Drupal 10: Ships with PostgreSQL 13
• Ubuntu
  • 20.04 LTS (april 2020): Ships with PostgreSQL 12
  • 22.04 LTS (expected april 2022) Probably ships with PostgreSQL 14
• Red Hat Enterprise Linux
  • 8 (7th may 2019): Ships with "10 and 9.6 via modules"
  • 8.3 (29th october 2020)

Database

• 9.5 released January 2016 and EOL February, 2021
• 9.6 released September 2016 and EOL November, 2021
• 10 released October 2017 and EOL November, 2022
• 11 released October 2018 and EOL November, 2023
• 12 released October 2019 and EOL November, 2024
• 13 released September 2020 and EOL November, 2025

Proposed resolution

Require PostgreSQL 13. The problem what should we do with RHEL as it is stuck on PostgreSQL 10.

Remaining tasks

Discuss.

User interface changes

None.

API changes

TBD.

Data model changes

TBD.

Release notes snippet

TBD.

Problem/Motivation

Drupal requirements list the following SQLite requirements currently:

Drupal 9 requires SQLite 3.26 or higher

Decide on Drupal 10 requirements changes if any.

Distros

• Debian
  • 10 (6th july 2019): Ships with SQLite 3.27
  • 11 Expected to be released before Drupal 10: Ships with SQLite 3.34
• Ubuntu
  • 20.04 LTS (april 2020): Ships with SQLite 3.31
  • 22.04 LTS (expected april 2022)
• Red Hat Enterprise Linux
  • 8 (7th may 2019): Ships with SQLite 3.26
  • 8.3 (29th october 2020)

Database

• 3.26 released December 2018
• 3.27 released Februari 2019
• 3.31 released Januari 2020
• 3.34 released December 2020

Proposed resolution

Require SQLite 3.26 or higher. We should look at what changes we would like to use from SQLite newer versions. See: https://sqlite.org/changes.html.

Remaining tasks

Discuss.

User interface changes

None.

API changes

TBD.

Data model changes

TBD.

Release notes snippet

TBD.

Problem/Motivation

• We currently store several serialized data structures in the database, such as {config}.data, {cache_*}.data, the Layout Builder data of per-entity layouts, and plenty others. Many of these would benefit from being serialized as JSON instead of PHP. #3046696: Move from serialized columns to JSON encoded data wherever possible, or use allowed_classes includes some discussion about this.
• Nearly all modern relational databases now support a json datatype and corresponding JSON parsing functions that can be used during querying. If we could rely on this within our database system, then in following Drupal 10 minor releases we could add the APIs for efficiently querying these structures. For example, Drupal\Core\Config\Entity\Query\Query could be reimplemented as native queries by the database rather than its current implementation of in-memory PHP filtering only partially optimizable with a keystore. Or, Layout Builder could provide a way to query entities by aspects of its layout.

Proposed resolution

Require json support for all database drivers, both for the ones in core and for contrib/custom. This would mean:

• For MySQL require at least 5.7.8; and for MariaDB require at least 10.2.7. See #3107113: [policy] Decide on MySQL/MariaDB/Percona Server version support status for Drupal 9.
• For PostgreSQL require at least 9.4. See #3106077: [policy] Decide on PostgreSQL 9.x/10.x support status.
• For SQLite, version isn't an issue, but we'd have to require that it be compiled with the json1 extension. This isn't the default, but (some? all?) Linux distributions include it in their build of it. For example, Ubuntu does. From PHP 7.4 sqlite uses the library on the system. Drupal 10 will require at least PHP 8.0
• In contrib/custom space:
  • Microsoft SQL Server supports JSON beginning with version 2016. Mainstream support of earlier SQL Server versions has ended, but version 2012 still has extended support until 2022 and version 2014 still has extended support until 2024.
  • Oracle supports JSON beginning with version 12. Extended support of version 11 ends in Dec. 2020.
  • Any other SQL databases that we care about?

Remaining tasks

• Decide if it's acceptable to require these minimum database versions.
• Decide if it's acceptable to disallow SQLite usage for people whose SQLite is compiled without the json1 extension.

Problem/Motivation

Moving modules into contrib/custom after install doesn't seem to work. According to the documentation, all one has to do if one wants to move modules into a custom or contrib directory structure is mv the directory, and clear the cache. This does not work. In fact uninstalling a module, and installing it in one of these directories doesn't work.

Proposed resolution

Ultimately fix this if it can be fixed, but presently updating the documentation would help alleviate the 'oh crap' feeling of a broken site.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

AMP requires AMP Library which uses composer to install. Tried to follow instructions from github to install library but either composer fails for unknown reasons or drupal 8 doesn't detect that the library is installed, in both cases there are no hints of what is not working.

Is there a clear Drupal AMP library install instructions? the library instructions tells you to go read about how composer work if installing for Drupal.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet