[wp-hackers] Theme development and hooks.

[Unteins (Jason Goldsmith)]

This thread goes way back to April, but I am catching up on the  
hackers list (only 2331 more emails to read, not bad considering I  
started with over 6000 :)

Anyway, there may have been a solution posited later on that I  
haven't reached yet, but if not, here's my input (as I am currently  
struggling with my own plugin Live+Press as well as 3rd party plugins)

I think the solution isn't to try and automagically guess what may or  
may not be the valid and correct markup and CSS for the theme but  
rather to make a nice configuration setup so the user can input the  
right information manually. Yeah, I know, that's not a "user  
friendly" solution, but it is the only viable one. It is too easy for  
a user to create a bizarre layout or to not include something or  
whatever to bork the lookup tables.

If you really want automagical plugin output, you could parse the  
active theme or somesuch when the configuration page loads. To be  
perfectly honest, and I am leaning in this direction with Live+Press,  
it might also be good to make clean, output with no markup, or at  
least output functions that can take variables for input.

My layouts are messed up because of bad plugin output (my own  
included) and are nearly impossible to style correctly.

Which also reminds me, plugin developers should be careful when  
puking CSS directly into the html file. It is MUCH better imo (again,  
changes to Live+Press are in order, so I am an offender here as well)  
to simply tell users to add the appropriate css link or import  
directive to their templates. The big problem with all of the  
automatic CSS imbeds from plugins is that plugin a can stomp over  
plugin b's CSS and then the layout is unfixable.


On Apr 8, 2005, at 12:27 PM, David Chait wrote:

>> Just to point out a glitch in this thinking- You're saying that  
>> designers inherently use different layout styles in CSS, yet you  
>> think it's still possible to maintain compatibility between styles  
>> by providing a translation table from one name to another?  Why  
>> not just standardize on a single set of names instead of  
>> complicating things with a translation table?
>>
>
> A 'translation table' may be minimizing the complexity of what I've  
> been discussing (and why I kept talking about functions).  For MY  
> use, I'm thinking about 'how do plugins output HTML that looks the  
> same as the rest of the theme'.
>
>
>> The *real* issue that will break this translation table idea is  
>> that designers can use additional/different tags to demark their  
>> content.  A prime example of this is the post ID that is attached  
>> to posts.  Logic would have the post ID for each post be written  
>> into the post <div>, but in the case of the themes packed with  
>> WordPress, they're in the post's <h3> title.
>>
>
> Actually, if you read back, I've been talking about this exact  
> thing. Frankly, I don't use h3's, if it's an archive list they are  
> h2's, and if it's a single-post page the title is an h1.  But I  
> totally agree: people have different approaches to encapsulation:  
> it isn't enough to know the CLASS name, you have to know the tag(s)  
> wrappering.  At that point, having "post_wrap_open" and  
> "post_wrap_close" functions that output the proper wrappering might  
> help (this is why in the CG-PowerPack I have my 'sideblock'  
> functions, to abstract this very thing from implementation of  
> plugins to the output for a sidebar block styling...).
>
>
>> Where this complicates things (and why it would even matter to  
>> plugin authors at all) is if you use these things as IDs for DOM,  
>> you have to apply it differently for different themes.  On one  
>> hand (<h3>) you've got to use getElementById(postid).parentElement  
>> to get the post div, and on the other it's just getElementById 
>> (postid).  Who knows what radical differences there could be in  
>> other layouts!
>>
>
> Again totally agreed.  Are there a set of elements you might want  
> access to, and a method that'd provide you access by the theme  
> providing the right function?  I don't know... you're moving into  
> scripting, and I'm only (at the moment) looking to OUTPUT something  
> that looks like the theme. ;)  But good point to throw in!
>
>
>> It seems necessary to me to first create a standard that  
>> delineates where a plugin can expect to find certain elements and  
>> what their names (ids) should be, then to create any needed  
>> translation services.
>>
>
> No argument -- I see the 'standard' and 'services' as one, but you  
> can look as it as two steps along the path.
>
>
>> An alternative (and maybe this is what you're actually talking  
>> about) would be to include a table with every theme that describes  
>> how to find certain elements of the layout.  The table would be  
>> indexed by an item like "The element containing the entire post,  
>> including the title" and would provide some method for divulging  
>> that tag id based on the current post id.  It might work, but I  
>> think it's impractical, since publishing a standard would do  
>> essentially the same thing without forcing theme authors to go  
>> through the extra work of building a table for each theme.
>>
>
> Again, I agreed with the earlier post of it is impractical to  
> expect every theme author to match a given 'standard'  
> encapsulation, tagging, class nomenclature, etc.  Don't get me  
> wrong, I'd love it!  But as I gave my own site example above, some  
> of us are concerned about things like SEO optimization work, which  
> requires using certain tags in certain places for best results.
>
>
>> Enjoying this discussion.
>>
>
> As am I!  Glad there's some more going on, finally... ;)
>
> So to step back, I guess the basic form I'm looking for is:
> - how do I output something that goes in a sidebar/menu and looks  
> right? what is the title, what are subelements, etc.  (and 'what'  
> means 'what tag and class').
> - how do I output something that goes in a 'main content' area,  
> that looks like a 'post'?  what is the title, what is any meta-data  
> (timestamp or other notation), what is the body of the post, etc.
>
> Note that the 'post' theme info could be used to properly style  
> customized pages, such as an RSS feed page (which I've started  
> shipping an example of with CG-PowerPack), or a Contact Form page,  
> etc.
>
> This also hits the issues that Kubrick raised, which is using class  
> tagging on the id=content block to define a page meant to have a  
> sidebar or not --  which in 'my world' I'd have done as a enclosing- 
> DIV with id=nosidebar or something like that.
>
> -d
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>