This is a follow up to #2969231: errors in migration process configuration don't give a clear message. The changes there introduce a check in getProcessNormalized which will throw a MigrateException if the process is not an array. Because of that there is a block of code in Migration:getProcessPlugins() that appears eligible for removal. This issue is to determine if it is safe to do that and do it, or not and keep it in. The lines are:

        if (!is_array($configurations) && !$this->processPlugins[$index][$property]) {
          throw new MigrateException(sprintf("Process configuration for '$property' must be an array", $property));
        }

Proposed resolution

Delete these lines.

Remaining tasks

Review

↧

Remove redundant role from node articles

March 2, 2020, 12:36 pm

≫ Next: Convert migrate, migrate_drupal, migrate_drupal_multilingual, migrate_drupal_ui module hook_help() to topic(s)

≪ Previous: Remove is_array check in getProcessPlugins

article is the default role of an<article> and thus the attribute can be removed.

To test this, copy this snippet into the W3 validator: https://validator.w3.org/nu/#textarea

<!DOCTYPE html>
<html lang="en">
<head>
<title>test</title>
</head>
<body>
<article role="article">
<h1>test</h1>
</article>
</body>
</html>

Also see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/article

↧

Convert migrate, migrate_drupal, migrate_drupal_multilingual, migrate_drupal_ui module hook_help() to topic(s)

August 8, 2019, 3:08 am

≫ Next: a disabled block's admin title gets double-escaped

≪ Previous: Remove redundant role from node articles

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the migrate, migrate_drupal, migrate_drupal_multilingual, migrate_drupal_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:

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().
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.
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.
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).
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).
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).
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:

Apply the patch.
Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
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.
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].
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.

↧

a disabled block's admin title gets double-escaped

June 12, 2019, 2:36 am

≫ Next: Show composer instructions for available update version

≪ Previous: Convert migrate, migrate_drupal, migrate_drupal_multilingual, migrate_drupal_ui module hook_help() to topic(s)

If a block's admin title contains text such as ' then when it's disabled, that is double-escaped.

Eg, not disabled:

This block's great!

Disabled:

This block's great! (disabled)

↧

Show composer instructions for available update version

January 18, 2020, 1:36 pm

≫ Next: Properly deprecate module_load_include() in favor of \Drupal::moduleHandler()->loadInclude()

≪ Previous: a disabled block's admin title gets double-escaped

Modules show the path name but available updates don't. You need the path name to use composer. Yes, as you hover over it it shows at the bottom of the browser screen but you can't copy from that.

↧

Properly deprecate module_load_include() in favor of \Drupal::moduleHandler()->loadInclude()

January 28, 2010, 7:29 am

≫ Next: Use an optimised autoloader in testing

≪ Previous: Show composer instructions for available update version

Problem/Motivation

We would like to deprecate all legacy code in the file core/includes/module.inc. The function module_load_include() lives in that file.

Proposed resolution

The module_load_include() function should be deprecated, and its use removed from core.

Remaining tasks

TBD

User interface changes

None

API changes

The function module_load_include() will be deprecated.

Original report by scor

This is a follow up issue on Drupal 7's #599122: Do not use module_load_include() in global context. This function is misleading and useless in some cases like in an .install file or in "global context" where a native PHP require_once call must be used instead.

The module_load_include() function provides little or no advantage over calling simpler functions directly. In #599122, several calls to require(DRUPAL_ROOT . 'file') were changed to use module_load_include() for consistency. This broke core, so after the changes were reverted, webchick commented in #599122-15:

I guess we should look at removing this stupid, confusing, and useless function in Drupal 8.

↧

Use an optimised autoloader in testing

March 3, 2020, 5:07 am

≫ Next: Title formatting broken due to flawed EntityViewController->buildTitle

≪ Previous: Properly deprecate module_load_include() in favor of \Drupal::moduleHandler()->loadInclude()

Problem/Motivation

Now that we're using composer's classloader we can use composer dump-autoload --optimize to dump the optimised autoloader.

Proposed resolution

Remaining tasks

