Problem/Motivation
Drupal\Core\PathProcessor\PathProcessorFront uses an array_replace to merge query parameters from the inbound path into the frontpage path. However, the $parameters variable is not assigned again, therefore any parameters passed in are lost.
Steps to reproduce
1. Install standard
2. Go to /admin/config/system/site-information and set the frontpage to /admin/people?status=2
3. Visit / - Notice the view is filtered by Status=Blocked (expected)
4. Visit /?status=1 - Notice it's still filtered by Status= Blocked (bug)
5. Visit /?user=foo - Notice no value added in the "Name or email contains" filter (bug)
Proposed resolution
Change line to $parameters = array_replace($parameters, $request->query->all());
Remaining tasks
Write tests
User interface changes
None
Introduced terminology
None
API changes
None
Data model changes
None
Release notes snippet
N/A
| Comment | File | Size | Author |
|---|
Issue fork drupal-3126761
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3126761-parameters-not-reassigned
changes, plain diff MR !12667
Comments
Comment #2
puddyglumIt makes sense to fix the missing assignment.
Comment #3
puddyglumRetry patch without trailing whitespace.
Comment #4
puddyglumRetrying again, unsure what the whitespace truly is.
Comment #5
puddyglumComment #6
longwaveThis looks like it could do with a test to exercise this behaviour.
Comment #7
puddyglumIn developing a test for this, I found two additional issues introduced in #3000671: Frontpage with query parameter results in "Page not found". I've updated the issue description.
I think both issues can be resolved at the same time as they appear to be related to the handling of query parameters present in Default front page.
Comment #8
puddyglumIt looks like, from #3000671: Frontpage with query parameter results in "Page not found", the only effective change was setting the $path to be something else. The array_merge and subsequent $request->query->replace() did not create changes outside of the function. Working on creating a patch for this.
Comment #9
puddyglumI'm not sure why the browser redirects to the path of the frontpage when there is a query string in it. For instance, if you set front page to /admin/people, it will stay at /. If you set front page to /admin/people?anything, it will redirect to /admin/people. I don't see anything in PathProcessor that is causing that.
Attached patch basically cleans up the code and removes the unnecessary processing of potential query parameters.
Comment #11
puddyglumRemoving the tests against $request->query->all(), which also only used a copy of the $request object. My apologies for not testing this myself before providing the patch.
To summarize this fix, it keeps the $path = $components['path']; fix from #3000671: Frontpage with query parameter results in "Page not found" which prevents Page not found when a user adds parameters. It removes the portion that was thought to add query parameters to the current request. It only changed a copy of the current request.
I would rather that it did change the current request, but after reviewing the code I feel that is outside the scope of the PathProcessor, and changing the request should be made in the Routing or Url systems.
Comment #12
puddyglumComment #13
puddyglumShould we add a validation on the Default front page field, so that adding query parameters is not allowed? For instance, with or without the fix, if you add a ? to the path, it will pass validationn, but frontpage will display Page not found. If you add ?anything to the path then it will redirect to the path.
Visiting / in the borwser with these Default front page values:
a. Value of /valid-path => allowed, 200, browser URL is /
b. Value of /valid-path? => allowed, 404, browser URL is /
c. Value of /valid-path?some-query => allowed, 200, browser URL is /valid-path
If we disallow query strings, users will not experience cases (b) or (c). I don't believe it creates any breaking changes either.
Comment #19
smustgrave commentedThis issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.
Not sure I can answer #13 so tagging for subsystem review
See this was also previously tagged for tests so that still needs to happen
Thanks!
Comment #21
acbramley commentedTriaged as part of BSI and reproduced this bug manually, still an issue on 11.x. Some of the reported issues in the IS aren't reproducible though.
Rewriting the IS with the standard template.
Comment #23
acbramley commentedComment #24
acbramley commentedComment #25
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #26
acbramley commentedComment #27
smustgrave commentedNot sure why I tagged for sub-maintainer but that was when we just got NRQI off the ground.
Ran the test-only feature here https://git.drupalcode.org/issue/drupal-3126761/-/jobs/6378866
The actual fix core/lib/Drupal/Core/PathProcessor/PathProcessorFront.php makes complete sense.
LGTM!
Comment #28
alexpottCommitted 4d349db and pushed to 11.x. Thanks!
There were conflicts with 11.2.x so did not backport.
Comment #30
longwaveDoesn't look like this got pushed.
Comment #31
alexpott