[wp-trac] [WordPress Trac] #15063: Add a "context" property to WP_Query as a 2nd param to its constructor
WordPress Trac
wp-trac at lists.automattic.com
Thu Oct 7 22:41:32 UTC 2010
#15063: Add a "context" property to WP_Query as a 2nd param to its constructor
--------------------------+-------------------------------------------------
Reporter: mikeschinkel | Owner:
Type: enhancement | Status: closed
Priority: normal | Milestone: Awaiting Review
Component: Post Types | Version:
Severity: normal | Resolution: wontfix
Keywords: |
--------------------------+-------------------------------------------------
Comment(by mikeschinkel):
Mark:
The use-cases I'm most concerned about are not when I'm using the
`WP_Query` but when someone else is such as in core or plugins.
I'm doing all my work with CMS-related sites and I'm finding I probably
spend >50% of my debugging time tracking down a bug that happened because
I didn't get the limiting context correct in global filters. I'm looking
for ways to make plugin code more robust.
By analogy I am basically trying to go from protecting myself against all
the potential alternate needles in the haystack and instead wanting to
focus on a single specific needle that is known. Instead of looking for
and testing for ''"artifacts"'' i.e. `$postnow`, `$typenow`, `$_GET`,
`$_POST`, `$_SERVER['REQUEST_URI']` etc. etc. I'd like to be able to
tested for a know identifier in every reasonable context.
Filters called by `WP_Query` is but one place where where context is badly
needed, but its one of the bigger ones.
If you don't like this proposal, can we explore other ways to allow to to
pinpoint context with known markers? This was less important in the blog
days because you had nailed most patterns, but with CMS use-cases the
number of potential patterns has increased exponentially.
-Mike
--
Ticket URL: <http://core.trac.wordpress.org/ticket/15063#comment:2>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list