If you’re upgrading an MT 4.0 install that was using Arvind’s CustomFields plugin to MTP 4.1 which has CustomFields built in, the first thing you need to know is that MTP will not automatically import your old CustomFields data. You need to install the CustomFields Upgrade Assistant plugin to do the migration for you. (Six Apart please get this out of Trac and into the Plugin Directory!)

A note about installing the upgrader: Arvind’s CustomFields plugin lives in the /plugins/ directory; the CustomFields that ships with MTP lives in the /addons/ directory. You should remove the old CustomFields plugin when installing the CF Upgrade Assistant plugin. Make sure that it’s actually replacing your old /plugins/CustomFields/ directory. Leaving the old plugin code in there presents troubles because MT tries to use the old plugin code. The final location for your CF Upgrade assistant should be /plugins/CustomFields/lib/CustomFieldsUpgrader/

Murphy’s Law

I tried logging into Movable Type, but I kept getting the following error:

A Error during upgrade: Can’t call method “can” on an undefined value at /var/www/dev/html/mt/addons/Commercial.pack/lib/CustomFields/Util.pm line 260

I first thought that the MTP upgrade and the CF Upgrade Assistant could not be run at the same time. However, it turns out that errors in the CF upgrade were keeping me stuck in the upgrade loop.

Important note for Safari users: If the upgrade is throwing errors, you won’t see them if you’re using Safari. I’m not sure why, but when the upgrade fails, it gives no feedback or error message in the log window, returns an “Upgrade Complete!” and throws you right back into an upgrade loop. I suspect it has something to do with the javascript.

Troubleshooting Orphans

Hopefully you didn’t read a space into the first word of that subtitle.

Anyhow, I was stuck in an upgrade loop. David Phillips, God bless his soul, stepped in at this point with some heavy duty troubleshooting. Turns out that the upgrade assistant chokes when it gets to orphaned custom field data. What do I mean by orphaned data? You can create custom fields for almost every object in the system (blog, entry, author). However, the older version of CustomFields would not delete the custom field data even if the object associated with that custom field got deleted. So if you had an entry with custom field data, and that entry was deleted, the custom field data would still live in the database, but you’d never see it in the UI. The upgrade assistant would then find these objects, try to migrate them and then fail because the object they’re supposed to be associated with no longer exists.

Unfortunately, there’s no elegant solution.

At this point, the orphans can only be cleaned up through the database. However, to help speed things up, I’m posting the queries I used to get rid of my orphaned data. You can issue these fairly easily through something like phpMyAdmin or CocoaMySQL. And the standard warning: Make sure you back up your database before doing any type of massive database manipulations.

To clean up orphaned custom fields data associated with entries, use the following SQL query:

 DELETE FROM mt_plugindata WHERE 
 LEFT( plugindata_key, 6 ) = 'entry_' 
 AND plugindata_plugin = 'CustomFields' 
 AND (SELECT entry_id FROM mt_entry 
 WHERE LEFT( plugindata_key, 6 ) = 'entry_' 
 AND plugindata_plugin = 'CustomFields' 
 AND SUBSTRING( plugindata_key, 7 ) = entry_id) IS NULL;

To clean up orphaned custom fields data associated with authors, use the following SQL query:

 DELETE FROM mt_plugindata WHERE
 LEFT( plugindata_key, 1 ) = '_' 
 AND plugindata_plugin = 'CustomFields' 
 AND (SELECT author_id FROM mt_author 
 WHERE LEFT( plugindata_key, 1 ) = '_' 
 AND plugindata_plugin = 'CustomFields' 
 AND SUBSTRING( plugindata_key, 2 ) = author_id) IS NULL;

One Last Bug Squash

All your orphans should be gone. But there’s a minor bug in CustomFields that we need to take care of. If you tried running your upgrade at this point, you’d get this error message:

Error during upgrade: Can’t call method “text” on an undefined value at /var/www/dev/html/mt/addons/Commercial.pack/lib/CustomFields/Util.pm line 322.

