The Lullabot Web site has a clever way to help answer the question of “Is that site running Drupal?” Angie Byron mentions that the HTTP “Expires” header returned by Drupal corresponds to a specific default date. Look for that date in the HTTP headers, and you can make a reasonable guess that a site is a Drupal site — or at least one that hasn’t modified one of the core files.
Some commenters posted notes about how to do the same thing with wget and then curl. I expanded on the curl instructions to make them a little more robust (especially in the case of redirects or URL rewriting), and here’s the result:
$ curl -fsIL http://jaharmi.com/ 2>&1 | grep -q -m 1 "Expires: Sun, 19 Nov 1978 05:00:00 GMT" && echo "Yes, this appears to be a Drupal site." || echo "No, this does not appear to be a Drupal site."
Yes, this appears to be a Drupal site.
It looks like some recent change to the Google Analytics module for Drupal 5 broke my link to the Analytics service. Well, I’m being overbroad there. It really was working, but apparently only tracking when my administration account and users from a certain other user role (think: group) were logged in.
Well, obviously, that could lead to a significant traffic drop — if for no other reason than anonymous users weren’t being tracked — and that’s what I was seeing throughout my Analytics data. I only check Analytics every once in a while, and it’s currently only a curiosity to me, but it was still confusing as to why I saw all the graphs plunge starting March 7.
My best guess is that one of my recent module update binges loaded a new Google Analytics module which changed something, and only two user roles were set up to be tracked. (The Drupal 5 update process leaves something to be desired. Sure, I should have read the “read me” to find out about the change beforehand, but when you have so many modules to update, you just want to get it done. Wish it had warned me that something needed my attention.) Now that I’ve changed that setting and other user roles — including anonymous — will be tracked again, we’ll see what happens.
In order to figure out if I can upgrade to Drupal 6, I have to review the compatibility of the following modules I use under Drupal 5:
Not all of these are essential, of course. Heck, they aren’t even all enabled. But it will still take some time to review what modules I need and don’t need to make the site run in the way I’m accustomed to it running. Still, the urge to throw caution to the wind and upgrade blindly is certainly there.
The Achilles heel of Drupal, as I perceive it, is the core philosophy of “the drop is always moving.” Although I can appreciate that the software needs to break with tradition at times, the compatibility rat race is really painful.
I run a site. I want/need modules to make that happen. The modules are written for specific versions of Drupal. Each major version of Drupal has new module requirements. There’s no guarantee any module will be upgraded to work with the next version of Drupal. Old modules don’t even run in a reduce functionality state. It’s rather aggravating; there are modules I wanted to run that haven’t been upgraded since Drupal 4.6 or 4.7, so they weren’t even compatible with 5.x. The only recourse may be to upgrade the modules yourself if you are that interested in them, as I haven’t seen a bounty to upgrade a module work yet.
Of course, it’s worse if the module isn’t even hosted in Drupal’s contributed module repository (aka “contrib”).
Unfortunately, I’m not at a point where I feel I can contribute much to making the modules compatible with Drupal 6. Most of that work requires coding PHP and testing on a non-production site, two tasks I’m ill-equipped for right now.
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!
Last week, I found and installed the Drupal Bad Behavior module. It’s been remarkable to see it working; in only one week of operation, it’s already logged 98 pages of events — at 23 items per page. That’s 2254 likely bots blocked!
In order to install the module, I had to find the latest patch/version — one that would work with the current Bad Behavior library — on the Drupal site and install it in my modules directory. I then had to install the Bad Behavior PHP library inside the the new module’s folder. Although this was a little tricky, it certainly feels worth it.
I finally resolved my inability to refresh or post a new note from MarsEdit 2 to one of my Drupal sites, based on this tip. I had to enable the “Edit own stories” permission on my role for blogs in the Drupal Access Control list. Until I did that, I was consistently receiving the error:
“You either tried to edit somebody else’s blog or you don’t have permission to edit your own blog.”
On that site, I still can’t get a list of all of the taxonomy terms in the MarsEdit Categories list. Actually, I get none. I’ve at least taken on important step in the right direction, so that’s helpful.
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.
Since the on-line frenzy surrounding the iPhone is building feverishly before its June 29 release, I thought I would try out Marketcircle’s iPhoney browser simulator. It’s bare bones, but interesting nonetheless.
Basically, it showed me that my site will look like crap on the iPhone. Even in landscape, the Garland template for Drupal, along with my Drupal block configuration, makes Irreality far too wide to be seen without scrolling on the iPhone’s screen.
Ah, well. I’m not going to bother fixing that now. Too much else on my plate.