Drupal

I moved iaslash to AIfIA's new host, so now we should have better performance on that site. ibiblio's MySQL server was extremely slow for some reason.

I also upgraded iaslash to Drupal 4.4.0. Most everything seems to be working ok. notify.module is suffering from a bug, however, where notification emails don't show the base url in links. More on that problem is documented here.

Trackback on Drupal 4.4.0 works nicely. Trackbacks are included among comments. See this entry for an example of how trackbacks appear in Drupal posts. To submit trackbacks to posts on this site, copy the "trackback url" link below the post that you want to cite and paste into your tool's "urls to ping" section.

In my continuing attempts to get different output from Drupal, I've hacked together a module to show all of the entries (well, 5000 entries anyway) restricted to a node type and taxonomy term. What I basically wanted was a way to print my parenting journal to give to my son one day. What I ended up with is this: view_all.module. It's a module that takes two arguments: 1) node type, 2) taxonomy term id. So in this way, I'm able to print out a diary such as this which finds all type blog nodes tagged with taxonomy term #3.

I'm happy enough with the output, but there are improvements I'd like to make and don't quite know how to. For instance, I'd like to be able to use forms on the view_all default page with a drop down (select) menu with node types, and a multiple select menu with taxonomy terms. This way I could generate a printable view via a form. Of course, this would mean I'd have to learn how to use all of those form and taxonomy functions. Ugh.

As usual, these problems will probably remain unresolved in this module. I'm mainly concerned with the output and don't have much time to muck around with the PHP.

While I'm on the topic of alphabetic indexes, I quickly threw together an A-Z index module for this site. I'm sure the way I hacked together the code to hilight the selected letter is inelegant, but it works ... sort of. OK, I didn't know how to skip articles in the beginning of titles, so titles starting with articles a, an, the, etc. will sort that way, i.e. won't use the first non-article word. But, hell, I was happy to figure out what I did and to find the Doxygen Drupal documents. Writing small modules and finding documentation is one good way to understand how Drupal works, by the way.

So if you want to use this module, you can download the source here: alpha_index.module. I don't have a CVS account or know how to contribute modules, so I'll just offer via this blog entry for now. If you have a way to make my code more efficient, please send me a patch!

Incidentally, I'm going to start listing the modules I create on this book page.

Well, I finally got this site upgraded to 4.4.0, but not without considerable pain. What worked in the end was installing a new 4.4.0 and adding content from tables piecemea to figure out where stuff was getting confused. First I loaded node tables, then user tables. It was the user table that was causing problems. Eventually I was able to get the Page Not Found errors to stop appearing when I deleted the #1 user from the old database and just created the new user #1 by registering. Very strange. I guess Boris was on the right path, but it wasn't a role table problem.

One casualty in all this was my familytravelog site. I set up a shell script and cron job to dump the database periodically. I then ran the script to dump it for the first time, then I purged the familytravelog database to try to upgrade that one from scratch. Unfortunately, I used the wrong password in the script, so the dump file was empty. Stupid, stupid mistake. I should have dumped it manually first or tested the script and viewed the dump file. It wasn't until I got the errors from cron that I realized what had happened. Luckily Google cached my 1 review, so I didn't lose the content, but I will need to rebuild that review table. I will remember to back up the structure of the site and then the structure and data before I mess that one up again.

So anyway, it will take me some time to get all my urlgreyhot modules updated. I'll get to it eventually.

Drupal 4.4 has been released. It includes some excellent improvements and additions. I'm looking forward to seeing these functionalities: OPML export, search query logs, and the MetaWeblog API. While I've had a recent CVS version running so I can upgrade my theme, I'm holding off installing for now until I have a good block of time available. I'm running familytravelog on this installation as well and haven't upgraded that theme yet. Very nice work as usual. Thanks, Drupal developers!

