Hmmm. So what they hell have I been doing with my time lately. Not blogging, clearly. Well first there’s the day job, I’m trying to keep it . Then I’ve been working on a Real Estate plugin built on the PodsCMS framework. (Which incidentally is about to launch version 1.90) Why a plugin based on a plugin? Well Pods creates the power on the database side to build a better real estate listing system than would be possible using custom fields.

Real Estate listings have LOTS of fields, i.e. List Price, Agent, Square Footage, Neighborhood, etc. Sure you could use WP’s native taxonomies for some of these fields, but there are still going to be a lot of Custom Fields like # of beds, # of baths, etc. And try putting together a standard WP Query to filter for 20 custom fields. Damn. I’m just not that much of a pro I guess.

So the plugin will take the power of the pods framework and package it up in a way that you won’t really have to learn anything about pods in order to use it. I’m also adding some custom functions to create listings, display related listings, etc. Hopefully it will prove a valuable plugin to small to mid-size real estate companies looking to showcase their listings.

Full credit, I started the plugin as part of a freelance project for Big Sea Design. Woot! Woot!

At any rate, for anyone who’s running a pods installation and having trouble getting SEO friendly titles on your pod pages, this plugin creates a template tag <?php pods_seo_title(); ?> that you can use to override wordpress default behavior. The plugins check to see if the page is a pod page, and if so calls the title of the respective pod. If not, it checks to see if the page is singular and returns the TITLE | SITENAME format if it is. Otherwise it returns the SITENAME | SITE DESCRIPTION form.

Download: Pods SEO Titles

The Issue: You’re working on a site designed long before Custom Post Types were an itch in Matt’s cerebellum. But now that the functionality is there and you want to incorporate it into your theme. Previously you used conditional code to theme your single.php file.

<?php if(in_category('foo')) { ?>
   Do something.
<?php } elseif(in_category('bar')) { ?>
   Do something else.
<?php } else { ?>
   Do yet another thing.
<?php } ?>

The thought of adding yet another layer of conditionals makes you sick to your stomach. Custom Post Types need to be treated completely different. They have different categories, taxonomies, and even different sidbars. Arg!

Solution: One simple function. Call it whatever you want, but here’s what it looks like. When I say simple … I mean simple.

function get_post_in_context() {
   global $post;
   $type = $post->post_type;
   include(TEMPLATEPATH .'/layouts/single-'.$type .'-content.php');
}

Now just create a directory in your theme called “layouts”. Then copy and paste all the markup in your single.php file between the get_header() tag and the get_sidebar() tag to a file named single-post-content.php and save the file to your layouts folder.

Now place a the get_post_in_context() tag into your single.php  where you want the markup from single-post-content.php to show up.

<?php get_header(); ?>
<?php get_post_in_context(); ?>
 <?php get_sidebar(); ?>
<?php get_footer(); ?>

The beauty of this is that you can now create a new single-POSTTYPE-content.php (example:single-events-content.php) file for any of your custom post types and it will automagically get called instead of the single-post-content.php without any more changes to the single.php file.

I can’t take total credit for the idea. Some theme frameworks already employ a version of this strategy. But I need to adapt an existing theme rather than start from a framework. This function above will allow you to scale your existing theme to accomodate new post types without having to redesign your whole site.

Moreover, I was confused because Carrington Theme didn’t seem to make it any easier to turn WordPress into a CMS! It made it harder because there was yet another layer of abstraction to worry about.

But my negative assessment was born of ignorance more than experience. It wasn’t until I was knee-deep into my first CMS project managing more than 10,000 pages of content with at least 10 different “content types” that I began to remember the Carrington Framework … and then click! it all made sense.

Carrington is a framework built to help developers manage sites with hundreds of customizations. I built my CMS site without Carrington and my sidebar.php file looks like Frankenstein on acid: include, conditional, biconditional, include, exclude, uhg. Sometimes when I need to fix a particular customization it takes me ten minutes to figure out which include file it’s in.

The whole point of Carrington is to make 90% of that conditional code unnecessary because so much of it is predictable. If you’re building a CMS, you can pretty much guarantee that you want change the sidebar depending on the context of the page, right? Carrington just makes it simpler to do so.

Perhaps the confusion over Carrington is that it markets itself as a “CMS Framework”. But in fact, it’s a THEME framework for CMS builders. If you are using Carrington, you will still need to know how to use WordPress custom fields and write panels etc. But the theming will be 100 times easier.

Here’s the problem, I have a theme that is built to make WordPress a CMS, so it requires a few steps to set up. But I just got an email back from the WordPress clue in which it was clear that the theme tester, effectively the gate keeper, didn’t even bother going through the steps.

My Onstage Theme for Actors uses ‘/home.php’ to display a headshot, and only a couple of excerpts from the blog. Users have to create a page for the blog template that is included. But the theme tester didn’t even bother to set it up. Instead he complained that the posts weren’t paged and there was no sidebar, both of which are part of the blog template.

So how is WordPress to become recognized as a full content  management solution when the WordPress theme directory seems to expect a cookie cutter installation process?

For the wordHeavy user, that is the designer/developer building their content management system on the wordpress platform, there isn’t all that much to be excited about. The easy theme feature is likely to further centralize theme development within the grips of WordPress.org theming rules. Not that there’s anything inherently wrong with this, I just worry about those designers who charge for their creations loosing market share to “free” themes.

Perhaps WordPress will come up with a more inclusive gallery system? Or maybe an enterprising developer will develop a competing gallery that can be installed with a simple plugin.

The one development I’m looking forward to using is the widgets. As a freelancer, you have clients who need a specific sidebar widget. A special campaign logo for instance. The need is small enough that it isn’t worth the time developing a custom plugin for the widget (even though it really doesn’t take that long). Instead, I routinely use simple text widgets to paste in the small bits of code.

Trouble is you can’t save a text widget for later use. So the client one day feels a little adventurous, start playing with widgets … they are fun to play with … and accidentally delete your modified text widget. Doh! Not that big of a deal, but a real pain in the ass.

But starting with 2.8, widgets can be made “inactive,” which means they are saved in the system. Sweet!!! Now all those little widgets can be safe from unnecessary annihilation at the hands of the unsophisticated end user.

Actually, they are not entirely safe. For some reason the WordPress developers didn’t take the next logical step. When you have a widget in the sidebar and click the “remove” action, the widget doesn’t dump into the inactive bin, it is DELETED! I think it would make sense for the to go to the inactive bin first and to have widgets only deleted from the inactive bin. That’s what I get for not keeping up with the WordPress developers email list. Oh well, maybe 2.9 right?

The other improvement on widget management is that you no longer have to click which sidebar you want to show. Nor do you have to save the widget (clicking the “done” button) and then also save the sidebar (clicking “save changes”). Now all the options and functionality are on one page. That reduces the number of needed clicks to add a widget by half. Little stuff for most, but big stuff for heavy WordPress users.