One thing all this suggests is that we really need to look the opcache and apcu settings on drupalci

User interface changes

API changes

Data model changes

Release notes snippet

↧

Title formatting broken due to flawed EntityViewController->buildTitle

January 31, 2018, 11:58 pm

≫ Next: After adding media, return the user to the media listing they started from

≪ Previous: Use an optimised autoloader in testing

Problem

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

1 Malformed HTML output

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

Example scenario:

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

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

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

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

2 Prevents manage display of label field

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

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

3 Inconsistent, only works selectively

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

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

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

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

4 Node titles missing label

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

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

Overall effect

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

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

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

FYI Comment incorrect

The comment in buildTitle claims that the purpose is

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

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

Proposed Solution

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

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

Use the new "Template" if the label

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

Rejected solution

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

Downsides

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

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

↧

After adding media, return the user to the media listing they started from

February 18, 2019, 2:19 pm

≫ Next: Add API for "upcasting" from AccountInterface to a full User entity?

≪ Previous: Title formatting broken due to flawed EntityViewController->buildTitle

Problem/Motivation

When a user is on the media table listing at `admin/content/media-table`, and use the "add media" button, they eventually get returned to the `admin/content/media` grid.

I'd expect to arrive back at the table version, not the grid.

Proposed resolution

Remember which version of the media listing the user invoked "add media" from, and return them to that.

We can use a destination query parameter, with a form alter, and add this with hook_form_alter().

Bonus points: make this work for all variants of the media library listing. Site builders can easily add more display variants to the view, so maybe the form alter could work by view name, instead of the individual view display?

Remaining tasks

Patch.
Tests.

↧

Add API for "upcasting" from AccountInterface to a full User entity?

October 30, 2013, 5:28 am

≫ Next: Installation warnings/errors have line breaks mid-word

≪ Previous: After adding media, return the user to the media listing they started from

At BADCamp last week, I participated in the two lab sessions to upgrade a module to Drupal 8. The module I was working on was Mixpanel.

There are three places in the the D7 module which use global $user; to get the current user. I ported that to \Drupal::currentUser() in D8, which is documented as returning AccountInterface - but I actually need UserInterface so I can call ->getLastLoginTime() and ->getCreatedTime().

Right now, my only option is copying the following magic incantation to three places in my module:

$user = \Drupal::currentUser();
if (!$user instanceof UserInterface) {
  $user = user_load($user->id());
}

This is something of a developer experience WTF for me. It'd be great to have an API for this, maybe even a new method on AccountInterface, so that instead, module developers can do:

$user = \Drupal::currentUser()->getFullUser();

What do you think?

↧

Installation warnings/errors have line breaks mid-word

January 20, 2017, 8:45 am

≫ Next: Users Can't See Comment Type

≪ Previous: Add API for "upcasting" from AccountInterface to a full User entity?

A picture is worth a thousand steps to reproduce...

From core/themes/seven/css/theme/install-page.css:35

.install-page table td {
  word-break: break-all;
}

↧

Users Can't See Comment Type

May 9, 2020, 5:13 pm

≫ Next: "status_messages"-like render element with a preset message

≪ Previous: Installation warnings/errors have line breaks mid-word

Users can't see comment types without the "Administer comment types and settings" permission. E.g. adding "comment type" as a field to a view returns a blank field unless user has that permission.

↧

"status_messages"-like render element with a preset message

March 10, 2017, 4:10 am

≫ Next: Node grant access check missing cacheable dependency on node

≪ Previous: Users Can't See Comment Type

Problem/Motivation

The "status_messages" render element (\Drupal\Core\Render\Element\StatusMessages) comes with nice CSS. We want to reuse its look when we display warning and/or error messages in the middle long forms, like this:
Color extractor library missing message
Unfortunately, "status_messages" is only for displaying messages set by the \drupal_set_message method. That means that it will be displaying all kinds of system messages in a place where we only want our custom message. Instead, we would like an element that displays only the warning/error message that we directly set in its render array.

Proposed resolution