It's been over 2 years since we started talking about how Drupal could move beyond simple node categorization. Marco's implementation of the taxonomy.module we specified in that one thread moved the system into a completely new realm, where people can consider using the platform for larger content management purposes. It's even spawned a few good modules for taxonomy browsing, including taxonomy-dhtml.module and taxonomy-html.module. I'm still waiting for someone to consider coding a taxonomy-facet-browser.module, but not sure that will get done unless I try to do it myself (now's as good a time as any to invoke the lazyweb).

Recently, I showed some colleagues a screenshot of the taxonomy.module running on urlgreyhot. It was to suggest a method for handling list order management in a CMS -- the weight option in term editing. See the screenshot I gave them below.

Click the thumbnail above for full image.

I think it's pretty cool that I can refer to an aspect of Drupal as an example of how to implement something in a large system where I work, that's looking for something to emulate.

SixApart's ears must be buzzing with all the talk about TypeKey lately. Mark Pilgrim writes some pretty sharp, lucid and hilariously written criticism of SixApart's plan to provide a centralized comment authorization service as a method for preventing the comment spam. On his Musings blog, Distler's calls it a lot of bother, for not a lot of benefit. Burningbird dives much deeper into why this is not a great idea. Everyone's concerns are valid. Centralized authentication may not be the right way for SixApart to go. I'm happy that Drupal requires authentication on my server. Preventing anonymous and unregistered user comments takes care of the spam issue. While I'm not sure that everyone thinks any kind of authentication is a good idea, it does prevent us from having to deal with comment junk.

In the end, will this matter to users of SixApart's applications? I would say it will matter a lot to people who use MovableType sites and care about this issue philosophically. For one, this means providing even more of your personal information to people you cannot be sure will protect your interests. What happens to all that information if SixApart ever gets purchased down the road? Secondly, why should anyone have to install a blog application relying on some external service for comments? That's really the only reason I like MT over Radio. If I install some content publishing system, I want control of it -- all of it, including the comments. Burningbird talks about more reasons why this doesn't make sense technically, but for me, ownership and control are the issues that would make me opposed.

I'm sure there will be many casual bloggers who won't think about this issue on a philosophical level and will just use TypeKey to prevent comment spam. But this solution is not the one they were necessarily looking for. They just want to prevent junk appearing in their comments (or a good way to remove the junk), not to require their users to go register somewhere for the privilege of commenting.

It's a hard call for SixApart at this point. One way they can go without requiring centralized authentication is to require registration on each MT site. That way the personal information of the commenters is registered with an individual site, but not sent over to SixApart. This does place a lot of burden on the part of the blog reader, and I can understand why people are against that idea. Many of us read 10s to 100s of blogs a day, so all that registration would mean added work. The ease of entering comments on MT sites is often cited by MT blog users as a reason to like MT over Drupal. But that was before comment spam crashed their party.

One question that lies at the heart of the matter for me is whether or not centralized comment registration is a bad idea for weblogs in general. I agree that, for instance, Microsoft's Passport registration was a pain in the ass, but a remotely accessed authentication doesn't seem a bad idea in theory. On the one hand, central control of your information by a commercial entity is probably not appealing to many bloggers. On the other hand, a single registration/login XML/RPC method would mean a flexible sign-on system a bit similar to what we have across Drupal sites. Well not really similar, but from a user perspective it could be similar. Drupal's is more of a decentralized model. The registered login can exist on any site in Drupal's network and not necessarily on one. Gary Murphy talks a bit about how Drupal distributed authentication works in comparison.

I guess it all comes down to trust. Do you trust that if you give SixApart your information that it will always be secure and never used for any commercial purposes?

I used to use Drupal's built in RSS aggregator on iaslash a lot. I used the "blog it" links to move stuff from the aggregator into the blog. But for my own news watching I've been relying on NetNewsWire Lite on the Mac and recently on SharpReader on the PC. SharpReader has a nice threaded feature that I wish NNW had. I remembered that the paid version of NNW came with a built in weblog editor and note taking tool, so I decided to have a look at it again.

I installed the demo version and tried the built in weblog editor. It uses XML RPC to post entries -- make sure you have the blogapi enabled. You can view recent entries and post new entries to your Drupal site from this desktop application. This is not new, but I haven't tried using it with a Drupal site. NNW makes dashing off quick notes on urlgrehot very easy. The one down side, however, is that the categories function doesn't seem to work with my Drupal site. I don't know why that is, but it would be nice if someone helped NNW figure that one out. (Update: According to Boris Mann, this works in 4.4RC) One thought I had was to create a different user and post entries from NNW using that user login so I could separate blog entries into those formally entered via the web site and those entered from NNW. Since you can't see and apply categories for entries you have to edit via the web site after the fact. Separating the blogs entries might make my process of post-entry categorization go a little more smoothly. I could also change my home page module to show the real blog entries in one column, and the thought wanders (from NNW) in a separate column. Not sure if this will work for me yet.

Another con is that rather than entering your title in a form, you have to wrap your title in a title tag. Not a biggie, but am sure that can be fixed. (Update: Tried using the Other/MetaWeblogAPI after the suggestion was made by Boris and Brent from Rachero -- the Internet is cool like that -- and Title field works.)

Have a look below to see how this works:

This is nice for dashing off thoughts. Adding taxonomy terms later is maybe not such a big deal, but this investigation is driven by my need to keep track of thoughts in an easy to use tool. The real thing that is drawing me to NNW is the built in Notepad, which is an outliner that lets you drag headlines over from the aggregator. This works for me as a quick and easy way to capture the headlines I want to look at later, categorized by topic. When I read the full post, I can enter a few notes in the Notepad, then perhaps blog it in the Weblog Editor when I have some fully formed ideas to write about. This might be ideal. I know it takes my link capturing away from the link log on urlgreyhot, but I'm not sure that's a bad idea.

Another thought I had was that NNW could add threading to show which entries referred to each other. SharpReader for Windows does this very nicely, which is why I use that on my work PC. [See this screenshot of SharpReaders' threading in action.] Then I could drag an entire thread to my notepad for later reading and note taking. What would be really fun is if I could then take a bunch of headlines and their attached threads and drag it into OmniGraffle to play at showing relationships between posts. This is the kind of thing Anacubis would excel at. If their tool allowed you to view a set of RSS headlines and relate them (by the reffering URLs in the entries) then you could visualize the connections and perhaps arrange them by dimensions such as date of entry. Would be an interesting experiment probably to get something approaching HP Labs' Blog Epidemic Analyzer.

Anyway, current scenario I have to work with seems serviceable for now. One thing that would be really nice, and probably not hard to achieve, is if this could be better integrated with OmniOutliner. The advantage of using OO is that it allows you to use multiple columns in your outline (sort of like a spreadsheet) and you can enter lengthy notes per outline entry. Right now I can drag headlines to OO and it creates a new item with only the URL of the headline. This is not ideal because it again forces me to take the extra step of typing. Using the NNW notepad lets me organize and arrange the recent items I want to look at, then view and read them later. But at some point, I will want to annotate what I view. Perhaps what it needs is an export function that will work with OO. Or, I suppose, I could try to automate some of this with an AppleScript -- I dread having to learn another scripting language, though. (Update: Brent from Ranchero tells me that the notepad is very well documented and suggested I make a feature request of OmniGroup for the drag and drop functionality. I'm going to play at it a bit more before I do, but I think that's a great idea.)

Upon writing and thinking about this, I think a well-integrated NNW and OO environment would be a wonderful way to do personal information management. I don't see why this can't work better for me than a wiki. Well, except that wikis still have the advantage of being wickedly flexible and easy to use if you give it enough time. OK. I will have to ruminate on this for a while.

Later that day...

Upon further investigation I find that the notepad is actually an OPML file saved in ~/Library/Application Support/NetNewsWire/Notepad/Notepad.opml. When you
import the OPML file into OmniOutliner, it gives you a multi-column formmated outline, retaining the folders (main outline branches) you created in NNW. Very cool. There are separate fields for the feed title, site URL, RSS item URL, RSS item description, rss item title, and notes. Not sure how to enter notes in NNW, though. The output looks like this:

This is really excellent. XML makes integration with OO a no-brain activity. Just import and go. Synchronization would be hard if you modified the OO file, though. What would be really excellent is if you could modify the OPML file via OO and the changes got reflected live in NNW. Also nice would be the ability to create multiple notepad (OPML) files in NNW. All in all I'm really pleased with what you can do without much effort.

[P.S. this entry was created in NNW, and post-categorized and post-edited in Drupal.]

After spending a little time yesterday trying to add links to my weblinks directory and then filing them under my Drupal book pages, I think it's time to start using a wiki. After using the IAWiki and an AIfIA wiki over the past few years, I decided about a year ago to get my organization using a wiki for our internal staff documentation. I've been finding it so much easier to do simple dashing off notes in a wiki, but I also find them pretty good for more complex documents such as for product requirements gathering, meeting notes, etc. I really like Drupal's book module -- it integrates so well with the other node types -- but, I find that it just requires too many steps to for me utilize it well. I found myself spending time creating book pages to organize my topics, then inputting a lot of metadata into the weblink or blog entries to make them findable in the index, then finally "administering"
each node to attach it to a book page. Way too many steps for me to work effectively.

I had seen a few posts on Drupal.org about wiki modules in the past year, but none of them seem to be producing a wiki module that allows you to use WikiWords or some similar method to produce new nodes. So I attempted to use the book module instead for my PKM. After attempting for a while to bring together a lot of loose ends in my KM notebook, I've decided to abandon it and go build it in a wiki. I'm going to be using PHP Wiki PmWiki. I don't think this means I'll be forgoing using my weblinks module (the thing that produces the "recent links" on my homepage), but I will be doing more organizing rather than stream of consciousness posting on the wiki. We'll see how this experiment goes.

P.S. A few people have suggested desktop wiki clients. I've tried both am very impressed by them as early version software. Perhaps the best feature offered by these desktop clients is Exporting.
* Mac: VoodooPad
* Windows: WikidPad