If you’ve worked with MVC frameworks, then you’ll probably agree that the VC portion of MVC is pretty nice. It really helps keep your presentation code separate from application code. For example:

Controller:

<php
$title = 'Welcome!';
$content = 'Glad you could join us';
?>

View:

<h2><?php print $title; ?></h2>
<div class="content"><?php print $content; ?></div>

Result:

<h2>Welcome!</h2>
<div class="content">Glad you could join us</div>

Nice, organized, simple.

But with wordpress’ theme system most all of the functions print output directly to the screen when called. Example:

<?php
// prints to the screen immediately
the_title();


// if you tried this, you'd be left with '1'
$title = the_title();
print $title; // doesn't work!
?>

Now, this is totally cool because wordpress is blogging platform; it’s not meant to be a CMS, running lots of pages and endless posts.

But it can be used this way. And it will be used this way.

A friendlier (and independent?) theme layer

Stay with me for just a few paragraphs of motivation.

Often a website will contain several applications. The less the better, but let’s be realistic. It’s quite common for one site to run a wordpress, menalto gallery, some static pages, some custom database stuff, and a forum. And throw an ecommerce app on top of it.

In general, you’d like for each of these applications to share the same common layout. Ok, no problem. Simply modify the presentation of each application, wrangle your theme and common elements into them, and pray you never have to update them ever again.

Of course, you will update them. And you’ll forget to modify the forum’s header file, or you’ll forget that your wordpress uses the same header file, and now that you’ve modified it, the modal windows are broken… The result? An inconsistent common theme across applications and too much manual work when making global changes.

An idea for an independent theme layer

So I’ve come up with an idea for an independent theme layer. It’s a collection of a couple of small classes, and it would allow you use common theme files across multiple applications without having to wrangle code or make 10 different header.inc files, each with different class=”forum” or class=”blog” or other piddlies that don’t seem to be worth a whole inc.

I’m not releasing this thing yet or anything, but I am currently using it for one of my wordpress sites in development. I’m gonna keep working with it to see if it’s even worth developing further.

Didn’t you say this post was about wordpress?

Now that I’ve got a little motivation going, here’s the general idea of how to use this theme layer with a wordpress theme. It’s probably best to explain with some quick examples.

Let’s look at a normal wordpress theme, with the classic wordpress loop:

<div id="content">
  <?php if (have_posts()): while (have_posts()): the_post(); ?>
    <h2><?php the_title(); ?></h2>
    <div class="content"><?php the_content(); ?></div>
  <?php endwhile; endif; ?>
</div>

Ok, pretty standard wordpress loop that iterates over posts. But what if it were more like this:

<?php
  $page->add_to_region('Header', load('commom/header'));
  $page->add_to_region('Footer', load('commom/footer'));


$c = '';
  if (have_posts()) {
    while (have_posts()) { 
      the_post();
      $c .= load('tpl/single_post_template');
    }
    $c .= load('tpl/posts_navigation');
  }
  $page->add_to_region('Content', $c);

// prints the final output
  $page->render();
}
?>

Where single_post_template looks something like this:

  <div class="post">
    <h2><?php the_title(); ?></h2>
    <div class="content"><?php the_content(); ?></div>
  </div>

Note that the load() function (or whatever it eventually would be named) would have to use some kind of output buffering control to keep the wordpress theme functions from printing directly to output. Output buffering could be used to store these values.

Then, when its render() method is called, a full wrapper will be loaded, and the values of each region would be plopped right in. Here’s an example of such a wrapper:

  <html>
    <body>
      <div id="Header"><?php print $Header; ?><?/div>
      <div id="Content"><?php print $Content; ?><?/div>
      <div id="Footer"><?php print $Footer; ?><?/div>
    </body>
  </html>

Once render() is called, the variables in the wrapper file will be replaced with whatever you’d assigned to the regions above.

The VC in MVC

What this does is give us the VC portion of MVC, but only in the context of a theme; in other words, to wordpress this adds a nice separation of the Controller and View layers.

The wordpress template file (i.e. index.php, single.php) becomes the “theme controller” layer and the partial templates (i.e. header.php, single_post_template.php) represent the “theme view” layer.

Independence

Now that you’ve seen the wrapper layout file and how it could be used to display dynamic regions, you can see how using this shared layout across several applications could work. You’d assign values to each region based on what that application needs to output.

What do you think?

To me, I really like that I can keep all XHTML out of the index.php, single.php, and other template files and in the view files.

This method also reduces the amount of repeated code, with the exception of the wordpress loop, which probably isn’t worth wrapping in a class anyway.

What do you think?

• Do you think this could be useful to you?
• Is the benefit of keeping clean template files enough to justify the additional processing?
• Have you ever even been bothered by repeating yourself in wordpress templates?