Create a new render element for a such a message box.
e.g., named "message" with properties "#message" and "#style". "#message" is the message that is to be displayed in the box. "#style" can be either "status", "warning", or "error" and determines the appearance.

Or extend "container" with this functionality. (Add optional "#style" property.)

Or make it possible to set "status_messages" to only display messages included in the form array.

Remaining tasks

User interface changes

API changes

Data model changes

↧

Node grant access check missing cacheable dependency on node

February 20, 2018, 3:23 am

≫ Next: Semi random CacheableBadRequestHttpExceptions

≪ Previous: "status_messages"-like render element with a preset message

Problem/Motivation

The node access grant system does not add a cacheable dependency on nodes in all circumstances. It's important that this dependency be added because variations to the node can most certainly have an affect on the node access query logic.

Proposed resolution

Add the missing cache dependency!

Original report

A content type has an entity reference field.
A node "foo" of that content type references an unpublished node "bar".
Viewing the node "foo" as an anonymous user will create caches.
When publishing the node "bar" it is expected to become visible on the page "foo" but that page won't show the referenced node "bar" that is now published.

EntityReferenceEntityFormatter::viewElements only adds accessible nodes to the render array (not the unpublished or inaccessible ones) but a node that is referenced might be inaccessible at first and become accessible later.

↧

Semi random CacheableBadRequestHttpExceptions

April 24, 2020, 2:05 am

≫ Next: RouteProvider::getRouteCollectionForRequest() can poison query string of next request

≪ Previous: Node grant access check missing cacheable dependency on node

We started seeing the exceptions seen below in the logs. We use simple_oauth to authenticate users so Drupal caching should not affect the request handling, right?

At the moment we have:
Core 8.7.3
Simple Oauth 8.x-4.4
Consumers 8.x-1.11
CDN 8.x-3.3 with AWS CloudFront

Any suggestions about how to proceed with debugging?

Apr 22 01:01:42 habinator drupal: https://api.habinator.com|1587517302|php|64.252.xx|https://api.habinator.com/jsonapi/node/habit?filter%5Buid.id%5D%5Bvalue%5D=ed90efe7-03da-45a8-aa05-375d7cdabe33&include=field_goal_image||1344||Drupal\Core\Http\Exception\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'destination', '_exception_statuscode'. in Drupal\jsonapi\EventSubscriber\JsonApiRequestValidator->validateQueryParams() (line 78 of /srv/www/habinatorbe/web/core/modules/jsonapi/src/EventSubscriber/JsonApiRequestValidator.php).

Apr 22 01:38:46 habinator drupal: https://api.habinator.com|1587519526|php|70.132.xx|https://api.habinator.com/jsonapi/node/quote?fields%5Bnode--quote%5D=body%2Ctitle&filter%5Bfield_quote_number%5D=22||257||Drupal\Core\Http\Exception\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'destination', '_exception_statuscode'. in Drupal\jsonapi\EventSubscriber\JsonApiRequestValidator->validateQueryParams() (line 78 of /srv/www/habinatorbe/web/core/modules/jsonapi/src/EventSubscriber/JsonApiRequestValidator.php).

Apr 22 05:36:28 habinator drupal: https://api.habinator.com|1587533788|php|64.252.xx|https://api.habinator.com/jsonapi/node/habit/e891ee8a-056e-4605-8c25-4972b6f43e79?fields%5Bnode--habit%5D=field_progress||2048||Drupal\Core\Http\Exception\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'destination', '_exception_statuscode'. in Drupal\jsonapi\EventSubscriber\JsonApiRequestValidator->validateQueryParams() (line 78 of /srv/www/habinatorbe/web/core/modules/jsonapi/src/EventSubscriber/JsonApiRequestValidator.php).

Apr 23 03:00:13 habinator drupal: https://api.habinator.com|1587610813|php|64.252.xx|https://api.habinator.com/jsonapi/node/habit/fbe7de6f-80ba-4d39-9042-f6cb8e5594b1?fields%5Bnode--habit%5D=field_progress||1939||Drupal\Core\Http\Exception\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'destination', '_exception_statuscode'. in Drupal\jsonapi\EventSubscriber\JsonApiRequestValidator->validateQueryParams() (line 78 of /srv/www/habinatorbe/web/core/modules/jsonapi/src/EventSubscriber/JsonApiRequestValidator.php).

