dummied

MT-Planner, the answer to my prayers?

At a glance

This entry was written on September 14, 2005.

The entry prior to this is entitled The limits of MT.

The entry following this is entitled Finishing the CSS Reboot.

There are 0 comments on this post.

This entry has been tagged as Blogs, MovableType, Thissite, Work.

Archives are also available.

After yesterday's entry, I spent a lot of time thinking of ways to stick with Movable Type and somehow pull this off. I like MT a lot, especially since the template tags and template structure in general has always made sense to me (as opposed to say, WordPress). I like having near-total control over how things are outputted when it comes to the XHMTL and CSS. I like being able to essentially design my page and then plug in the tags where I need the content to go with minimal fuss.

So, I thought and I hemmed and I hawed before deciding to try and come up with a plugin of some sort. Now, this would be a big step for me, since I know next to nothing about Perl (despite owning and leafing through a copy of "Perl In a Nutshell" for nearly four years now). I'm starting to get a handle on PHP, enough to where I know just enough to hurt myself and others, but Perl might as well be written in Arabic most of the time.

I went out, bought "Hacking Movable Type," and skipped straight to the write-your-own plugin section before getting totally confused again by terms like callbacks and subroutines. Again, I'm getting to a point where XHTML and CSS are down pat and my knowledge of PHP is growing by leaps and bounds, but Perl ... still Arabic.

Then, I flip to the back of the book to a section about turning an MT blog into an event calendar of sorts—the exact thing I was trying to figure out how to do yesterday. In it, it offers up another upcoming plugin, MT-Planner, which will do exactly what I'm struggling so mightily to find an easy way to do.

Whenever the companion blog/website for "HMT" goes online (and there's certainly no rush given Jay Allen's connections to New Orleans), I can start fiddling with the plugin and heavily customizing the MT interface to simplify things. Unless, of course, they need someone to beta test ...

With the event calendar fiddling set aside, I just need to work on an easier way to upload photos (short of integrating Flickr ... which is still a viable option) and a simple linkslog (which I've been putting off because it is, by far, the easiest thing to rig).

In the meantime, I think I'll slow down on the MT tinkering and concentrate more on designing the pages themselves for the next month or so. I still need to finalize most of the New England Adventures redesign, finish the design for the actual business site, design two more sets of default templates for clients and redesign and relaunch this site itself.

UPDATE: Okay, after an evening spent ignoring my wife and nearly everything else in my life, I finished off "HMT," and have discovered to my dismay that MT-Planner does not appear like it will do exactly what I want it to do. I've already worked in much of the basic functionality of it into the events calendar of NEA (and please do keep in mind that this part of the site, even more than the rest of it, is very much a work in progress ... and yes, I'm debugging the navbar CSS), and would just need to rework some templates to get date-based views instead of the list view I currently prefer for this application.

The chapter in MT dealing with building an events calendar still uses the date stamp for the entry as the date and time for the event. As far as I can tell, MT-Planner includes no way to set a duration of an event. It will, however make recurring events much easier to work with, but no joy as far as duration goes.

Again, pending the future release of the plugin, as far as I can tell from the write-up in "HMT," it will not help if you're wanting to say 'We're going to Grandma's on Tuesday ... and we'll be there for three days."

You could, of course, add in three separate events, one for each day, but that seems like a very unnecessary hack—especially when the most simple, logical and cleanest thing to do is to create a new database table filled with columns such as mteventid, mteventstart, mteventend, mteventdecription, mteventtitle, mteventauthor, mteventurl and mteventcategory.

I know how to work with databases using PHP at this point (haven't had a lot of chances to test out this knowledge in a live environment, but I'm feeling comfortable) and know how to get things into the database using web forms (including menus rather than text entry fields for the start and end times so that formatting, and by association sorting, can be done on a consistent basis).

Of course, another thought that just occurred to me, thanks to inspiration from a Greasemonkey script I stumbled upon last night, would be a sort of mini-app that would fill in an extended entry field with a fully-marked up bit of hCalendar. The problem with the script I found last night is that I can't expect potential clients to a) have Firefox, b) install Greasemonkey, c) install said script and d) come to grips with how to use it once they do have it all installed.

Of course, this min-app plan assumes you can use one of the APIs (XML-RPC, Atom or Perl) in a web-based app. Hey, I'm still a little new to this and the APIs are still slightly murky to me; so, if you know if this can be done, please let me know.

The good thing about doing it this way is that almost all the hCalendar stuff would be contained in one text field, as opposed to being spread across damn near all of MT's text fields. This means users could go back later and fill in the Entry Body field with an entry about the event itself after the fact. Using something like MTOtherBlog, you could then fold back in event entries with the main blog (say, with a category such as events that links back to the events calendar page or a regular category archive page).

Actually, if you can use the API from another web page, that also would make modifying the MT interface practically a moot point if you're not wanting to let people get to configuration settings or templates and whatnot. You could just make a mini-app that looks and behaves exactly as you want it to and then just zip the stuff over to MT to do the dirty work.

Of course, this sounds entirely too cool and logical to actually work in any sort of usable manner. My guess is that you can't use the APIs from another web page (though for the life of me, I can't figure out why you wouldn't be able to).

Please, if anyone knows (and I know at least one person from Six Apart has read this blog before), feel free to correct me.

FINAL UPDATE: Okay. That's what I get for skipping the Perl API chapter. Yes, all of this I mentioned earlier is possible.

I just means that I likely have to learn Perl. Which means I'm essentially making a plugin or two ... which was the original plan all along.

Here goes nothin'.