Movable Type 3.0 Guide



NAME

mt30 - Guide to the New Features in Movable Type 3.0


SYNOPSIS

This document describes the new features in Movable Type 3.0, and the steps for upgrading users to take advantage of these features.


FEATURES

Comment Management

Movable Type 3.0 includes powerful new features for managing comments.

All comments can be searched and modified from a central ``Comments'' page. And as in previous versions, the `edit entry' page still contains a list of comments associated with the corresponding entry.

Throughout the comment, entry, and trackback listings, you'll see the new magnifying glass icon beside a field, which means you can search on the value of that field. For example, this allows you to search for ``All comments by this author'' or ``All trackbacks connected with this entry.''

Comment Registration

In addition to comment management, Movable Type 3.0 offers a way to accept an identity for each commenter, and to moderate comments based on that identity.

The authentication service in Movable Type 3.0 is provided by the TypeKey system. TypeKey is a centralized registration system which offers users a single sign-on service across a variety of applications including Movable Type 3.0.

A commenter's identity is stored and managed at the TypeKey site, but as a weblog owner, you control the set of commenters who have permission to leave comments on your site.

The comment registration system has a variety of options which can be controlled in the ``Weblog Config'' area of Movable Type.

Upgrading Templates to Enable Comment Registration

When you install Movable Type 3.0 `out of the box,' it comes packaged with new default templates which contain the links to the comment registration sign-in process, and wihch greet the user on return to your site.

If you're upgrading from a previous version and you want to enable comment registration, you'll need to modify your templates. The easiest way to do this is to use the <$MTCommentFields$> tag. This tag detects whether you have comment registration enabled and, if so, expands to an HTML <form> element that contains all the correct fields for your current configuration.

Object Callbacks for Plugin Developers

The most interesting new feature in Movable Type 3.0 is a feature that plugin developers will use to make the Movable Type platform even more powerful. Developers looking for more information about this feature should look at the perldoc documentation in MT::Object, MT::Plugin and MT::Callback.

Internationalization

By default, a fresh installation of Movable Type 3.0 labels all its pages as being in the UTF-8 character encoding (upgraded installations won't be reconfigured unless you reconfigure them). You can change the encoding that you use by using the PublishCharset configuration setting.

Note that under Apache 2.0, the Apache directive AddDefaultCharset will override MT's setting. If you want MT to use a character set different from the one that Apache uses, you should turn off the AddDefaultCharset option in your Apache configuration file.

Background Tasks

Movable Type 3.0 has a smoother interface, in part because of a new feature called 'background tasks.' This allows Movable Type to do some lengthy operations, such as rebuilding, in the background, rather than forcing you to wait for them to complete. This also allows Movable Type to play more nicely with other pieces of software, such as notification tools that send TrackBack pings.

However, this feature is not compatible with some systems. If you have trouble with rebuilds or if you see erratic database-related errors, try turning this feature off. To do so, add this line to your mt.cfg configuration file:

   BackgroundTasks 0


New Archive Filenames

Traditionally, Movable Type archives were a flat directory rather than a hierarchical structure, and individual archives were given numerical names, such as 0000451.html.

In Movable Type 3.0, individual archives have a name that is based on the (original) title of the entry, such as great_expection.html. Furthermore, all archives are stored in a date-based hierarchy, so an individual archive will have a path such as 2004/05/great_expectation.html. Daily, monthly, and weekly archives are also stored within the directory corresponding to the larger time unit. For example, May 2004 archives are stored in 2004/05/index.html.

If you are upgrading from a previous version of Movable Type, you may not want your archive URLs to change, for example, if other websites are linking to your archive pages. In this case, you will want to set the Weblog Config option, ``Use Old-style Archive Links.'' Your archives will be built using the exact same names they traditionally have. By default an upgraded installation will have this option turned on, while a fresh installation will not.


UPGRADING

This section describes the actions you should take if you have already installed a previous version of Movable Type and are upgrading that installation.

Movable Type 3.0 has two new files that support a better user interface. If you're using a ``static files'' directory, as described in ``Configure path to Static files'', you'll need to move mt.js and styles.css to that directory.

If you're upgrading from version 3.0 or later, just run the script mt-upgrade30.cgi. If you're upgrading from an earlier version, you need to upgrade to each successive version in turn. This is done by running the upgrade scripts in order:


DEVELOPER NOTES

Lazy Loading of Entries

In previous Movable Type versions, we placed an element in the stash called entries which was a reference to a list of MT::Entry objects. The particular set of objects depended on the context; for example, inside each iteration of an <MTArchiveList archive_type="monthly"> tag, entries contained the list of entries for the corresponding month.

In order to improve rebuilding performance, in Movable Type 3.0 we're using lazy evaluation to get the entries only when needed.

In version 3.0b3 and later, entries will not contain a reference to a list of entries, but rather a ``promise'' for such a reference. To get the entries, you just need to ``force'' the promise. Instead of the following:

my $entries = $ctx->stash('entries');
foreach my $e (@$entries) {
    ...
}

You should use the following:

my $entries = $ctx->stash('entries')->force();
foreach my $e (@$entries) {
    ...
}

Note that entries always contains a promise, regardless of whether the entries have already been loaded. Every place where your code uses entries needs to be updated to reflect this.

Also note that this convention applies to the entries element but not to the entry element.

If you want to set the value of entries, you need to create a promise. You create a promise using delay(). Where previously you would have written this:

my @entries = MT::Entry->load(...);
local $ctx->{__stash}->{entries} = [ @entries ];

You would now write this:

local $ctx->{__stash}->{entries} =
    delay(sub{ my @entries = MT::Entry->load(...); [ @entries ]; });

This routine, delay(), always takes a CODE reference which should return a reference to a list of entries. The delay routine needs to be imported from MT::Promise, using:

use MT::Promise qw(delay);

or

require MT::Promise;
import MT::Promise qw(delay);

top