Drupal

Technorati's tag indexing has gotten me interested in having a full Atom feed for this site, including categories. So I downloaded the latest Atom module for Drupal 4.5 and then used Walkah's patch to modify the module to generate a full Atom feed. Then http://urlgreyhot.com/personal/atom/feed stopped working. Oddly enough, when I commented out the cache portion it worked again. So now I have an atom feed with categories here: http://urlgreyhot.com/personal/atom.xml

I recording the steps I took to do this because this module is not documented (as is sometimes the case with Drupal modules). Good luck:

1) Downloaded the atom module.

2) Downloaded atom.diff and saved to modules/atom/ directory.

3) Executed command in Unix terminal window: patch < atom.diff

4) Checked the module's output at http://urlgreyhot.com/personal/atom/feed

5) Created an alias via the menu "Administer > Url aliases" from atom/feed to atom.xml.

Thanks to Kika for providing the module and to Walkah for the patch. This is why I now send people who ask me if I freelance over to people like those Bryght guys.

Who has the time to babysit their blog? 3 times today I had to go to the MySQL command line to delete trackback spam. I got over 500 trackback spams in one day. Stupid poker sites. Go away. I'm convinced now that Anonmyous Trackback and Comments are just broken.

This was a test of the nofollow module and walkah's filter patch. Almost works. Doesn't add rel="nofollow" to the URL linked to Anonymous users. Of course, this doesn't prevent comment spammers from attacking the site.

Because anonymous commenting is broken and I'm tired of dealing with comment spam, I've turned it off. I still maintain that the best way that I know of presently to make anonymous commenting unbroken is to use a captcha.

I installed the beta version of flickr.module, with the help of creator Jonas Luster. This module uses the Flickr API to display the sets (albums) from your Flickr account. I also added the javascript at the top to show my last 5 uploads.

The beta version works for CVS versions of Drupal, but I installed it on my 4.5.1 system and it's working nicely. Check it out in the photos section.

A module to incorporate some Flickr functionality into your site. Each site must have its own API key, and can have only one Flickr account associated with it. Once installed, the module exposes your photosets (must have at least one) to /flickr and gives you a convenient local page with all images in that set. It also allows the use of tags inside nodes to display flickr images.

I've had anonymous comments configured on the site for the last few days and have gotten more comments posted in that period than in the last few months. There is no doubt in my mind that the new anonymous comment features are a great improvement and provide fewer obstacles for posting comments on a blog. However, it's isn't quite done yet. A couple things are missing.

The spam.module is a nice module to install if you have anonymous comments set up on your blog. However, it appears to me that another effective way to prevent spammers from filling your comments would be for the captcha.module to also be used with anonymous comments. Captchas are those slightly distorted images you see on registration forms that you have to copy into an input field in order to prove that you are a human and not a robot entering data into the form. James Seng did this on Drupal 4 Bloggers. Apparently they're not entirely foolproof because I've heard mention of OCR being used by spamming robots, but I would guess they're effective enough most of the time.

A glaring omission is the absence of a "Remember me" function for the anonymous commenter. Users of MT have long had the ability to click a "Remember me" checkbox so that each time they return to a site, their Name, Email and Homepage address are automatically filled into the comment form. The MT method used JavaScript to set a cookie that is read back into the form inputs. This should be a requirement for anonymous comments. One thing I don't like is having to type the same thing over and over and I surely don't want to prevent people from commenting on my site because they're forced to work too hard. And by the way, I don't think a solution is to require users to enable the automatic form filling features of their browser.

I've put in a feature request at the Drupal site and I hope that someone will take the issue for the next release. All in all, I've been extremely pleased with Drupal 4.5. The bug fixes were much needed and the subtle usability enhancements are a step in the right direction. But it's core usability issues such as this one that seem really minor, but that really impact user experience that I want Drupal to improve the most.

For some reason I had forgotten that more conventional anonymous commenting -- the kind where people need only enter their name and email address rather than having to register on my site -- was added as a feature to 4.5. So I've turned it on. Up until now, I haven't had problems with comment s p a m because I required people to register. But I've always hated that people had to register on this site in order to leave a comment, especially since I never know if the "remember me" cookie settings work in every scenario. We'll see how it goes. I like how WordPress provides one of those authentication boxes where you have to enter the characters shown in an image to prove that you're a human. That seems a very good solution to warding off the s p a m bots.

Derrick sent me a very nice rewrite of the A-Z index module (alpha_index.module) used on this site. It's much more elegant than what I hacked together. Derrick's version also filters out the articles A, AN, and THE and files titles under the next word appearing after the article -- a feature I really wanted, but didn't know how to implement. View the module source code here.

Thanks, Derrick! You rock. Next, hopefully someone will hear my lazyweb request for a KWIC index module.

Jeffrey Veen doesn't like open source CMS (OSCMS). He succintly states the most common of purpose of a content management system -- a statement that I agree with completely:

Ultimately, a content management system should be designed to empower writers and editors to do content creation and maintenance themselves. I'd like to see it take a step further: empower designers, information architects, and site owners with the ability to make the CMS work for them.

I couldn't agree more. These are the primary purposes of content management systems -- to allow content authors and managers to publish and manage content. Problem is many OSCMS are designed by and for techies. There is often not enough attention paid to designing for typical content managers, who are not usually technical people, but are people who want to work with a content publishing and management tool without needing to know how things work in the background.

The "of and by the programmers" characteristic is almost an inseparable part of most open source projects. The reason is obvious really. Open source projects are often created to fill a developer need and to provide a community for building the project together. The community codes what they want in order to serve their specific needs as developers who will use what they produce. OSCMS are therefore often unrefined tools until you have a programmer or consultant customize it to suit your needs. And although this probably generally true of OSCMS, I think these systems can be made to be more content manager-friendly without too much effort. But making it friendly enough for everyone seems to be difficult for developers of open source projects, and I can understand why they might see little incentive for doing this.

Take Drupal, for instance. At a high level, a few of us -- including some very talented and well-known web designers -- outlined how certain areas of Drupal could be made more usable. We documented these suggestions on my wiki. Some people wireframed and flowcharted the interaction of some of the components. Some of these suggestions seem to have made into the next release, but apparently not all.

I guess it's hard, with a community-driven effort, to simply make a suggestion like, "Installation should be driven by a wizard following this scenario" or even "Here's the flow and wireframes of the corresponding UI for function x. Go make it happen.". It's just hard to keep all these issues in mind. Dries made an offer to Jeff that he would get behind what Veen might suggest in a design review and make those changes happen. I'd like to see that happen. But I don't know. Adaptive Path exists to make money. Veen would have to buy into the idea that something like Drupal could be a tool they can exploit in their paid projects. But it should be obvious that getting behind it's design and helping guide how it works will mean they get to use a CMS created to suit the needs they try to meet in customer projects. He's first gotta believe that it's a tool worth backing.

I don't have a pitch for Drupal. I use it because I think it works well and I know how to configure most of what I need. Anything more and I usually get some decent answers on the Drupal forums.

Here's an example. I've been working with a customer to develop a document library. Take a look at these wireframes for the project (PDF, 84K) and then come back here. Really simple requirements for this project. Using Drupal 4.5, users are maintaining a repository of support documents. So far so good. These people hated using QuickPlace and we're finding that Drupal is a capable replacement. We can make it more usable, but the reason it's a viable tool is because the required functionalities are there. But it won't be usable until I get under the hood and customize how it looks and feels to the end user.

In my work as an in-house developer and IA, I've generally found that tools unfortunately *do* require both a designer/IA and a programmer to make them usable. They're very often created to suit some common-deonminator of needs, and therefore don't suit any specific needs very well until they're customized. This is perhaps one of the reasons groups with a programming staff might want to build versus buy. What you have with some of the OSCMS available to you out there are merely platforms -- they're only lumps of clay waiting to be molded into things of utility. That said, I believe a lot of the things that Jeff mentions are useful but perhaps not universal. Looking closely at my users' needs (in my case above I look at public users, moderators and administrators) helps me decide where to tweak the tool to make it more usable depending on levels of access (roles).

I'm upgrading this site to Drupal 4.5 release candidate. You can expect things to break.

Thanks to all the developers who worked on the 4.5 RC. So far it looks very good and many of the usability suggestions seem to have made it in.

I upgraded all of my drupal modules to work with 4.5. Wasn't painful at all. The Drupal handbook has instructions for converting 4.4 modules to 4.5. The only thing I had to modify was the _link functions to use _menu. The doxygen entry for hook_menu was useful for this. There's still a few bugs I haven't figured out. For instance, the title is really wacky on section.module. Check my code. See anything I'm missing in section_menu() ? The title is doing some wierd things that I don't understand.

Will get to the skinner.theme at some point later on. I'm considering discontinuing the skinner.theme. See Ber's Theme Switcher for an interesting way to implement skin switching in Drupal. Only drawback is that the skin selection doesn't persist after the browser is closed for users that aren't logged in.

For now, I'm busy installing/configuring my first Drupal system at work. The new upload/attachment functionality built into Drupal rocks. I'm looking forward to seeing how node-based permissions will work. I plan to hack a node module to track hits to downloads per user so I can create reports showing who has downloaded what. That should be an interesting project, though I'm unsure if I will be able to figure it out alone.