[wp-hackers] pre_get_posts problem

[Dion Hulse (dd32)]

On Thu, 22 Jul 2010 07:13:36 +1000, Thomas Scholz <info at toscho.de> wrote:

> scribu:
>
>> On Wed, Jul 21, 2010 at 8:14 AM, Andrew Nacin <wp at andrewnacin.com>  
>> wrote:
>>
>>> This is one of the dangers/pitfalls of using pre_get_posts. It seems to
>>> be recommended often for some reason when dealing with custom post
>>> types, but it is much better to modify the request itself, versus any
>>> old get_posts or WP_Query call.
>>>
>>
>> I think the reason it's recommended often is that people usually start
>> looking into the WP_Query class first and 'pre_get_posts' looks like the
>> right place to hook into.
>
> Maybe a comment above this filter with pointers to better places would be
> useful?

This might be a good idea on some of the more commonly abused hooks, or  
more specifically, filters which exist in code which can exist in multiple  
contexts.
PHPDoc comments at the start of functions do sometimes reference the  
filters used within, but often some people may skip the large chunk of  
text in preference for the code.

There once was a time where WP_Query was mainly utilised by the actual  
query, get_posts/get_pages etc duplicated their own content, and since  
they've been reduced to utilising existing code, developers who did it  
that way once upon a time, may also be bringing through bad practices.

For example, I've seen people suggesting using is_admin() inside certain  
filters to exclude the admin, where, in actual fact, they should be  
hooking somewhere completely different to prevent affecting other queries.  
Unless people highlight to others (and menu's have really helped do this)  
that doing things in certain ways will break code, people dont change, and  
new articles/blog posts dont get made explaining the "correct" new way of  
achieving it.

-- 
Dion Hulse / dd32
Contact:
  e: contact at dd32.id.au
  Web: http://dd32.id.au/