Thord’s post on using WordPress as a CMS got me to thinking about all the times I’ve used Movable Type for that purpose. I use MT for the same reason he uses WP — I know it well enough I can make it do anything I want. It also helps that Six Apart has been steadily adding more CMS features.

So what do you need to know if you’re going to use MT as your CMS? Thord’s article covered a lot of things that should be considered when selecting any CMS software, so I’m going to concentrate on some of the pros, cons, and quirks involved in working with MT.

Pros

• Templating – MT’s templating system really does let you publish your data in any way you want. Depending on the needs of your website, you can setup MT to generate anything from a simple web page to a complex CSV file to a proprietary feed format. For many things you don’t need a plugin, you just need to know the structure of the final output. One practical example is creating an email newsletter from your recent blog posts. I once created a template that included excerpts from recent blog posts in a format that could be fed directly to sendmail (or some other mail transfer agent) to send to my subscribers. Worked great, and made it easy to reuse my blog content.
• Custom Fields – Custom fields in MT are very powerful, and easy to create. “Blog entries” can have fields appropriate to the actual content, such as an address field for an event or a rating field for a movie review.
• Multiple blogs – It’s easy to setup multiple blogs so that each can maintain a different section of a site. You might want one blog for your photo gallery and another for your product catalog, for example. And, both can make use of global templates, so you don’t have to duplicate work.
• Roles – MT gives you fine-grained access control over what users can do. This allows you to setup a hierarchy of authors, editors, designers, and admins that control different aspects of the site.
• Custom App – The application itself is built using the same templating system used for blog templates, so you can customize the interface. You could do anything from replacing the header with your client’s logo to completely reskinning the admin to match their site.

Cons

• Publishing – Movable Type’s concept of publishing — and republishing everything when you make a design change — can be difficult for users. Static publishing does not give you quite the same instant gratification that dynamic publishing does.
• Plugins – There are a lot of great MT plugins, but the development community is small when compared to Drupal or WordPress. There’s also very few “big feature” plugins. If you’re looking for ecommerce or event calendar plugins, you’re not going to find them.
• Themes – As with plugins, the variety of MT themes is rather limited.
• Image uploads – Tying images or other files to a page or post is still complicated. Plugins help, but it could be easier.

Quirks

• Templating – At this point, the templating system is almost its own programming language, which may put off some designers. And if you do something wrong, the error message can be difficult to interpret.
• Organizing – Organizing an MT-based site takes some advanced planning. Can you arrange a single blog the way you want with categories and tags, or do you need to use multiple blogs to control the site? If you change your mind later on, it’s not going to be an easy switch.
• Multiple Domains – It is possible for MT to power multiple domains from a single install, but setting it up properly takes some work. If you’re considering doing this, you might want to read how I got my system working.

Which software you choose for your CMS depends largely on your needs and what you’re familiar with. Personally, when I consider what software to use to run a website, my first question is, “How easy will it be for me to customize this?” In that regard, MT has met my needs for a lot of projects.

Have you ever used MT as a CMS? Tell us about your experience in the comments.

Movable Type 4.2 came out about two weeks ago, and since then I've been poring over the documentation to learn about the new features in this release. There's a lot here for developers and designers to enjoy. Things like social networking, improved templates, and better performance make upgrading an easy decision. Let's look at some of the new things we have to play with.

Community Features

The MT Community Solution was first introduced over a year ago. With 4.2, that feature is expanded and, possibly more importantly, now free for non-business users. Your blog can include forums, ratings, user profiles, and more.

What makes me excited about this is the combination of a full suite of social networking features with MT's powerful templating system. Designers can break out of the standard forum look to develop new (and hopefully better) user interfaces.

New Default Templates

Although the modularity of the default templates in 4.0 simplified site-wide changes, many developers found them too complicated. The 4.2 templates attempt to correct this. The line-upon-line of <mt:setvar> tags that started many of the templates are now gone. There's also far fewer includes. These new templates should be easier to modify for people new to MT.

Template Module Caching & Server Side Includes

