The key to using the Cache Block plugin to speed up publishing is to cache items that may require a lot of resources or database queries to build, that don't strictly need to be updated on every single page build. One thing to keep in mind when planning your caching strategy, is that the posting of new entries and the posting of comments will trigger a automatic rebuild/re-publish of multiple pages of your site. For example, when someone posts a comment, the entry page for that comment gets rebuilt, as does the category pages for all categories of that entry, any date-based archives containing the entry, author archives for the entry author, and all index templates that are set to "rebuild with indexes". As such, the frequency of comments can play a major role in how much publishing activity happens on your site.

Some ideas for Cache Blocks:

  • cache your entire sidebar for 60 minutes
  • cache your entire "Archive Index" for 1440 minutes (a full day)
  • cache your feeds for 60 minutes (so they won't get built on every comment)
  • cache entry summaries and comment detail modules to speed page builds with many entries or comments
  • cache individual sidebar widgets that don't need to be updated frequently
Example: Cache Your Sidebar

If you are using MT4 default templates, you can cache your sidebar as shown below. In this example, the sidebar is cached for 60 minutes.

<MTCacheBlock key="blog1_footer" expiry="60">
<$MTInclude module="Footer"$>

Let's assume the above code is on your "Main Index" template. The existing MTInclude is simply wrapped inside an MTCacheBlock container. Note that doing it thos way will only check the cache when the Main Index template is built. But most sites have the same sidebar displayed on multiple pages of the site. If this is true for your site, you can gain even more benefit from wrapping each of those MTInclude blocks, using the same cache key. But be careful -- many sites have unique sidebars for each archive page (entry, category, etc.) -- in such cases you won't want to pull the same "Main Index" sidebar.

Looking at the above example, you may be wondering whether it would be easier to simply place the MTCacheBlock tags inside the "Footer" template module. That way, you wouldn't have to repeat the process for each template that shares the same sidebar. There are two reasons why this is not a good idea:

  1. As a general rule when caching the contents of template modules, you will get more speed gains by placing the MTCacheBlock tags around the MTInclude statement, rather than inside the module itself. The reason is that if MT finds the block in the cache, it won't even bother trying to load and evaluate the included Template Module, which requires a database lookup by itself. In short, you can save at least one database lookup by wrapping the MTInclude tag instead.
  2. The second reason -- at least in this specific example -- is that the default "Footer" module is included for all pages for the site, and it contains some conditional code that creates different sidebars for different pages. As noted above, the sidebar for the Main Index may be different from the sidebar that appears on an Entry archive page. In such case, you need to be very careful. If you placed the MTCacheBlock tags inside the Footer module, then every page would have the exact same sidebar, and that would be the first sidebar that was built and saved in the cache. For example, suppose the first page to publish was one of you Entry Archives. MT would built the special sidebar for that entry ("This page contains a single entry from....", etc.) and save that in the cache with the key "blog1_footer". And then MT would publish your Main Index and MT will check the cache for "blog1_footer" and it will grab that Cache Block and place it in your Main Index. You should always be careful when caching block that include condition logic. For similar reasons, you should also be careful when caching block that are inside looping container tags (see below).

Example: Caching the 'Comment Detail' Module for each Comment

Suppose you have a site that gets a lot of comments. Some of your entries get over 100 comments. Every time a new comment gets added, MT will re-publish your entry page and build the HTML for every one of those 100+ comments. Consider that once a comment has been posted, it rarely changes (unless you edit the comment for some reason). As such it is safe to cache the HTML for each individual comment, so MT won't have to evaluate those template tags for each comment. You can do so as follow, in your "Comments" template module:

<MTSetVarBlock name="comment_cache_key">comment_detail_<mt:CommentID></MTSetVarBlock>
<MTCacheBlock key="$comment_cache_key" expiry="120">
<$MTInclude module="Comment Detail"$>

Notice that this example is a little different. Because the MTInclude tag is inside the MTComments container, which is repeated for every comment, we can't use the same cache key for every comment. We need to make sure that we use a unique cache key for each comment. We do this by using MTSetVarBlock to create a variable that represent a unique key. In this case, I chose comment_detail_<mt:CommentID> which will be unique because it includes the commentID number. Once we have saved this unique key in the "comment_cache_key" variable, we can then use that as the key by specifying key="$comment_cache_key" (note the dollar sign to indicate that we are using a variable).

The examples above are just two of the many ways that you can use Cache Block to speed up your MT publishing. Since each site is different in terms of templates, posting activity, traffic, etc., different techniques may work better for different sites.

I am going to submit this as a bug report as well, but I wanted to share this on Pronet, as it may save other MT consultants/developers the hours of support time that I have spent on this issue. I have seen this 3 times with user of plugins, and it can be difficult to diagnose.

In short the problem seems to affect people:

- who upgrade to MT4 from a previous version of MT,
- AND who used dynamic publishing before and after the upgrade,
- AND whose path to MT4 is different from the path to the older version (for example, before the upgrade is was /var/www/cgi-bin/mt and after it was /var/www/cgi-bin/mt4)

The problem is that the old mtview.php (in the blog root directory) does not get updated. The side effect is that the mtview.php file is still pointing to the pre-MT4 directory, point to the old mt-config.cgi and the old mt.php file. In many cases the old versions of these files still exist at the old paths, because when people upgrade they often upload MT4 to a new directory, leaving the older MT in place -- this makes this problem difficult to diagnose, because MT4 is read a valid config file and valild mt.php library -- it doesn't know that it has the old files.

Things can get even more confusing when the old MT config file points to a old, pre-upgrade version of the database that still exists -- one user of Fast Search was stumped (as was I) when after upgrading to MT4, his search results included only the pre-MT4 entries -- there were no error messages at all, but the search was being handled by the older version of MT against the older version of the database!

Another symptom of this problem is when MT can't seem to find certain dynamic template tags. Errors like:
Smarty error: [in mt:17 line 23]: syntax error: unrecognized tag 'MTTemplateTagName' will result, even though the php files may be in the correct location.

Part of the problem here stems from the fact that MT4 got "smart" and no longer included the "dynamic bootstrapper" template with each blog, that built the mtview.php, but rather built it behind the scenes when publishing settings are saved. The side effect was that the file didn't get rebuilt with indexes, as was the default in previous versions. It was also "out of sight, out of mind" with MT4. While the MT4 upgrade includes an upgrade task to remove the mtview.php bootstrapper, it does not delete the the old mtview.php file, nor does it attempt to update the existing mtview.php file(s). :( I think (but am not sure) that saving the publishing settings for blog will attempt to update the the file, but who changes there publishing setting after upgrading?

If you or a client run into any strange dynamic publishing issues under MT4, I recommend the following as one of the first troubleshooting steps:

1. Rename the existing mtview.php file.
2. Save the Publishing settings for the blog. This should recreate the mtview.php.

I hope this helps save others from the hours of frustrating troubleshooting that I have ensured on this....

Movable Type has a scheduled tasks system that is used to perform certain tasks on scheduled basis. Built-in tasks include expiring junk (spam) trackbacks and comments, and posting entries that were scheduled to to published at a certain date / time. Movable Type plugins can also use scheduled tasks, as some of my plugins do (including Visitor Stats Pro, Ajax Rating Pro, and Blog Janitor). One of the benefit of scheduled tasks is to improvement performance and user experience -- resource intensive functions can be run without making admins, authors, and commenters wait while they complete.

Triggering Scheduled Tasks

Scheduled task will only run when they are triggered. This is important. Even if a task is scheduled to run every hour, it scheduled tasks don't get triggered, the task will never run. By default Movable Type will trigger scheduled tasks in the following cases:

  1. You receive a junk (spam) comment or trackback. Note: this will only trigger the 'Junk expiration' task - it won't trigger plugin tasks.
  2. You view or download an XML "activity feed" (These feeds show up on with orange feed links on many screens of the admin MT interface, including entry and comment listings, and activity log).
  3. When the run-periodic-tasks script (found in the 'tools' directory of MT) is run via the command line or via cron.

Testing Scheduled Tasks

Here is an easily method that I use to test scheduled tasks and make sure they are running correctly:

  1. Go to System Overview > Activity Log.
  2. Click the "Activity Feed" link on the right side of the page.
  3. After the XML feed displays, hit the back button.
  4. Now refresh the System Activity Log.
  5. Read the recent log entries. If tasks were just triggered, there should be a message stating that tasks were run, along with the names of those tasks. In addition, some plugin tasks may post custom log messages to the Activity Log, providing more information about the task completed.

Note that in some cases, depending of the task, you may have to rebuild your pages after the task has run, in order to see the results of the task. One example of such a case is my Visitor Stats Pro plugin, in which a scheduled task tallies the page views of each entry, so that they can be displayed in a "Most Read Entries" widget that lists the most popular entries.

Setting Up a Cron Job

To ensure that scheduled tasks get triggered on a regular basis, I recommend setting up a cron job to run the run-periodic-tasks script once per hour. If you are not familiar with setting up cron jobs, please read the following helpful article on Learning Movable Type: Scheduled Postings and Cron Jobs.

One of the advanced features of User Profiles Pro is the ability to enable authors and commenters to edit extended profiles. Extended profiles come with 22 "built-in" fields:

Date type fields:

  • birthdate

Basic text fields:

  • first_name
  • last_name
  • address
  • city
  • state
  • country
  • mobile_phone
  • land_phone
  • sex
  • marital_status
  • occupation
  • company

Long text fields (suitable for textareas):

  • signature
  • about_me
  • activities
  • interests
  • music
  • tv_shows
  • movies
  • books
  • quotes

Most sites, however, will not want to use every single one of these fields. The list of fields available when editing an extended profile can be customized, in both the admin interface, and via the commenter profile interface.

Customizing Extended Profile Fields in the Admin (CMS) Interface

There are two ways to do this:

Edit the 'extended_profile_fields.tmpl' file found in /plugins/UserProfiles/tmpl, OR
Add a new template module (to the blog chosen in User Profiles settings) called "Extended Profile Fields". Note that it must be named this exactly. While you can start from scratch with this module, it likely easiest to copy and paste everything from the extended_profile_fields.tmpl mentioned above, and edit from there.

Each field in the default template looks something like this:

label="<__trans phrase="City">"
hint="<__trans phrase="The city where you live.">">
<input name="userprofiles_city" id="city" class="half-width" value="<mt:UserProfile field="city" escape="html">" />

As you can see from this example, this is the "city" field. Note that the "name" of the input field is always "userprofiles_field_name" -- this is important. Also note the "value" of the input field uses the <MTUserProfile field="field_name"> tag to dislay the current value of that field.

If you simply want to remove certain fields so user cannot see/edit them, you can safely delete sections like the one above. Alternatively, if you think you might want to add certain fields in the future, you may want to wrap the "inactive" fields in <mt:ignore> tags, as follows:

label="<__trans phrase="City">"
hint="<__trans phrase="The city where you live.">">
<input name="userprofiles_city" id="city" class="half-width" value="<mt:UserProfile field="city" escape="html">" />

Customizing Extended Profile Fields in the Commenter Profile Interface

Note that by default, both the admin (CMS) interface and the commenter "edit profile" interface use the same 'extended_profile_fields.tmpl' discussed above. So if you edit that file, the change will be automatically detected in both interfaces, so you only have to make the change in once place.

That said, you may want separate them so that you can customize each separately. To customize the commenter interface fields independently, open the "Edit User Profile" template and look for the following line:

<mt:var name="fields">

This line tells MT to grab the field template code from the file mentioned above. You can replace this line with your own template code for the fields, or use an <MTInclude> tag to include the "Extended Profile Fields" module (as discussed above), or another module containing the fields. Either way, the best way may be to start with the contents of the default template file and customize from there.

Adding Custom Fields to the Extended Profile

While a subset of the above 22 fields may be enough for most sites, some site may want to add other custom fields to the Extended Profile. This can be done very easily, by simply adding another field to the field template(s) as discussed above. For example, suppose we want to add a field called "middle_name", we would add a field as follows:

label="<__trans phrase="Middle Name">"
hint="<__trans phrase="Your middle name.">">
<input name="userprofiles_middle_name" id="middle_name" class="half-width" value="<mt:UserProfile field="middle_name" escape="html">" />

Then save the template. Now a middle_name field will appear on the form and users will be able to add a middle name to their profile. Once again the naming convention of the "name" attribute is important here, it must be "userprofiles_field_name" or it won't work. If you have custom fields and they are not being saved in the database, make sure this naming convention is being used.

Customizing Published Profile Pages

Of course, once you have customized Extended Profile forms, you may want to customize the display of the "User Profile" template module to customize the display of the published profiles. Note that the default template is designed to only display fields that contain data. In other words, if the marital_status field is empty, this field won't be shown at all on the page. This can be a time saver -- if you simply want to remove certain fields from the form, you may not need to edit the User Profiles template at all (because the fields you removed will always be empty, so they won't display on the profile pages). However if you have added custom fields, or if you want to change the display order of the fields, you can do so by editing the "User Profile" module, much like you would edit any other MT template. Note the format for the <mt:UserProfile> tag is the same for both built-in and custom fields. As such, to add our middle name field to the profile, we would use:

<mt:UserProfile field="middle_name">

Finally, remember that the "User Profile" module is a special one in that when you save it, it will automatically republish all of the profile pages. When available, the plugin will do so as a background task so you won't have to wait for the rebuild to finish. After the publishing all the profile pages, the plugin will post a message to the system activity log, include the number of seconds that the process took to complete.

The Ajax Rating Pro plugin enables you to setup comment threshold viewing for Movable Type powered sites. For more information about Ajax Rating Pro, click here.

This article focuses on ways that you can use Ajax Rating Pro to setup comment thresholds for Movable Type. The concept behind comment threshold is the ability to hide or collapse comments with rating score below a certain threshold. The result is collaborative filter, readers rate each others comments, and higher ranked comments are given more prominence, while lower ranked comments are given less prominence. Popular site such as Slashdot, Digg, and Scoop-powered sites use comment threshold filtering. It is a great tool for popular sites that attract a large number of comments.

Ajax Rating Pro is very flexible and customizable -- you can decide how you want to implement comment threshold filtering. Do you want to completely hide low ranked comments? Merely collapse them? Implement a default threshold score, or let readers choose their own? Something else in mind?

Ajax Rating Pro comes with a few built-in tools to help setup some of the more common approaches to comment thresholds. Let's walk through such an example. First take a look at the test entry here. Feel free to rate some comments and set a person comment threshold - notice how the display changes (refresh the page if needed). I am going go step-by-step to setup comment thresholds in this manner.