You need to edit Util.pm. If you open it up in a text browser, you’ll see this at line 322:

 my $text = ($entry->text || '') . "\n" . ($entry->text_more || '');

Both occurrences of $entry need to be changed to $obj. The final code should look like this:

 my $text = ($obj->text || '') . "\n" . ($obj->text_more || '');

Upgrade!

If you followed these somewhat complicated instructions carefully, the upgrade process should run through smoothly and your CF data should be migrated successfully.

Please feel free to leave your comments or questions here. Several people have told me that they’ve run into this; the more scenarios we can address, the more useful this article will be. Thanks.

<mt:Authors include_blogs="all">
    <mt:IfNonEmpty tag="AuthorEmail">
        <mt:IfNonEmpty tag="AuthorDisplayName">"<mt:AuthorDisplayName />" </mt:IfNonEmpty>
        &lt;<mt:AuthorEmail />&gt;,
    </mt:IfNonEmpty>
</mt:Authors>

And the Authors tag allows for all sorts of cool filtering attributes so you can get at any group of authors in the system, ordered however you like:

• display_name: Specifies a particular author to select.
• lastn: Limits the selection of authors to the specified number.
• sortby: Supported values: displayname, name, created_on.
• sort_order: Supported values: ascend, descend.
• roles: comma separated list of values. eg “Author, Commenter”
• need_entry: 1 | 0 (default is 1)
• status: Supported values: enabled, disabled. Default is enabled.

Note: Some people have asked about creating an email list of all the commenters on the system, and it’s very simple. The code stays the same, but you just need to specify roles=”Commenter” and need_entry=”0” (since most commenters won’t have written an entry). Here’s the code to do it:

 <mt:Authors include_blogs="all" roles="Commenter" need_entry="0" sort_by="display_name"><mt:IfNonEmpty tag="AuthorEmail"><mt:IfNonEmpty tag="AuthorDisplayName">"<mt:AuthorDisplayName />" </mt:IfNonEmpty>&lt;<mt:AuthorEmail />&gt;, </mt:IfNonEmpty>
 </mt:Authors>

Notice the code is much more compressed than the code given previously. If you tried the previous code, you probably noticed that the spacing is crazy because of all the hard returns and spaces we have in there. This second set of code I posted will give you a highly compact list of email addresses than can literally be copied and pasted into an email client.

Just make sure you use this for good, not evil.

Many of the sites I build use CustomFields to place a masthead image at the top of an entry. This takes the hassle out of uploading and really just makes it easier for customers to have a consistent look and feel for their posts. Trouble is, when I upgraded to Movable Type 4.1 (see this post for details about how to upgrade from Arvind’s CustomFields plugin to the one that’s built in to MT Professional Pack), the image asset links were only showing up as text links. For example, using the code they suggested on the CustomFields screen:

 <mt:IfNonEmpty tag="EntryDataMastheadImage">
      <mt:EntryDataMastheadImage />
 </mt:IfNonEmpty>

Resulted not in a placement of the image, but rather the words “View Image” with a link to the photo. Not exactly what I had in mind. I want the actual photo itself.

Now, there are all sorts of cool new tags (like <mt:AssetLabel /> and <mt:AssetUrl />) that let you get at any part of your uploaded asset. The only trouble is, there’s no documented way to put the asset you want (in our case <mt:EntryDataMastheadImage />) in context. Sure, you can do an mt:Assets loop that lets you list the last however many assets; but we’re trying to get at mt:EntryDataMastheadImage, nothing else.

Solution: Create CustomField Container With -Asset Suffix

