Jaharmi’s Irreality renewable hyperlinks with 0% transfat since 1999

After starting to use Drush, I wanted to switch my Drupal cron jobs over to it. I’d previously been running these jobs the standard way, loading a URL for each of my Drupal sites with curl. That curl command was run by the cron; Site5 allows editing of your crontab directly or through its Backstage Web interface.

I started with the basics. Drush was installed in my home directory, with an alias under ~/bin in my Site5 account. I replaced my curl command one-for-one with the following:

This didn’t work out well. I was getting a huge number of mail messages, indicating problems with the cron jobs. The messages typically contained “tput: No value for $TERM and no -T specified.” Needless to say, this was rather frustrating, so after some trial and error, I modified the command as follows, and that has been working better for me.

The biggest change is that I specify PHP, rather than Drush, directly. This was done so that I could increase the PHP memory limit for the cron job significantly, to 64M, while running Drush. I’m sure that this increase was needed partly due to the number of modules I have installed on my main site (which has an even larger default PHP memory limit in its php.ini). My research indicated that I needed to do this for Drush since it doesn’t access the Drupal sites in the same way loading a page does.

The other noticeable change is that I provide the path to the drush.php file rather than pointing to the Drush alias.

Apache Solr provides a Web service front end for the Apache Lucene indexing and search engine library. Both Solr and Lucene (upon which Solr depends) are Java-based, which has implications for shared Web hosting.

Drupal is an open source CMS, and I happen to use it on a shared Web hosting provider as of this writing. Drupal is gaining support for Apache Solr through a module that has had a lot of input from Acquia (the “Red Hat” of Drupal).

Dries Buytaert of Acquia has some interesting perspective on search for the Web and CMSes in some recent articles on his site. Specifically, he talks about Acquia Search, a Solr-based search service that is being offered to Drupal sites on the Acquia Network. He discusses the advantages afforded by good search capabilities for both visitors to a Drupal Web site and for site administrators.

I’ve used Acquia Search (in beta), and it has been great. It’s very fast compared to the core Drupal Search module. The ability to perform faceted searches, word stemming, spell checking, and more is all tremendous. (You can see it in action in the search field in the site sidebar, as long as my Acquia Network subscription from the beta lasts.)

But Acquia Search part of a larger service offering — the Acquia Network — which ultimately makes it too expensive for me on my personal sites. It’s priced out of reach for me — more costly for one year than two years of Web hosting, domain registrations, and separate e-mail hosting for my domains are today. I think it’s clear that Acquia is aiming at a different market, and that’s fine.

My idle thought, however, is that search by itself is a compelling feature even for small Web sites like mine. It’s as compelling as hosting files, like HTML or PHP or images, or serving databases, like MySQL and PostgreSQL.

If it’s important as Dries notes in his posts — that the search market is so large and growing, and of such universal importance — then great search is a compelling feature to have for many levels of sites. After serving the files and serving the database, it may be the next big service that a Web hosting provider could offer. And today, Web hosting offers a range of pricing (and service levels) to meet various needs.

I could see advertising that for some monthly fee, a Web host offers 55 GB of storage and 550 GB of monthly data transfer and unlimited MySQL databases — and oh, by the way, some reasonable level of indexing/search with Apache Solr and/or Sphinx or whatever. Although I hate to suggest it, search could even be an optional add-on, as many providers treat dedicated IP addresses or SSL or the like.

There may be an additional win, in that separate servers could be optimized for search to offload that processing from the Web server. It could even be something that a Web host contracts out or partners with another to provide — maybe even with a company like Acquia that’s already set up their infrastructure to scale on Amazon EC2.

Especially if other CMSes, such as WordPress, get Solr integration — as with this WordPress Solr plugin — then the case for Web hosts offering something like Solr search gets convincing.

I wanted to find a way to do syntax highlighting of code snippets on my Drupal blog. I came across the GeSHi Filter module, which lets Drupal sites take advantage of the apparently well-regarded GeSHi Generic Syntax Highlighter library that’s meant for just this purpose.

However, I ran into some roadblocks implementing it on my site. Here’s the short story of what I settled on after some trial and error.

My existing code snippets are in <code> blocks, and the initial GeSHi Filter settings applied badly to them. I made the decision to only use GeSHi on <blockcode> blocks, since I wasn’t using that tag yet and it wouldn’t conflict with the snippets already posted.

I most commonly write Bash/Zsh, Python, and AppleScript snippets on my blog. However, the Bash code I was using as part of my trial and error simply wasn’t highlighting; it was coming through as the default (and boring) plain text — but was at least boxed off from the rest of the blog post.

I thought that GeSHi wasn't correctly discovering that the code was written in UNIX shell syntax. I couldn’t find a way to specify the language for that blockcode tag, until I did some searching on the ’net. To change my blockquotes to choose a certain language — at least for the purposes of this Drupal module, if not for GeSHI in general — I needed to add the “lang=lang” style to the tag. For Bash, I could use “lang=bash,” for Python, “lang=python,” and for AppleScript, “lang=applescript.” That made sense.

However, my code was still not being syntax highlighted. I discovered that the Drupal module came with an initial set of languages enabled. The others were all turned off, but that could be changed in the module settings. Without turning them on, even properly-tagged <blockcode> sections did not get the benefit of syntax highlighting.

I changed the GeSHi Filter options to enable some of the languages that were initially disabled, and then disabled the ones I didn’t anticipate using. This allowed me to add Bash and AppleScript syntax highlighting support, as both had been turned off by default. After that, I saw the results I’d hoped for: a syntax-highlighted code snippet.

It took some work, but now that it’s done, I should be all set.

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.