The results of template modules can be cached so they don't have to be recreated every time you publish. This is great for sidebar content that doesn't change with each entry you create. Combined with the new settings for Server Side Includes, this should be a powerful replacement for my optimal includes.

Custom Fields

Custom fields is another feature that's been around a while, but with 4.2 it becomes available to more people through the free blogger license. This is huge for people using MT as a CMS. MT's custom fields are particularly nice, because each type of field you can create comes with its own set of template tags.

Pagination for Dynamic Publishing

Any dynamically-published template can be paginated. This feature is not a part of the default templates, but the implementation is very simple. This goes hand-in-hand with new options that give you more control over how each template is published.

...and many more changes, both large and small. Over the next few weeks I'll be exploring these new features more and giving you new and interesting ways to use them.

Notes for Upgraders

Since the initial release, a couple of changes have come to light that you should know about if you're upgrading an existing blog. First, because of a change in how per-template publishing is handled, any index template you had set not to publish automatically will now be set to publish. You'll need to go into each one and change the Publishing option to Manually.

Also, the dirify modifier no longer strips out hyphens. If you have a custom archive path that uses dirify (e.g. <mt:entrytitle dirify="1">.php), it would change where some files get published. On the ProNet mailing list, this work-around was offered:

It's likely this change will either be reversed or someone will release a plugin that makes dirify work the way it used to.

Have you tried MT 4.2 yet? What are your favorite new features?

Take a look at most search results pages and what do you typically see: Each result has a title, a short excerpt, some metadata, and maybe a thumbnail image. The default search results from a Movable Type blog, though, will show the Body of each result. To me, this introduces some problems. First, each post could be quite long — much longer than one wants to read on a results page. And each result may or may not show any images, depending on whether the images are in the Body or the Extended section of the entry.

Fortunately, we can fix these problems, and at the same time learn a new way to pass variables to included modules.

In our Entry Summary template module, we want to modify the template where it outputs the entry body to match this:

This is pretty simple: We test the show_thumbnail variable, and if it's not empty we find the first asset in this post and display it as a thumbnail. Notice that when we display a thumbnail, we output the entry excerpt rather than the entry body. By default, the excerpt strips out HTML, so we don't take a chance of the image displaying twice.

Our Search Results system template only needs a small change:

The <MTInclude> tag passes any attributes it doesn't recognize as variables in the included module. There are two benefits to this method. First, it's a little shorter than typing a full <mt:setvar> tag for each variable. And, the variable is local — it's only available inside that included module (and any modules it calls). You don't have to worry about conflicts with other variables of the same name in the Search Results template.

With a little CSS, our search results can look something like this:

Screenshot of search results

It's a small addition to your search results, but it can help your visitors quickly scan the returned results and find content they are interested in.

A recent post on ProBlogger discussed the pros and cons of dates on blog posts. The gist of it is recent dates can make posts appear fresh, but a post with an older date might appear stale, even if the information is still relevant.

One option discussed in the article was removing dates from older posts. This seemed like an interesting idea to me, so I set out to see how it could be done with Movable Type. It's fairly easy, although it does require either a plugin or some PHP code.

Let's start with the plugin version. We'll need to install DateTags. This is an older plugin that's not entirely compatible with MT4. In particular, there's a problem with the <MTNextNEntries> tag. We don't need that tag for this, so for our purposes it will work fine.

After you install the plugin, open your Entry Metadata template module and add this code to the top:

Simple, right? Let's go through it, though, and see what's going on.

MT uses the Entry Metadata template module in a lot of different templates, but I only want to control the appearance of dates on individual entry archives. You can skip this check if you want the change to be site-wide.

This is the real meat of it. We use the <mt:deltadays> tag from DateTags to find the difference between the entry date and the current date. We then store that value in the daysdiff variable.

Now we check daysdiff to see the age of our entry. I'm checking if it's about 6 months (180 days) old, but you can use whatever length you want. We then set another variable, displaydate, based on that age.

A bit further down in our template, we use displaydate to determine, well, whether we display the date:

