Opened 12 years ago
Last modified 2 years ago
#23862 reopened defect (bug)
Clean up old WP->public_query_vars and WP->private_query_vars
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Query | Keywords: | has-patch |
Focuses: | Cc: |
Description
There are some old non-working public_query_vars still in the WP class that should be cleaned up.
- posts - broken 10 years ago http://core.trac.wordpress.org/changeset/182/trunk/blog.header.php
- search - hasn’t done anything since wp_query was created
- calendar - don’t see support since ‘b2’
- pb - don’t see support since ‘b2’
- static - only used in determining if is_page, though it no longer works correctly, added http://core.trac.wordpress.org/changeset/1527/trunk, but functionality was partially changed the next commit
Also, since 'post_type' is now a public_query_var, it can be removed from the private_query_vars.
Attachments (1)
Change History (15)
#8
@
11 years ago
I don't care much about static, pb, or even calendar, but I think it'd make sense for search and posts to remain reserved. (I wonder what pb was for.)
Going to clean up post_type and leave the others alone for now.
#9
@
11 years ago
- Owner set to nacin
- Resolution set to fixed
- Status changed from new to closed
In 27738:
#10
@
11 years ago
- Milestone changed from 3.9 to Future Release
- Resolution fixed deleted
- Status changed from closed to reopened
Alright, this actually broke a canonical unit test. (The noRewrite ?post_type=fake-cpt&p=1 one.)
WP::parse_request() parses public query vars and then parses private query vars. But in between there, it discards any post types that aren't publicly queryable. The canonical tests leverage WP::main() directly, and thus private query vars have outsized influence... It's kinda tough to explain, and was not fun to track down.
Anyway, as this was ostensibly for cleanup, and it clearly causes some side effects, I'm reverting.
#12
@
11 years ago
#27549 and #27547 — this definitely breaks things, in this case the admin which uses wp() and thus private query variables directly.
So at least for the post_type query variable, which is a particularly special case in the WP class, it's *not* invalid for it to be listed in public *and* private query variables.
Keep in mind it may be worth holding onto some of these as reserved terms for future use, like search.