Geekery

That was a test, and that was only a test. Hopefully it was at least an amusing test — I was playing with the MovableJive text formatting plugin for MovableType 2.6. I probably won’t use it very often, but it could be fun from time to time.

Unfortunately, at this point, the plugin mangles URL’s (see the comments to the previous post) so I can’t use it to post and link anywhere. With any luck that will be corrected at some later point, though…

This is a test, and this is only a test. Hopefully it will at least be an amusing test — I’m playing with the MovableJive text formatting plugin for MovableType 2.6. I probably won’t use this very often, but it could be fun from time to time. Included filters are Jive, Texas Drawl, Cockney, Swedish Chef, Valley Girl, German Accent, and Hunting Wabbits.

(Via the MT Plugin Directory via Mark Pilgrim)

Two important (in my world) software upgrades hit the ‘net today: Mac OS X was upgraded to version 10.2.4, and MovableType was upgraded to version 2.6. Both are installed, and both are working like a charm.

This is complete geek-speak, but my favorite change in MT v2.6:

MT::Util::html_text_transform (the default “convert line breaks” code) will no longer add <p> tags around paragraphs that start with certain HTML tags (pre, table, ol, ul, pre, select, form, and blockquote). (Phil Ringnalda)

Since I use <blockquote> a lot when I’m posting links to other sites, this will save me some headaches.

Thanks to a comment answering a question of Jonathon’s, I’m about 95% sure that the cookies for djwudi.com are finally being set correctly, so that the comment forms will actually remember your information, instead of just teasing you with the possibility that they might remember one day if they feel like it.

Turns out it was just six characters I needed to add to the JavaScript code in the template. Sheez.

In Scott’s words from his post on Jonathon’s page (emphasis mine):

The cookie code does not pass a path, so the browser by default make the path that of the calling page.

In other words, the code really was setting the cookies — but only for one page at a time. This led to some of the confusion, where both Dyanna and I thought it was working at first, then it wasn’t working again. We’d leave a comment and the cookie would get set for that page, so when the page reloaded, our info was there, and it looked like it worked. But then, as soon as we went to another page, the info was lost again.

Luckily, the fix is easy enough:

If you want the cookies to apply to the entire site, you can adjust the code to pass the path ‘/’ as a parameter…

function rememberMe (f) {
var now = new Date();
fixDate(now);
now.setTime(now.getTime() + 365 * 24 * 60 * 60 * 1000);
setCookie('mtcmtauth', f.author.value, now, <strong>'/'</strong>, HOST, '');
setCookie('mtcmtmail', f.email.value, now, <strong>'/'</strong>, HOST, '');
setCookie('mtcmthome', f.url.value, now, <strong>'/'</strong>, HOST, '');
}

function forgetMe (f) {
deleteCookie('mtcmtmail', <strong>'/'</strong>, HOST);
deleteCookie('mtcmthome', <strong>'/'</strong>, HOST);
deleteCookie('mtcmtauth', <strong>'/'</strong>, HOST);
f.email.value = '';
f.author.value = '';
f.url.value = '';
}

The bolded bits in the above code were the only parts of my individual entry template I had to change — once those were fixed, I rebuilt my site, and things actually seem to be working now!

The reason that this problem doesn’t affect most people is that by default, MT stores all archives in a single directory. Since every archive page is pulled from the directory the cookie is set for, it works fine.

I’ve adjusted my archives to fall into directories based upon when they are posted — for instance, this entry will end up in the /archives/2003/02/10/ directory. So, when the cookies are only set for one directory at a time, it causes problems. By adding the slash to the above lines of JavaScript, the cookie is set for the entire site, and will be read for every page, no matter which directory it lives in.

Much better.