Problem/Motivation

This is a follow-on to #2745123: Simpletest module crashes on cleanup, uninstall which will, we hope, find non-disruptive solutions to the problem of class loading classes under core/tests during runtime. This includes the problem of simpletest_clean_environment() needing to access TestBase.

In this issue we can refactor the simpletest cleanup code to be more maintainable and clear, with inversion of control, in a somewhat more disruptive way for 8.3.x.

simpletest_cleanup_environment() is used by both the Simpletest UI and run-tests.sh. This makes it a good candidate for refactoring to improve the testing system moving forward.

Proposed resolution

Refactor the following functions into a helper class called something like EnvironmentCleaner:

• simpletest_clean_environment()
• simpletest_clean_database()
• simpletest_clean_temporary_directories()
• simpletest_clean_results_table()

Mark these functions as deprecated.

Remaining tasks

Turn the EnvironmentCleaner class into a proper service. This would involve turning the TestDatabase class into a service or parameter service as well which might be outside the scope of this issue.

User interface changes

API changes

Data model changes

Problem/Motivation

Follow-up to #3074043-13: Move simpletest.module DB-related functions to TestDatabase, deprecate

Check if it the queries can be changed to dynamic.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

\Drupal\Core\Field\Plugin\Field\FieldFormatter\EntityReferenceFieldFormatter::viewElements() tracks how many times an "instance" of a reference has been rendered, to avoid ending up in a recursive loop, which is understandable.
By one "instance" is meant one combination of "Entity with id X of type Y referenced by parent Z of type A in field B".

The problem is that there's no way to reset the counters in (EntityReferenceFieldFormatter::$recursiveRenderDepth) when you intentionally want to render a node multiple times, possibly as different users would see it.

In our use case we email out a personalized rendering of some node entities to 20+ users. "Computed" fields handle most of the personalized values on these nodes so the nodes are rendered using a specific view mode where these fields show up.)
It works well for the first 20 users, after that some data is missing and we get a "Recursive rendering detected when rendering entity...." error in the log.

Before and after each rendering we use @account_switcher to "view" the node as each specific user. (To actually make this work we also have to call a custom "@language_enforce" service which switches to using the user's preferred language and clears a huge amount of services' caches before each batch of nodes. We even have to temporarily replace @language.default else other things grab stale values from it. It can not currently clear the counter in EntityReferenceFieldFormatter though.)

I could post our @language_enforcer class somewhere, but this specific problem does not seem to be caused by it.

A hacky workaround I use for now is to implement hook_field_formatter_info_alter() and replace the formatter's $info['entity_reference_entity_view']['class'] with \Drupal\my_module\EntityReferenceFieldFormatterProxy (and $info['field_collection_items']['class'] with \Drupal\my_module\FieldCollectionItemsFormatterProxy) that have an extra static method to reset the counter, and call it whenever we know this could happen.

Proposed resolution

1. Give EntityReferenceFieldFormatter an additional static method for clearing its cache when someone knows they'll likely hit EntityReferenceFieldFormatter::RECURSIVE_RENDER_LIMIT.
   Feels hacky since you're making developers know and compensate for implementation details at non-obvious places.
2. Listen to some "event" and have the class automatically reset itself when it seems reasonable (when switching users?). Have not found a suitable solution yet.
3. Refactor so the keys into EntityReferenceFieldFormatter::$recursiveRenderDepth are also based on some value which we can influence and change if rendering the same entity multiple times? (Think cache-busting.)

Remaining tasks

Discuss.
Write patches...

User interface changes

None, hopefully.

API changes

Possibly an addition.

Data model changes

None.

Steps to reproduce:

• Add a media field to a vocabulary
• Set the field widget to Media library
• Go to Add term page
• Click on Add media

The following warning occurs: Warning: array_keys() expects parameter 1 to be array, null given in Drupal\taxonomy\TermForm->buildEntity() (line 120 of /core/modules/taxonomy/src/TermForm.php)

If error messages are set to be displayed, it completely blocks the modal opening. Reproduced on Drupal 8.7.x and 8.8.x.

Problem/Motivation

