#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 jondavis):
It seems to me that creating a formal API for this situation is a bit
overkill. Seems by designthat query vars shouldn't be used as a registry
for plugins/themes to use as custom query string arguments. My own
confusion on the issue was in my rush to move to doing things the
"WordPress way" I was attempting to use the query vars as a whitelist of
registered `$_GET` variables unnecessarily.
That said, there may be edge-cases I (or apparently anyone else) are not
aware of where plugins/themes do need to use registered query vars but
still expect to get `page_on_front`. I can't even imagine why that might
be. In any event, for that use case I submitted
`test_page_on_front_query_var.diff` as a use case to test against should
the powers-that-be decide it is a worthwhile design consideration.
Given my new understanding of the design intent, I will be changing our
plugin code to just use `$_GET` variables and ensure proper input
sanitization is occuring.
As an action item, perhaps the result from this ticket is to update the
codex to explicitly direct developers in the proper/expected/intended use-
case strictly for modifying the `WP_Query`, and avoid any possible
misunderstanding that `WP_Query` query vars should not be used for general
purpose `QUERY_STRING` "query vars".
--
Ticket URL: <http://core.trac.wordpress.org/ticket/16373#comment:8>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software