Al-Muhajabah's Movable Type Tips

RDF versions of your blog entries

I seem to be on an XML kick lately, lol. The latest thing I've been playing around with is semantic weblog posts. This involves creating an RDF version of your blog entries to support the Semantic Web. Basically, it involves creating an alternate format of the entry that presents the data in a structured way that is meaningful to computers, similar to RSS feeds. An example of how this can be useful is Piggy Bank, a Firefox extension that allows you to view RDF data in a nice format in your browser and do things with it. I started with the template at HubLog, but then decided to modify it based on an article about adding more metadata with Movable Type. I made a few tweaks because of an issue with dynamically-generated pages in MT 2.661. Because I'm using MT 2.661, I used this method for dynamically generating the RDF files. The template is at "rdf" here. Check out the finished product. To get the full effect, you would need to be using Piggy Bank in Firefox (note: what you would need to do is go to the regular entry page in Firefox and click the data coin icon in the status bar. For me, the data from the RDF file is on page 4). Later: I made a few more modifications after looking up the RSS 1.0 specs, especially the modules. Check the template file for the latest.

tag cloud

If you're using tags, you may want to display a "tag cloud" that shows all your tags, weighted by frequency so that the more times the tag is used, the larger it appears (for an example, here's my del.icio.us tag cloud). You can create a tag cloud with MT. I started with this PHP script from Dan and Sherree but made some modifications to it so that it only lists my assigned tag keywords (instead of pulling words from blog entries as in the example), doesn't remove any, displays all tags, and links the tags to their pages (see Using keywords and tags to help visitors find related content). For the code, go to my templates page and scroll down to "Tag Cloud". Please note that the use of the <MTOtherBlog> tags in the template is because I created the template in a different blog than the entries (and their tags) are located in. I did this so that it doesn't increase rebuild time when I create new posts. If you're not doing this (and you probably aren't) then you can remove those tags. And here's the tag cloud page.

close comments and pings, or open them again

For a long time I used a simple PHP script to quickly close comments on my old entries. It doesn't do anything but that; set the comments status on old entries to "close", but I didn't need anything more. However, after receiving some really nasty trackback spam, I decided that I needed a better option. I briefly considered modifying the PHP script to turn off pings for old entries, but then decided to take a look around. I knew that there were some other scripts that did this and I wondered if any of them also closed pings. Sure enough, I found MT-Close2. Just upload it to your MT directory, set permissions to 755, then run it in your browser. You can choose whether to close comments, pings or both, or to open them, select which blogs you want to do it for, and what the cut-off point is (i.e., comments or pings older than x days will be closed). The script is quite a bit slower than the PHP one, especially if you're changing the status for a lot of entries. I also found that I had to run it more than once to actually close all the pings I wanted, because there are several thousand entries in my blogs. It may work better to do it in smaller batches at a time. TypePad already gets hit with trackback spam something terrible and I expect this is something we're going to see more and more in the future. MT-Blacklist already works with pings as well as comments, but since a close comments script is a valuable spam fighting tool, having a close pings script is a good addition to the toolkit. I've closed pings on all my blogs for entries older than 90 days.

desktop clients

There are a number of desktop clients available that will interface with MT. The main purpose of these is to allow you to write blog entries while offline and to subsequently upload them to your site. Many people also like desktop clients because it allows them a more WYSIWYG posting interface, usually including a spell-checker. I don't have a great need for a desktop client because if I'm on my computer I'm almost always online and it's easier to just use the regular MT posting interface. However, I thought I would give one a try. I'm using MT-Client, which was developed by a friend of mine, Earl Dunovant. It seems to work fairly well and I can help him in the development process. It's very easy to set up and configure. If you're interested in a desktop client, you might want to give MT-Client a try, inshallah.

show all comments by an author

Update 3/26: In place of girlie's script, I'm using this variation by Lynda of So Very Posh. It encodes the author's email address. I had been hiding it with the MTObfuscate plugin but I didn't feel very comfortable about making it even that visible. This is something I added awhile back but forgot to post about over here at the tips blog. It's a functionality I've wanted for a long time. Girlie has a PHP script that will create a page listing all comments by any comment author. You can link to this in your comments display and pass the commentor's name and email address to the script (see update above). I'm already listing the number of comments by each commentor using the CommentLeaders plugin, so I hyperlinked this number to the all comments script.