• https://www.drupal.org/docs/8/system-requirements/browser-requirements lists some extremely outdated browsers, such as Firefox 5 and Safari 5. It's unlikely that any core developers or testers test on these browsers. The browser vendors have long ago abandoned security support for them, so for a core developer or tester to even install one of them potentially opens their computer up to a security vulnerability.
• In Drupal 8.4, we updated to jQuery 3: #2533498: Update jQuery to version 3. https://jquery.com/upgrade-guide/3.0/#browser-support lists what is officially supported by that, which is e.g., only Current and (Current - 1) of Firefox and Safari.
• A lot of Drupal core JavaScript depends on jQuery. Authenticated users with no other roles, and in some cases even anonymous users, can view pages that run jQuery. For example, just a permission to post a comment exposes use of CKEditor, and the Link button in the toolbar opens a dialog that makes use of jQuery and jQuery UI. And the drupal.comment-by-viewer library is available to anonymous users and invokes jQuery code. There's lots of other examples.

Proposed resolution

1. Update https://www.drupal.org/docs/8/system-requirements/browser-requirements to match the browser versions on https://jquery.com/upgrade-guide/3.0/#browser-support. This means raising Safari, Firefox, and Chrome to Current and (Current - 1) and Opera to Current. It also means adding Edge (Current and Current - 1), Safari Mobile iOS: 7+, and Android 4.0+.
2. Open separate issues for diverging from the above. For example, jQuery itself supports IE9+, but jQuery UI only officially supports IE11+, so #2842298: [policy, no patch] Drop IE9 and IE10 support from Drupal 8.4.x.
3. Open a separate issue for discussing security policy. For example, do we fix known security vulnerabilities that only affect outdated, but still used, browsers? How long do we retain existing security fixes and tests for outdated browsers in our codebase? Pending that issue, see #21.
4. Send out an announcement somewhere ahead of 8.3's release?

Remaining tasks

• Agree (or not) on above.
• Decide if we want a separate issue for discussing Firefox ESR. I don't know how to interpret jQuery's policy with respect to that: do "Current" and "Current-1" apply to that as well, or is Firefox ESR officially not supported by jQuery (since the ESR version is often more than 1 behind the Current Firefox version)? Seems a shame for Drupal, a CMS designed for organizations, to not support a version of Firefox geared towards organizations.

Hey there,

I'm using Drupal between several layers of reverse proxies, which means that my "Forwarded" headers are already set.

However, I'm now using JSONAPI for my REST API, and I've put an API Gateway in front of it so I can manage accesses, scopes, quotas…

This is what i've got right now:

API Consumer -> API Gateway -> OpenShift HA Proxy -> Drupal

Someone browsing the drupal site -> OpenShift HA Proxy -> Drupal

The issue is that the links exposed in the JSONAPI response when I contact the API using the gateway are pointing directly to the website. This was fine until we had paginated data, we were obliged to parse the query string, grab the next page information, then concatenate it with the previous query string.

So, my answer is, what would be the best-practice to override the generated links from JSONAPI? I think that changing the $_SERVER['REMOTE_ADDR'] or equivalent solutions won't work since it's gonna break the exposed drupal site. I was thinking about a hook in jsonapi for this url to be overriden, but I wanted your advice before submitting a patch.

Thanks a lot for any inputs you can provide!

have a view with 2 pages and 2 blocks.

when configuring the more link, help text says:

This will add a more link to the bottom of this view, which will link to the page view. If you have more than one page view, the link will point to the display specified in 'Link display' above. You can override the url at the link display setting.

but i cannot find any "'Link display' above" and both block more links point to the same page.

Problem/Motivation

Currently layout_builder is very limited when it comes to more complex layouts. The issue is lack of nesting or wrapping ability. See:

• #3053145: Allow layout builder sections to be nested.
• #2960384: Allow Concept of Section Wrappers

I believe that all use cases bringing people towards these issues could be solved if we would simply allow people to create layouts with configurable regions. These could be a "second class citizens", yet would allow devs or contrib modules to develop custom complex rules of layout building, and store them in layouts configurations.

Proposed resolution

The simplest way of supporting this would be to add a new method to the Drupal\Core\Layout\LayoutInterface: getDynamicRegions. Other parts of the system could decide themselves if they want to support dynamic layout regions or not, as this information is not always available, but where it is available, it is very useful.

Remaining tasks

• Patch review
• Discuss and agree on the solution

API changes

Drupal\Core\Layout\LayoutInterface modified with additional method. It would be implemented by default in the Drupal\Core\Layout\LayoutDefault though.

Follow-up to #2362517: Improve default 403/404 exception HTML subscriber: don't duplicate the page render pipeline, use the routing system — add system.403 and system.404 routes

Problem/Motivation