In this scenario, reader will rate comment with a vote up or a vote down. Votes are +1 point and votes down are -1 point. The default threshold is -3. In this scenario, comments with a total score of less than -3 will appear in a collapsed state. A single-click reveals the below threshold comment. Reader can optionally choose their own threshold using the form at the bottom of the comment listing.

Step 1 - After you have installed Ajax Rating Pro, go to the plugin settings for the blog you want. Choose Thumbs Up/Down for comment mode and choose 1 for Comment Max Points. Set the default threshold as desired (in this example, we will use -3).

Step 2 - Add a thumb rater to your Individual Archive template, between the <MTComments> and </MTComments> tags. In this example, I added it after the comment date on the default MT 3.3+ template:

<$MTAjaxThumbRater type="comment" report_icon="1"$> Score: <strong><span id="ajaxrating_comment_<MTCommentID>_ttl"><MTAjaxRating></span></strong> (<span id="ajaxrating_comment_<MTCommentID>_cnt"><MTAjaxRating show="vote_count"></span> votes cast)

Then rebuild your individual archives. (Tip: make sure you have the Ajax Rating lines in the <head> section of this template, as described in step 10 here. After rebuilding, each comment should have a thumb rater -- test to make sure the ratings are working.

Step 3 - Now that our readers can rate others' comments, now we can change the display for comments that fall below the threshold. In this example, we will do this using CSS styles to show or hide things. First we want to create add a section to the Individual Archive template, that will display only when comments fall below the threshold. In this example, immediately after </MTCommentsHeader>, enter the following:

<span class="below-threshold" id="threshold-<$MTCommentID$>">
<a href="#" id="c<$MTCommentID pad="1"$>" onclick="showComment(<$MTCommentID$>); return(false);"><$MTCommentBody trim_to="30" strip_linefeeds="1" remove_html="1"$>...</a> (Below threshold)
<p class="comment-footer">
Posted by <$MTCommentAuthorLink default_name="Anonymous"$> <$MTCommentAuthorIdentity$> |
<a href="#comment-<$MTCommentID$>"><$MTCommentDate$></a> | Score: <strong><$MTAjaxRatingTotalScore$></strong>

The first and last lines above are very important. This <span> encloses the stuff that we want to display when a comment is below the threshold. We will show and hide this span depending on the score and threshold. Both the class="below-threshold" and id="threshold-<$MTCommentID$>" are required for this purpose.

Inside the the span, you can customize what you want to display when a comment is below threshold. In this example, we have included a link that will display the comment. Notice the onclick argument in the link:

onclick="showComment(<$MTCommentID$>); return(false);"

This onclick section is important, as it will cause the link to run some javascript to display the comment in the browser.

Step 4 - The next step is to include a form that readers can use to set their own threshold. (If you don't want readers to be able to set their own threshold, you can skip this step). Below the </MTComments> tag, enter the following form code:

<form id="threshold-form" name="threshold_form" action="<$MTEntryLink$>#comments" onsubmit="setThreshold(this);">
<input type="text" name="threshold" size="3">
<input type="submit" name="submit" value="Set Comment Score Threshold">

The important part of this form is the onsubmit="setThreshold(this);" section as this will set the readers threshold by storing in a cookie in their browser.

Step 5 - By default, the section that we added in Step 3 above is hidden from view, and the full comment is displayed. At this point we need to compare the score to the threshold of each comment and decide which comments should be collapsed. Add the following below the form coded added in Step 4:

<script type="text/javascript">
var comments = new Array(<MTComments>'<$MTCommentID$>',</MTComments>'');

The above javascript will check each of the comments. If a comment is below the threshold, the comment will be hidden and the section from Step 3 above will be displayed instead.

Step 6 - Rebuild your individual archives and test it!

The customized individual archive template used in this example on the test entry can be found here.

The above example is only one way to implement comment thresholds on your site using Ajax Rating Pro. You can customize the above to meet your needs. You can even edit the javascript and CSS elements to customize things further.

Another Built-in tool is the <MTIfAjaxRatingBelowThreshold> conditional tag. You can use this tag inside an <MTComments> container. Anything between <MTIfAjaxRatingBelowThreshold> and </MTIfAjaxRatingBelowThreshold> tags will not be inlcuded in the HTML of the page. (Note that the score is checked against the default threshold when the page is rebuilt, or if you are using PHP dynamic publishing, when the page is displayed). For example, if you wanted to completely hide comments below the default threshold, you could do something like this:


.....comment template code here......


Note that if you use this tag, you won't be able to provide a link to display the comment like in the example above.

Another way to use this tag might be to apply certain filters to comments below the default threshold. For example you might want to remove HTML from comments below threshold:

<MTCommentBody remove_html="1">

I hope that the example above provide a few examples of how you can implement comment threshold viewing, and perhaps inspire a few ideas for unique ways to do so.

To get Ajax Rating Pro, or for more information, click here.

In this article I will cover some of the more advanced features of the Ajax Rating plugin. Ajax Rating is rating plugin for Movable Type that makes it easy for readers to rate entries, comments, and more. If you haven't read about Ajax Rating yet, you should read this first, and then come back to read this article afterwards.

Covered in this article:

Custom images for star and thumb raters
Using custom raters
Dynamically updating numeric ratings and vote counts
Setting up comment raters
Rating non-MT objects

Custom images for star and thumb raters

Whether you are using Ajax Rating or Ajax Rating Pro, you can use alternative images for rating items. For star/point raters, the image must be named "starrating.gif". The image should be a "three state" image. For example, here is the default image that comes with Ajax Rating (design credit to Ryan Masuga):

Note that the image has 3 stars, appearing one on top of the other. As such, the height of the image should be 3 times as long as the width. The default image, above, is 30 pixels wide by 90 pixels high. The star at the top is the "empty star", the star in the middle is the "hover star" (the color of the star when you hover your mouse over it), and the bottom star is the "current rating star". Of course, the images don't have to be "stars" at all -- you could use images of hearts, checkmarks, boxes, or bananas. As an example, Ajax Rating comes with an alternative star image called 'starrating16x16.gif' that looks like this:

Note that this image is 16 pixels wide and (16 times 3 equals) 48 pixels high. if you want to use this image, you can rename it 'starrating.gif'.

After you have the image you want, make sure it is named starrating.gif and then upload into the /mt-static/plugins/AjaxRating/images/ directory on your server.

The final (but important) step is to browse to the Ajax Rating settings for your blog and enter the width on your new image into the "Star Icon Width" field. Save your settings and then rebuild the Ajax Rating javascript and styles index templates. Finally rebuild all your pages with star raters.

To use custom image with Thumb Raters (Pro feature), the process is much easier. The only rule is that you have to name your images "up.gif" (+1 point) and "down.gif" (-1 point). You make them any size that suits your needs. Upload the new images to the /mt-static/plugins/AjaxRating/images/ directory and you are done (no need to rebuild any pages).

Creating Custom Raters

The previous section explains how to customize the look of the raters that appear when you use the convenient <MTAjaxStarRater> and <MTAjaxThumbRater> tags. You are not limited to those raters, however. You can create your own custom raters.

For example, here is a simple rater that consists of a "Vote For This Entry!" text link:

<a href="#" onclick="<$MTAjaxRaterOnclickJS points="1" type="entry"$>">Vote For This Entry!</a>

The above example illustrates the key elements of rating link. Set the href equal to "#" and include an onclick= argument. The special MTAjaxRaterOnclickJS tag helps you fill the javascript required to capture the vote. They key argument here is the "points" argument -- use this to specify how many points get assigned when someone clicks that link.

To expand the above example, here is a 5 point rater using text links instead of images:

<a href="#" onclick="<$MTAjaxRaterOnclickJS points="1" type="entry"$>">1</a> <a href="#" onclick="<$MTAjaxRaterOnclickJS points="2" type="entry"$>">2</a> <a href="#" onclick="<$MTAjaxRaterOnclickJS points="3" type="entry"$>">3</a> <a href="#" onclick="<$MTAjaxRaterOnclickJS points="4" type="entry"$>">4</a> <a href="#" onclick="<$MTAjaxRaterOnclickJS points="5" type="entry"$>">5</a>

Tip: if you want your customer rater to disappear after a vote, surround in a div or span element with an "id" in the following format "thumb{type}{id}", replacing {type} and {id} with the type and id of the object being rated. For example:

<span id="thumbentry105"> ...rater goes here </span>

Dynamically updating numeric ratings and vote counts

Often you will want to display numeric representations of ratings and vote counts on your pages. Consider the following example, which shows box a star rating and the average rating and vote count:

  • Currently 3.9/5
  • 1
  • 2
  • 3
  • 4
  • 5

Rating: 3.9/5 (1204 votes cast)

Notice when you make a rating with the above rater, the average rating and vote count numbers get updated dynamically. The trick to doing that is to surround those numbers in "span" tags. Here the template code for the above example:

<$MTAjaxStarRater type="entry"$>
Rating: <strong><span id="ajaxrating_entry_<$MTEntryID$>_avg"><$MTAjaxRatingAverageScore type="entry"$></span></strong>/<$MTAjaxRatingEntryMax$> (<span id="ajaxrating_entry_<$MTEntryID$>_cnt"><$MTAjaxRatingVoteCount type="entry"$></span> votes cast)

First looking at MTAjaxRatingAverageScore, the "id" of the span must be in the format id="ajaxrating_{type}_{id}_avg". For an entry with an id of 105, that would be id="ajaxrating_entry_105_avg". Using MT template tags in this example, you can do it as follows:

<span id="ajaxrating_entry_<$MTEntryID$>_avg"><$MTAjaxRatingAverageScore type="entry"$></span>

For MTAjaxratingVoteCount, the process is the same, but the id ends in "_cnt" instead of "_avg". So the template code becomes:

<span id="ajaxrating_entry_<$MTEntryID$>_cnt"><$MTAjaxRatingVoteCount type="entry"$></span>

If you wanted to dynamically update MTAjaxRatingTotalScore (not shown in above example), the id should end in "_ttl":

<span id="ajaxrating_entry_<$MTEntryID$>_ttl"><$MTAjaxRatingTotalScore type="entry"$></span>

Setting up comment raters

With Ajax Rating Pro you can rate comments and other objects. Setting up comment raters is similar to entry raters. While you can use star raters or thumb raters, many people will prefer to thumb raters for rating comments, so my example will focus on these.

To add a thumb comment rater, place the following in suitable place in a <MTComments> container:

<MTAjaxThumbRater type="comment">

(Optionally, you could include a report_icon="1" argument to display a third button, that will enable readers to report comments to entry authors)

Rating non-MT objects

With Ajax Rating Pro, you can even create raters for non-MT objects. For example, suppose I have five photos in my sidebar, and I want people to be able to rate them. The rules for rating non-MT objects are as follows:

  • choose a unique "type" of object (don't use the reserved names like 'entry', 'comment', etc.)
  • create a unique numeric id for each specific object you want to rate.

In the sidebar photo example, let's choose the type "sidebarphoto" and give each photo a numberic id from 1 to 5. For the first photo, I would use the following code to display a star rater:

<$MTAjaxStarRater type="sidebarphoto" id="1" max_points="5"$>

...and the second photo would be:

<$MTAjaxStarRater type="sidebarphoto" id="2" max_points="5"$>

... and so on.

Also note that the discussion above about dynamically updating ratings and vote counts also applies to non MT objects -- just be sure to use your chose "type" and "id" values in the span ids.

The features above are just a few advanced ways to use Ajax Rating. To get Ajax Rating, or to learn more, click here.

Look forward to the next article (soon) on Ajax Rating: Setting Comment Threshold Viewing.

Entry Post is a plugin that enables visitors to post entries to Movable Type via an external form. To get Entry Post, or for more information, click here.

Entry Post can be used in many different ways, using the many options available. This entry provides some tips on a few usage scenarios, and may inspire a few ideas for other ways that it can be used.

Displaying Information about Entry Posters

If you want to display information about the person who submitted an entry, you can use the following template tags. (Note: these template tags are provided by the CustomFields plugin, which is a requirement for Entry Post v1.0)

<MTEntryDataName> - The Name of the poster.
<MTEntryDataEmailAddress> - The email address of the poster.
<MTEntryDataURL> - The URL provided by the poster, if any.

For example, if you wanted to display a linked name, you could use the following code:

<MTIfNonEmpty tag="EntryDataURL">
<a href="<MTEntryDataURL>"><MTEntryDataName></a>

But suppose you are entries that could be posted via Entry Post or posted by an Author in the system. The following code can be used to simulate the "Posted by..." line from the MT 3.3 default templates:

click here for the template code

Displaying an Image Submitted by the Poster

If you are enabling posters to submit an image, you can display the image using the following template code:

<MTIfNonEmpty tag="EntryDataImage">
<img src="<MTBlogURL><MTEntryDataImage>">

Requiring Moderator Approval before Publishing

If you don't wanted entries to be published immediately, you can choose "Unpublished" as the "Default Status" in the settings for this plugin. In such cases, you may want to include a hidden "redirect" field on your form. Here is an example:

<input type="hidden" name="redirect" value="">

When Entry Post finds a redirect URL in the submitted form, it will redirect the poster to that URL after the submission has been received. The redirect page can be any page, usually with some text thanking them for their submission, that it is pending moderator approval, etc. This is also very useful when using MT as a contact form (see below).

Using Entry Post as a Contact Form

An advanced usage of Entry Post is a contact form. A contact form is a form which accepts information from the poster and then sends you the results via email. In a business context, this is sometimes referred to a "lead from". To make the plugin work this way, there are two important settings. First, ensure that email notification is turned on in the settings, and make sure that an email address is entered. Second, check the "Disable Entry Creation" setting: this will prevent an entry from being created. While contrary to the primarily purpose of the plugin, this options converts the form into a contact form, only sending you the submission by email. Using a form is better than posting your email address on your site, as email address harvesters will find your email address and you will get (even more) spam in your inbox. When using Entry Post in this way, it is a good idea to add a hidden 'redirect' field, as discussed in the previous section. An example of an Entry Post contact form can be seen here (view the HTML source to seem what the form looks like, including the hidden fields at the top).

Overriding Default Settings

Depending on your needs, there may be some case where you want to override some of the default settings. One reason you might want to do this, is when you would like to include more than one EntryPost form on the same blog, each with a different purpose. For example, one for entry submissions and another as a contact form. The following settings can be overridden by fields in form:

Default Category - If a form includes a field (hidden or visible) named 'cat_id', the value of that field will be used as the Category ID for the entry to be placed in. You could include a hidden cat_id field and assign a category ID, or create a visible dropdown box so that the poster can choose a category (an example of the latter can been seen here with template code found here.)

Default Tags - Similar to above, the default tags can be overridden by including a field named 'tags' in your form. A tags example is also present on the form and code linked to above.

Disable Entry Creation - If you include a field called 'no_entry' and set its value to 1, then no entry will be created when the form is submitted. This field is useful as a hidden field when you want to create a contact form using Entry Post, but also want to have another form for submitting entries. An example on my contact form on this site.

Creating a Contact Author Form

The Contact Form technique described above is useful, but what if you have more than one Author, and you want people to be able to contact each of them? Entry Post has an advanced feature that addresses this. In addition to the above overridable fields, the Notification Email Address field can also be overridden. However, including authors' email addresses in a hidden form field does not protect their privacy, and will certain lead to more email spam. For this reason, you need to include a field called 'email_author_id' and then assign the MT Author ID of the author to send the email to. Entry Post will take the email_author_id and look up the author's email address in the MT database, and send the email to that author. Similar to categories, this can be a hidden field, but it may make more sense as a dropdown box, enabling visitors to choose the Author to contact.

I hope the above tips and tricks are useful, and perhaps inspire creative uses for Entry Post. If you have questions or suggestions, please reply to this entry. To get Entry Post, or for more information, click here.

While there are many strategies for blocking, filtering, and reducing blog spam, many of them don't due much to reduce the CPU load incurred to handle all that spam. Even if you have strong MT spam filters, or close comments on your entries, spam may continue to cause increased CPU load, even if the spam is rejected or filtered.

As far as spammers are concerned, the automated ones don't care much (or even realize) that comments are closed on your entries. And they don't take the time to see if their attempts were junked or pubished. They will continue to submit comment spam and trackback spam. MT will refuse them, of course, but the entire MT application loads on every attempt -- the MT cgi scripts still incur load in process these, but likely not as much as a junked or successful comment submission. The main benefit to closing comments and using MT junk filters is to reduce / remove the clean-up effort, and to keep spam from be published on your blog. You end up with less published spam, but I am not sure how much CPU load is saved in these cases.

To address the CPU load of spam, you need to prevent/reduce spam hitting the MT cgi scripts. A temporary solution is to rename your comments and trackback scripts. Spammers will still try to hit the old URLs, but they will get 404 "not found" errors. This still incurs some load, but not as much as if MT had to handle those requests to reject or filter them. This solution is temporary because spammers will soon learn the new names of your scripts, and spam and load will increase thereafter.

A longer term solution is to attempt to block spam *before* it hits the MT scripts. mod_security is one way to do this. It is an Apache module that uses rule-based filters to block requests at an early stage. You still need a good ruleset, of course. In many, case you will need a dedicated server to use this, but some shared hosting providers support mod_sec to varying degrees. In recent days, spam attempt have increased on my server. Yesterday, mod_security blocked almost 4,000 spam attempts. Without mod_security, that would have been a lot for MT and my dedicated server to handle. My server would likely have crashed several times. But my blocking the spam before it gets to my MT scripts, I was able to weather the attack without a huge spike in CPU load.

1. Start with one of your blogs (any blog, it doesn't matter)

2. Create a new Template Module.

3. In the "Link this template to a file" field, enter a file system path and file name to save the template text. For shared template modules, I save them all to a "shared" directory and give each file a "txt" extension.

4. Save the template module.

5. Go to another blog that you also want to use the shared template and create a new template module.

6. Don't put anything in the body of the template module.

7. Give the template module a name and specifiy the *same* path and file name in the "Link this template to a file" field.

8. Save the template. You will see the template module code from the first blog appear in the body.

9. At this point you can modify the template code from any of your blogs and it will be updated across all blog using the module.