mt31 - Guide to the New Features in Movable Type 3.1
This document describes the new features in Movable Type 3.1, and the steps for new and upgrading users to take advantage of these features.
The most prominent new feature in Movable Type 3.1 is the dynamic page functionality, allowing you to combine static page generation with dynamic pages on a per-template basis. This allows you to balance the publishing and traffic for your weblog, and gives you the best of both worlds: you can turn on static page generation for frequently-requested pages like your site index and feeds, and use dynamic pages for your monthly, individual, and other archive pages. This completely eliminates the need to manually rebuild your files; when you update the design of your archive templates, for example, the design of your site will immediately be updated without requiring you to rebuild.
To enable dynamic rendering of your templates:
templates_c. It should have a permission mask of 777.
# Disable fancy indexes, so mtview.php gets a chance...
Options -Indexes
<IfModule mod_rewrite.c>
# The mod_rewrite solution is the preferred way to invoke
# dynamic pages, because of its flexibility.
# Add mtview.php to the list of DirectoryIndex options, listing it last,
# so it is invoked only if the common choices aren't present...
<IfModule mod_dir.c>
DirectoryIndex index.php index.html index.htm default.htm default.html default.asp /mtview.php
</IfModule>
RewriteEngine on
# don't serve mtview.php if the request is for a real directory
# (allows the DirectoryIndex lookup to function)
RewriteCond %{REQUEST_FILENAME} !-d
# don't serve mtview.php if the request is for a real file
# (allows the actual file to be served)
RewriteCond %{REQUEST_FILENAME} !-f
# anything else is handed to mtview.php for resolution
RewriteRule ^(.*)$ /mtview.php [L,QSA]
</IfModule>
<IfModule !mod_rewrite.c>
# if mod_rewrite is unavailable, we forward any missing page
# or unresolved directory index requests to mtview
# if mtview.php can resolve the request, it returns a 200
# result code which prevents any 4xx error code from going
# to the server's access logs. However, an error will be
# reported in the error log file. If this is your only choice,
# and you want to suppress these messages, adding a "LogLevel crit"
# directive within your VirtualHost or root configuration for
# Apache will turn them off.
ErrorDocument 404 /mtview.php
ErrorDocument 403 /mtview.php
</IfModule>
If your weblog is under a subdirectory, like /weblog, then you should prefix the location of mtview.php with that path (ie: /weblog/mtview.php).
If you already have a .htaccess file, append the above lines to the bottom of it.
An optional step is to turn on dynamic caching of your pages. If you want
to try this option to see how it works, create a cache subdirectory in
your weblog's root directory and set the permissions to 777. Then add
this line to your Dynamic Site Bootstrapper template:
$mt->caching = true;
That should be placed just above the $mt->view() line.
Please note that at this time, only the standard Movable Type tags are
supported with the dynamic rendering option. Existing plugins are not
compatible with this new feature, since they are written in Perl and not
PHP. If you are seeing errors due to using plugin tags, you will either need
to remove the tag(s) or change that template to render statically.
Using post scheduling, you can set a time and date for your posts to appear, permitting automatic updates to your weblog even when you're away. Using post scheduling, you can keep your weblog community up to date and involved, even if you're not at your computer to create new posts.
To set up scheduled posting, you need to be able to set up a cron job on your server. If you have shell access, you can do this as follows:
% crontab -e
0,15,30,45 * * * * cd <path to mt>; ./tools/run-periodic-tasks
This instructs the cron monkey to run the script at zero, fifteen, thirty, and forty-five minutes after the hour, every hour. The asterisks are a way of telling cron to do this every hour, every day, every day of the week and month. Make sure you have exactly four asterisks separated by spaces.
<path to mt> should be the path to your Movable Type application directory.
After that, just save the file, exiting your editor, and cron will report that it installed a new crontab.
Note: if you have a cPanel account, you can set up cron jobs through the cPanel web interface. See the manual for more information.
To specify the time when the entry should appear on the site, use the field labeled ``Authored On'' on the Edit Entry screen.
The new category management interface in 3.1 gives you fine-grained control over the organization and display of your posts. You can easily create new subcategories, and move a subcategory from one parent category to another using a slick, easy interface. Not only that, the subcategory support is extremely powerful, because it builds upon David Raynes' SubCategories plugin and thus inherits all of the tags included in that plugin. David has done a great job helping us with integrating the plugin into the core Movable Type engine.
To start managing the sub-categories in your Movable Type weblog, log in to Movable Type, click on the weblog name that you wish to edit, then click on the ``Categories'' tab.
For new users, the default templates in Movable Type 3.1 have been updated to take advantage of the new subcategories functionality. If you're an upgrading user, you can add a list of your subcategories to your template using the following code:
<MTSubCategories> <MTSubCatIsFirst><ul></MTSubCatIsFirst> <MTIfNonZero tag="MTCategoryCount"> <li><a href="<$MTCategoryArchiveLink$>" title="<$MTCategoryDescription$>"><MTCategoryLabel></a> <MTElse> <li><MTCategoryLabel> </MTElse> </MTIfNonZero> <MTSubCatsRecurse max_depth="3"> </li> <MTSubCatIsLast></ul></MTSubCatIsLast> </MTSubCategories>
More documentation about the new subcategories tags is available in the manual.
Building on the new extensibility in Movable Type 3.0 are new features in 3.1 that developers will appreciate. The object callback interface added in 3.0 allowed developers to intercept all calls to save, remove, and update data objects in the database. This added an infinite new amount of options for developers to hook into, but 3.1 adds even more.
We've added a number of new application callbacks, hooks that allow developers to associate new actions with critical pieces of the application code. Plugins can now add code to be executed to filter comments and TrackBacks before they're posted; to hook into the publishing process, filtering and modifying the list of files that will be published; etc.
Six Apart, http://sixapart.com/