I just installed the Drupal Administration Menu contributed module, and I really like it. When you are logged in and have administrative privileges, it provides a small menu bar with drop-down menus and submenus at the top of every page in your site. It provides quick access to every admin function I’ve needed, and really streamlines the process of making changes to the site.
Here’s a screen shot of what it looks like:

In that respect, I rank it up there with the Taxonomy Manager module, which also provides a major productivity boost.
Update: Apparently I’m not alone; Administration Menu is among the modules included with the Acquia Drupal distribution. I think that lends quite a bit of credibility to this module … if my own recommendation didn’t provide a tipping point for you.
Now that I’ve upgraded to Drupal 5.10, I’ve discovered I can no longer post from MarsEdit. I get this error upon submitting a post via XML-RPC, via Drupal’s core Blog API module:
You either tried to edit somebody else’s blog or you don’t have permission to edit your own blog.
Annoying things like this happen all too often with Drupal. I’ve had enough problems with the core BlogAPI and (practically required) Pathauto modules that I should really consider whether the Drupal platform is worth it. It feels like updates for modules are never really tested before they are put out, and so problems like this slip through.
I haven’t figured out what the problem is yet, but hopefully I’ll get this fixed soon. I hate posting through Web interfaces if I can avoid it.
And, just to be clear, all I did was update to the current Drupal 5.10 via my normal routine. I kept my “settings.php” file and my “files” and “sites/all/modules” directories, but everything else is from Drupal 5.10. I ran the “update.php” script after the upgrade. No settings were changed in MarsEdit, which worked before the upgrade.
Update 9/20: I looked in the “Access control” page of my sites’ Drupal Administration section. The “administer content with blog api” had been turned off for my user role. I re-enabled it tentatively, and now posts from MarsEdit appear to work again. I’m not sure why the “administer content with blog api” permission would have been disabled in the Drupal 5.10 update, but that’s what appeared to happen to me.
I was blocked from my own site today by Bad Behavior, for both loading pages and sending XML-RPC from MarsEdit. There is some self-help for this kind of problem, which I followed when I had a chance.
I didn’t see any of my IP addresses in my site’s spam logs, which meant something else was probably wrong.
It turns out there was an update to the Bad Behavior library, which now stands at version 2.0.11. It was updated December 6, 2007. And the description:
“Within the past two days users have found themselves blocked from their own sites while using recent versions of Bad Behavior. A third party blacklist which Bad Behavior queries recently began sending false positives for any IP address queried, causing everyone using Bad Behavior to be blocked. This issue is fixed in Bad Behavior 2.0.11.”
Once I downloaded and installed that library in the Drupal Bad Behavior module, I was able to access my site and use MarsEdit successfully again. Whew!
Oh. My. Gosh. I heard about and installed the Taxonomy Manager module for Drupal 5 — which was a just-completed Google Summer of Code 2007 submission — and it is fantastic. It makes managing taxonomy in Drupal so much more fluid. No, it makes taxonomy management possible.
It’s not perfect, and there are little visual oddities in the version I installed, but Taxonomy Manager is so much better than the normal user interface for taxonomy in Drupal core that I can’t see using anything else now. I’ve been spoiled.
Hearing about stuff like this — even if it’s nearly a throwaway comment by Angie Byron, almost lost in all the other voices on episode 48 — is exactly why I listen to the Lullabot Drupal Podcast. Thank you.
Oh, and sometime, I will look into free tagging. Gotta do that. Love it on del.icio.us.
I keep forgetting how to construct the very useful combinations of taxonomy terms in Drupal. I feel as if these tricks are not as well documented, or perhaps exposed in the user interface, as they could be.
There are two forms I’m aware of, at least with the taxonomy module in Drupal 5.2.
The form with taxonomy termids separated by a comma gives an overlap of the terms. It’s the equivalent of asking for nodes which contain both the first time and the second term.
/taxonomy/term/1,2
The plus sign form results in a list of nodes with either the first term or the second term.
/taxonomy/term/1+2
I don’t know how far you can extend the list of terms, but I’ve personally tried as many as five.
Unfortunately, I’m not aware of a good way to find what terms match up to which termids.
Also, although you do get an RSS feed indicator, it directs to the RSS feed for the entire site. (I thought somewhere that I’d found a way to get a unique RSS feed for each such query.)
You can also specify the depth, as per this Drupal support posting.
/taxonomy/term/termids/depth
… where the termids, of course, are the termid numbers, as seen above, and the depth is how deep you want to go in a nest hierarchy of taxonomy terms. For depth, 0 is the same as not specifying a depth and “all” includes all subterms. Any number in between limits the depth.
I’m not even sure what the utility of trackbacks are, but I have the feature enabled on my Drupal site. Unfortunately, I discovered that this made the site susceptible to junk trackbacks.
Given that I only vaguely understand what they’re for, I should probably just disable the feature altogether. When the concept first came up, I was running Userland Manila and trackbacks didn’t make sense to me then — let alone now.
The response I’ve taken tonight is to enable a spam filter for Drupal that will scan trackbacks. I’ve also taken the liberty of deleting all of the existing junk — most of the identifiable source addresses came from Russia — to prevent these many tiny messages from clogging up my database. One set of queries, I kid you not, deleted over 3,000 database entries in one fell swoop.
This is an unfortunate state of affairs. Trackbacks are apparently just one more piece of social software that can get spammed. Sigh.
I have to say that after my upgrade and implementation of Drupal 5.1, and my recent discoveries of the joys of system administration scripting with Python, I’m feeling hugely empowered.
I have a lot of newfound software tools at my disposal that just make me feel like I can do a lot more than I could have done in the same amount of time six months ago. It’s a good feeling.
Maybe this is what it feels like to have The Force (of Star Wars) “surround us, penetrate us, and bind the galaxy together.” Or maybe I’m just reacting to the nice weather we’ve been having this week.
Sometime after my Drupal 5.1 upgrade — but before a day had passed — I noticed that line breaks and paragraphs were missing from my posted stories. That just didn’t seem right.
After a bit of searching on the Drupal site, I stumbled upon a solution. (See, for example, this thread.) I have my own custom input format that I call “Standard filter”. Each of the filters had started out with a standard weight of 10, which meant they all ran as one big glob.
I reordered the various filters in this custom input format until the rendering improved. The winning combination was one where the “Filtered HTML” filter was highest (with a weight of -10), coming before the various inline filters and so on that I’d added to my custom input format. I spread the rest of the filters along the weight scale, going all the way from -10 to 10. Having “Filtered HTML” come first in the priority queue makes some sense, as it gets to attack its problem set first before the “Line break” filter and others step in to do their duty.
I learned something about Drupal thanks to this problem. Even though it was a pain, I came away impressed. That pretty much summarizes all of the Drupal work I did over the weekend — I learned a lot and like Drupal more because of it.
I figured out how to set up Drupal taxonomy as the basis for access control to nodes. After several attempts to get access control working for nodes, I’ve settled on a working method with Taxonomy Access Control. I tried Content Access and Taxonomy Access Control Lite.
Why? I have another site where I wanted to associate taxonomy tags with a story. If a particular tag was listed on that node, it would automatically deny access to anonymous users and other accounts not assigned a specific role.
With TAC Lite, unfortunately, I wasn’t able to get the critical “deny” feature. If a restricted term appeared in the taxonomy list for the node along with restricted terms, anonymous users could still see the story. The TAC module doesn’t have this failing.
I just couldn’t get Content Access to do anything other than deny access to every story, so it didn’t work for me.
It appears that I have successfully upgraded the site from Drupal 4.7.6 to Drupal 5.1.
Contrary to some others’ experiences, I was able to go directly between those versions without stopping at 5.0 in between.