When you create a custom field in Movable Type, it creates two tags for you. The first is the one I listed before: <mt:EntryDataMastheadImage /> and it’s a single tag that’s used to call to the asset in question. There’s another, undocumented tag that’s created: <mt:EntryDataMastheadImageAsset />. This tag is a container tag that does exactly what we need: puts that particular CustomField data in context. Once it’s in context, we can use all of those nifty tags to get at whatever specific asset information we want. Here’s how I solved my particular problem:

 <mt:IfNonEmpty tag="EntryDataMastheadImage">
      <mt:EntryDataMastheadImageAsset>
           <img src="<mt:AssetURL />" />
      </mt:EntryDataMastheadImageAsset>
 </mt:IfNonEmpty>

A great big round of applause to Mark Carey for helping me discover this little undocumented nugget. Update: Arvind pointed out that it’s documented on his forums.

For those of you just upgrading to Movable Type 4, I’m sure you’re experiencing a considerable amount of confusion regarding the new modular template approach. If you’ve just gotten on board, it probably makes even less sense.

I won’t go into too much detail on this modular approach, because I’ve already dealt with it previously on this site. The gist of it is this: instead of having dozens of copies of the same code strewn across all your templates, the new approach is having all the code snippets you’re likely to use more than once—headers, sidebars, entry lists—stored in template modules and called to from each individual template. So instead of changing your sidebar in seven different templates, you only have to change it once.

A great big thanks to Mark Norwood for putting this together. There are a few changes I’d like to make as well as a giant “cheat sheet” that might prove handy. But I figure I’d get it out there now for anyone struggling with the new template structure.

Download Movable Type 4 Template Map (.pdf/80k)

A couple of things to note first: Makes sure that you’ve got author archives set up. You can hack this to work with author profiles, but that’s not the scope of this tutorial.

<?php
    $displayed_authors = array(); // Will hold indexes from $authors for authors already displayed
    $show = 25; // How many authors should we show?

    <mt:Authors>
        $authors[<mt:AuthorId />] = '<li><a href="<mt:EntryLink archive_type="Author" />"><mt:EntryAuthorDisplayName encode_php='1' /></a></li>';
    </mt:Authors>

    for ($i=1; $i <= $show; $i++) {
        $rn = array_rand($authors); 
        // Loops until it finds an author not displayed
        while(in_array($rn, $displayed_authors)) {
            $rn = array_rand($authors);
        }
        array_push($displayed_authors, $rn);
        echo $authors[$rn];
    }
?>

First, we set up an array where we’ll store all the authors that have already been displayed. More on that in a minute. Then we define how many authors we want to show with this block.

Next, we loop through all the authors, stashing them all into an array. Actually, we’re stashing the html that we want displayed as it gets looped through. This can be basically whatever you want. If you use other Movable Type tags, make sure you add the encode_php='1' filter or else you could get some nasty PHP parse errors and break your site. (Usually because of single quote/double quote mismatching.)

Next up is displaying the authors. We’re going to loop through authors 25 times; remember, that’s what we set up with the $show variable. The array_rand function basically says “pull a random number from 1 to the number of items in our array”. We had to put in a special while loop to make sure it didn’t pick a number already used; this would result in duplicate listings of a single author. The array_push then stores the new, non-duplicate random number in our displayed authors array to ensure we don’t duplicate it next time through the loop.

Finally, we echo a random item from the $authors array. This loops through however many times you’ve told it to with the $show variable.

Thanks to Arvind for helping me solve the dupe problem. He also made me say that I will now worship him forever.

A recent customer asked me if they could have an easy to manage banner ad setup, with the ability to add advertisements and specify links and alternate text. All of this while being able to manage them easily. Sounds like a job for… Movable Type!

Despite the title, this little tip can be used for any ads—any images at all for that matter. There are four basic steps: upload the ad, create an entry for it, create the php file and include it in your template.

Quandary: Someone clicks on a subcategory archive, but it looks just like every other category page. How can we give the user a better sense of context for the subcategory pages?

Solution: Breadcrumbs! You know, they look like: Category » Subcategory , with links that let us get around a complex hierarchy pretty easily. Put this code where your category title gets displayed:

<mt:HasParentCategory>
    <mt:ParentCategories exclude_current="1">
        <a href="<mt:CategoryArchiveLink/>"><mt:CategoryLabel /></a>
    </mt:ParentCategories>  »
</mt:HasParentCategory>
<mt:ArchiveTitle />

Essentially, we check to see if the category page we’re on has a parent. If it does, we append the title with that parent category name (exclude_current hides the subcategory we’re in) and link so the user can jump back pretty quickly.

Display Subcategories As A Menu On A Category Archive Page

Quandary: You got several categories with subcategories, and you’d like to show these subcategories as a menu on the parent category archive page.

Solution: This is a little tricky because all subcategories are categories too. So you have to think more in terms of relationships to tackle this one. Here’s the code:

<mt:HasSubCategories>
    <ul>
    <mt:SubCategories>
        <li><a href="<mt:CategoryArchiveLink/>"><mt:CategoryLabel /></a></li>
    </mt:SubCategories>
    </ul>
</mt:HasSubCategories>

<mt:HasParentCategory>
    <mt:ParentCategories exclude_current="1">
        <mt:HasSubCategories>
            <ul>
            <mt:SubCategories>
                <li><a href="<mt:CategoryArchiveLink />"><mt:CategoryLabel /></a></li>
            </mt:SubCategories>
            </ul>
        </mt:HasSubCategories>
    </mt:ParentCategories>
</mt:HasParentCategory>

The first chunk says, “If this category has subcategories (children), then run through the list of them and create a menu.” This part targets the parent category pages, because they have children.

The second chunk is similar, but it’s meant for the subcategory pages themselves. This code says, “If this category has a parent category, then give us a list of subcategories (children) that belong to that parent and make a menu.” Since Movable Type doesn’t have any type of sibling tags, we have to go back to a parent if it exists and then display that parent’s children (those are the siblings).

Clearly, this new release from Six Apart is monumental. Massive changes to both the interface and the innards make this a drastically new product for them. If you've not yet downloaded it, go on, it doesn't cost you anything.

Action Oriented Interface

Movable Type 3.x was primarily object oriented: entries, comments, templates. Movable Type 4, on the other hand, is very action oriented: Create, Manage, Design. It's much more content-centric as well. When you land of the dashboard, you're presented with dynamic content like "Most Recent Comments" or "You have 13 drafts".

Most everything is where you'd expect it to be. Vital information shows up on the right hand side with relevant links (imagine that). There are still some common-sense items that didn't make it in, like a rebuild option on the entry template list action menu; but overall it's much easier to navigate that the previous incarnations.

And as I understand it, the application interface is much easier to change; what that means is a plethora of plugins that let you customize the UI to your hearts content. Kevin's Bookmarks plugin gives you a bookmarks menu for your most frequented MT pages. Arvind's Template Shelf creates a sidebar widget to the app that lets you quickly browse templates in your blog. Arvind's even created a retro plugin called "My Blogs" (not to be confused with My Humps by The Black Eyed Peas) that makes your MT4 install look like MT3. And with the launch of the new Plugin Directory, I think it's safe to assume we'll be seeing more in the same vein.

Common Tasks

The new workflow takes a little getting used to, and I'm sure it won't work for everyone; but common tasks like reviewing comments and creating entries seems considerably faster. I know many will balk at the new interface, but it really is much clearer. There is a much more structured placement of information: System wide information at the very top, blog selection on the next level, then a blog related action menu below that. It flows well.

There have been some concerns raised about the menus. First, clicking versus hover. Six Apart chose to make the action menu expand on hover and the blog menu expand on click. I think it's a fair compromise as most people won't be furiously switching blogs (compare this to the jump menu at the top of the old interface, two clicks instead of 3). Second, disabled items graying out versus disappearing. Six Apart chose to leave them in and just gray them out when they're not available. Having worked tech support before, I know how maddening a thing disappearing menu items (Microsoft called them personalized menus) can be. The human brain builds habits or pathways when using an interface; when those constantly change, it can end up taking a considerable amount longer while generating frustration. (But there is a plugin out there for those of you who just have to have it that way.)