#2362517: Improve default 403/404 exception HTML subscriber: don't duplicate the page render pipeline, use the routing system — add system.403 and system.404 routes adds a Http4xxController for returning 403 and 404 page markup.
In comment #12 @dawehner noted it would be good if these had their own theme functions to allow simple changes to the markup - e.g. #theme => 'page__403' or #theme => 'page__404'.

Proposed resolution

Add them

Remaining tasks

Wait for #2362517: Improve default 403/404 exception HTML subscriber: don't duplicate the page render pipeline, use the routing system — add system.403 and system.404 routes
Write patch.
Add tests.
Review.

User interface changes

None.

API changes

None.

Problem/Motivation

Following #3051352: [Plan] Remove unused jQuery UI components and replace with a suite of contrib packages for the continuous upgrade path we need to actually deprecate all the unused jQuery UI components in core, pointing to a change record which will in turn point to the contrib modules and how to update dependencies.

Proposed resolution

For jQuery UI components that are not used by core, deprecate them entirely in core and move them to contrib. This would be done via a set of contrib projects so that a security issue in one component doesn't require a security release for unrelated components.

Some utilities could be grouped under a main jquery_ui project.

These modules could consist of an info and libraries file and the specific js or css currently in core/assets/vendor/jquery.ui.

example folder structure:

jquery_ui_[component]
 |_jquery.ui
 |  |_ui
 |  |  |_widgets
 |  |    |_[component]-min.js
 |  |
 |  |_themes
 |    |_base
 |      |_[component]-min.css
 |
 |_jquery_ui_[component].info.yml
 |_jquery_ui_[component].libraries.yml

example info file:

name: jQuery UI Droppable
type: module
description: 'Provides jQueryUI Droppable library.'
package: jQuery UI
core: 8.x
dependencies:
    - jquery_ui
    - jquery_ui_draggable        

The libraries file would be identical to what is currently in core.libraries.yml except for updated paths to files and dependent libraries.

Proposed list of modules, starting with the modules that can be currently marked deprecated:

• jquery_ui - this project page already exists but has not had activity since jQuery UI went into core. It would be great if we could use this as the namespace for this new module.
  It could include jQuery "core" files as well as some utilities depended on by the other libraries.
  • jquery.ui
  • jquery.ui.widget (required by nearly all the other libraries)
  • jquery.ui.mouse (required by slider, selectable, draggable)
  • jquery.ui.position (required by selectmenu, tooltip)
• jquery_ui_accordion - jquery.ui.accordion
• jquery_ui_button - jquery.ui.button - not in the deprecated list but required by spinner.
• jquery_ui_checkboxradio - jquery.ui.checkboxradio
• jquery_ui_controlgroup - jquery.ui.controlgroup
• jquery_ui_draggable - jquery.ui.draggable - not in the deprecated list but required by droppable.
• jquery_ui_droppable - jquery.ui.droppable
• jquery_ui_effects - since the individual effects depend on jquery.ui.effects.core it's more convenient to package them together.
  • jquery.ui.effects.core
  • jquery.ui.effects.blind
  • jquery.ui.effects.bounce
  • jquery.ui.effects.clip
  • jquery.ui.effects.drop
  • jquery.ui.effects.explode
  • jquery.ui.effects.fade
  • jquery.ui.effects.fold
  • jquery.ui.effects.highlight
  • jquery.ui.effects.puff
  • jquery.ui.effects.pulsate
  • jquery.ui.effects.scale
  • jquery.ui.effects.shake
  • jquery.ui.effects.size
  • jquery.ui.effects.slide
  • jquery.ui.effects.transfer
• jquery_ui_menu - jquery.ui.menu - not in the deprecated list but required by selectmenu.
• jquery_ui_progressbar - jquery.ui.progressbar
• jquery_ui_selectable - jquery.ui.selectable
• jquery_ui_selectmenu - jquery.ui.selectmenu
• jquery_ui_slider - jquery.ui.slider
• jquery_ui_spinner - jquery.ui.spinner
• jquery_ui_tooltip - jquery.ui.tooltip

Remaining tasks

None.

User interface changes

None.

API changes

A number of jQuery UI asset libraries are deprecated. See the change record and proposed resolution.

Data model changes

None.

Release notes snippet

jQuery UI asset libraries that are not used by Drupal core have been deprecated.

Problem/Motivation

Followup from #2218039: Render the maintenance/install page like any other HTML page.

Bring file name patterns in line with core standards.

Address theme suggestions as well, for example, page__maintenance.

Proposed resolution

Use core's template suggestions and rename templates and related preprocess functions

User interface changes

None.

API changes

removal of theme keys maintenance_page& install_page

