[wp-hackers] Avoiding Side-effects in Filters & Actions

[SoJ Web]

I've run into this problem too, but I think it would be really tricky  
to formalize a way of doing this, mainly because the context depends  
on what you're looking for. For me, and maybe my experience is  
different, the context has always been something dependent on the  
content of the site, so there's no way to "build it in" with a theme  
or a plugin.

I can see the value of creating a place where theme or plugin  
developers can create and store the context, but, because it's so  
variable, I wonder if it isn't better to just let them do it  
themselves. For posts and pages, I've used custom fields, and it has  
worked quite well. For instances where it's an archive page, it's been  
plain old blocks of logic using the conditional tags, but it works.  
There have also been cases where I made special templates pages, so as  
to guarantee the context.

> Another aspect is the content on the part of the page. For example,  
> I might have a page that has a criteria based list of posts that has  
> widgets that also contain list of posts. There's no concrete way to  
> say "In this part of the page add *this* to the WHERE clause on on  
> this other part of the page do not." Instead you have to search for  
> artifacts to test, and often those artifacts don't behave as you  
> first assume causing bugs that aren't traced down until after you've  
> deployed for the client.

Something like this, I'd think, would simply have to built into the  
theme. Creating custom template tags that live with the theme in the  
functions.php file. That's how I've done it, anyway.

So how would you define a WP_Context class? And how would it be used?  
Would get_page_id() be any different than $post->ID? Or  
get_section_id() from $post->post_parent?


On Apr 2, 2009, at 1:10 PM, Mike Schinkel wrote:

> "Peter Westwood" <peter.westwood at ftwr.co.uk> wrote;
>> I'm not sure where you want the context or what type of
>> context you want but you can use the is_ template tags
>> with plugin code not just themes. Things like is_tag(),
>> is_ page() etc
>
> Yeah, I already use those when I need them. But they are not very  
> granular and sometimes granularity is essential. There are many  
> examples and but let's start with one, maybe there is a canonical  
> approach to this that I've not discovered yet.
>
> First example is a need to get a page's identity in code. The first  
> use-case is a client wants "messaging" modules on their site where a  
> "placement" is defined for a given time period by the page on which  
> is it located and the location on the page (i.e. "products- 
> page_bottom-right".)  To implement this I wrote a generic  
> "messaging" plugin that took the "page name" from context and a hard- 
> coded location on the page and did a database lookup for the current  
> messaging module.  The problem was I wasn't able to come up with a  
> consistent way to identify the page name other than sniffing the URL  
> and creating a function I used that did an ugly "if-then" construct.
>
> One of the reasons that page names are difficult is that some pages  
> represent a record in wp_posts whereas others represent a query (all  
> posts for April 2009, all posts tagged with "London", all posts in  
> the "News" category, etc.), others represent an author, others an  
> attachment, others a search page, and so on. And worse, some plugins  
> define their own context but don't have a standard best-practice way  
> to expose that content (i.e. a gallery plugin might have current  
> image and an calendar events plugin might have current event.) There  
> is no one place you can go (that I am aware of) to get the "page id"  
> that is known to be unique and that is reasonably non-cryptic except  
> the URL which itself doesn't always specific the type of page  
> without more information.
>
> Another aspect is the content on the part of the page. For example,  
> I might have a page that has a criteria based list of posts that has  
> widgets that also contain list of posts. There's no concrete way to  
> say "In this part of the page add *this* to the WHERE clause on on  
> this other part of the page do not." Instead you have to search for  
> artifacts to test, and often those artifacts don't behave as you  
> first assume causing bugs that aren't traced down until after you've  
> deployed for the client.
>
> On some sites there was also the need to establish "sections" for  
> analytic tracking. While this is somewhat subjective and site  
> specific, in many ways it follows the if-else  statement in template- 
> loader (note these are *not* the same as the corresponding is_*()  
> function because the if-else also tests for a valid template):
>
> 404
> search
> taxonomy
> home
> attachment
> single
> page
> category
> tag
> author
> data
> archive
> comments_popup
> paged_template
> template_index
>
> In addition to these, the paged_template could be subdivided to  
> include sections based on pages with no parent (i.e. top level menu  
> items.)  And these sections would need to  be overridable, probably  
> with a filter.
>
> Now maybe my most recent project pushed WordPress harder people push  
> WordPress and that I ran into these "edge cases" far more often than  
> others?  Whatever the case, I had to write lots of if-then  
> statements with a lot of trial and error to "map" URLs to "pages  
> names" and to "inspect" various global variables and call various  
> functions, all of which time to discover and time to figure out it  
> it was really appropriate. This logic is being performed in core,  
> but I don't have direct access to it. I'd be happy to send my 600  
> line "mapper" file from my most recent project to any individual  
> that wants to see more concretely what I mean.
>
> So what would I propose? I could start building a WP_Context  
> singleton class with a goal of having it become the object to  
> inspect when you need the current context in WordPress. I'd start  
> with the methods get_page_id() and get_section_id() and evolve it as  
> needed. I can do this on my own however I would occasionally need  
> access in core to setting its values where I currently don't have  
> access, for example in template-loader.php. And if it became robust  
> enough and generally useful, you could role it into core.  Would  
> that work?
>
> -Mike Schinkel
> Custom Wordpress Plugins
> http://mikeschinkel.com/custom-wordpress-plugins
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers