MI-80 De Oppresso Liber

So with the basic framework in place it was time to start getting core functionality returned, after all a site's worthless if you can't post content. Likewise I had to start making decisions regarding older data made before we got the new server as well as solve some interesting issues regarding Drupal's new flagship release.

To begin I must discuss my personal philosophy with third party modules. Due to the fluid nature of software, especially third party stuff, some projects will eventually be abandoned, that's just how it goes. I'm sure some of the modules that work for 4.6/4.7 will never be ported to work with Drupal 5. Because of this I'm very careful with what modules I use. With the major exception of the Image module, which gives me my galleries, I generally don't use modules that would break parts of the site if I had to abandon them. I normally go for ones which work behind the scenes, ones I could live without on a moments notice. Going along with this thinking, I also take into account that modules add code, which adds attack surface that isn't scanned by as many eyes as the core code or the main Drupal developers, and it's entirely possible the authors of these modules have never coded with security in mind a day in their lives. Because of this, again I aim for modules which normal users don't have direct interaction with. My goal is to make available awesome functionality, but functionality that's “just there”, stuff that people may not even realize they're using. That said my choice in modules can mainly be lumped into two groups, security and “back end magic”.

Due to the nature of this site as well as my personal interests, and the fact many people use the same physical server for numerous purposes, security is huge concern. While the general precautions taken to protect the server are outside the scope of this discussion, I am going to touch upon a few Drupal 5 specific items I've implemented to keep things locked down. First off is the bane of every website which allows public posts: spam.

MI-80's fight against spam involves three tiers, two technological and one human based. The human based is simple enough, users must acknowledge an acceptable use policy when first making their account, this ensures it's within any administrators power to remove unacceptable content after it's been posted. Despite the technology based measures, intelligent hard-working humans still make up the final and most effective anti-spam measure.

From there I take advantage of three Drupal 5 modules. To prevent spam from ever making it in the first place Captcha's are used. Those are the obnoxious anti-spam images you see so often these days which contain letters or numbers, and you have to copy that data to prove you're human. Luckily because computers are very poor at reading distorted text off images while humans are pretty good at it, this has proved a very competent first line. This alone has actually stopped virtually all spam, except through trackbacks. Captcha's however can be annoying to users, so they've been implemented lightly. They're required during initially making an account and for most actions taken by anonymous users, such as leaving comments. However if a real human takes the time to make an account, this check is deemed no longer necessary.

From there two modules, the Akismet and Spam modules, check content after posting. Akismet acts more like a traditional Real Time Black-List (RBL), that is it's a continuously updated list of known spammers. This has a higher likelihood of false positives (blocking legitimate users) than other anti-spam techniques, but is also very effective at catching spam and allows for a queue, so administrators can review caught traffic to help let through false positives. The downside is this requires an API key, handed out free from http://wordpress.com, but requiring registration. I do with they'd open it up at least for non-commercial use, like many email RBL's.

The Spam module works more like SpamAssassin does for email. Though it features similar real-time lists, it also uses several other techniques to identify spam by posting characteristics, websites the post links to, and other traits in the content itself. This has proved very effective at catching trackback spam. Overall through the combination of these three modules, along with some human intervention, nearly all spam is caught before it ever reaches readers eyes.

So what about all the back end stuff? Along with the interface overhaul what would a major upgrade be without added functionality or ease of use?

After looking over, quite literally, every module http://drupal.org lists, I did find several that I like. The autotimezone module automatically adjusts users timezone settings so time stamps are shown in local time, the commentcloser automatically locks threads after a set period of inactivity, and the printable module gives users an option to strip pages of most images and formatting making them easier to send to a printer. In addition a pair of information modules, releasemonitor and systeminfo, allow administrators to gain a quick glance to ensure third party modules are updated as well as giving a general overview of the servers configuration. While all these are great, another module has really stood out for the new features it's given me.

The jstools module includes several features, including a few I've disabled simply because I don't see any real advantage to running them. However this module does grant me the ability to perform in-place AJAX based editing. That is instead of having to open a page, then open its Edit page (now on a separate page), nearly every headline, title, block, and article has a little icon only administrators can see. A single click of that icon brings up the context of that area for immediate editing. That means I can click that icon, change an articles headline, and check out the edit instantly without ever leaving the main page. This is both a time saver and just a great feature to show off over proprietary alternatives to Drupal. That said I did find one minor issue; while enabled for normal users the icon would display even beside content that user didn't own. While they weren't allowed to make modifications, this just led to an amateur feeling, hence why I disabled it for everyone but administrators. It's my hope in the future this module is flushed out more so I can let any user signed in utilize this functionality.

The second day was also when I ran into my first major issue. After moving MI-80 from its old host to the new Sun server, the gallery contents took a dump. It was all there, but previews and scaling weren't being done properly. I found out that resubmitting an image recreated its thumbnail and all, fixing the issue. Due to the time limitations though I had to make a hard call, namely deleting all old galleries. The images themselves are still safe and sound, but until I find the time to resubmit them all by hand they'll be down.

That's about all that I got done on the second day of work. Reviewing the available modules and ensuring a proper install and functionality for each took many hours. The second and third day blurred over heavily, so due the length of this article I'm going to save some of the trouble shooting for the Day Three article. That'll involve finally getting my hands into some code and having to customize my PHP installation to tweak performance, security, and ensure things bloody work like they're supposed to.