Template name changes.
maintenance_page => page--maintenance
install_page => page--maintenance--install
maintenance_page__offline => page__maintenance__offline

preprocess functions moved to system module
template_preprocess_maintenance_page() => system_preprocess_page__maintenance()
template_preprocess_install_page => system_preprocess_page__maintenance__install()

Beta phase evaluation

Original report by @jessebeach

Problem/Motivation

Right now, if a fatal error or an exceptions occurs while performing an ImageToolkitOperation, we get WSOD as these events are not captured by ImageToolkitBase::apply.

This was already discovered in #2583041: [PP-2] GD toolkit & operations should check for available memory.

Proposed resolution

In 8.8.x where we only support PHP 7+, we can catch a \Throwable that will cover all cases not managed.

Remaining tasks

Review

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Problem/Motivation

• Per #3051352: [Plan] Remove unused jQuery UI components and replace with a suite of contrib packages for the continuous upgrade path, we need to stop depending on jQuery UI.
• jQuery UI includes a bunch of sub-libraries. This issue is just about the jquery.ui.sortable library. Other issues can be opened for the other libraries.
• 3 of Drupal core's modules currently depend on jquery.ui.sortable: ckeditor, media_library, and layout_builder.

Proposed resolution

• Decide on a replacement library. https://github.com/SortableJS/Sortable might be a good option to evaluate, in that it seems popular (in terms of github stars and forks), actively maintained (looking at recent issue fixes and releases), and the comparison video looks impressive.
• Switch ckeditor, media_library, and layout_builder to use the replacement library.
• Deprecate jquery.ui.sortable (e.g., emit a deprecation notice for modules/themes that depend on it).

Remaining tasks

• Decide on the replacement library.
• More tasks TBD once that's decided.

User interface changes

API changes

• Whichever replacement library is chosen will likely have a different JS API than jquery.ui.sortable. Decide whether we need to provide a bridge/facade, or whether it's ok to require contrib modules to change their JS code to the new API.

Data model changes

Release notes snippet

Problem/Motivation

We are in the process of deprecating jQuery UI in core. The jQueryUI position library is among the components that need to be removed/replaced.
As mentioned in the parent issue: #3067261: [Plan] Remove jQuery UI components used by Drupal core and replace with a set of supported solutions
The OpenJS Foundation lists jQuery UI as an Emeritus project in https://openjsf.org/projects/ which is described as:

Emeritus projects are those which the maintainers feel have reached or are nearing end-of-life

Proposed resolution

In core, jQueryUI Position is primarily used by other jQuery UI libraries that will be deprecated. There is one instance where it is used in isolation and must be specifically addressed: the Quickedit module. This means this issue is essentially finding a new library for Quickedit's positioning

Some options

• https://github.com/HubSpot/tether (probably a bad option, Hubspot was impressibly candid about no longer maintaining this)
• https://github.com/FezVrasta/popper.js (recommended by Hubspot as a well maintained alternative)

Rule out libraries that shouldn't be used due to abandonment, performance, etc.
Create a prototype for the remaining libraries to be used in place of jQuery UI for quickedit's positioning
If prototype appears to function well, get signoff from Quickedit maintainer.

User interface changes

Ideally, there will be none. Any changes shouldn't be more than a mildly noticeable pixel difference

API changes

...

Data model changes

N/A

Release notes snippet

...

Enter a descriptive title (above) relating to class LanguageNegotiator, then describe the problem you have found:

When implementing a custom LanguageNegotiator that implements a LanguageSwitcherInterface, placing this custom languagenegotiator on top of the negotiators list, does not result in the getLanguageSwitchLinks being called first.

Looking at the calling code we see that the order of the enabled negotiators is made obsolete by a array_intersect_key call.

API page: https://api.drupal.org/api/drupal/core%21modules%21language%21src%21Lang...

public function getNegotiationMethods($type = NULL) {
    $definitions = $this->negotiatorManager->getDefinitions(); <== These are not ordered by weight
    if (isset($type)) {
      $enabled_methods = $this->getEnabledNegotiators($type); <== These are ordered by weight
      $definitions = array_intersect_key($definitions, $enabled_methods);  <== This array_intersect_key call removes the order.

      uasort($array, function($a, $b) { return $a['weight'] > $b['weight']; }); <== We need this added
    }
    return $definitions;
  }

Problem/Motivation

Output of composer outdated -D on PHP 7.0

