[wp-hackers] Regarding wp markup language

Mike Schinkel mikeschinkel at newclarity.net
Mon Apr 19 22:42:09 UTC 2010

On Apr 19, 2010, at 5:52 PM, Otto wrote:
> On Mon, Apr 19, 2010 at 9:30 AM, Jeremy Clarke <jer at simianuprising.com> wrote:
>> For your consideration:
>> function the_loop($args) {
>>    $defaults = array (
>> ...
> I'm not opposed to the idea, but it strikes me that a function call
> with some customization type stuff in it is not really any clearer
> than simply having the loop spelled out explicitly right there.
> A wrapper is only useful when it simplifies. I don't think callback
> functions are necessarily simpler by design. Especially when you have
> people wanting to do things like style alternating posts differently,
> or put advertising after the third post, etc.
> Yes, you can probably make a function generic enough to do this sort
> of thing, but I think you'd really be better off making the loop
> simpler directly instead of trying to eliminate it entirely.
> Your basic loop is this:
> <?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?>
> ...
> <?php endwhile; ?>
> It could be a bit easier than this. And one could feasibly eliminate
> the use of globals, which always make things so difficult.

In general I concur.  The callbacks are not as straightforward for themers as many would like.  If they have to type the word "function" and think about passing and accepting parameters most seem happier to just throw it all away and start from scratch. At least the designers I've worked with are mostly that way.

That said, what if the "callbacks" where optionally templates, and these was a default template hierarchy when not specified?  That could even leverage subdirectories for organization like Daryl Koopersmith's most recent proposal.

One thing I've found in working with TwentyTen is I quickly get myself confused with WordPress's standard like "page.php", "single.php", "loop.php" and so on, the templates I create based on the template hierarchy "single-financial-term", the templates based on get_template_part() like "loop-financial-term.php" and the templates I need to create for myself, i.e. "financial-term.php." It's not that it's all that difficult but it requires up-front thought and experience in what all is needed to properly architect a clean template hierarchy and most people (myself included, in this case), just start hacking things out and create a mess.  I've been thinking "I need to go back and fully rearchitect this mess" but I've not had the time and certainly I alone can't do the job the community could do collectively.   

Having a "the_loop()" where a clean template hierarchy was all figured out and consistent with all other templates would make life a lot easier for many, I think.  Rethinking the template system to use names in a more structured way could make it easier for someone to know what the files created by another themer are used for. If we use subdirectories we won't be limited by existing naming conventions i.e. "page.php" is the full HTML page for a post_type of page but "single.php" is the full HTML page for a post_type of post. Consistent? Not really.  It would be so nice to have a new clean-slate for template naming now that we have custom post types and custom taxonomies and thus so many more contexts than the current template structure envisioned.  Files like style.css, header.php, footer.php, sidebar.php could stay in the root but the rest could be moved to subdirectories, as one potential example: "pages", "posts" and "loops" (pages=full web pages, posts=post type snippets, loops=listings of post type snippets.)

Note in my example above "financial-term.php" differs from "single-financial-term.php" where the latter is a full HTML page for a single "financial-term" post type and the former is just a snippet to display a single "financial-term" to be used in a list or a widget. WordPress doesn't have a concept for the former but I'd really like to see us formalize it and I think this discussion begs that question.  Also, it would be nice to see themer-defined contexts like "financial-term-just-formula.php", "financial-term-excerpt-only.php", "financial-term-full-description.php", for example.

So by baking all this logic into the proposed "the_loop()" I think we will be much better off instead of just trying to simplify and use the loop directly.

BTW, one thing I'd like to see implemented is a way for the themer to easily discover the templates that are possible along a given execution path.  Maybe a developer add-on that used jQuery to popup a list when the plugin is activated and the page is loaded with a given URL parameter.  Maybe some though for something like this could go into this discussion too?  This would be useful for hooks to, come to thing of it.

> Now, this is just me thinking out loud here... What if the Loop fed
> into an object? That object could be like a container for your posts.
> You could pass it a function to output those posts like a callback, or
> you could get the posts from it one at a time and display them how you
> wanted. You might be able to loop through it directly even.
> The WP_Query actually covers some of this ground, the problem is the
> main Loop functions all act on globals. Perhaps those could be built
> into this object instead.
> I could have a WP_Posts which extends the WP_Query object. I could say
> $posts = new WP_Posts() to get the default query. WP_Posts could
> implement Iterator (or IteratorAggregate), so then I could say
> something like
> foreach ($posts as $post) {
> $post->the_title();
> $post->the_content();
> }
> No globals, no fuss, no muss.

Now that I really like.  And I don't think it conflicts with what I typed above, either because: 

1.) People can still use it instead of the_loop() if they want, and 
2.) It can be used inside the loop for even cleaner code then if we used existing constructs.

It also really cleans up a lot of the interface inconsistencies and the problems inherent in the global vars.  (Only caveat is if WP_Posts should extend or contain WP_Query? I'm concerned about the potential overhead of nested classes and more importantly the fragile base class problem.) 

Anyway, great idea.


More information about the wp-hackers mailing list