NOTE: This documentation is for Movable Type 3.2. If you are using a newer version, please see the documentation for Movable type 3.3x or Movable Type Enterprise.
Weblogs are not just a one-way medium for publishing. With the use of a singular, often conversational voice, enhanced by the loosely coupled nature of the Internet and lightweight syndication formats, weblogs are akin to conversations, regardless of the size and makeup of the audience. "A" writes about something on their mind -- an experience, the news, or a project's status. "B" reads it and expresses their take. "C" finds both posts interesting and notes something A and B has not mentioned and so on.
Not everyone has a weblog (sadly) and not everyone wants to make a post to their weblog for everything they want to say. "This is great. Thank you." is not much of a weblog post. Hence the need for comments.
Weblog comments allow readers to post comments on an entry and engage in a more direct and immediate conversation; this idea originated from the earliest of online community tools -- bulletin boards. Weblog comments differ by organizing the conversation in a single thread. Unlike on a bulletin board, these discussions are typically started by a limited number of individuals, which generally increases the quality of the comments.
Movable Type features a built-in commenting system where the publisher can selectively control which entries are open for comment and moderate them if desired. MT includes functionality to identify "junk" comments either automatically through plug-ins or manually by using the CMS interface. In many respects the junk concept is similar to the filters in most modern email applications that screen out unwanted messages.
The Comments Listing screen displays all the published and unpublished comments for a weblog or the system. This is the screen in which comment moderation is managed. Use the Comments button on the Weblog or System Toolbars
1 Comments Tab. Displays a listing of comments that are published and queued for moderation
2 Junk Comments Tab. Displays a listing of comments that have been marked junk either manually or by the plug-in system
3 Filter. A dynamic control to filter the list of comments.
4 Quick Filter. A link that sets the filter to only display comments awaiting moderation.
5 Comment Checkbox. A control for marking the corresponding row to indicate that an action should be performed on it.
6 Comment Flag. An icon indicating the status of the comment in the system.
7 Comment Summary. The beginning of the comment that is linked to open the Edit Comment Screen.
8 Commenter. The name of the commenter that is linked to the Edit Commenter screen.
9 Entry Title. The title of the comment's associated entry that is linked to its Edit Entry Screen
10 Date. The date the comment was submitted.
11 Publish Button. Releases the checked comments awaiting moderation.
12 Delete Button. Permanently removes the checked comments from the system.
13 Junk Button. Marks the checked comments as junk.
14 More Actions Pulldown Menu. Additional actions such as unpublishing a comment, banning a commenter or marking one as trusted.
15 Display Options. A control for setting what and how list elements are displayed in the screen.
graphic Comment Listing Screen
The Edit Comment screen is used to modify an existing comment in the system. This screen can be reach by clicking on a title found on the Comments Listing screen.
1 Comment Text. The body of the comment.
2 Status. A pulldown menu to denote the comment as either published, moderated or junk.
3 Commenter Name. The name of the commenter.
4 Commenter Email. The email address of the commenter if provided.
5 Commenter URL. The website URL of the commenter if provided.
How does 3-5 react if authenticated?
6 Comment Date. The date the comment was submitted.
7 IP. The network address of the commenter when the comment was submitted.
8 Save Changes Button. Saves any modification to the comment and republishes the entry.
true?
9 Delete Button. Permanently removes the comment from the system.
graphic Edit Comment Screen
The Commenters Listing Screen displays all authenticated users of the weblog. This screen can be reached by clicking the Commenters button on the Weblog Toolbar.
graphic Comment Listing Screen
1 Filter. A dynamic control to filter the list of comments.
2 Quick Filter. A link that sets the filter to only display comments awaiting moderation.
3 Commenter Flag. An icon indicating the status of the commenter in the system.
4 Commenter. The name of the commenter that is linked to the Edit Commenter screen.
5 Identity. The username of the commenter in the authentication system.
6 Email. An icon that, when clicked, will open a new email message with the commenter's address. This icon will not be present if a commenter has not supplied their email address.
7 URL. An icon that will open a new browser window with the commenter's URL when clicked. This icon will not be present if a commenter has not supplied one.
8 Comments. The number of comments the user has made on the weblog.
9 Most Recent Comment. The date the commenter last posted a comment to the weblog.
10 Trust Button. Designates all of the checked commenters as trusted.
11 Ban Button. Restricts the checked commenters from further postings on the weblog.
12 More Actions Pulldown Menu. Additional actions such as Unban and Untrust a commenter.
13 Display Options. A control for setting what and how list elements are displayed in the screen.
You want to set commenting policy for your weblog.
Use the controls under the Feedback tab of the weblog's Settings screen.
When Movable Type Version 3.0 was released, its most significant enhancements came in the area of comment and TrackBack management and moderation, providing publishers numerous means of controlling the community elements of MT-powered sites.
While the Comments and Commenters Listing screens provide the ability to manually tend to comments in a more efficient manner than previous versions, MT also added logic for applying a range of policies to these features on an individual weblog basis. These policies are set in the weblog settings along with other commenting preferences.
To begin click the Settings button on the Weblog toolbar, then the Feedback tag. Here we'll find numerous options to control how the system will handle comments.
This screen uses a dynamic interface to assist in changing configuration settings. Some options below will not be visible unless another option that they are dependent upon is checked.
With this setting, you can control whether comments are on or off for the entire weblog. The ability to leave comments can be made contingent on the commenters authenticating themselves. "Off" effectively turns off comments for all entries in your weblog despite the reader's individual comment status. This setting affects access only to the comment system; other publishing is not affected.
Authenticated systems supporting the TypeKey API require a key or "token" to operate. This control allows you to store your token in the authentication service. If you don't already have a token, click the Setup Authentication button to set up and install one. Not all authentication services support the automated form.
This checkbox forces a commenter to provide their email address as part of the authentication process.
You can control if incoming comments are immediately published or queued for moderation based on the commenter's status.
You can request that the system send an entry's author an email notification for comments with this control. For more see "Receiving Comment and TrackBack Ping Activity".
This checkbox defines whether HTML is permitted in the comment body. If the box is unchecked and HTML is not allowed, all markup will be stripped before storing the comment.
When checked, all URLs will be transformed into links. This option is ignored if you have enabled Allow HTML in comments.
Like entries, comments can use a text formatting engine. The pulldown menu specifies the text formatting plug-in to be used for weblog comments.
With so many options, weblog publishers will need to weigh various issues of inclusion, privacy, quality, and protection from abuse. Which policies you enable will depend on the type of community you intend to foster and your own preferences and tolerances.
This diagram is a simplified view of how to select the comment policy options in MT based on the level of protection from abuse and inclusiveness you want to establish. For the most part comment policy is set using the Comments and Comment Publishing controls in the Settings screen. This table defines the various comment policy levels that are available to you, starting from the most protective and ending with the most inclusive.
Table: Comment Policy| Accept comments from | Immediately publish comments from | |
|---|---|---|
| Off | - | Most Protective |
| Only Authenticated Commenters | No one | |
| Only Authenticated Commenters | Trusted Commenters | |
| Only Authenticated Commenters | Any Authenticated Commenters | |
| Only Authenticated Commenters | Anyone | |
| On | No one | |
| On | Trusted Commenters | |
| On | Any Authenticated Commenters | |
| On | Anyone | Most Inclusive |
You want to allow comments to be made on an entry.
Set the Allow Comments pulldown menu on the New/Edit Entry screen to Open.
"Turning on" comments for a particular entry is easy. While creating or editing an entry, simply set the Allow Comments pulldown menu to Open. Depending on the display options you have set for the New/Edit Entry screen, this control may or may not be visible. Also depending upon the Default Settings for New Entries for the weblog, it may already be set to Open.
This control is dependent upon the comment access policy of the weblog. For instance, if comments are turned off, selecting Open in the Allow Comments pulldown will not turn them on.
Does turning off comments in Settings affect the interface aka entry layout?
You want to display comments in your weblog.
Use the template tags prefixed with MTComment.
The default templates that ship with Movable Type are comment-ready. These templates are set up so that comments appear on both the popup comment window and the individual archive pages.
All of the various options for moderating and managing comments combine to make the default template code and HTML for comments quite extensive and sophisticated. To get you familiar with how comments can be implemented in MT templates we'll look at some basic examples. Once you become more familiar with how the comment tags work and can be combined, you can look at the default templates and modify them to suit your preferences and purposes.
Let's look at a simple comment display that may be inserted following the contents of a post on an individual entry archive template.
<MTIfCommentsActive>
<h2 id="comments">Comments</h2>
<MTComments>
<div id="c<$MTCommentID$>">
<$MTCommentBody$>
</div>
<p>Posted by: <$MTCommentAuthorLink spam_protect="1"$>
<$MTCommentAuthorIdentity$> at
<$MTCommentDate$></p>
</MTComments>
</MTIfCommentsActive>
The first line, MTIfCommentsActive, is a conditional
tag that will render the contained HTML and template tags if comments
exists or are being accepted for the entry. Next we add a section heading
with an anchor of "Comments" that will allow links to this section.
Used in this context, MTComments will select and loop
through all comments for the associated entry, using the values set in the
weblog's preferences. These preferences (sort order etc) can be selectively
overridden with attributes added to the MTComments tag. (See
the entry for Comments in Appendix A for more on these
attributes.)
The comment ID (MTCommentID) is placed in a HTML
div tag so that individual comments can be linked, while the
div tag wraps the comment body
(MTCommentBody).
The comment ends with a posted-by footer that uses
MTCommentAuthorIdentity, MTCommentDate, and
MTCommentAuthorLink.
Should we explain where the commenter name comes from relative to TypeKey usage.
MTCommentAuthorIdentity. A link to the commenter's TypeKey profile with the link text of the TypeKey username.
MTCommentDate is the timestamp designating when the comment
was submitted. The format used is dependent upon the weblog's preferences
or can be modified using the format argument and the standard
Date Tag Formats. See Appendix A
for more.
MTCommentAuthorLink inserts the commenter's name with a
hyperlink if possible. Depending upon the information given by the
commenter, this tag will return different results. See MTCommentAuthorLink for more information on using this tag.
For those who are (potentially) displaying email addresses, adding the
spam_protect global filter with a value of 1 (true) is a good
idea. More on this in "Protecting Email Addresses from Spammers".
Does MTCommentURL use the redirect mechanism?
The block then closes the MTComments and
MTEntryIfCommentsActive tag contexts.
Getting a bit more sophisticated, there are a couple of comment-related conditional tags you'll want to be aware of.
MTEntryIfCommentsAccepted is a conditional tag that will
render its contents if comments on the entry are closed as opposed to the
MTEntryIfCommentsActive which will render its contents if
comments exists.
MTIfRegistrationRequired is a conditional tag that will
only render its results if a reader has signed into the system's designated
authentication system.
Like all conditional tags each of these can be used with the
MTElse tag to render only if the opposite is true. (See "Publishing Content When a Conditional is False" for more.)
You want to create a form that accepts comment submissions.
Create an HTML form that submits its input to the Movable Type comment
script or instead use the MTCommentFields tag.
"Displaying Comments" discusses how to lay out comments. If there isn't a way for readers to make comments, then there won't be any to display. Here is a simple, example form layout that could be used in an individual entry archive template.
<form method="post" action="<$MTCGIPath$><$MTCommentScript$>">
<input type="hidden" name="static" value="1" />
<input type="hidden" name="entry_id" value="<$MTEntryID$>" />
<p><label for="author">Name:</label><br />
<input id="author" name="author" /></p>
<p><label for="email">Email Address:</label><br />
<input id="email" name="email" /></p>
<p><label for="url">URL:</label><br />
<input type="text" name="url" id="url" /></p>
<p><label for="text">Comments:</label><br />
<textarea id="text" name="text" rows="10" cols="50"></textarea>
</p>
<div align="center">
<input type="submit" name="post" value="Post" />
</div>
</form>The form is set up with MTCGIPath and
MTCommentScript; these create the URL where the input is
submitted. Next are two hidden fields that the mt-comments.cgi
script requires for processing. The static field tells the comments
script how to generate the comment link, which is not stored. The
entry field is the ID that the comment is associated with.
Next we move on to the labels and inputs used to collect the commenter's name, email address, and URL. (This example covers commenting that does not require registration. A TypeKey compatible registration system will provide the name and email address for us.) Using a radio button, this example form allows the commenter to decide whether they'd like the system to remember their information for future comments. A text field is provided for the actual comment, and a Post button for submitting the input to the associated comment script.
A simple way of implementing such a form is to use the
MTCommentFields tag, which handles all of this for you by
inserting a generic comment submission form into your template. By using
this tag, you have the advantage not needing to create the comment form
yourself, but you sacrifice a certain amount of flexibility in how the form
is constructed.
MT's built-in commenting system can be enabled to allow commenters to preview what they've written before they submit it. This feature is enabled by the system Comment Preview template, which requires some added considerations to the standard comment form layout.
Your layout of the comment being previewed uses different, though similarly named tags.
These tags all have the same meaning as the like-named comment tags (sans the Preview) discussed earlier. The only real difference is that these tags represent content that has not been stored in the system yet.
These tags should also be used to set the values of the form elements
the commenter can use to make changes to their text. Don't forget to use
the encode_html filter on all of them.
A comment preview template also has one additional tag at its disposal:
MTCommentPreviewIsStatic. This tag is used inside of the form
to indicate to the system where to redirect users after posting a comment.
Since the preview function and template are shared by both comment
interfaces, the value of the static will vary depending upon
use. Here is how we use it in our preview form:
<input type="hidden" name="static" value="<$MTCommentPreviewIsStatic$>">You are using comments and want to handle comment submission errors.
Create a Comment Error template with the MTErrorMessage and
MTComment tags.
Since the comment preview page is dynamically generated (even when using the traditional static publishing model), a special template is needed in the event that an error occurs. For example, if you have disallowed anonymous comments, and the user does not supply a name or email address, you can customize the error page that the user receives using the Comment Error Template. You can use this template to provide a form where users can fix whatever error has occurred in their submissions and then re-post (or preview) the comment.
This template should include a MTErrorMessage tag and a
form that allows you to edit the comment so that you can correct the error.
This form is constructed using the same tags as in the Comment Preview
Template.
With template tags and web forms in place, checking the "Allow Comments" option of an entry and saving it will enable comments to be received.
You want to publish comments that are queued for moderation.
Use the Publish action button on the Comments Listing screen.
Depending on your Comment Policy settings, comments can be received but not published. These comments are in the moderation queue and need to be manually published to be viewed.
Publishing comments is typically done through the Comments Listing screen. Once a comment is deemed appropriate for publication, use the comment's associated checkbox to select it, and click the Publish action button.
Alternately, while viewing the comment through the Edit Comment screen, you can set the status to "Publish." When the Save Changes action button is clicked the comment will be published.
You have some commenters that always make relevant contributions, so you don't want to bother moderating them.
Designate the commenters as "trusted."
In the course of allowing comments on your weblog, some users will emerge as trusted commenters -- those who become known to you and make appropriate and relevant contributions to the conversation. Perhaps they are friends, colleagues, or even other authors from your weblog. Or maybe they are like-minded people with similar interests and insightful views.
Giving commenter trusted status allows the system to handle them differently, publishing their comments immediately, while other commenters are queued for moderation. Besides the goodwill this designation generates, it can save you the time and effort of moderating and publishing queued comments.
In order to identify and trust a commenter in the system, you must be using authentication (i.e., TypeKey).
Denoting a commenter as trusted can be done a couple of different ways. The most common is from the Commenters Listing screen. Click Commenters on the Weblog Toolbar, check all of the commenters you want to mark as trusted, and click the Trust action button.
Another way commenters can be marked as trusted is in the Comments Listing screen. In this screen you mark comments made by a commenter you wish to trust (only one comment per commenter is needed), select "Trust Commenter" from the Actions pulldown menu, and click Go.
You want to ban a commenter from commenting on a weblog.
Use the Ban Commenter action on the Comments Listing screen.
Occasionally a commenter will abuse a weblog's comments, leaving you no alternative but to ban them from further commenting. In order to identify and ban a commenter from the system, you must be using authentication (i.e., TypeKey).
There are a number of ways in which a commenter can be banned. The most straightforward is to click the Commenters Toolbar button, find the commenter you wish to ban, check the box next to their name, and click the Ban action button.
You can alternately ban commenters through the Comment Listing screen. From this screen, find a comment by the commenter whom you wish to ban, click the associated checkbox, select the Ban Commenter(s) option in the Actions pulldown menu, and press Go.
Is there an edit commenter screen and does it also have a ban action on it?
You want to configure the junk handling features for the weblog.
Use the controls under the Junk section on the Feedback tab of the Settings screen.
In order to modify the Junk handling settings, click Settings in the Weblog Toolbar followed by the Feedback tab. Under the Junk section you will find three controls related to junk handling of comments and trackback pings.
This control gives each weblog administrator the ability to set the junk feedback tolerance independent of any plug-in scoring system. Automatic junk filtering can be performed by one or more plug-ins which analyze comments and grade them. Movable Type collects these scores and averages them into an overall junk score that is compared to the Junk Score Threshold. Comments with scores less than the threshold value are automatically marked as junk and not published, while those equal to or greater than the threshold are stored and published according to other feedback policy settings.
Use the slider control to change the value or enter a value in the textbox. Threshold values can be any real number between -10 and 10.
When checked, Movable Type will not save any comments that have been deemed junk. There is no way to reverse a junk classification.
This control allows you to choose how many days comments marked as junk should be held before permanently removing them. The default is 60 days.
You want to manually mark a comment as junk.
Use the Junk action button on the Comments Listing screen.
There are a few ways that comments can be marked as junk. Go into the Comments Listing screen by clicking the Comments button on the Weblog Toolbar. From here you can check which comments you want to mark as junk and press the Junk action button. Alternately, you can junk a comment by opening it in an Edit Comment screen and selecting "Junk" as the status before clicking the Save Changes action button.
Marking a comment as junk is the smarter approach to handling unwanted "spam" comments, because by doing so, it will be analyzed for future automated junk processing. Deleting a comment circumvents this analysis.
Junk comments are automatically deleted by the system after a set period of time, which is defined in the Junk section of the Feedback Settings screen. (See "Configuring Junk Handling Settings")
You want to permanently remove a comment from the system
Use the Delete action button on the Comments Listing screen
There numerous ways in which comments are deleted either manually or through system functions.
The most common is to go into the Comments Listing screen by clicking the Comments button on the Weblog Toolbar. From here you can check which comments you want to remove and press the Delete action button. Alternately, you can delete a comment by opening it in an Edit Comment screen and clicking the Delete action button.
If a comment is junk, mark it as such. (See "Marking Comments as Junk".) If you simply delete the message it will not be analyzed by any of the automated junk filters that learn from feedback.
Junk comments are automatically deleted by the system after a set period of time, which is defined in the Junk section of the Feedback Settings screen. (See "Configuring Junk Handling Settings")
You want to change your system's authentication service to another TypeKey-enabled system.
Set the TypeKey configuration directives in mt-config.cgi and reset your authentication token.
HTML was used in the comments, but you want to limit which tags get displayed.
Use the "Limit HTML Tags" settings of the weblog.
When data is submitted by visitors to your site, that data should not necessarily be trusted. For example, if you are allowing HTML in your comments, visitors to your site could submit malicious HTML, or scripts in Javascript or PHP, to run code on your site. This code could do anything including reading cookies or reading private files on your server.
To protect your site, Movable Type can limit any markup submitted by visitors to your site via comments or TrackBack pings (Prior to MT 3.2 this was referred to as "sanitizing.") This process removes any code that could compromise the security of your site. The sanitization process works by allowing only specific HTML tags; all other tags and scripting instructions (PHP, JSP, Javascript) are removed.
The basic specification format is a string of markup tag names separated by commas. The sanitization process assumes all HTML attributes are not permitted and will be removed. This behavior can be modified on a per tag basis by following the tag name with any attribute names delimited by a space and without a comma. More detail on defining your own specs follows below.
By default, MT permits the following HTML tags and attributes: a
href, b, i, br/, p,
strong, em, ul, ol, li, blockquote, pre. This collection can be modified with the GlobalSanitizeSpec directive in the mt-config.cgi file. The
permitted tags in the system configuration can also be overridden on a
per-weblog basis in the weblog settings. To specify the permitted markup
for a weblog, go to the General Settings screen and use the controls
labeled "Limit HTML Tags".
The sanitization process will also add closing tags to any tags left
open in the sanitized text. For instance, if a visitor to your site places
a <b> tag in a comment and forgets to close it, the
sanitize process will add a </b> tag. If that tag is
left open, all content that follows the comment on that page will be in
bold. It's quite easy for this to happen by accident with even the most
well-meaning commenter, so monitoring markup is not entirely about
security.
To process any MT template tag data use the sanitize global
filter.
<$MTFoo sanitize="1"$>This global filter runs the sanitize filter on the text the tag outputs. If the value of the attribute is 1 (true), the default sanitize spec for the weblog is used. If the value is 0 (false), sanitizing will be turned off for this tag. Designers can define a sanitization spec inline with this global filter with a value other then 1 or 0. For example:
<$MTEntryBody sanitize="a href"$>Here the sanitize filter would strip all markup except for
a with the href attribute from the entry
body.
The default value for sanitize is 0 (false) except for the
following tags where it is treated as true (1) unless explicitly turned
off:
MTCommentAuthorMTCommentEmailMTCommentURLMTCommentBodyMTPingTitleMTPingURLMTPingBlogNameMTPingExcerptFor more details on the sanitize specification format see the article on the GlobalSanitizeSpec configuration directive.