If you're using the "About This Page" widget, you'll want to do the same thing there. Remember, variables declared in one part of a template (or in an included template module) are available to any code that follows, so we don't have to recalculate the date difference in the widget, just check displaydate.

Using this method, you should get into the habit of regularly republishing your entire blog. That way, older posts will get updated as they "mature."

PHP Alternative

If for some reason you can't or don't want to use the DateTags plugin you can still accomplish this by publishing your entry archives as PHP files. Just use this bit of PHP code to calculate your date difference:

Then use PHP instead of MT to test whether or not to display the date. The nice thing about this option is you don't have to worry about republishing regularly to make this work — PHP will handle that automatically.

And there are other uses for this technique as well, like changing CSS files based on the age of the entry. You could set up a series of styles that cause your entries to "age" over time.

How do you highlight (or hide) the age of your posts? Let us know in the comments.

Whenever I blog something good — a long tutorial that I'm really proud of, for example — I'm often tempted not to blog for a while. I want that great article to stay at the top of my home page for as long as possible. It's not just about vanity, though. This can be useful when you make an announcement and want to be sure people see it. Plus, featuring your best work in a prominent position can help keep new visitors exploring your site. And if these "featured posts" usually have photos, they can improve the first impression someone gets from your home page.

For this tutorial we're using our default Movable Type index template. The code below would replace the <MTEntries> block at the top of the template:

Now, instead of one <MTEntries> block, we have two. The first one finds our most recent featured post and displays it. The second is our default list of entries for the home page, with a check to make sure we don't repeat the featured post.

Let's take a closer look at how we're doing that. We'll start with our search for a featured entry:

This will bring back our most recent entry that was tagged with the word "featured." If that entry has an image attached, we want to display it:

Our <mt:entryassets> block will only bring back the first image it finds in the entry. The <mt:AssetThumbnailURL> tag will generate a thumbnail for us, if one that size hasn't already been created.

We then output a link to the entry, and end the block by storing the ID of the featured entry in a variable:

We then check that variable when we output the rest of our entries, to make sure we don't display the featured post again:

Maybe it would look something like this:

For this to work, you will need to tag an entry with the word "featured" — ideally it will have an image embedded in it. Now republish your main index, and add some styling to the content of div.headliner to set it apart from your regular posts. Now, whatever you consider your latest and greatest post can always have an eye-catching position at the top of your blog.

One of the big new features that came in Movable Type 4 was the Asset Manager -- a central location for maintaining the files you upload to your blog. Asset Manager gives you an admin for uploading, tagging, labeling, and deleting your files. It also comes with a rich set of template tags for publishing your assets. Combined with a bit of JavaScript, the Asset Manager can easily produce a beautiful photo gallery.

There's any number of JS or Flash photo galleries you can use. For this example, I've chosen Galleria, a jQuery-based photo gallery. It degrades well in the absence of JavaScript or CSS, allows linking to individual files, and looks beautiful out of the box.

To get started, download Galleria (it includes jQuery) and upload the CSS file, the jquery.min.js file and the jquery.galleria.js file to your server. Create a new index template, name it whatever you want, and populate it with this template code. You'll likely have to modify the CSS <link> and the <script> tags to point to where you uploaded your files, and of course change the titles and text to whatever you want.

This template is based on the example that comes with Galleria. If you're comfortable with JS and want to customize the look and behavior of your gallery, I recommend you read the Galleria options documentation, then take a look at the JS code in the template. There's almost no end to the ways you could modify the transitions, thumbnail appearance, and other details.

Towards the end of this template is where the Asset Manager does it's work. Let's look at those lines:

The classes and ids we use here are for the benefit of Galleria. You can change those, as long as you also change them in the script code earlier in the template. The code is pretty simple: create an unordered list, then loop through our assets:

This is where we start our assets loop. We're saying we want up to the last 20 assets of type "image" that have the "historical" tag. Of course, you'll want to change that to whatever tag you've used for your photos. Or you can leave it off to get all images in your asset manager. Other assets attributes allow us to filter based on author or file extension, or sort by various settings.