One essential technique that speeds up my work is opening new parts of the app in separate tabs; those 1 or 2 second loads can add up quickly. Just hold down Ctrl or Apple as you click a menu item.

Javascript Heavy

The new interface relies on quite a bit of javascript wizardry, which seems to cause quite a bit of drag, especially using Firefox, one of the slowest browsers at processing javascript. The template editor with code highlighting and line numbering is not just a nice touch, it's really helpful. Unfortunately, something funny would happen once or twice over the course of a day and I couldn't edit my templates without a full reboot of the system. The scripting is really great, but they need to tighten the belt before they release 4.1.

New User Controls

If you're a lone blogger, you may never touch this feature, but poke around in there. The ability to define custom roles and permission sets and then assign them to different users makes MT4 the platform of choice for community blogs. Movable Type can even build a profile page with author information.

Code Base

I'm not a developer, but I follow the developer lists; several of the more well-known MT developers were really frustrated with some of the new changes to the code base. Whether that's just a normal response to a major code overhaul or because the plugin documentation was scarce up until just a few weeks ago, I can't say for sure. It had me shaking in my boots when Tim Appnel threw up his hands in frustration when trying to port his Tags.app plugin; but a recent boom in MT4 plugins has slaked some of those concerns.

Templates

Aye, there's the rub. It's a bittersweet thing. The Movable Type templating language used to be so simple and easy to figure out; but with this release, templates are becoming less like templates and more like a programming language. This has it's advantages and disadvantages. The current template structure works much like TypePad's setup: every chunk of template is stored separately and the included based on conditionals. So much nicer than hunting through six different templates to make a tiny change in the html header; but along with power comes complexity. Might be daunting for newcomers. That being said, the old templates work just fine in MT, if that's how you want to roll.

Also, I've been wanting template packs ever since we started The Style Archive, and even though it's not in this release, Byrne assures me it's coming in 4.1.

MT4: Satisfied?

I'm really pleased with Movable Type 4. It's made several large jumps forward in blogging. It's going to take some time to get used to the new workflow, so I may be able to give a better review then. It didn't solve all of my image handling concerns (nor has any online software out there, except Flickr). But the overall feel and functionality of the new MT makes it really fun to use; and with an open source release of it on the horizon, that settles it for me.

More to come...

http://movabletweak.com/assets/lovabletype-1680.png
http://movabletweak.com/assets/lovabletype-1280.png
http://movabletweak.com/assets/lovabletype-1024.png
http://movabletweak.com/assets/lovabletype-800.png