Apr 21 11:17:10 habinator drupal: https://api.habinator.com|1587467830|php|70.132.xx|https://api.habinator.com/de/jsonapi/node/habit/c078a5a7-865e-4603-bd9b-db0485d55d11?fields%5Bnode--habit%5D=field_progress||1867||Drupal\Core\Http\Exception\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'destination', '_exception_statuscode'. in Drupal\jsonapi\EventSubscriber\JsonApiRequestValidator->validateQueryParams() (line 78 of /srv/www/habinatorbe/web/core/modules/jsonapi/src/EventSubscriber/JsonApiRequestValidator.php).

Apr 21 13:34:57 habinator drupal: https://api.habinator.com|1587476097|php|64.252.xx|https://api.habinator.com/jsonapi/node/habit/4da649f9-996b-45ee-81a0-d0f4bd3895b6?fields%5Bnode--habit%5D=field_progress||1473||Drupal\Core\Http\Exception\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'destination', '_exception_statuscode'. in Drupal\jsonapi\EventSubscriber\JsonApiRequestValidator->validateQueryParams() (line 78 of /srv/www/habinatorbe/web/core/modules/jsonapi/src/EventSubscriber/JsonApiRequestValidator.php).

Apr 21 14:00:11 habinator drupal: https://api.habinator.com|1587477611|php|70.132.xx|https://api.habinator.com/jsonapi/node/quote?fields%5Bnode--quote%5D=body%2Ctitle&filter%5Bfield_quote_number%5D=21||491||Drupal\Core\Http\Exception\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'destination', '_exception_statuscode'. in Drupal\jsonapi\EventSubscriber\JsonApiRequestValidator->validateQueryParams() (line 78 of /srv/www/habinatorbe/web/core/modules/jsonapi/src/EventSubscriber/JsonApiRequestValidator.php).

Apr 21 18:45:46 habinator drupal: https://api.habinator.com|1587494746|php|70.132.6xx|https://api.habinator.com/jsonapi/node/habit/dfe8812d-d043-4db6-bbed-fc395eecc6b1?fields%5Bnode--habit%5D=field_progress||2084||Drupal\Core\Http\Exception\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'destination', '_exception_statuscode'. in Drupal\jsonapi\EventSubscriber\JsonApiRequestValidator->validateQueryParams() (line 78 of /srv/www/habinatorbe/web/core/modules/jsonapi/src/EventSubscriber/JsonApiRequestValidator.php).

Apr 22 01:01:42 habinator drupal: https://api.habinator.com|1587517302|php|64.252.xx|https://api.habinator.com/jsonapi/node/habit?filter%5Buid.id%5D%5Bvalue%5D=ed90efe7-03da-45a8-aa05-375d7cdabe33&include=field_goal_image||1344||Drupal\Core\Http\Exception\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'destination', '_exception_statuscode'. in Drupal\jsonapi\EventSubscriber\JsonApiRequestValidator->validateQueryParams() (line 78 of /srv/www/habinatorbe/web/core/modules/jsonapi/src/EventSubscriber/JsonApiRequestValidator.php).

Apr 22 01:38:46 habinator drupal: https://api.habinator.com|1587519526|php|70.132.xx|https://api.habinator.com/jsonapi/node/quote?fields%5Bnode--quote%5D=body%2Ctitle&filter%5Bfield_quote_number%5D=22||257||Drupal\Core\Http\Exception\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'destination', '_exception_statuscode'. in Drupal\jsonapi\EventSubscriber\JsonApiRequestValidator->validateQueryParams() (line 78 of /srv/www/habinatorbe/web/core/modules/jsonapi/src/EventSubscriber/JsonApiRequestValidator.php).