Each iteration of the loop creates a list item:

Here, we're using a loop meta variable -- __first__ -- to add a class to the first list item we output. That will make the photo show up as the main photo when someone first visits the page.

Then we output our <img> tag:

And that's it. Put in an output path for your template, then save and publish it. If the template is finding the CSS and JS files, you should get a gallery like this one.

As I mentioned before, you can use MT's Asset Manager with any number of existing photo galleries, or you could create your own from scratch. There are many asset-related template tags that give you access to all your files' data. MT can also generate thumbnails on the fly and cache them for future use.

Have you created your own photo gallery with the MT Asset Manager? Tell us about it in the comments.

As far back as I can remember, Movable Type has always had the ability to include one template (or a file) in another template. You do it like this:

<mt:include module="footer">

But, there are problems with this method. First, it can slow down publishing, as the MT engine traverses all the included templates in each page it publishes. And if you're publishing static files but including something that should be kept up-to-date (like your Action Stream), then you can end up with pages that look stale.

What I like to do is output the fragment I want to include to a text file, then pull that text file into whatever page on my site I want. But different pages publish differently, so it's sometimes tricky to include the same file on all those pages. I handle this with a little snippet of MT template code. Let's start by taking a look at that code:

<MTIf name="is_php">
    <?php include($_SERVER['DOCUMENT_ROOT'] . '/actionstream.inc'); ?>
<MTElse>
    <MTIf name="system_template">
        <MTInclude file="/actionstream.inc">
    <MTElse>
        <!--#include virtual="/actionstream.inc" -->
    </MTIf>
</MTIf>

Our first line checks a is_php variable. We have to set that ourselves on any page we output as PHP -- a contact form, for example. So let's assume we have a Contact template that publishes to contact.php. At the top of that template we would add this:

<mt:setvar name="is_php" value="1">

When this variable is set, our code will use a standard PHP include to pull in the file:

<?php include($_SERVER['DOCUMENT_ROOT'] . '/actionstream.inc'); ?>

If it's not a PHP page, we then check the system_template variable. This is already set in all the default system templates, so we don't have to set it ourselves. System templates are served via CGI -- they're not published to static files, they're displayed dynamically. Search results and comment previews use system templates. In this case, the standard MT include is the best option:

<MTInclude file="/actionstream.inc">

Notice we're using the file attribute rather than the module attribute. This tells MT to look for a file on your web server.

Finally, if neither of the first two conditions apply, we use a Server Side Include (SSI):

<!--#include virtual="/actionstream.inc" -->

You will have to configure your server for SSI, but if you were able to install MT, you should be able to set up SSI.

Now that we know how to do our includes, let's create something we can reuse whenever we need to do a file include. Create a new Template Module, name it Include, and put in the following modified version of our code above:

<MTIf name="is_php">
    <?php include($_SERVER['DOCUMENT_ROOT'] . '<mt:var name="includefile">'); ?>
<MTElse>
    <MTIf name="system_template">
        <MTInclude file="$includefile">
    <MTElse>
        <!--#include virtual="<mt:var name="includefile">" -->
    </MTIf>
</MTIf>

Now, anywhere we need to do a file include, we just put two lines of code:

<mt:setvar name="includefile" value="/actionstream.inc">
<mt:include module="Include">

The <mt:include> has access to any variables set before it's called, so we can set includefile to the file we want to include, then call our Include module.

You've probably seen the <mt:var> tags before, but this might be new to you:

<MTInclude file="$includefile">

Here, we're using an MT variable as the value for a tag attribute. This can be done on any MT tag, just append a dollar sign to the beginning of the variable name.

Again, this is really useful for things that don't need to be part of the MT publishing process. In particular, any time you're using an external API (Twitter, Flickr, etc.) to put content into your sidebar. In those cases, it's more efficient to set up an external process to write that content to a file, then pull it in with our optimal include. As your site grows, you'll be grateful for any time you can save on the publishing process.