doctrine/annotations         v1.2.7  v1.4.0   Docblock Annotations Parser
doctrine/common              v2.6.2  v2.7.3   Common Library for Doctrine projects
egulias/email-validator      2.1.7   2.1.8    A library for validating emails against several RFCs
masterminds/html5            2.3.0   2.6.0    An HTML5 parser and serializer.
paragonie/random_compat      v2.0.18 v9.99.99 PHP 5.x polyfill for random_bytes() and random_int() from PHP 7
pear/archive_tar             1.4.6   1.4.7    Tar file management class with compression support (gzip, bzip2, lzma2)
symfony-cmf/routing          1.4.1   2.0.3    Extends the Symfony2 routing component for dynamic routes and chaining several routers
symfony/class-loader         v3.4.26 v3.4.28  Symfony ClassLoader Component
symfony/console              v3.4.26 v3.4.28  Symfony Console Component
symfony/dependency-injection v3.4.26 v3.4.28  Symfony DependencyInjection Component
symfony/event-dispatcher     v3.4.26 v3.4.28  Symfony EventDispatcher Component
symfony/http-foundation      v3.4.27 v3.4.28  Symfony HttpFoundation Component
symfony/http-kernel          v3.4.26 v3.4.28  Symfony HttpKernel Component
symfony/process              v3.4.26 v3.4.28  Symfony Process Component
symfony/routing              v3.4.26 v3.4.28  Symfony Routing Component
symfony/serializer           v3.4.26 v3.4.28  Symfony Serializer Component
symfony/translation          v3.4.26 v3.4.28  Symfony Translation Component
symfony/validator            v3.4.26 v3.4.28  Symfony Validator Component
symfony/yaml                 v3.4.26 v3.4.28  Symfony Yaml Component
twig/twig                    v1.38.4 v2.11.3  Twig, the flexible, fast, and secure template language for PHP
typo3/phar-stream-wrapper    v2.1.2  v3.1.2   Interceptors for PHP's native phar:// stream handling
zendframework/zend-diactoros 1.4.1   1.8.6    PSR HTTP Message implementations
zendframework/zend-feed      2.7.0   2.12.0   provides functionality for consuming RSS and Atom feeds

Proposed resolution

Updated these packages.

Remaining tasks

Create a patch.
Review.
Commit.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Our PHP dependencies have been updated. This includes
- Removing symfony/polyfill-iconv (v1.11.0)
- Updating doctrine/lexer (v1.0.1 => 1.0.2)
- Updating doctrine/inflector (v1.1.0 => v1.2.0)
- Updating doctrine/collections (v1.3.0 => v1.4.0)
- Updating doctrine/annotations (v1.2.7 => v1.4.0)
- Updating doctrine/common (v2.6.2 => v2.7.3)
- Updating egulias/email-validator (2.1.7 => 2.1.8)
- Updating pear/archive_tar (1.4.6 => 1.4.7)
- Updating symfony/class-loader (v3.4.26 => v3.4.28)
- Updating symfony/debug (v3.4.26 => v3.4.28)
- Updating symfony/console (v3.4.26 => v3.4.28)
- Updating symfony/dependency-injection (v3.4.26 => v3.4.28)
- Updating symfony/http-foundation (v3.4.27 => v3.4.28)
- Updating symfony/event-dispatcher (v3.4.26 => v3.4.28)
- Updating symfony/http-kernel (v3.4.26 => v3.4.28)
- Updating symfony/process (v3.4.26 => v3.4.28)
- Updating symfony/routing (v3.4.26 => v3.4.28)
- Updating symfony/serializer (v3.4.26 => v3.4.28)
- Updating symfony/translation (v3.4.26 => v3.4.28)
- Updating symfony/validator (v3.4.26 => v3.4.28)
- Updating symfony/yaml (v3.4.26 => v3.4.28)
- Updating twig/twig (v1.38.4 => v1.42.2)
- Updating zendframework/zend-diactoros (1.4.1 => 1.7.2)
- Updating zendframework/zend-stdlib (3.0.1 => 3.2.1)
- Updating zendframework/zend-escaper (2.5.2 => 2.6.0)
- Updating zendframework/zend-feed (2.7.0 => 2.12.0)
- Updating symfony/dom-crawler (v3.4.26 => v3.4.28)
- Updating symfony/browser-kit (v3.4.26 => v3.4.28)
- Updating symfony/css-selector (v3.4.26 => v3.4.28)
- Updating symfony/phpunit-bridge (v3.4.26 => v3.4.28)

I created new content of the default type Article.
Tittle 'Test'
Url alias '/test'

Result is a Internal Server Error when viewing the article.