Apr 22 05:36:28 habinator drupal: https://api.habinator.com|1587533788|php|64.252.xx|https://api.habinator.com/jsonapi/node/habit/e891ee8a-056e-4605-8c25-4972b6f43e79?fields%5Bnode--habit%5D=field_progress||2048||Drupal\Core\Http\Exception\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'destination', '_exception_statuscode'. in Drupal\jsonapi\EventSubscriber\JsonApiRequestValidator->validateQueryParams() (line 78 of /srv/www/habinatorbe/web/core/modules/jsonapi/src/EventSubscriber/JsonApiRequestValidator.php).

Apr 22 08:28:24 habinator drupal: https://api.habinator.com|1587544104|php|70.132.xx|https://api.habinator.com/jsonapi/node/habit/6c269d12-6f0a-4060-a8f9-ded8568accdb?fields%5Bnode--habit%5D=field_progress||1660||Drupal\Core\Http\Exception\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'destination', '_exception_statuscode'. in Drupal\jsonapi\EventSubscriber\JsonApiRequestValidator->validateQueryParams() (line 78 of /srv/www/habinatorbe/web/core/modules/jsonapi/src/EventSubscriber/JsonApiRequestValidator.php).

Apr 22 22:46:10 habinator drupal: https://api.habinator.com|1587595570|php|130.176.xx|https://api.habinator.com/jsonapi/node/habit/5f77e560-e9b7-4866-98ee-432e07265cc7?fields%5Bnode--habit%5D=field_progress||757||Drupal\Core\Http\Exception\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'destination', '_exception_statuscode'. in Drupal\jsonapi\EventSubscriber\JsonApiRequestValidator->validateQueryParams() (line 78 of /srv/www/habinatorbe/web/core/modules/jsonapi/src/EventSubscriber/JsonApiRequestValidator.php).

Apr 23 03:00:13 habinator drupal: https://api.habinator.com|1587610813|php|64.252.xx|https://api.habinator.com/jsonapi/node/habit/fbe7de6f-80ba-4d39-9042-f6cb8e5594b1?fields%5Bnode--habit%5D=field_progress||1939||Drupal\Core\Http\Exception\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'destination', '_exception_statuscode'. in Drupal\jsonapi\EventSubscriber\JsonApiRequestValidator->validateQueryParams() (line 78 of /srv/www/habinatorbe/web/core/modules/jsonapi/src/EventSubscriber/JsonApiRequestValidator.php).

Apr 23 04:41:34 habinator drupal: https://api.habinator.com|1587616894|php|54.182.xx|https://api.habinator.com/jsonapi/node/habit?filter%5Buid.id%5D%5Bvalue%5D=357aa64f-be83-4249-a409-4b6d543a7a28&include=field_goal_image||332||Drupal\Core\Http\Exception\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'destination', '_exception_statuscode'. in Drupal\jsonapi\EventSubscriber\JsonApiRequestValidator->validateQueryParams() (line 78 of /srv/www/habinatorbe/web/core/modules/jsonapi/src/EventSubscriber/JsonApiRequestValidator.php).

Apr 23 06:22:52 habinator drupal: https://habinator.com|1587622972|php|84.46.xx|https://habinator.com/jsonapi/node/habit||4||Drupal\Core\Http\Exception\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'destination', '_exception_statuscode'. in Drupal\jsonapi\EventSubscriber\JsonApiRequestValidator->validateQueryParams() (line 78 of /srv/www/habinatorbe/web/core/modules/jsonapi/src/EventSubscriber/JsonApiRequestValidator.php).

Apr 23 08:04:35 habinator drupal: https://api.habinator.com|1587629075|php|54.182.xx|https://api.habinator.com/jsonapi/node/habit?filter%25%5Buid.id%5D%5Bvalue%5D=ed90efe7-03da-45a8-aa05-375d7cdabe33&include=field_goal_image||261||Drupal\Core\Http\Exception\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'filter%'. in Drupal\jsonapi\EventSubscriber\JsonApiRequestValidator->validateQueryParams() (line 78 of /srv/www/habinatorbe/web/core/modules/jsonapi/src/EventSubscriber/JsonApiRequestValidator.php).