If you're a good Web 2.0 person, you've probably been relentlessly tagging all your entries. You might even have a tag cloud so big it threatens to rain folksonomies. But shouldn't there be something more useful you can do with your tags? How about linking to related entries? Here's how we can do it in Movable Type, and without installing any extra plugins.

First, create a new Template Module named "Related" and type this code into the box:

<mt:entryiftagged>
<mt:setvarblock name="curentry"><mt:entryid /></mt:setvarblock>
<mt:setvarblock name="sgtags"><mt:entrytags glue=" OR "><mt:tagname></mt:entrytags></mt:setvarblock>
<mt:setvarblock name="listitems"><mt:entries tags="$sgtags"><mt:setvarblock name="listentry"><mt:entryid /></mt:setvarblock><mt:unless name="listentry" eq="$curentry"><li><a href="<mt:entrypermalink />"><mt:entrytitle /></a></li></mt:unless></mt:entries></mt:setvarblock>
<mt:if name="listitems">
<h3>Related Entries</h3>
<ul>
<mt:var name="listitems">
</ul>
</mt:if>
</mt:entryiftagged>

It's very important that when you type this in there are no line breaks within any of the <mt:setvarblock></mt:setvarblock> containers. In theory, you should be able to use the strip_linefeeds attribute and not worry about line breaks, but I've not had any luck with that. In fact, it's revealed a very strange bug. Rather than deal with bugs, we'll just remove the line breaks ourselves.

Now save it and go to your Entry Archive template. Somewhere in there (if you're using the default templates, right after <$MTInclude module="Entry Detail"$> would be a good choice) add this line:

<$MTInclude module="Related"$>

Republish your blog and you should see a list of related entries on each individual entry page. Let's take a closer look at our code and see what's happening.

<mt:entryiftagged>


We don't want to do any of this if the entry doesn't have tags.

<mt:setvarblock name="curentry"><mt:entryid /></mt:setvarblock>

We store the ID of the current entry to use later.

<mt:setvarblock name="relatedtags"><mt:entrytags glue=" OR "><mt:tagname></mt:entrytags></mt:setvarblock>

Here, we're using the <mt:entrytags> container to output a list of tags from the current entry. The glue attribute specifies what text should be between multiple tags. So, if our entry is tagged with cats, pet food, and dogs, we'll get this:

cats OR pet food OR dogs

And this will be stored in a variable we'll use on the next line.

<mt:setvarblock name="listitems"><mt:entries tags="$relatedtags"><mt:setvarblock name="listentry"><mt:entryid /></mt:setvarblock><mt:unless name="listentry" eq="$curentry"><li><a href="<mt:entrypermalink />"><mt:entrytitle /></a></li></mt:unless></mt:entries></mt:setvarblock>

We're using a <mt:entries> container with the tags filter. This will limit the entries returned to only those that have at least one of the tags from the current entry. As we process each entry, we store its ID in a variable. We then use the <mt:unless> conditional tag to compare the ID to the one we stored earlier. This allows us to filter out the current entry from the list we're creating. If it's different from the current entry we create a link to that entry and store it in a variable to use in the final output (which is only output if there is anything in that variable):

<mt:if name="listitems">
<h3>Related Entries</h3>
<ul>
<mt:var name="listitems">
</ul>
</mt:if>
</mt:entryiftagged>

Now, this is not necessarily the best way to do related entries. There's no "scoring" involved to determine which entries are the most related, we just assume they're related if they have at least one tag in common. And if you're publishing static files rather than publishing dynamically then old entries won't have links to new entries unless you republish your entire blog. Still, it's an easy way to link your entries, and it's a good example of the complex things you can do with Movable Type variables.

There's been a lot of excitement the last few weeks over FriendFeed, the new lifestreaming service that lets you pull together all the different services you publish to into a single feed.

I've tried FriendFeed and it works great, but why ask someone else to do something you could do yourself? The combination of Movable Type and the Action Streams plugin make rolling your own lifestream easy.

More →

In my last post, I talked about the different types of templates and what they're used for. Now that we have a feel for what our templates do, let's take a closer look at one and see what's going on inside. More →