[wp-trac] [WordPress Trac] #16373: Wrong page loaded requesting custom registered query_vars when correcting is_* for page_on_front requests
WordPress Trac
noreply at wordpress.org
Mon Oct 29 20:13:42 UTC 2012
#16373: Wrong page loaded requesting custom registered query_vars when correcting
is_* for page_on_front requests
-------------------------------------------------+-------------------------
Reporter: jondavis | Owner:
Type: defect (bug) | markjaquith
Priority: high | Status: accepted
Component: Query | Milestone: Future
Severity: normal | Release
Keywords: has-patch 3.3-early needs-unit- | Version: 3.0
tests | Resolution:
-------------------------------------------------+-------------------------
Comment (by dd32):
So the main issues here are:
- We assume that if a Query var (other than the whitelisted vars: preview,
page, paged, cpage) is set, then it's a archive/loop modifying query var
- Query Vars do not directly map to a Query modification, It can affect
plugins/Themes instead
- We have no filters available to say that a query var is a non-query
modifying query var
- Changing this could have backwards compatibility issues -
To expand on that last one, If we simply wrapped a filter around the array
of whitelisted vars, a plugin could do something such as this:
{{{
add_filter( 'singular_query_vars', function( $vars ) {
$vars[] = 'qv_test';
return $vars;
} );
}}}
but, that would still require multiple filters (One to add the query var,
and one to set the 'context' of the query var.
Perhaps what we really need here, Is a better way to register query vars,
and provide some kind of context at the same time (ie. "This query var
maps to this WP_Query tag", "This query var only modifies content on a
singular view", etc)
--
Ticket URL: <http://core.trac.wordpress.org/ticket/16373#comment:7>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list