a brief user's guide to mt-view.cgi

I've posted previously about mt-view.cgi. This is an "experimental" script that's been shipping with MT since the release of MT 2.6 a year ago. I'm using mt-view.cgi to create dynamically-generated individual archive pages for Al-Muhajabah's Islamic Blogs, as well as printable versions of my entries, both at Al-Muhajabah's Islamic Blogs and here. The purpose of this entry is to give a little more background on mt-view.cgi and how to use it. Because the script is considered "experimental", there is no documentation. However, some information about how to use it can be gleaned from MT's source files. The way that MT works, it creates static webpages. When a new entry or comment is added, certain of these webpages are rebuilt and updated with the new information. Typically, all index pages and the archive pages where the entry (new entry or commented-on entry) is found are rebuilt. However, if you do something like list recent entries on each individual entry archive page, these will not be updated. Also, if you make a change to your archive templates, you have to rebuild all the archives. This can be a very time-consuming process if you have a large blog with a lot of entries. For these and other reasons, you may be interested in dynamically generating your blog archives. First turn off safe mode in your mt.cfg file by including the following line: SafeMode 0 The dynamically-generated versions of your templates can be accessed as follows: Index templates: http://path.to.mt/mt-view.cgi/blog_id/filename.htm Category archives: http://path.to.mt/mt-view.cgi/blog_id/section/category_id Individual archives: http://path.to.mt/mt-view.cgi/blog_id/entry/entry_id/template Daily archives: http://path.to.mt/mt-view.cgi/blog_id/yyyy/mm/dd Weekly archives: http://path.to.mt/mt-view.cgi/blog_id/week/yyyy/mm/dd Monthly archives: http://path.to.mt/mt-view.cgi/blog_id/yyyy/mm Replace path.to.mt with the URL of your MT directory. Insert blog, category, and entry IDs as appropriate. Yyyy stands for the four-digit year, mm for the two-digit month, and dd for the two-digit day for the by-date archives. Filename.htm refers to the output filename of the index template you want to display. Template refers to the individual entry archive template you want to use. This option requires the use of the custom dynamic pages hack. If you are creating links to the dynamically-generated pages in your templates, you can make use of MT tags to supply some of the data. Note that if you use PHP in your templates, the PHP code will appear unparsed in your dynamic pages. This is because PHP and CGIs don't play well. See my entry on my dynamic individual entry archives for a workaround. This only works on individual entry archives and not on category or by-date archives; these would need additional hacks. In addition to having dynamically-generated archives, you may wish to have dynamically-generated index pages; you can see this is an option above. You can easily get around the PHP problem by creating a new index template that doesn't use PHP or to include the results of mt-view.cgi in a PHP page (the workaround mentioned above). No hacks are needed here. Why might you want to do this? Many people like dynamically-generated indexes because they want to display entries or comments from the database in any combination without having to create a static page for each one. If you want to do this in MT, take a look at the MT-Dynamic plugin. This allows you to add arguments to the mt-view.cgi filename to display entries in a certain way. For instance, to use your main index template but only display entries in a certain category, you could use the following URL: http://path.to.mt/mt-view.cgi/blog_id/index.htm?category=category In the template, you would have to replace your <MTEntries> container tags with <MTDynamicEntries> in order to get this functionality. The following arguments can be used in the display of entries: entry_author, category, lastn, dyn_offset, days, recently_commented_on, sort_by, sort_order. You can also do this with comments; here you might want to use dynamic individual entry archives rather than an index page. Replace <MTComments> with <MTDynamicComments> in your template. You can use the following arguments: start, show. These are similar to lastn and offset but make better sense with the way comments are displayed. I have not yet implemented MT-Dynamic but am looking into ways that I might do so, inshallah.

comment subscription

