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 →

If you've installed Movable Type recently, there's a fair chance you looked at the templates and were immediately overwhelmed. Don't feel bad, you're not the only one. By default, MT ships with no less than 56 different templates — all to publish a blog with a single style. You might find yourself asking...

What are MT templates for, anyway?

The templates in Movable Type format the output of your blog. When you write a blog entry and click Publish, MT figures out — based on the date, category, etc. — which of your template files to use in generating new pages on your blog. It reads each template, plugs in the data from your entry, then outputs the new file as part of your blog.

As you poke around in the templates, you'll find some of them refer to other templates, while still others don't seem to be used at all. And while this can make MT confusing, it also makes it very powerful. All those templates make customizing your blog much easier.

To understand MT templates, you need to understand the different types and what we use them for. MT templates are all about context. The context of a template determines what MT tags you can use within that template. It's also possible to establish your own context within a template to customize the output. For example, the <mt:entrytitle> tag only makes sense in the context of an <mt:entries>. The individual entry archive establishes that context automatically. But, if you wanted to put a "Featured Entry" in your sidebar, you would need to create an <mt:entries> context within the sidebar.

We'll get deeper into this in future posts. For now, just keep in mind that context is important for tags, and templates help to establish that context.

Let's take a look at the different types of templates:

Index Templates

Index templates don't have a context by default. Instead, you create context within them through the use of container tags. This is a very powerful feature, because it allows you to publish your entries as anything. Index templates are used to produce RSS and Atom feeds for syndicating your blog. You could use one to produce a CSV file that you could import into Excel. Any kind of text file can be generated by index templates — they don't even need any MT tags in them. You can use them to maintain your CSS and JavaScript files, if you want.

Archive Templates

Archive templates are used to publish entries and pages, either individually or grouped together based on category, date, or author. How an archive template gets published depends on its type (assigned when you create the template) and the archive mappings associated with it.

Archive Template Types

There are three different types of archive templates. The type of template determines what context the template has when it's published:

• Entry – Entry templates are for individual blog entries. They have an <mt:entries> context, which is filtered down to a single entry. You can use tags like <mt:entrytitle>, <mt:entrybody>, and others. Typically, this is the template you'll use to publish an entry and its comments.
• Entry Listing – Entry listing templates are for a group of entries. These are your category archives, date-based archives, or author-based archives. They filter the entries to publish based on the archive mapping (more on that in a bit). These templates create a context for tags like <mt:archivelink> and <mt:archivetitle>, as well as more specific tags based on what kind of archive it is.
• Page – Templates for individual pages. These tend to be very similar to Entry templates, since Pages are just entries that exist outside the flow of the blog.

Before you can publish an archive template, it needs an archive mapping. The mapping tells MT where to publish the files and, in the case of entry listings, what type of archive to publish. An archive template can have multiple mappings. This can be used to publish the same templates in different locations. With entry listings, this allows you to use the same template to publish all your archives — categories, date-based, and authors.

Template Modules

Template modules are snippets of template code that are called from other templates. If you are familiar with PHP or SSI, think of it as an include. In fact, that's exactly how you use it:

<mt:include name="Header">

Template modules do not get published on their own, only when they're included in another template. You use them for pieces of code you want to reuse. They make it easy to have the same header and footer across all your pages, for example. Anytime you find yourself using the same code in multiple templates, it's a good idea to evaluate whether you should pull that code out and put it into a module.

System Templates

System templates are used for pages that MT has to generate based on an action taken by a reader, such as posting a comment or searching your blog posts. These have their own contexts, and they have a few quirks because of how they're generated. We'll explore system templates more in an upcoming post.

Widgets

Widgets are just template modules, but by declaring them as widgets we can use them in Widget Sets. Widget Sets give us an easy drag and drop interface for customizing our sidebars, footers, and more.

Backup Templates

Backup templates are copies of templates that have been replaced by MT. This can happen if you use the Style Catcher to change the look of your blog, or if you use "Refresh Templates" to restore your templates to the defaults.

I recommend taking a look at the different templates to get an idea of how they're structured. We'll go deeper into this in future posts, but for now just try to get a sense of how the different templates are connected. You can do this by opening the templates and looking at the information to the right of the template. This will tell you what template modules and widgets are included in the template, and what MT tags are used. The tags link to the MT documentation, which can be useful for learning what the tags do.

Have a question about MT templates? Let me know in the comments.