In unrelated news, Jacques Distler recently observed that the search function in MT is fairly resource intensive and could be a target of abuse by launching multiple concurrent searches. To mitigate that potential, he has released a patch—also available as a drop in replacement—for the search module that limits the number of concurrent searches allowed. I have followed his example. I doubt it will affect anyone as at most I have ever seen two possibly concurrent searches happen in the past months log files (grep is your friend).
]]>Recently the comment spam problem for MovableType users escelated when some script kiddies released an automated comment spammer. The site hails it as:
“the first integrated solution for testing Movable Type blogs for working anti-spamming features”
Six-Apart, the team behind MT(MovableType) released a modification to enable comment throttling–limit the number of comments allowed to be posted in any given period of time–which Jacques Distler improved upon with a further patch which enabled even tighter controls on commenting including IP banning based on comment frequency — they have all been installed here as well.
It seems now however that the poor loser is mad at Jacques for linking to the FloodMT web site. In the comments to Jacques post, One Down a “DV” complained that Jacques was linking to the site and threatened to redirect all visitors refered from Musings to “Goatse” or “Tubgirl” — the two most popular of a slew of disgusting/shocking images out there on the net.
So to spread the fun a little bit once again here is the crapflooders website, or at least the “tool” that he uses: FloodMT
If you are running MT and allow commenting or trackback pings I suggest very highly upgrading to MT 2.661, then applying the patches provided by Jacques to further tighten comment throttling and — to combat the latest annoyance, trackback spamming — trackback throttling.
If you’re a programmer also, you might want to keep an eye on the latest developments at FloodMT to keep abreast of their latest developments to stay, if not a step ahead, then at least only a half step behind their developments.
Edit: 23:55
More of the background from this spate of crapflooding and the history of Dv along with FloodMT and FloodMT.perl (along with a server that seems to be having uptime issues) is available on Phil Ringalda’s site in the post and comments for Throttling Down and Confidential to my crapflooder. Phil is how I found the music of Kris Delmhorst, which I have really been enjoying, so a big thanks for that one Phil.
Damn, now I’m 36.
He also added a great tag,
Currently viewing in preview mode
to your Individual archive Template in MT. When previewing an entry you get the warning message (in bolder red etc) but when it is published those tags are ignored in the build process and the page appears without the warning. Great!
Unfortunately it appears—from my feeble attempts at least—that
< $MTEntryBody apply_macros="1" check_spelling="1"$>
< $MTEntryMore apply_macros="1" check_spelling="1"$>
< $MTEntryBody apply_macros="1"$>
< $MTEntryMore apply_macros="1"$>
The preview page looks exactly as I wanted it to, it has the MT-Speling marked entry and extended entry followed a check-box and suggested spelling corrections, with the check-box to turn on or off the MT-Speling visuals. Unfortunately the published site version, well… it’s sort of missing a body and extended entry. It seem to hit the tag.
Right now this entry will be a bit of a mystery to anyone who looks at it on the individual archive page, but I’m going to leave it this way for a day or two…
To make the plug-in work with the
Recently the comment spam problem for MovableType users escelated when some script kiddies released an automated comment spammer. The site hails it as:
“the first integrated solution for testing Movable Type blogs for working anti-spamming features”
Six-Apart, the team behind MT(MovableType) released a modification to enable comment throttling—limit the number of comments allowed to be posted in any given period of time—which Jacques Distler improved upon with a further patch which enabled even tighter controls on commenting including IP banning based on comment frequency—they have all been installed here as well.
It seems now however that the poor loser is mad at Jacques for linking to the FloodMT web site. In the comments to Jacques post, One Down a “DV” complained that Jacques was linking to the site and threatened to redirect all visitors refered from Musings to “Goatse” or “Tubgirl”—the two most popular of a slew of disgusting/shocking images out there on the net.
So to spread the fun a little bit once again here is the crapflooders website, or at least the “tool” that he uses: FloodMT
If you are running MT and allow commenting or trackback pings I suggest very highly upgrading to MT 2.661, then applying the patches provided by Jacques to further tighten comment throttling and — to combat the latest annoyance, trackback spamming—trackback throttling.
If you’re a programmer also, you might want to keep an eye on the latest developments at FloodMT to keep abreast of their latest developments to stay, if not a step ahead, then at least only a half step behind their developments.
More of the background from this spate of crapflooding and the history of Dv along with FloodMT and FloodMT.perl (along with a server that seems to be having uptime issues) is available on Phil Ringalda’s site in the post and comments for Throttling Down and Confidential to my crapflooder. Phil is how I found the music of Kris Delmhorst, which I have really been enjoying, so a big thanks for that one Phil.
Damn, now I’m 36.
no language attributes allowed in XHTML 1.1
name attribute is only allowed in
id attribute
Get rid of
Wrap all
and tags in block-level elements.
I’ll have to scope out Jacques Distler‘s entries at Musings to review the changes needed to MT(Movable Type)’s templates and comments to maintain validable pages. I think I will have to—just to make it more fun—follow the W3C(World Wide Web Consortium)’s recommendation to serve XHTML 1.1 as @application/xhtml+xml@ as well. Luckily Jaques has been there, done that and written up a nice How-To. This entry is really just a “note to self” of sorts, to remember the links and resources I may need during the conversion.
]]>index e.g.:
< $MTArchiveDate format="%Y/%m/%d"$>< $MTEntryTitle dirifyplus="sld"$>/index
Why did I do this in the first place? Well the short version of it is future-proofing the URL(Uniform Resource Locator)’s as well as providing a cruft free and heirarchal URL that are “hackable” by the user to climb back up—one level at a time any number of levels—to the root. It was Mark’s article (cruft free) that I originally followed as my blueprint. Unfortunately there are some downsides, although very minor, to the way it was done. First off the web reporting software chokes on the fact that there is no extension on the file. In reality this is the fault of the reporting software, but it is something I have no control over either. Minor nuisance, but there. The larger issue for me is that mod_gzip is not consistently delivering the html documents as compressed to clients, even modern browsers. Again a minor nuisance, and this could easily be something that I could find a solution to but it seems that the answer is just to put the .html back on the files—or .php or .shtml or…
That’s the nice thing about Dave’s solution, since it puts each archive entry as a directory index, you still get URL’s without the extension. In fact the only visible difference in the URL and the site, is the trailing “/” behind them—which is added by the server automatically. The same URL that used to point to an html file (albeit masquerading as a directory) now points to a directory of the same name. The server technology is not being broadcast, and the .html is saved from being transmitted with every request. If I change technology next month the URL will remain the same, while the file extension change and I make one change (possibly) to the apache directives to add the new index.xyz as a directory index format. Yet I now get reliable mod_gzip compression across the board and the statistics packages don’t choke on the the extensionless files. Of course it took a little work to actually make the transition.
Since the existing entries were without any extension, I couldn’t just make the change in one rebuild. Instead I used MT’s template feature to create an “archive” page that had only the links to each page–one link per line. The template (which I named “exporter” and set to save to a file of the same file name) consisted of 4 tags:
<mtarchivelist>
<$MTArchiveLink$><br />
</mtarchivelist>
Rebuilding this template will give you a list of all the URL’s to your articles:
http://heupel.com/eclectic/2003/12/29/black-on-black-field-of-beans
http://heupel.com/eclectic/2003/12/28/bh-video-catalog-porn/
http://heupel.com/eclectic/2003/12/27/the-trick-is-to-keep-moving/
http://heupel.com/eclectic/2003/12/27/riaa-silly-dvd-jon-and-privacy/
http://heupel.com/eclectic/2003/12/24/smile-daddy/
http://heupel.com/eclectic/2003/12/24/sco-gets-another-ahole-for-christmas/
...
A couple of quick substitutions in vim, regex or whatever and you have a shell script ready to remove the old entries and create empty directories in the proper location with the same name. At this point rebuilding the site will put the new “index.html” files for each individual entry in the proper place, along with rebuilding the category and other archives. Nothing should have broken even though all the links are now for directories with the trailing “/” since the original setup was so well thought out—by Mark that is. Of course it remains that way too, ready for the next change of servers.
I also added Dave’s other MT plugin, Short Titles. This plug-in essentially does what Mark uses Brad Choate’s MT-If-Empty plugin to do. While Mark’s solution is infinitely more flexible, Dave’s plugin fits my needs perfectly. Just as with Mark’s solution if there is a key word, or keywords for an entry they can be selectively used to create a “slug” title. If there are no keywords, or none set off by using brackets then the MT Entry Title gets run through dirify before being written out as the file (well directory in this case). I decided it was time to start using slugs because some of the titles I like to use can get a bit too long for a useful URL. However I want the URL’s to be human readable and understandable. Some folks use the entry ID, or the first X characters or words of the entry title. Unfortunately that still puts some constraints on titling an entry, Using either Mark’s method or Daves plugin—unfortunately both require a plugin—you have far greater latitude in both titling and the length and decipherability of the slug title.
]]>I debated creating a PHP / MySQL solution from scratch of modifying one of the other systems out there, but the build up time would have been to long to build, test, refactor, test etc etc before I could even begin building a clients site in it. I would really rather have the luxury of building a more custom application in a lot of ways, but I am finding that MT fits most of the needs right “out of the box.” Where it doesn’t quite work I have already found answers and plug-ins in the very active community.
So why am I writing all of this, especially for an audience of two, both of which understandably don’t care about most of what I just said?
Mostly because I am trying to document my process to some degree. While I will continue to update the site with personal opinions etc. I will also add to the MT category those bits that I find interesting or useful. In particular I will add entries with a keyword of colophon that relate to the architectural design of this site. For instance creating yearly archives. While Brad came up with it quite some time ago, his solution was extremely useful to me now, as I sought to solve the exact same problem. If I find a solution or plug-in I will enter it in the MT category with a keyword of colophon. If I create a solution to an issue in the design of the site, or a solution to a issue with getting MT to do what I want/need it to do I will likewise post it. If for some reason I stop using a solution/plug-in I will annotate the original entry to show it is no longer being used and why.
This way I have a running diary of the design of the site. It should be relatively easy at a later time to write up a comprehensive how-to or a detailed colophon directly from these entries. As (if) the site find wider readership, others can benefit from my journey.
]]>