Apr 23 17:42:18 habinator drupal: https://api.habinator.com|1587663738|php|52.46.xx|https://api.habinator.com/jsonapi/node/quote?fields%5Bnode--quote%5D=body%2Ctitle&filter%5Bfield_quote_number%5D=23||603||Drupal\Core\Http\Exception\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'destination', '_exception_statuscode'. in Drupal\jsonapi\EventSubscriber\JsonApiRequestValidator->validateQueryParams() (line 78 of /srv/www/habinatorbe/web/core/modules/jsonapi/src/EventSubscriber/JsonApiRequestValidator.php).

Apr 24 02:19:13 habinator drupal: https://api.habinator.com|1587694753|php|70.132.xxx|https://api.habinator.com/jsonapi/node/habit/bdd849e1-53ad-4490-86d3-e596d45f3bee?fields%5Bnode--habit%5D=field_progress||1566||Drupal\Core\Http\Exception\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'destination', '_exception_statuscode'. in Drupal\jsonapi\EventSubscriber\JsonApiRequestValidator->validateQueryParams() (line 78 of /srv/www/habinatorbe/web/core/modules/jsonapi/src/EventSubscriber/JsonApiRequestValidator.php).

Apr 24 03:00:26 habinator drupal: https://api.habinator.com|1587697226|php|70.132.xxx|https://api.habinator.com/jsonapi/node/habit/d2d49210-15a1-40a4-9573-f772ae58930a?fields%5Bnode--habit%5D=field_progress||1884||Drupal\Core\Http\Exception\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'destination', '_exception_statuscode'. in Drupal\jsonapi\EventSubscriber\JsonApiRequestValidator->validateQueryParams() (line 78 of /srv/www/habinatorbe/web/core/modules/jsonapi/src/EventSubscriber/JsonApiRequestValidator.php).

↧

RouteProvider::getRouteCollectionForRequest() can poison query string of next request

October 2, 2019, 5:30 pm

≫ Next: Wrong arguments passed to LocaleConfigSubscriberTest::assertNoConfigOverride

≪ Previous: Semi random CacheableBadRequestHttpExceptions

Problem/Motivation

Requests have their query parameters overridden by RouteProvider::getRouteCollectionForRequest() (here) when a route collection is matched in the cache. This is problematic if the cache entry was saved during a subrequest which alters the original request, specifically DefaultExceptionHtmlSubscriber, which sets two internal query parameters (_exception_statuscode and destination) for the error route.

This is problematic in so far as it's not intuitive behaviour (though this dates back to some early pre-8.0 work; see #2480811: Cache incoming path processing and route matching) but more importantly that the query parameters of later requests are overridden with those in the cache. For a form submission, this would mean the destination is overridden and incorrect, but in the case of a jsonapi path, it also means you get:

Drupal\\Core\\Http\\Exception\\CacheableBadRequestHttpException: The following query parameters violate the JSON:API spec: 'destination', '_exception_statuscode'. in Drupal\\jsonapi\\EventSubscriber\\JsonApiRequestValidator->validateQueryParams()

For instance, a common pattern in OAuth/JWT workflows is that a client will make a request with an existing access token; if it's unsuccessful (e.g., returns 401 - see #2840205: Error messages/codes should be more helpful & match spec.) then the client will attempt to obtain a new access token with a refresh token grant, and retry the original request. In this case, the retried request will fail with the above exception against a jsonapi endpoint as the now-authorized request will have the non-JSON:API spec compliant query string added.

Proposed resolution

The query string recovery from cache has mostly to do with the private files controller; see notes below. However, this issue is sensitive to alterations to the Request object prior to the cache ID generation for the collection cache, earlier even than incoming path processing.

Current thoughts are to not cache the match if we're doing a subrequest (though we currently lack that context as that's information stored in the kernel) or set the format for json:api requests sooner, so as to keep the html exception handler from firing to begin with. Or, something else?

Adjust the route collection cache cid to include the query parameters stored on the Request object after early processing.