Problem/Motivation

When running `composer scaffold` (or other Composer command such as `composer install` that end up calling scaffold), a list of every file processed is printed.

In general, this information is useful; however, it is re-printed on every single run of the scaffold operation, leading to very verbose output. In contrast, other Composer commands, e.g. `composer install`, only print output when they are actually doing something, and remain silent in other cases, e.g. if a package has already been downloaded.

Proposed resolution

Do not scaffold a file unless the on-disk version differs from what would be written. Show the scaffold information only for files that are actually written.

Remaining tasks

Commit

User interface changes

Users no longer see excessive information about scaffold files being re-copied at the end of every composer command (install, update, etc).

API changes

None. Only internal to composer plugins (which aren't API).

Data model changes

None.

Release notes snippet

The output of the `composer scaffold` command is now much less verbose. Scaffold operations are only displayed on the first run, or when a file is changed (e.g. rewritten).

Problem/Motivation

#2510104: Convert drupalSettings from JavaScript to JSON, to allow for CSP in the future could potentially be backported to 7.x

Proposed resolution

Remaining tasks

Copy the last 7.x patch from the original 8.x issue, and continue.

User interface changes

API changes

Data model changes

Problem/Motivation

Automated tests greatly increase the size of a bare Drupal installation on disk. (As of 609912bced (8.8.x, July 15, 2019), they accounted for 43M of 94M (46%).) And they provide no benefit to end users in production. Indeed, they can contribute to security vulnerabilities and other problems. The number and size of files can also be a problem for users of shared hosting (c.f. #2338671: Create a smaller Drupal core download, removing tests, for production sites.), and they needlessly increase download and transfer times and disk usage for everyone, including drupal.org.

Proposed resolution

Use the approach documented in Use gitattributes to keep your tests out of other people’s production to exclude all tests/ directories from release packages. Since the Drupal.org packaging system already uses git-archive to create releases, the change would involve nothing more than the addition of a few lines to our .gitattributes file and would take effect immediately. Note: This would have no effect on Git clones, so neither the testbot nor core contributors would be affected.

Remaining tasks

• Consider possible unintended consequences.
• Review/test (forthcoming) patch.
• Probably write a change notice.
• Decide when to commit/release the change.

User interface changes

If tests can be considered to belong to the user interface in any sense, the change is that they will disappear from tarballs.

Release notes snippet

TBD.

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the breakpoint, color, layout_builder, layout_discovery, and field_layout modules.

Also the parts of the system module related to installing/uninstalling/configuring themes.

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
   

     switch ($route_name) {
       case 'help.page.contact':
   

   And ends either at the end of the function, or where you find another case 'something': line.

3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig (and "MODULENAME" can be "core" as discussed above).
7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

1. Apply the patch.
2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
4. Review the topic text that you can see on the page, making sure of the following aspects:
   • The text is written in clear, simple, straightforward language
   • No grammar/punctuation errors
   • Valid HTML -- you can use http://validator.w3.org/ to check
   • Links within the text work
   • Instructions for tasks work
   • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the views, views_ui module(s).

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
   

     switch ($route_name) {
       case 'help.page.contact':
   

   And ends either at the end of the function, or where you find another case 'something': line.

3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig (and "MODULENAME" can be "core" as discussed above).
7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

1. Apply the patch.
2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
4. Review the topic text that you can see on the page, making sure of the following aspects:
   • The text is written in clear, simple, straightforward language
   • No grammar/punctuation errors
   • Valid HTML -- you can use http://validator.w3.org/ to check
   • Links within the text work
   • Instructions for tasks work
   • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

We should update all of core's remaining JavaScript dependencies prior to 9.0.0-beta1, including any major version updates that may be available. This includes dependencies listed in package.json.

Proposed resolution

Here's a table of all core JavaScript dependencies in the package.json, and the latest versions of the packages.

Major

Minor

Patch

Remaining tasks

core_field_views_data() provides reverse relationships for entity reference fields, but this is only for config fields.

For base fields on entities, such as the node uid field, core entity modules have to implement this themselves.

Eg UserViewsData::UserViewsData():

    $data['users_field_data']['uid']['relationship'] = array(
      'title' => t('Content authored'),
      'help' => t('Relate content to the user who created it. This relationship will create one record for each content item created by the user.'),
      'id' => 'standard',
      'base' => 'node_field_data',
      'base field' => 'uid',
      'field' => 'uid',
      'label' => t('nodes'),
    );

Problem/Motivation

Follow up to #3075695: Move search_index() and related functions to a service there are a number of text processing/tokenisation functions that can be moved to a service and deprecated. This includes:

• search_index_split()
• search_simplify()
• search_expand_cjk()

Proposed resolution

Move them to a SearchTokenizer service and deprecate.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the menu_link_content, menu_ui module(s).

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
   

     switch ($route_name) {
       case 'help.page.contact':
   

   And ends either at the end of the function, or where you find another case 'something': line.

3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig (and "MODULENAME" can be "core" as discussed above).
7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

1. Apply the patch.
2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
4. Review the topic text that you can see on the page, making sure of the following aspects:
   • The text is written in clear, simple, straightforward language
   • No grammar/punctuation errors
   • Valid HTML -- you can use http://validator.w3.org/ to check
   • Links within the text work
   • Instructions for tasks work
   • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Ignore! Testing issue.

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the ckeditor, editor module(s).

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
   

     switch ($route_name) {
       case 'help.page.contact':
   

   And ends either at the end of the function, or where you find another case 'something': line.

3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig (and "MODULENAME" can be "core" as discussed above).
7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

1. Apply the patch.
2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
4. Review the topic text that you can see on the page, making sure of the following aspects:
   • The text is written in clear, simple, straightforward language
   • No grammar/punctuation errors
   • Valid HTML -- you can use http://validator.w3.org/ to check
   • Links within the text work
   • Instructions for tasks work
   • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

In a Drupal 8.8.1 project I'm trying to exclude Devel and Webprofiler contrib modules configs from being exported while running drush cex command, for that I used the new Drupal 8.8.0 feature configs exclude by setting the array of excluded module in settings.local.php as bellow:
$settings['config_exclude_modules'] = ['devel', 'webprofiler'];
But the following modules configs are still exported into the sync directory:

• devel.settings.yml
• devel.toolbar.settings.yml
• webprofiler.config.yml

Any idea why this behavior occur?

Problem/Motivation

After adding a custom block you can find the custom block in the list of admin/structure/block, but you are not provided with a link to edit this block.

To actually edit the block you have to switch to the "Custom block library" admin/structure/block/block-content, to find the contextual "Edit" link you are looking for.

This is very puzzeling, especially if you manage to create your new block on admin/structure/block by clicking "Place block" near a region header and follow "Add custom block" in the dialog. This way you are able to create a block without ever visiting the "Custom block library".

Proposed resolution

Add an "Edit" link for custom blocks in admin/structure/block.

Remaining tasks

- Add contextual links
- Write/adapt tests

User interface changes

- Custom block have an extra link in the list of admin/structure/block.

Original issue summary

Referring to http://drupal.stackexchange.com/questions/144133/contextual-links-for-cu...

"I have created a custom block type and it would be wonderful to have a link in the block dropbutton: "Edit block content"."

thanks and regards
sb

Problem/Motivation

Spun off from #3087644: Remove Drupal 8 updates up to and including 88** where we identified that trying to remove all updates in one go resulted in an enormous patch that was too difficult to review.

Proposed resolution

As per #79 from that issue, we can try and remove update hooks and tests from system.module on their own.

Remaining tasks

Figure out what else is needed for patch to pass.

Problem/Motivation

Drupal 9 will once again allow hook_update_N() to be used between major versions.

However, database updates still regularly introduce bugs, since they often run up against issues on real sites, such as corrupted data, or incompatibilities with contributed and custom schema changes/additions. Also sites that run into upgrade path issues and report them to the issue queue are not always run by people who can debug upgrade path issues themselves.

Proposed resolution

• Remove all updates added prior to Drupal 8.8.0-rc1 from Drupal 9.
• Remove all real legacy update tests

This will mean that sites still on Drupal 8.7 or lower, will need to update to Drupal 8.8.0 or later, prior to updating to Drupal 9.

There are various advantages to this:

1. Old upgrade path bugs from Drupal 8.5/8.6 can no longer be fixed in Drupal 8.7 but they can still be backported to Drupal 8.8. Therefore for sites running out of date core versions, getting them onto 8.8 first means they have the best chance of a smooth minor upgrade path before the major one.

2. Old updates may rely on deprecated APIs that are being removed in Drupal 9, and re-writing upgrade paths risk introducing new regressions.

3. Ensuring that every Drupal 8 site is on Drupal 8.8 or 8.9 before they update to Drupal 9 will drastically reduce the variables when upgrade paths are reported (compared to letting people update from Drupal 8.4 to Drupal 9 directly).

4. Contributed modules will also need to be updated to their latest versions prior to moving to Drupal 9, so ensuring core installs do this is encouragement to update contrib too.

Remaining tasks

Create a patch

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Drupal 8 upgrade path has been removed.

Problem/Motivation

Hreflang links were pointing to the actual node view page ("node/9") instead of just front ("/") when using that node as a front page (google sent a notification about the issue).

Proposed resolution

Don't create hreflang links from the entity route, just add the languages prefix to root path.

It seems that the current implementation of the alternate hreflang links for the entities is not yet optimal in regard of the following:

Replace html_head_link by html_head

#2873648: With many languages, content_translation_page_attachments adds too many alternate links to the response headers crashing varnish (503)

Was there a reason to set it in html_head_link? Anyway, with this problem or not, it's recommended to use only 1 method for the alternate hreflang (among the 3 methods: meta html, http header, sitemap xml ; see the global SEO recommendations) and html_head_link generate meta html + http header.
I guess it should be set in html_head by default (the most safe we will said) and if someone needs these links to be in the http headers for some specific technical/SEO reason, he can always duplicate/move the existing generated links via some alter, knowing his own environment configuration. At least, "immediately", doing that for the alternate hreflang links in our context (the last comment let suppose that the problem is larger (?)).

Include the hreflang in the key

#2945033: HtmlHeadLink processing does not allow for duplicated alternate hreflang links

Knowing this issue and the previous one, it it move in html_head only, the key should be something like:

languages:rel:hreflang:href

Wrong hreflang values

#2926013: Alternative language link tag being set for content with language "not specificed"
#2811533: wrong hreflang-values for non-translated pages in multi-language environment

The "not applicable" and "not specified" code languages are not valid for the alternate hreflang links context.
If the hreflang is equal to "zxx" (LANGCODE_NOT_APPLICABLE) or "und" (LANGCODE_NOT_SPECIFIED), it should be replace by "x-default" (LANGCODE_DEFAULT) or the alternate link should not be generated.

Hreflangs links when using specific node as a front page

#2796399: Problematic hreflang links when using entity as front page.

No direct issue for the moment, but should be considered

• 403/404

Global solution

#2303525: Provide link tags to alternate languages (hreflang) in HTML head (last comments)
#2521782: HTML head has alternate hreflang links to unpublished translations

For these issues and for what the hreflang module trying to do in his own.
And following this issue that i've just created recently #2994575: Url access / PathValidator not language/options aware

I guess that what is in content_translation_page_attachments currently should be moved in the language module and manage directly by the path (via some PathValidator), not the route object (view, entity, webform or whatever...), having to duplicate the code logical in multiple modules/places to generate these links (to avoid all the potential problems indicated above and below). Doing like should permit to go through all the access/security layers of what is behind a path and automatically managed any new layer of access added by any kind of modules (if done the "official" way we agree).

On a different note, as indicated in #2994575: Url access / PathValidator not language/options aware. Going that way, it could help to some replacement of the current getLanguageSwitchLinks, or just an addition, to improve the current 'frontend' language switcher? For something more aware-access, relevant for the "80% scenario case" (?).

Example

Below just to give some idea for all the points above, a raw and not really tested php:

function language_get_translations_for_route() {

  // 404/404 case
  if(\Drupal::requestStack()->getCurrentRequest()->attributes->get('exception')) {
    return [];
  }

  // Locked languages case (zxx, und, ...)
  foreach(\Drupal::routeMatch()->getParameters() as $p) {
    if(is_object($p) && method_exists($p, 'language') && $p->language()->isLocked()) {
      return [];
    }
  }

  $paths = [];

  if (\Drupal::languageManager()->isMultilingual()) {

    $languages = \Drupal::languageManager()->getLanguages(LanguageInterface::STATE_CONFIGURABLE);

    foreach ($languages as $lang) {

      $url = Url::fromRoute('<current>', [], ['language' => $lang]);

      //if ($url) {

        $path =[
          'language' => $lang,
          'access' => FALSE,
        ];

        // Permission/access-layers case
        if (\Drupal::pathValidator()->getUrlIfValid($url->toString())) {
          $path['access'] = TRUE;
        }

        // Frontpage case (managed because of the "canonical" situation (see related issues))
        if (\Drupal::service('path.matcher')->matchPath('/' . $url->getInternalPath(),'<front>')) {
          $url = Url::fromRoute('<front>', [], ['language' => $lang]);
        }

        $path['url'] = $url->toString();
        $path['url_absolute'] = $url->setAbsolute()->toString();

        $paths[] = $path;
      //}
    }
  }

  return $paths;
}

function language_page_attachments(&$page) {

  foreach(language_get_translations_for_route() as $translated_path) {

    if ($translated_path['access']) {

      $hreflang = $translated_path['language']->getId();

      // Html_head case
      $page['#attached']['html_head'][] = [
        [
          '#tag' => 'link',
          '#attributes' => [
            'rel' => 'alternate',
            'hreflang' => $hreflang,
            'href' => $translated_path['url_absolute'],
          ],
        ],
        // Key case
        'language:alternate:' . $hreflang . ':' . $translated_path['url_absolute'],
      ];

    }

  }
}

I want to fetch the max resolution thumbnail from YouTube (1280x720), but OEmbed is providing only the the 480x360 thumbnail URL and there is currently no way to override that. Could a hook be provided to alter the OEmbed data? Currently one can only change the OEmbed url via hook_oembed_resource_url_alter().

{
  "author_url": "https://www.youtube.com/user/ZackScott",
  "provider_name": "YouTube",
  "height": 270,
  "thumbnail_width": 480,
  "thumbnail_height": 360,
  "width": 480,
  "version": "1.0",
  "html": "<iframe width=\"480\" height=\"270\" src=\"https://www.youtube.com/embed/M3r2XDceM6A?feature=oembed\" frameborder=\"0\" allow=\"accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen></iframe>",
  "title": "Amazing Nintendo Facts",
  "provider_url": "https://www.youtube.com/",
  "thumbnail_url": "https://i.ytimg.com/vi/M3r2XDceM6A/hqdefault.jpg",
  "author_name": "ZackScott",
  "type": "video"
}

Problem/Motivation

Spun off from #3087644: Remove Drupal 8 updates up to and including 88** where we identified that trying to remove all updates in one go resulted in an enormous patch that was too difficult to review.

Proposed resolution

As per #79 from that issue, we can try and remove update tests from modules other than system.module, then remove the update hooks themselves.

Remaining tasks

Figure out what else is needed for patch to pass.

Follow up to #2044435: Convert pager.inc to a service

+++ b/core/lib/Drupal/Core/Pager/PagerManagerInterface.php
@@ -0,0 +1,153 @@
+   *   $where = "status = 1";
+   *   $total = mymodule_select("SELECT COUNT(*) FROM data " . $where)->result();
+   *   $num_per_page = \Drupal::config('mymodule.settings')->get('num_per_page');

@catch:

I'm sure this is copy/pasted but there's no need for $where to be a variable here. Would be good to update the docs to use selectquery or similar (in a follow-up, appreciate this is probably copy and paste from the old example).