Problem/Motivation

PHP 7.4 was released in November 2019. Drupal 7 is not yet compatible with it.

Proposed resolution

Solution broken down to various smaller issues for easier review (not necessarily in priority or dependency order):

• #3085163: Comment module incorrectly calls field_delete_field on uninstallation
• #3125824: Trying to access an array offset on value of type null in forum_get_topics()
• #3085148: Remove unneeded field_test_field_attach_delete_bundle()
• #3085151: field_ui_display_overview_form() expects to always get an array from field_info_formatter_types()
• #3085098: PHP Phar Stream Wrapper should be updated (PHP7.4 support, drop fileinfo dependency)
• #3087121: drupal_hmac_base64() should not blindly cast everything to string causing PHP notices/errors
• #3118301: Curly brace syntax for accessing array elements and string offsets has been deprecated in PHP 7.4
• #3126133: NumberFieldTestCase uses non-existing formatter number_float
• #3126138: taxonomy_update_7004() uses non-existing widget "select"
• #3126140: PHP 7.4 notice in run-test.sh
• #3126312: PHPCompatibility 7.3: Since PHP 7.0, functions inspecting arguments, like func_get_args(), no longer report the original value as passed to a parameter, but will instead provide the current value.

Done:

• #3084943: Pass parameters as implode($glue, $pieces); reverse order is deprecated
• #3084955: Invalid characters passed for attempted conversion, these have been ignored in _color_unpack()
• #3084961: Trying to access array offset on value of type null in theme_pager/pager_first/pager_last/pager_previous/pager_next()
• #3084935: element_children() and DrupalRequestSanitizer::stripDangerousValues() should not use integer keys as array
• #3084945: Trying to access array offset on value of type null in _batch_finished()
• #3084953: Trying to access array offset on value of type null in _drupal_build_css_path()
• #3084965: Trying to access array offset on value of type bool in search_excerpt()
• #3084980: Trying to access array offset on value of type null in path_delete()
• #3085088: menu_get_item() might return FALSE; calling code should take account of this

Remaining tasks

Get all sub-issues to RTBC. Review and commit them all.

User interface changes

None.

API changes

Hopefully none. See sub-issues.

Data model changes

Hopefully none. See sub-issues.

Release notes snippet

This is the first Drupal 7 release to fully support PHP 7.4. Please test and report any bugs in the issue queue.

I am trying to upgrade my Drupal 8 from 8.8.0 to 8.8.4, I followed these instructions https://www.drupal.org/docs/8/update/update-core-via-composer. I couldnt find any anything on the following error at all doing a search.

I am getting the following error when running drush updb

[error]   (Currently using Missing or invalid modules Array)

In UpdateDBCommands.php line 55:

  Cancelled.


updatedb [--cache-clear [CACHE-CLEAR]] [--entity-updates] [--post-updates [POST-UPDATES]] [--                                             no-cache-clear] [--no-post-updates] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--vers                                             ion] [--ansi] [--no-ansi] [-n|--no-interaction] [-d|--debug] [-y|--yes] [--no] [--remote-host                                              REMOTE-HOST] [--remote-user REMOTE-USER] [-r|--root ROOT] [-l|--uri URI] [--simulate] [--pip                                             e] [-D|--define DEFINE] [--xh-link XH-LINK] [--notify [NOTIFY]] [--druplicon] [--] <command>

PHP Fatal error:  Uncaught Drupal\Core\Entity\Query\QueryException: 'is_default' not found in                                              /mysite/core/lib/Drupa l/Core/Entity/Query/Sql/Tables.php:367
Stack trace:
#0 /mysite/core/lib/Drupal/Core/Entity/Query/Sql/Tables.php(261): Drupal\Core\Entity\Query\Sql\Tables->ensureEntityT                                             able('', 'is_default', 'LEFT', NULL, 'base_table', 'store_id', Array)
#1 /mysite/core/lib/Drupal/Core/Entity/Query/Sql/Query.php(291): Drupal\Core\Entity\Query\Sql\Tables->addField('is_d                                             efault', 'LEFT', NULL)
#2 /mysite/core/lib/Drupal/Core/Entity/Query/Sql/Query.php(192): Drupal\Core\Entity\Query\Sql\Query->getSqlField('is                                             _default', NULL)
#3 /mysite/core/lib/Drupal/Core/Entity/Query/Sql/Query.php(81): Dr in /mysite/lib/Drupal/Core/Entity/Query/Sql/Tables.php on line 367

When I ran drush --debug I got the following.