Change the URL Alias to '/test_1'.
Problem still the same

Change the URL alias to '/MyTest'
Now the content is viewed correctly.

Regards,
Wim

Problem/Motivation

As it turned out in #2500525: Time ago/hence date/time formatting breaks caching; needs appropriate max age and #2686409: Time Ago summary does not render on Manage Display for Timestamp and Datetime fields the TimestampAgoFormatter formatter outputs a string that is very hard to cache. A time difference interval string changes very often making it uncacheable and then the whole page become uncacheable. The big problem here is that we return a string from the server that is refreshes very often. Using a max-age strategy works but it has the drawback of being very bad for the user experience.

Proposed resolution

1. Use the default TimestampFormatter formatter to show also a time difference formatted dates and deprecate TimestampAgoFormatter EDIT: The deprecation is discussed in #2938705: Consider deprecating TimestampAgoFormatter.
2. Add a new "Display as a time difference" option (as checkbox) in TimestampFormatter settings. When this setting is On, a jQuery snippet replaces the current output of the formatter, which is a human readable formatted date/time, with a Display as a time difference string expression. Also the "Display as a time difference" settings will be visible and configurable.
3. The time difference replacement is formatted using a jQuery snippet that converts the actual PHP time difference functionality.

Pros of this solution:

• Assures a dynamic time difference that can be refreshed by JS with an interval that should be configured in the formatter.
• Is cacheable.
• Degrades nice to a normal formatted date/time for non-JS browsers.

Additional improvements:

• Use the <time ...> HTML5 element.
• Add a title (tooltip) to <time ...> so that while displaying a time difference string, the user still can see the exact time by hovering with the mouse. The format of the tooltip should be configurable apart from the main date format because we may want a more detailed format than the main one.
• Allow configuration of time difference string pattern as the actual TimeAgoFormatter does.

Remaining tasks

• Add tests.
• Add a post update script to fix configurations of existing entity view displays that are using the TimestampFormatter.
• Add update path test.
• Open a followup for the datetime.module corresponding formatter.

User interface changes

• For site builders: New options in TimestampFormatter settings.
• For users: "Time difference" dates will be up-to-date (no cached) and will refresh in the client browser on a specific interval.

API changes

Deprecated TimestampAgoFormatter formatter. EDIT: Moved to #2938705: Consider deprecating TimestampAgoFormatter.

Data model changes

New settings for TimestampFormatter formatter.

Problem/Motivation

The views mini pager templates provided by core are using a non-existing value for the pager's aria-labelledby attribute.

See:

1. Template in Views module
2. Template in Stable theme
3. Template in Classy theme

Proposed resolution

1. Create an id for the pagination heading and guarantee it's uniqueness. I think that the best place for this is template_preprocess_views_mini_pager() (see template_preprocess_pager()).
2. Use that id for the value of the aria-labelledby attribute of the pager's nav element AND as the id attribute of the pagination heading element, so we have to modify the templates (none of the tempates print the pager's {{ attributes }}, sadly).

Remaining tasks

Create a patch.

User interface changes

API changes

Data model changes

Release notes snippet

I noticed today that the views mini pager template file has a aria-labelledby attribute that references an id of pagination-heading which doesn't exist anywhere.

<nav role="navigation" aria-labelledby="pagination-heading">
    <h4 class="visually-hidden">{{ 'Pagination'|t }}</h4>
    <ul class="js-pager__items">
      {% if items.previous %}
        <li>
          <a href="{{ items.previous.href }}" title="{{ 'Go to previous page'|t }}" rel="prev"{{ items.previous.attributes|without('href', 'title', 'rel') }}>
            <span class="visually-hidden">{{ 'Previous page'|t }}</span>
            <span aria-hidden="true">{{ items.previous.text|default('‹‹'|t) }}</span>
          </a> 

I'd expect the code to be more like:

<nav role="navigation" aria-labelledby="pagination-heading">
    <h4 id="pagination-heading"  class="visually-hidden">{{ 'Pagination'|t }}</h4>
    <ul class="js-pager__items">
      {% if items.previous %}
        <li>
          <a href="{{ items.previous.href }}" title="{{ 'Go to previous page'|t }}" rel="prev"{{ items.previous.attributes|without('href', 'title', 'rel') }}>
            <span class="visually-hidden">{{ 'Previous page'|t }}</span>
            <span aria-hidden="true">{{ items.previous.text|default('‹‹'|t) }}</span>
          </a> 

Seems to be in both the module template file as well as in the Stable and Classy themes.