#35115 closed defect (bug) (fixed)
404 error when URL includes title=...
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.4.1 | Priority: | normal |
Severity: | normal | Version: | 4.4 |
Component: | Query | Keywords: | needs-unit-tests |
Focuses: | Cc: |
Description
Our web site is broken since upgrading to WordPress v4.4. We have several pages where we pass parameters in the URL. Since 4.4, any URL which includes "title=<some_text>", where <some_text> is any text at all, results in a 404 error.
Our permalinks are of the post name format ("/%postname%/"). I have not tested this with any other permalink formats, as changing permalinks would also break our site.
To reproduce, simply add "?title=test" to any page URL, at least while using post name permalinks.
Attachments (2)
Change History (25)
#1
@
9 years ago
- Component changed from General to Query
- Milestone changed from Awaiting Review to 4.4.1
#2
@
9 years ago
@wonderboymusic: This is caused by [33706], which is clobbering anything else using title
as a URL parameter. Any thoughts on how to keep the title search, while allowing folks to keep using title
in their own code?
#3
@
9 years ago
I'm not sure why the title
param is a public query var - is it really designed to be used in URLs, or should it be limited to code WP_Query
s?
#4
@
9 years ago
+1
We have customers with forms passing title as a parameter that are breaking because of this. Our example code for adding fields to PMPro checkout pages uses title as the name/key. I'm thinking we might need to add prefixes to those parameters to avoid future conflicts.
FYI here is code I'm using on some sites to disable the title query var. This might be overkill, but it works in a pinch.
https://gist.github.com/strangerstudios/856e900680330ee503ed
#5
@
9 years ago
As a follow up, we already avoid the other public query vars. I don't know if it makes sense (or is even that easy or possible) to have "title" available for queries in code but not by appending ?title= to a URL as @dd32 is suggesting. If there is and that makes sense, I'm game, but IMO, since 4.4 "title" is sacred and we need to find other parameters to use.
I can think of some crazy ways to allow parameter sharing, but they feel really icky to me.
#6
@
9 years ago
I agree - unless there's a need I'm not aware of (/?title=Hello%20World
is cute, but hardly necessary), title
shouldn't be a public query var.
#7
@
9 years ago
Just wanted to add - this also happens with POST requests, I have a form (with POST method) on one of the pages on my site that includes a "title" input and it always returns a 404 page after I submit the form.
#10
@
9 years ago
For the benefit of those of us who are not familiar with the code or the context of the variables, could you please clarify that this means the user can continue to use "title=" in the URL when 4.4.1 comes out? If so, thank you very much for the speed with which this has been handled.
#11
@
9 years ago
@Fuse99: Yes, this change will allow using the title
parameter without consequences in the URLs. This is the main goal IMHO, as this was working properly before 4.4.
The idea is to still allow querying posts by title (as introduced in [33706]), but without the option to query them directly through the URLs (which was causing 404s in GET and POST requests that contain title
parameter).
#12
@
9 years ago
- Owner set to pento
- Resolution set to fixed
- Status changed from new to closed
In 36034:
#13
@
9 years ago
- Keywords fixed-major added; has-patch removed
- Resolution fixed deleted
- Status changed from closed to reopened
#14
@
9 years ago
- Keywords has-unit-tests added
It might be a good idea to add a unit test for public query vars, so whenever a new public query var is introduced it at least needs the test updating, making it a more explicit action in that regard.
35115.tests.diff adds such a test.
#16
@
9 years ago
- Keywords commit added; fixed-major removed
- Resolution fixed deleted
- Status changed from closed to reopened
Hi @Fuse99!
Thank you for the bug report. I've confirmed that this works in 4.3, and is broken in 4.4, so we'll work on getting this fixed up for 4.4.1.