[preflight] Redispatch to site-local Drush: /mysite/vendor/drush/drush/drush.
 [preflight] Config paths: /mysite/vendor/drush/drush/drush.yml
 [preflight] Alias paths: /mysite/drush/sites,/mysite/drush/sites
 [preflight] Commandfile search paths: /mysite/vendor/drush/drush/src
 [debug] Starting bootstrap to max [0.1 sec, 9.09 MB]
 [debug] Trying to bootstrap as far as we can [0.1 sec, 9.09 MB]
 [debug] Drush bootstrap phase: bootstrapDrupalRoot() [0.1 sec, 9.09 MB]
 [debug] Change working directory to /mysite/ [0.1 sec, 9.09 MB]
 [debug] Initialized Drupal 8.8.5 root directory at /mysite/ [0.11 sec, 9.22 MB]
 [debug] Drush bootstrap phase: bootstrapDrupalSite() [0.11 sec, 9.57 MB]
 [debug] Initialized Drupal site default at sites/default [0.11 sec, 9.74 MB]
 [debug] Drush bootstrap phase: bootstrapDrupalConfiguration() [0.11 sec, 9.74 MB]
 [debug] Add service modifier [0.12 sec, 9.99 MB]
 [debug] Drush bootstrap phase: bootstrapDrupalDatabase() [0.12 sec, 10.35 MB]
 [debug] Successfully connected to the Drupal database. [0.12 sec, 10.35 MB]
 [debug] Drush bootstrap phase: bootstrapDrupalFull() [0.12 sec, 10.35 MB]
 [debug] Start bootstrap of the Drupal Kernel. [0.12 sec, 10.35 MB]
 [info] advancedqueue should have an extra.drush.services section in its composer.json. See http://docs.drush.org/en/master/commands/#specifying-the-services-file. [0.28 sec, 13.4 MB]
 [debug] devel commands loaded even though its constraint (^9) is incompatible with Drush 10.2.2. Broaden the constraint in modules/contrib/devel/composer.json (see 'extra\drush\services' section) to remove this message. [0.28 sec, 13.5 MB]
 [info] devel_entity_updates should have an extra.drush.services section in its composer.json. See http://docs.drush.org/en/master/commands/#specifying-the-services-file. [0.28 sec, 13.5MB]
 [debug] scheduler commands loaded even though its constraint (^9) is incompatible with Drush 10.2.2. Broaden the constraint in modules/contrib/scheduler/composer.json (see 'extra\drush\services' section) to remove this message. [0.28 sec, 13.5 MB]
 [debug] simple_sitemap commands loaded even though its constraint (^9) is incompatible with Drush 10.2.2. Broaden the constraint in modules/contrib/simple_sitemap/composer.json (see 'extra\drush\services' section) to remove this message. [0.28 sec, 13.5 MB]
 [debug] Found drush.services.yml for token Drush commands [0.28 sec, 13.5 MB]
 [info] pathauto should have an extra.drush.services section in its composer.json. See http://docs.drush.org/en/master/commands/#specifying-the-services-file. [0.28 sec, 13.5 MB]
 [debug] Get container builder [0.29 sec, 13.51 MB]
 [debug] Service modifier alter. [0.29 sec, 13.61 MB]
 [debug] process drush.console.services console.command [0.46 sec, 19.28 MB]
 [debug] process drush.command.services drush.command [0.46 sec, 19.28 MB]
 [debug] Found tagged service config.commands [0.46 sec, 19.28 MB]
 [debug] Found tagged service config.export.commands [0.46 sec, 19.28 MB]
 [debug] Found tagged service config.import.commands [0.46 sec, 19.28 MB]
 [debug] Found tagged service batch.commands [0.46 sec, 19.28 MB]
 [debug] Found tagged service cli.commands [0.46 sec, 19.28 MB]
 [debug] Found tagged service drupal.commands [0.46 sec, 19.28 MB]
 [debug] Found tagged service entity.commands [0.46 sec, 19.28 MB]
 [debug] Found tagged service image.commands [0.46 sec, 19.28 MB]
 [debug] Found tagged service jsonapi.commands [0.46 sec, 19.28 MB]
 [debug] Found tagged service language.commands [0.46 sec, 19.29 MB]
 [debug] Found tagged service locale.commands [0.46 sec, 19.29 MB]
 [debug] Found tagged service messenger.commands [0.46 sec, 19.29 MB]
 [debug] Found tagged service queue.commands [0.46 sec, 19.29 MB]
 [debug] Found tagged service role.commands [0.46 sec, 19.29 MB]
 [debug] Found tagged service state.commands [0.46 sec, 19.29 MB]
 [debug] Found tagged service twig.commands [0.46 sec, 19.29 MB]
 [debug] Found tagged service user.commands [0.46 sec, 19.29 MB]
 [debug] Found tagged service views.commands [0.46 sec, 19.29 MB]
 [debug] Found tagged service watchdog.commands [0.46 sec, 19.29 MB]
 [debug] Found tagged service pm.commands [0.46 sec, 19.29 MB]
 [debug] Found tagged service theme.commands [0.46 sec, 19.29 MB]
 [debug] Found tagged service sanitize.commands [0.46 sec, 19.3 MB]
 [debug] Found tagged service sanitize.comments.commands [0.46 sec, 19.3 MB]
 [debug] Found tagged service sanitize.sessions.commands [0.46 sec, 19.3 MB]
 [debug] Found tagged service sanitize.userfields.commands [0.46 sec, 19.3 MB]
 [debug] Found tagged service sanitize.usertable.commands [0.46 sec, 19.3 MB]
 [debug] Found tagged service advancedqueue.commands [0.46 sec, 19.3 MB]
 [debug] Found tagged service devel.command [0.46 sec, 19.3 MB]
 [debug] Found tagged service devel_entity_updates.command [0.46 sec, 19.3 MB]
 [debug] Found tagged service scheduler.commands [0.46 sec, 19.3 MB]
 [debug] Found tagged service simple_sitemap.commands [0.46 sec, 19.3 MB]
 [debug] Found tagged service pathauto.commands [0.46 sec, 19.3 MB]
 [debug] process drush.command_info_alterer.services drush.command_info_alterer [0.46 sec, 19.3 MB]
 [debug] process drush.generator.services drush.generator [0.46 sec, 19.3 MB]
 [debug] Finished bootstrap of the Drupal Kernel. [0.96 sec, 33.78 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\config\ConfigCommands [1.36 sec, 51.76 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\config\ConfigExportCommands [1.37 sec, 51.79 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\config\ConfigImportCommands [1.37 sec, 51.8 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\core\BatchCommands [1.37 sec, 51.8 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\core\CliCommands [1.37 sec, 51.8 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\core\DrupalCommands [1.37 sec, 51.81 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\core\EntityCommands [1.37 sec, 51.82 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\core\ImageCommands [1.37 sec, 51.83 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\core\JsonapiCommands [1.37 sec, 51.84 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\core\LanguageCommands [1.37 sec, 51.85 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\core\LocaleCommands [1.37 sec, 51.86 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\core\MessengerCommands [1.37 sec, 51.87 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\core\QueueCommands [1.37 sec, 51.87 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\core\RoleCommands [1.37 sec, 51.88 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\core\StateCommands [1.38 sec, 51.9 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\core\TwigCommands [1.38 sec, 51.92 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\core\UserCommands [1.38 sec, 51.93 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\core\ViewsCommands [1.38 sec, 51.97 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\core\WatchdogCommands [1.39 sec, 52 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\pm\PmCommands [1.39 sec, 52.03 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\pm\ThemeCommands [1.39 sec, 52.04 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\sql\SanitizeCommands [1.39 sec, 52.05 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\sql\SanitizeCommentsCommands [1.39 sec, 52.05 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\sql\SanitizeSessionsCommands [1.39 sec, 52.05 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\sql\SanitizeUserFieldsCommands [1.39 sec, 52.05 MB]
 [debug] Add a commandfile class: Drush\Drupal\Commands\sql\SanitizeUserTableCommands [1.39 sec, 52.06 MB]
 [debug] Add a commandfile class: Drupal\advancedqueue\Commands\AdvancedQueueCommands [1.39 sec, 52.06 MB]
 [debug] Add a commandfile class: Drupal\token\Commands\TokenCommands [1.39 sec, 52.07 MB]
 [debug] Add a commandfile class: Drupal\devel_entity_updates\Commands\DevelEntityUpdatesCommands [1.39 sec, 52.07 MB]
 [debug] Add a commandfile class: Drupal\scheduler\Commands\SchedulerCommands [1.39 sec, 52.08 MB]
 [debug] Add a commandfile class: Drupal\simple_sitemap\Commands\SimplesitemapCommands [1.39 sec, 52.08 MB]
 [debug] Add a commandfile class: Drupal\pathauto\Commands\PathautoCommands [1.39 sec, 52.09 MB]
Drush Commandline Tool 10.2.2

Problem

Patches to entities that are have Entity Reference fields that are set to use a View as the reference method fail with a 500 error, and the dreaded leaked metadata message:

“"The controller result claims to be providing relevant cache metadata, but leaked metadata was detected. Please ensure you are not rendering content too early. Returned object class: Drupal\\jsonapi\\ResourceResponse.””

Steps to Reproduce

• New Drupal 8.7 install
• Standard install profile
• Enable JSON:API and Serialization modules
• Ensure JSON:API is set to accept all methods (GET, POST, PATCH, DELETE)
• Create new content type
• Create a test node of the new content type
• Create Entity Reference view against the new content type
• Add reference field to Article content type selecting content.
  • Change the reference Method to Views: Filter by an entity reference view
  • Set the view to the newly created reference view
• Create a test Article node in Drupal, referencing the test node of the new CT.
• Find the same article in the JSON:API article endpoint
• After authenticating with external client, attempt a PATCH of the same article. No changes need to be made to the data.
• Witness the 500 error response.
• Edit the Article content type and change the Reference method to Default and check the box next to the new test content type,
• Try the same PATCH operation
• Witness a 200 OK response.

Additional information

Initial investigations have pointed the issue may actually stem from over in Viewsland. When patchIndividual() is executed, it necessarily goes and validates the entity prior to saving. From there, it looks like when the reference field is validated, it uses the entity reference view to perform that validation. It would seem that views considers this an HTML View according to the comments in Views’ StylePluginBase - see lines 702-713:

// Views may be rendered both inside and outside a render context:
// - HTML views are rendered inside a render context: then we want to
//   use ::render(), so that attachments and cacheability are bubbled.
// - non-HTML views are rendered outside a render context: then we
//   want to use ::renderPlain(), so that no bubbling happens
if ($renderer->hasRenderContext()) {
  $renderer->render($data);
}
else {
  $renderer->renderPlain($data);
}

I can confirm that the error isn't thrown if you force the call through renderPlain().

Obviously, it would seem that the real issue might indeed be Views (why render the whole view like this for field validation?), or even in the caching system as a whole (why hit these cache problems when doing a PATCH?), but I haven’t had enough cycles to keep diving the rabbit hole and figured (with @gabesullice’s advice) to go ahead and open the issue here for further exploration and discussion.

It's possible to override the sql_mode options by doing this in your database definition in settings.php:

$databases['drupal6_csp']['default'] = array (
  'database' => 'drupal8',
  'username' => 'drupal',
  'password' => 'hello',
  'init_commands' => [
    'sql_mode' => "SET sql_mode = 'ANSI,STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER'",
  ],
);

However, it's an all or nothing override. Connection::open does this:

    $connection_options['init_commands'] += [
      'sql_mode' => "SET sql_mode = 'ANSI,STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,ONLY_FULL_GROUP_BY'",
    ];

so either I override the whole of that string, or none of it.

We could allow an 'sql_mode_options' array to override each one, eg:

$databases['drupal6_csp']['default'] = array (
  'database' => 'drupal8',
  'username' => 'drupal',
  'password' => 'hello',
  'init_commands' => [
    'sql_mode_options' => [
      // I don't want this one.
      'ONLY_FULL_GROUP_BY' => FALSE,
      // I do want this one.
      'CAKE' => TRUE,
      // Anything I don't specify, I'm happy with core's default.
    ],
  ],
);

Problem/Motivation

In #3087685: Remove deprecated jQuery UI components and fork remaining source code into core jQuery UI code was added from the last tagged release at https://github.com/jquery/jquery-ui/tree/1.12.1
to Drupal core/assets/vendor/jquery.ui

Now, any security fixes or other improvements can be made directly to the jQuery UI files in core, and the minified files can be regenerated by running yarn build:jqueryui.

However, jQuery UI uses its own coding standards and the entire core/assets/vendor/**/* directory is ignored in .eslintrc so there are no guidelines to follow or linting standards to enforce.

Another potential problem would be if a future developer writing es6 or later js which would not get transpiled during minification.

Proposed resolution

Define coding standards
Document coding standards, possibly add an .eslintrc file to this folder.
Consider whether coding standards need to be addressed for other projects in core/assets/vendor such as Backbone, CKEditor, jQuery.

Remaining tasks

Problem/Motivation

The uninstall box for Layout Builder is grayed out with the message

The Layout Section field type is used in the following field: node.layout_builder__layout

The "Manage Fields" page shows the Layout field as locked.
The "Manage Display" page says

You must revert all customized layouts of this display before you can disable this option.

Without individually checking each node, there is no way to determine which must be reverted

Proposed resolution

• A "Revert All" button on Manage Display that works for only that single bundle. This will appear in the "Layout options" fieldset.
• This button is only visible if the layout has overrides
• When this button is visible, the "Use Layout Builder" and "Allow each content item to have its layout customized." fields are grayed out
• This button will first take the user to a confirmation form, to confirm they're OK with all overrides being deleted.
• After confirming, Layout Builder will be disabled for that display and all overrides in that bundle will be removed from the database (including revisions) and remove all tempstore data for overrides in that bundle

Remaining tasks

Review
Write tests.

User interface changes

The Manage Display UI will be slightly different see ^^Proposed Resolution for details.

API changes

N/A

Data model changes

N/A

"Exposed items per page options" should accept either ranges, e.g. 1-100, or a limit value, e.g. 100.

This would allow requesting any number of items within the range, or under the limit value.

As of now, to request a specific number of items in my example of 1 to 100, the "Exposed items per page options" option would have to be configured like:
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, ..., 100

which is not ideal.

Ideally, I should just be able to specify "100", and then I could request an arbitrary number of items under 100. As it stands now, if I set the value to 100 and then try to select 50 items, views throws an error.

Problem/Motivation

Contrib/custom database drivers are not in the Drupal\Core\Database namespace, and in this case Log::findCaller will not report the caller correctly, but just the first function/method coming after the first call to the database connection, or worse after a vendor namespaced method if the driver implements methods there.

Incurred into this while experimenting a db driver https://github.com/mondrake/drudbal in conjuction with #2605284: Testing framework does not work with contributed database drivers, and getting failure for the LoggingTest.

See the trace below: in this case the identified 'caller' is always 'query' since it's the first method coming after either not namespaced or not into Drupal\Core\Database namespace.

    [0] => Drupal\Core\Database\Log -> findCaller
    [1] => Drupal\Core\Database\Log -> log
    [2] => Drupal\Core\Database\Statement -> execute
    [3] => Doctrine\DBAL\Statement -> execute
    [4] => Drupal\Driver\Database\dbal\Connection -> query
    [5] =>  -> db_query
    [6] => Drupal\drudbal\Tests\LoggingTest -> testEnableLogging
    [7] => Drupal\simpletest\TestBase -> run
    [8] =>  -> _simpletest_batch_operation
    [9] =>  -> _batch_process
    [10] =>  -> _batch_do
    [11] =>  -> _batch_page
    [12] => Drupal\system\Controller\BatchController -> batchPage
    [13] =>  -> call_user_func_array
    [14] => Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber -> Drupal\Core\EventSubscriber\{closure}
    [15] => Drupal\Core\Render\Renderer -> executeInRenderContext
    [16] => Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber -> wrapControllerExecutionInRenderContext
    [17] => Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber -> Drupal\Core\EventSubscriber\{closure}
    [18] =>  -> call_user_func_array
    [19] => Symfony\Component\HttpKernel\HttpKernel -> handleRaw
    [20] => Symfony\Component\HttpKernel\HttpKernel -> handle
    [21] => Drupal\Core\StackMiddleware\Session -> handle
    [22] => Drupal\Core\StackMiddleware\KernelPreHandle -> handle
    [23] => Drupal\page_cache\StackMiddleware\PageCache -> pass
    [24] => Drupal\page_cache\StackMiddleware\PageCache -> handle
    [25] => Drupal\Core\StackMiddleware\ReverseProxyMiddleware -> handle
    [26] => Drupal\Core\StackMiddleware\NegotiationMiddleware -> handle
    [27] => Stack\StackedHttpKernel -> handle
    [28] => Drupal\Core\DrupalKernel -> handle

Proposed resolution

I think we can safely assume in D8 any logged query will always pass by the Connection object. Get its class name, and drop any stack entry with classes that are not the same as the connection class, drop any entry of the connection class, and then process the remaining stack trace as before.

I think we can safely assume in D8 any logged query will always pass through methods in the namespace of the Connection object.

• Get the connection class namespace,
• Drop any stack entry with methods from classes that are not within that namespace,
• Drop any stack entry with methods from classes that are within that namespace,
• then process the remaining stack trace as before.

This will get to:

    [0] =>  -> db_query
    [1] => Drupal\drudbal\Tests\LoggingTest -> testEnableLogging
    [2] => Drupal\simpletest\TestBase -> run
    [3] =>  -> _simpletest_batch_operation
    [4] =>  -> _batch_process
    [5] =>  -> _batch_do
    [6] =>  -> _batch_page
    [7] => Drupal\system\Controller\BatchController -> batchPage
    [8] =>  -> call_user_func_array
    [9] => Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber -> Drupal\Core\EventSubscriber\{closure}
    [10] => Drupal\Core\Render\Renderer -> executeInRenderContext
    [11] => Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber -> wrapControllerExecutionInRenderContext
    [12] => Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber -> Drupal\Core\EventSubscriber\{closure}
    [13] =>  -> call_user_func_array
    [14] => Symfony\Component\HttpKernel\HttpKernel -> handleRaw
    [15] => Symfony\Component\HttpKernel\HttpKernel -> handle
    [16] => Drupal\Core\StackMiddleware\Session -> handle
    [17] => Drupal\Core\StackMiddleware\KernelPreHandle -> handle
    [18] => Drupal\page_cache\StackMiddleware\PageCache -> pass
    [19] => Drupal\page_cache\StackMiddleware\PageCache -> handle
    [20] => Drupal\Core\StackMiddleware\ReverseProxyMiddleware -> handle
    [21] => Drupal\Core\StackMiddleware\NegotiationMiddleware -> handle
    [22] => Stack\StackedHttpKernel -> handle
    [23] => Drupal\Core\DrupalKernel -> handle

Remaining tasks

Review patch.

User interface changes

None

API changes

None

Data model changes

None

Problem/Motivation

We have a method to determine the db driver namespace if it is not provided - \Drupal\Core\Database\Database::getDatabaseDriverNamespace() - which supports supports fallling back to the core db driver namespace. This results in the connection info sometimes having the driver namespace and sometimes not.

Proposed resolution

Always set $info['namespace'] instead of using a method.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

N/a

After updading a Drupal site from 8.6.16 to 8.7.1 (PostgreSQL 9.6.13 , Nginx) I get this error in almost every operation (creating a view , installing a module, importing feeds, ....) with diferent plugins

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "{whatever}" plugin does not exist.
Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, any, float, string, boolean, timespan,[...]
in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 de /"
"/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

I use the drupal-project composer template so my update process was:

composer update --with-dependencies webflo/drupal-core-require-dev drupal/* "symfony/*" -d /<path/to/site> --no-interaction ;
cd /<path/to/site>
drush updb
drush cron
drush cr

It was not successfull, so I do this:

rm -rf vendor/*
composer update

and run again previous commands which It worked.

I though that I could be a problem with PHP version so I update from PHP 7.0 to PHP 7.3, but the error still remains.
I also thought that it could be related with a feeds module installation so delete all feeds content, feeds types, etc .. and unistall and reinstall the module several times (also run drush devel-entity-updates because drupal status report warned of a feeds field that needed to be deleted)

After see that the problem was related with multiples plugins I start looking for a more generic issue (config?, permissions?, ...) but I don't find cause/solution.

EDIT 1

Looking for a stack trace I try using drupal console:

drupal site:mode dev -v

and get this:

In DiscoveryTrait.php line 53:

  [Drupal\Component\Plugin\Exception\PluginNotFoundException]                                                                                                                                               
  The "system.performance" plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, any, float, string, boolean, timespan, language_reference, language, map  
  , binary, timestamp, list, datetime_iso8601, uri, integer, duration_iso8601, email, field_item:comment, field_item:datetime, field_item:daterange, field_item:file_uri, field_item:file, field_item:font  
  awesome_icon, field_item:image, field_item:link, field_item:list_integer, field_item:list_float, field_item:list_string, field_item:path, field_item:telephone, field_item:text, field_item:text_long, f  
  ield_item:text_with_summary, field_item:time_range, field_item:time, field_item:webform, field_item:email, field_item:uri, field_item:entity_reference, field_item:uuid, field_item:timestamp, field_ite  
  m:string_long, field_item:language, field_item:password, field_item:changed, field_item:float, field_item:decimal, field_item:map, field_item:boolean, field_item:integer, field_item:created, field_ite  
  m:string, entity, entity:block, entity:block_content_type, entity:block_content, entity:block_content:basic, entity:captcha_point, entity:comment, entity:comment:comment_forum, entity:comment_type, en  
  tity:contact_form, entity:contact_message, entity:contact_message:feedback, entity:contact_message:personal, entity:editor, entity:field_config, entity:field_storage_config, entity:file, entity:filter  
  _format, entity:image_style, entity:imce_profile, entity:language_content_settings, entity:configurable_language, entity:media_type, entity:media, entity:media:audio, entity:media:file, entity:media:i  
  mage, entity:media:remote_video, entity:media:video, entity:node_type, entity:node,[...], entity:node:page, entity:node:position, entity:rdf_mapping, entity:responsive_image_style, entity:rest_resource_config, entity:rules_reaction_rule, entity:rules_component, entity:s  
  earch_page, entity:shortcut_set, entity:shortcut, entity:shortcut:default, entity:action, entity:menu, entity:taxonomy_vocabulary, entity:taxonomy_term, entity:taxonomy_term:badge_type, entity:taxonom  
  y_term:categories, entity:taxonomy_term:forums, entity:taxonomy_term:materials, entity:taxonomy_term:nivel, entity:taxonomy_term:tags, entity:toolbar_menu_element, entity:tour, entity:user, entity:use  
  r_role, entity:webform_options, entity:webform, entity:webform_submission, [..], entity:menu_link_content, entity:pathauto_pattern, entity  
  :view, entity:base_field_override, entity:entity_view_mode, entity:entity_view_display, entity:entity_form_mode, entity:entity_form_display, entity:date_format, entity_reference

Exception trace:
 () at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php:53
 Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryCachedTrait.php:25
 Drupal\Core\Plugin\DefaultPluginManager->getDefinition() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/TypedData/DataDefinition.php:195
 Drupal\Core\TypedData\DataDefinition->getClass() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/TypedData/TypedDataManager.php:86
 Drupal\Core\TypedData\TypedDataManager->createInstance() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/TypedData/TypedDataManager.php:103
 Drupal\Core\TypedData\TypedDataManager->create() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/TypedConfigManager.php:394
 Drupal\Core\Config\TypedConfigManager->createFromNameAndData() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/StorableConfigBase.php:134
 Drupal\Core\Config\StorableConfigBase->getSchemaWrapper() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/StorableConfigBase.php:179
 Drupal\Core\Config\StorableConfigBase->castValue() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/Config.php:212
 Drupal\Core\Config\Config->save() at /home/"<user>"/www/"<site>"/vendor/drupal/console/src/Command/Site/ModeCommand.php:150
 Drupal\Console\Command\Site\ModeCommand->overrideConfigurations() at /home/"<user>"/www/"<site>"/vendor/drupal/console/src/Command/Site/ModeCommand.php:87
 Drupal\Console\Command\Site\ModeCommand->execute() at /home/"<user>"/www/"<site>"/vendor/symfony/console/Command/Command.php:255
 Symfony\Component\Console\Command\Command->run() at /home/"<user>"/www/"<site>"/vendor/symfony/console/Application.php:987
 Symfony\Component\Console\Application->doRunCommand() at /home/"<user>"/www/"<site>"/vendor/symfony/console/Application.php:255
 Symfony\Component\Console\Application->doRun() at /home/"<user>"/www/"<site>"/vendor/drupal/console-core/src/Application.php:184

EDIT 2

looking at the database I found two tables from feeds module (supposed to be uninstalled)

feeds_feed feeds_subscription

running drupal console commnand drupal debug:module feeds appears as the only module uninstalled with a schema version defined

ID     Name   Package  version      schema version  status      origin
...
feeds  Feeds  Feeds  8.x-3.0-alpha5    8001         Uninstalled no core
...

EDIT 3

After enable debugging (https://drupal.stackexchange.com/questions/127182/how-do-i-enable-develo...)

I got new clues about the error ( trying to create a view) but my lack of drupal core knowledge stops me from understanding where final cause is:

</br></br><em class="placeholder">Drupal\Component\Plugin\Exception\PluginNotFoundException</em>: The &quot;views.view.*&quot; plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, any, float, string, boolean, timespan, [...], entity:entity_form_display, entity:date_format, entity_reference in <em class="placeholder">Drupal\Core\Plugin\DefaultPluginManager-&gt;doGetDefinition()</em> (line <em class="placeholder">53</em> of <em class="placeholder">core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php</em>). <pre class="backtrace">Drupal\Core\Plugin\DefaultPluginManager-&gt;getDefinition(&#039;views.view.*&#039;) (Line: 195)
Drupal\Core\TypedData\DataDefinition-&gt;getClass() (Line: 86)
Drupal\Core\TypedData\TypedDataManager-&gt;createInstance(&#039;views.view.*&#039;, Array) (Line: 103)
Drupal\Core\TypedData\TypedDataManager-&gt;create(Object, Array) (Line: 394)
Drupal\Core\Config\TypedConfigManager-&gt;createFromNameAndData(&#039;views.view.test2&#039;, Array) (Line: 134)
Drupal\Core\Config\StorableConfigBase-&gt;getSchemaWrapper() (Line: 179)
Drupal\Core\Config\StorableConfigBase-&gt;castValue(&#039;uuid&#039;, &#039;c2f6326b-a77f-4f1e-9698-cb96154252cb&#039;) (Line: 212)
Drupal\Core\Config\Config-&gt;save() (Line: 284)
Drupal\Core\Config\Entity\ConfigEntityStorage-&gt;doSave(&#039;test2&#039;, Object) (Line: 449)
Drupal\Core\Entity\EntityStorageBase-&gt;save(Object) (Line: 263)
Drupal\Core\Config\Entity\ConfigEntityStorage-&gt;save(Object) (Line: 394)
Drupal\Core\Entity\EntityBase-&gt;save() (Line: 613)
Drupal\Core\Config\Entity\ConfigEntityBase-&gt;save() (Line: 993)
Drupal\views_ui\ViewUI-&gt;save() (Line: 191)
Drupal\views_ui\ViewAddForm-&gt;submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter-&gt;executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter-&gt;doSubmitForm(Array, Object) (Line: 590)
Drupal\Core\Form\FormBuilder-&gt;processForm(&#039;view_add_form&#039;, Array, Object) (Line: 319)
Drupal\Core\Form\FormBuilder-&gt;buildForm(Object, Object) (Line: 93)
Drupal\Core\Controller\FormController-&gt;getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer-&gt;executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel-&gt;handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel-&gt;handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle-&gt;handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache-&gt;pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware-&gt;handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware-&gt;handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel-&gt;handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel-&gt;handle(Object) (Line: 19)
</pre>

Problem/Motivation

Currently, drupal_get_database_types() only looks for database drivers in /core/lib and /drivers/lib. This means that contrib modules that implement database drivers must instruct users to copy the driver files from where modules are normally installed (e.g., /modules) into the required place within /drivers/lib. This is a tedious and error-prone step that needs to be re-performed every time the module is updated. While this can in some cases be automated with Composer, doing so requires edits to the website's root composer.json, and it doesn't help Drupal users who don't use Composer.

Proposed resolution

• Define a location within the module's namespace and src directory where database drivers can go. This issue proposes Drupal\MODULE_NAME\Driver\Database\DRIVER_NAME for the namespace, which using the already existing PSR-4 layout of the module's "src" directory corresponds to the src/Driver/Database/DRIVER_NAME directory.
• Expand drupal_get_database_types() to scan that location for all modules in the codebase. Note that this is done for all modules in the codebase, not only for enabled modules, because this needs to happen at the beginning of the installation process, before any modules have been enabled.
• Add an optional 'autoload' key to the database connection info array that's defined in settings.php for specifying the directory that corresponds to the driver's namespace. This is needed because the database driver needs to be loaded every request prior to when module namespaces are added to the autoloader, since that information lives in the service container which lives in the database. Having the value specified in settings.php avoids having to rescan the filesystem to find it for every request.
• Expand SiteSettingsForm::validateForm() to fill in the 'autoload' key, so that it is automatically written to settings.php by the installer.
• Expand db_installer_object()to take an optional $namespace parameter. This allows it to avoid having to rescan for all modules in the filesystem after drupal_get_database_types() already did it.
• Expand database URLs (used by console commands and test runners in lieu of a settings.php connection info array) to include a module query parameter for when the driver is provided by a module, and change Database::convertDbUrlToConnectionInfo() and Connection::createUrlFromConnectionOptions() to use and set that accordingly.
• Retain backwards compatibility for the Drupal\Driver namespace in drivers/lib. Existing Drupal 8 drivers using those namespaces will continue to work exactly as before.

Follow-ups:

• #3123461: Deprecate support for database drivers placed in DRUPAL_ROOT/drivers
• #3123240: Provide a better way to get driver name and database type
• #3125257: Deprecate support for database connections as URLs and replace with JSON strings
• #3125476: Add an API for determining whether a given PHP namespace or class name is within the namespace of an extension

Remaining tasks

• A release manager review to evaluate whether this can be committed to 9.0.x during beta. The motivation to do so is to enable people to more smoothly be able to use the contrib drivers created to help people on older versions of databases than Drupal 9 core's minimums, such as the PostgreSQL fallback driver.

User interface changes

None

API changes

Additions:

• An optional $namespace parameter added to db_installer_object().
• A new static method Drupal\Core\Database\Database::findDriverAutoloadDirectory() added.
• For database drivers in a module's namespace (as opposed to in Drupal\Driver or Drupal\Core), a module query parameter is added to the database connection URL. For example: pgsql://test_user:test_pass@test_host:5432/test_database?module=driver_test. URLs for database drivers in the Drupal\Driver and Drupal\Core namespaces are unaffected.
• For database drivers in a module's namespace (as opposed to in Drupal\Driver or Drupal\Core), an 'autoload' key is added to the database connection array in settings.php. Setting it is required if using a database driver from a module's namespace unless the Drupal site is using Composer and the driver's namespace is in Composer's autoloader. Setting it is not required for drivers in the Drupal\Driver and Drupal\Core namespaces.

Data model changes

None

Release notes snippet

Database drivers provided by modules can be placed in src/Driver/Database. Such drivers will be listed in the installer. Existing custom or contributed drivers do not need to make a changes and continue to work as before.

Currently the MySQL temporary table code explicitly specifies that the storage engine should be MEMORY. While this may commonly be the case, there are some reasons to use other storage engines instead (for example: TEXT/BLOB support; more efficient usage by providing true variable length storage).

From MySQL 5.6, it is also possible to change what temporary tables are created as:
http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysv...

Problem/Motivation

The Entity validator should use EntityInterface::label() to set the validated_title of the argument.

Proposed resolution

Set the validated_title of the argument after the Entity argument validator verifies the argument validity.

If views users are relying on the current (broken) behavior, they can switch their token replacements to use {{ raw_arguments.* }} instead of {{ arguments.* }}.

Remaining tasks

• Write tests

Configuration management shouldn't export custom blocks as currently it will result in broken block.

A custom block is made of two entities, one for the placement and one for the actual content. Only the actual placement can be exported with cmi. The content can not.
Therefore this will result in "Block description Broken/Missing" error on site where the config is imported. And since there is no option to disable custom blocks from being exported through Configuration management this will break the functionality.

Steps to reproduce

On Site A:

1. Create custom block
2. Assign this custom block to any region
3. Export configuration of the site

On Site B:

1. Import configuration from site A
2. Go to Block layout and you will see custom block in correctly assigned region, however block won't work or actually show anything.
3. Edit that block, you will see this messages:
   • Block description Broken/Missing
This block is broken or missing. You may be missing content or you might need to enable the original module.
4. Go under Custom block library and you won't see custom block.

Block layout got exported but block content didn't resulting in broken relationship.

Suggested solution

Don't export custom blocks through Configuration management.

Hello,

I updated my site multiple times over the last few years and it always worked. This site is originating from D7. Now i wanted to go from 8.7.5 to 8.8.4, but failed with the same problem, but even worse as the update of many modules failed and the site was not working. Then I tried to go to 8.7.12. This worked better, but I still face the problem that one update (taxonomy module, 8702 - Fix the parent field langcode data.) cannot be applied. In my dblog I get this error 18 times before the update fails:

TypeError: Argument 1 passed to Drupal\Core\ProxyClass\Render\BareHtmlPageRenderer::renderBarePage() must be of the type array, bool given, called in /home/.sites/136/site1497/web/core/modules/system/src/Controller/DbUpdateController.php on line 196 in Drupal\Core\ProxyClass\Render\BareHtmlPageRenderer->renderBarePage() (Zeile 73 in /home/.sites/136/site1497/web/core/lib/Drupal/Core/ProxyClass/Render/BareHtmlPageRenderer.php) #0 /home/.sites/136/site1497/web/core/modules/system/src/Controller/DbUpdateController.php(196): Drupal\Core\ProxyClass\Render\BareHtmlPageRenderer->renderBarePage(false, Object(Drupal\Core\StringTranslation\TranslatableMarkup), 'maintenance_pag...', Array) #1 [internal function]: Drupal\system\Controller\DbUpdateController->handle('sites', Object(Symfony\Component\HttpFoundation\Request)) #2 /home/.sites/136/site1497/web/core/lib/Drupal/Core/Update/UpdateKernel.php(115): call_user_func_array(Array, Array) #3 /home/.sites/136/site1497/web/core/lib/Drupal/Core/Update/UpdateKernel.php(76): Drupal\Core\Update\UpdateKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request)) #4 /home/.sites/136/site1497/web/update.php(28): Drupal\Core\Update\UpdateKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #5 {main}.

I also tried to go back to a DB backup a few weeks old, but the problem is the same.

I am hosted at a hoster, these are my software settings:

Webserver: Apache
PHP: 7.3.14
DB: MySQL 5.7.27-log

Installed modules:
AT Tools 8.x-3.2
Backup and Migrate 8.x-4.1
EU Cookie Compliance 8.x-1.8
External Links 8.x-1.2
Google Analytics 8.x-2.4
Honeypot 8.x-1.30
Security Kit 8.x-1.2
AdaptiveTheme 8.x-3-1
Pixture Reloaded 8.x-3.0+1-dev

Activated core modules:

Automated Cron, Bartik, Block, Breakpoint, CKEditor, Classy, Color, Comment, Configuration Manager, Contact, Contextual Links, Custom Block, Custom Menu Links, Database Logging, Datetime, Field, Field UI, File, Filter, Help, History, Image, Interface Translation, Internal Dynamic Page Cache, Internal Page Cache, Language, Link, Menu UI, Node, Options, Path, Quick Edit, RDF, Search, Serialization, Seven, Shortcut, Stable, Standard, System, Taxonomy, Text, Text Editor, Toolbar, Tour, Update Manager, User, Views, Views UI

Notice: Undefined index: name in system_requirements() (line 43 of core/modules/system/system.install).

system_requirements('runtime')
call_user_func_array('system_requirements', Array) (Line: 393)
Drupal\Core\Extension\ModuleHandler->invokeAll('requirements', Array) (Line: 116)
Drupal\system\SystemManager->listRequirements() (Line: 100)
Drupal\system\SystemManager->checkRequirements() (Line: 119)
Drupal\system\Controller\SystemController->overview('system.admin_config')
call_user_func_array(Array, Array) (Line: 128)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 577)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 129)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 102)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array) (Line: 139)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 62)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 62)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 103)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 82)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 55)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 55)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 637)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Drupal currently does not make any use of foreign keys in the database (see #911352: Document that foreign keys may not be used by all drivers). DBTNG should provide methods for developers to create foreign keys if they want to use them.

Currently, foreign keys are defined in hook_schema() implementations like this:

'foreign keys' => [
      'node_revision' => [
        'table' => 'node_revision',
        'columns' => [
          'vid' => 'vid',
        ],
      ],
    ],

I suggest that a developer who wants the foreign key to be created would do it like this:

'foreign keys' => [
      'node_revision' => [
        'table' => 'node_revision',
        'columns' => [
          'vid' => 'vid',
        ],
        'on update' => 'cascade',
        'on delete' => 'set null',
      ],
    ],

If both 'on update' and 'on delete' are set to valid values, FKs would be created in the database, otherwise, they would not be. Valid values are: "restrict", "cascade", "set null", and "set default" ("no action" is valid in SQL but will not be supported for the reason given in #137).

Changes required for each database driver:

• createTableSql(), createKeysSql(), and _createKeys() methods need to create foreign keys, much like they create unique keys.
• addForeignKey(), dropForeignKey(), and foreignKeyExists() methods need to be added to the API.

Problem/Motivation

Resolve the following SF4 Deprecations if possible:

'The "Symfony\Component\HttpFoundation\File\MimeType\MimeTypeGuesser" class is deprecated since Symfony 4.3, use "Symfony\Component\Mime\MimeTypes" instead.'

'The "Drupal\Core\File\MimeType\MimeTypeGuesser" class implements "Symfony\Component\HttpFoundation\File\MimeType\MimeTypeGuesserInterface" that is deprecated since Symfony 4.3, use {@link MimeTypesInterface} instead.'

'The "Symfony\Component\HttpFoundation\File\MimeType\FileBinaryMimeTypeGuesser" class is deprecated since Symfony 4.3, use "Symfony\Component\Mime\FileBinaryMimeTypeGuesser" instead.'

'The "Symfony\Component\HttpFoundation\File\MimeType\FileinfoMimeTypeGuesser" class is deprecated since Symfony 4.3, use "Symfony\Component\Mime\FileinfoMimeTypeGuesser" instead.'

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Hi,

I think it would be helpful to have a "clear all recorded statistics" button. For example, this would be useful for when a site transitions from being a private "development" site to being a public "live" site.

Problem/Motivation

It would be great, if it was possible to reset the Drupal core Statistics counter enabled under admin/config/system/statistics via Drush. The alternative would be to uninstall and reinstall the Drupal core Statistics module, which might have unintended consequences.

Proposed resolution

Perhaps add something like drush core:statistics:reset?

Remaining tasks

Update the code, adding the Drush command.

User interface changes

None.

API changes

None.

Data model changes

None.