RightFields lets you rename the standard fields (entry body, extended entry, etc.), but I had a strange situation today where I needed to keep the standard fields untouched and use only extra fields. (The client was migrating from using the entry body for everything to using the extra fields for different types of data, but it's a migration that will take a long time.) Of course, RightFields handles this beautifully, but the client has a unique request: move the extra fields to the top of the edit entry screen.

Unfortunately, RightFields doesn't have the option to place the extra fields before the standard fields. But here's the nifty tweak:

RightFields uses <TMPL_IF NAME=DISP_PREFS_SHOW_TAGS> as an anchor to place the extra fields in the edit_entry.tmpl file. (This is the template that you see when you edit an entry.) So let's fool RightFields into moving the extra fields by moving the anchor.

Edit the /MT_DIR/tmpl/cms/edit_entry.tmpl file.

Look for <div id="body-box"> and put the following code right after it:


<!-- Lets trick RightFields! -->

<TMPL_IF NAME=DISP_PREFS_SHOW_TAGS></TMPL_IF>

<!-- End trick -->


Your edit entry screen should now display extra fields first!

"After reading that MT4 supports previous versions templates, I have been trying to get templates from thestylearchive.com to work. MT4 is able to connect to the thestylearchive.com, view & select the template -- and files get copied into mt-static equivalent directory. However, the template doesn't reproduce properly at all (in fact neither did any of the templates choosen from thestylearchive.com, only templates built in to MT4 and those from the MT4 Style library. Is this a known bug with with Movable Type 4.0 RC1b, or am I not setting up something correctly?"

Well, for those of you that don't know, the new Movable Type 4 templates are much, much cleaner. Lots of unnecessary code has been whacked and the end result is a meaner, leaner template. Now, the good thing about cleaning up MT4's default templates is that they're much more manageable. Hurrah for clean code!

The bad thing, however, is that all of the styles over at TheStyleArchive.com are designed to work with the MT3.35 default templates. Now, MT is MT, so the default templates from MT3.35 still work with MT4. If you copy the old MT3 templates over into your new MT4 install, Stylecatcher can still pull in the styles from TSA and your site will look as the designer intended...

I know that using the old templates certainly isn't ideal, and because of that, we're working to get the TSA styles functional with the MT4 default templates. Realize, however, that it's going to take some time as converting stylesheets isn't always as simple as search-and-replace.

In the meantime, rest assured that MT4 is shipping with some really beautiful styles that will tide over you styleophiles.

"I am having a very hard time understanding the "Templates" within MT. I'm used to just being able to make a change within the header.php in Wordpress that affects every page. However, with Movable Type, it seems that if I make any chance in the template, I have to make that change in every different template I have (Main Index, Master Archive, Search Template, Comment-Pending Template, Comment-Error Template, etc., etc.). Am I just completely missing something? Or is this the only way to go about doing it?"

The question he raises is a good one. The first thing is not to confuse "template tags" with "template modules". As MT is currently bundled, each "template" has all of the code needed for a full page. The main index page has all of the html header information, the banner has all the banner information, sidebar, etc. Now, it's nice because most information like the blog name and description and meta tags are all stored in MT and get put into the page by using template tags (i.e. ). But essentially if you want to change the HTML for the header or the banner or anything else, you have to change it on that particular template. So, for example, adding a div above the banner would require opening each template and adding the div above the banner.

Now, there are ways around this; in fact, that's one of the reasons Six Apart is changing it's approach with the new Movable Type 4. It makes a lot more sense (even though it's a bit more confusing for the beginner). The basic approach is this: commonly used chunks of code are stored as template "modules" and then called to from each template. Makes MUCH more sense because you don't repeat code. If the header code is the same for all of your pages, then the only thing you need on each page is a call to the template module () that holds your header code. It's all in one place.

Of course, sometimes you've got things in those modules that need to be custom for each page, like the entry title in the HTML header area. Movable Type handles nearly all of that stuff with template tags. Put in between your

I've had a hard time finding my way around the current Movable Type documentation, especially the tag reference, and I've heard some others saying the same thing; so I put together a new site that lets you get at all of the tags in a number of different ways. If you find it helpful, cool; if it's not your thing, that's cool too. Just trying to make it easier to find/use MT template tags.

Some of the things still on my to do list:

• Add miscellaneous tag related help: Global tag attribute filters and date formats. Prominent links back to the official MT User Manual.
• Downloadable/printable PDF tag reference: An at-a-glance tag reference card so you don't have to keep switching screens to look up your MT tags.
• More Code Samples: The real purpose of this site is to have real-life examples of these tags in action, much like the O'Reilley cookbooks. Ideally this process of posting/sharing examples will be automated.
• Tag Versions: With the release of MT4, some older tags are deprecated, some newer tags are introduced. Look for markers soon to help make this reference version-specific.

MTTags.com -- Hope it's a helpful!

http://movabletweak.com/assets/mt4-1680.jpg
http://movabletweak.com/assets/mt4-1280.jpg
http://movabletweak.com/assets/mt4-1024.jpg
http://movabletweak.com/assets/mt4-800.jpg