The blog author gets an email notification whenever a new comment is posted on their blog. But, often, commentors themselves would like to be notified when new comments are posted to entries that they're monitoring. The venerable solution is the Scriptygoddess subscribe to comments script. Unfortunately, because of the way that the script is set up, it doesn't integrate very well with MT-Blacklist. Specifically, your subscribers may still receive notifications about comments that are rejected by MT-Blacklist or for other reasons. An update to the Scriptygoddess script blocked notifications on attempted comments from blocked IPs, but integration with MT-Blacklist was still lacking. There are two main options for a successor to Scriptygoddess's script, MT Notifier and EZ Subscribe. I decided to go with EZ Subscribe because it required minimal changes to my existing Scriptygoddess-based setup. If you're using Threaded Comments, as I am (or any other plugin or hack that adds new fields to your comments form) you will need to hack sub-to-com.cgi to include these new fields. Look for the section that contains this code: <form method="post" action="$script_name" name="comments_form"/> <input type="hidden" name="entry_id" value="$form{entry_id}"/> <input type="hidden" name="author" value="$form{author}"/> <input type="hidden" name="email" value="$form{email}"/> <input type="hidden" name="url" value="$form{url}"/> <input type="hidden" name="bakecookie" value="$form{bakecookie}"/> <input type="hidden" name="text" value="$form{text}"/> Add new lines with the names and values for the extra form fields (note: I've contacted the developer about this issue and he hopes to provide easier configuration in future releases). Upload sub-to-com.cgi to your MT directory and set permissions to 755. Now point your browser to it to read the documentation and do configuration. You can import all your Scriptygoddess subscriptions very easily. Once you've configured EZ Subscribe, go into your blog templates. On the comment listing template, the comment preview template, and your individual entry archive template (if you have a comment submission form on it), change the URL in the "action" element of the form (the documentation shows exactly what to do) from the Scriptygoddess file to sub-to-com.cgi. Be sure to do this for both forms: the subscription with comments, and the subscription without comments. If you've changed the name of your comment script, you will also need to pass the new name to sub-to-com.cgi. Again, the documentation explains what to do. After this, you should be good to go! You have the same functionality as with Scriptygoddess but can now rest secure that your subscribers won't be receiving notifications of spam or other blocked comments.

killing comment spam, part 3

One thing that many victims of comment spam have noticed is that the spam is often posted to old entries. There's an easy way to prevent that from happening: automatically close comments on old entries. I use the script to close comments on all entries older than 60 days but you can set it to any span of time that you would like. Another solution that's often suggested is changing the name of the CGI script that runs the comments, which is called mt-comments.cgi. As it happens, I've been doing that since July of 2002. It didn't have anything to do with comment spam at that time. Phil Ringnalda developed a plugin called CommentSwap. The idea behind CommentSwap is to prevent Google from indexing blank comments pages. What it does is check if the comment count on an entry is zero. If so, it inserts a link in your templates to a copy of the comments script called mt-nocomments.cgi. Only if the comment count is equal to or greater than one does it create a link to mt-comments.cgi. You can then edit your robots.txt file to tell Google not to index mt-nocomments.cgi Of course, we now discover that spam-bots looking for links to mt-comments.cgi won't find them on your comment-less entries (which have links instead to mt-nocomments.cgi), thus providing a small measure of protection to those entries.

add smilies to comments with ease

Many people like to make smilies available in their comments in a way that's easy for commentors to use them. One way of doing this is to use the Regex or Macro plugins to set up a shortcut code that is used by commentors and transformed into <img> tags when the comment is published. However, there's an easier way. Lazyman's smilies is a PHP script that you can call in a pop-up window from your comments. It provides clickable smilies. But what really makes it great for the lazy blogger (man or woman) is that it automatically grabs all image files in its directory and adds them to the pop-up. No need to add code whenever you want to add a smilie. Also, since it inserts the <img> tags right into your comments, the smilies will show up in live comment preview.

live comment preview

Live comment preview allows commentors to see what their comment will look like as they type it. It's a neat trick, although it works best if you have your comment posting form on the individual entry archive page or otherwise do it from a full-size window rather than in a comments pop-up. Start here, but modify it according to this if you have "convert line breaks" on as most people do. The modified version of live comment preview will fake the line breaks. Otherwise they don't show up and when people try to insert them, it messes up the actual published comment.