Setting the site name of a Drupal site

I just spent a frustrating couple of hours beating my head against a Drupal site, trying to change the site name (that appears in the site banner and title). No matter what I set in the admin/settings page, the site name remained unchanged. The database was being updated correctly:

mysql> select * from variable where name = 'site_name'\G
*************************** 1. row ***************************
 name: site_name
value: s:20:"My Fancy Drupal Site";

but the old name was still displaying on the site (and every time I went back in to admin/settings, the name had reverted).

Finally, I remembered this section of settings.php:

/**
 * Variable overrides:
 *
 * To override specific entries in the 'variable' table for this site,
 * set them here. You usually don't need to use this feature. This is
 * useful in a configuration file for a vhost or directory, rather than
 * the default settings.php. Any configuration setting from the 'variable'
 * table can be given a new value.
 */
$conf = array(
  'site_name' => 'My Drupal Site',
//  'theme_default' => 'bluemarine',
  'anonymous' => 'Visitor'
);

D’oh!

So I commented out that 'site_name' line, and everything worked as expected.

A test of weblogger.el

This is a test of the patched weblogger.el I found on Friends of Bart. It would be really cool if it worked, because emacs is like a second home to me. :)

Bug in Debian Drupal package

There’s a small bug in the just-updated Debian Drupal package in sarge (see bug #368835). If you just installed the updated deb from security.debian.org (4.5.3-6.1sarge1), you may see this message when trying to access your drupal site:

Parse error: parse error, unexpected T_STRING in /usr/share/drupal/includes/file.inc on line 106

This is caused by a missing semi-colon in file.inc (on line 106, surprisingly enough). This patch fixes it:

--- file.inc	2006-07-27 21:42:57.000000000 +1000
+++ file.inc.NEW	2006-07-27 21:42:51.000000000 +1000
@@ -102,7 +102,7 @@
       fclose($fp);
     }
     else {
-	  $message = t("Security warning: Couldn't write .htaccess file. Please \
    create a .htaccess file in your %directory directory which contains the \
    following lines: <code>%htaccess</code>", array('%directory' => theme('placeholder', \
    $directory), '%htaccess' => '<br />'. str_replace("\n", '<br />', \
    check_plain($htaccess_lines))))
+	 $message = t("Security warning: Couldn't write .htaccess file. Please \
    create a .htaccess file in your %directory directory which contains the \
    following lines: <code>%htaccess</code>", array('%directory' => $directory, \
    '%htaccess' => '<br />'. str_replace("\n", '<br />', \
    check_plain($htaccess_lines))));
       form_set_error($form_item, $message);
 	  watchdog('security', $message, WATCHDOG_ERROR);
     }

This appears to have already been reported in bug #380022.

Solving weirdness in an svn updated django install

I am playing with the “trunk” version of Django, a nifty python-based web framework. This evening, I spent a few hours getting back up to speed with the current state (trunk is changing fairly rapidly at the moment, all for the good though). But I kept getting TemplateSyntaxError in the admin module, with a message something like:

django.templatetags.adminmedia does not define a variable named "register"

(Sorry that’s not verbatim, I stupidly didn’t copy the error before I fixed it.)

I double checked all my settings and removed references to any of my local code, but kept getting the error. Finally, someone on the IRC channel (#django at irc.freenode.net) suggested cleaning out the django code to remove any *.pyc (compiled python) files.

Sure enough, doing this:

cd ~/src/django.svn/trunk # or where ever you checked out django 
find . -name "*pyc" -delete

fixed it.

A better pair of earphones

Last year, I bought some EarJams for my iPod.

They were passable, but I was getting increasingly frustrated with the lack of accuracy or balanced frequency response. In fact, I reverted to using just the naked Apple-provided buds, since at least they were more or less faithful to the original sound (if a little tinny unless manually held firmly in ones ear).

So for my recent birthday, thanks to some cash from my mum and dad, I splashed on a pair of Shure E2c in-ear ‘phones. And it’s probably the best technology purchase I’ve made in a while. They feel “serious” (solid is probably not the best word to describe in-ear head phones), the cable is substantial without being too stiff, and they look pleasingly “techy”. But most of all, the sound.

A friend had told me about a pair of Etymotics he had tried, how he could hear all sorts of things in recordings he’d never noticed before… and it’s the same with these Shures. The level of detail I can now hear, especially the live sound of classical recordings, is incredible. Of course, with some artists, like Glenn Gould, this is not necessarily a good thing. ;)

The overall balance is great, and the sound is lively and crisp across all musical styles–from thumpathumpa bass to an orchestral sound stage. I’m a happy camper. :)

Proud iBook owner

As recently chronicled, my Powerbook is no longer viable as a portable notebook computer. This makes me sad. :'(

The obvious silver lining, of course, is that it provided an opportunity for a new purchase. So I umm-ed and ahh-ed about the new MacBook Pro, but it was pretty hard to justify the four or five grand it would cost me. And everyone warns you off getting the first release of a new generation of Apple hardware.

Also, as much as I love the 15" wide screen, the idea of the 12" form factor was very attractive–most of the non-desk places I’m likely to use a laptop lend themselves to small and light.

So it came down to either a 12" PowerBook or iBook. I finally settled on the iBook. While it’s even slower than my old Powerbook, the price factor was too good to ignore. Essentially, it would have cost me about $1,000 more for the 20% speed boost and marginally smaller size/weight of the PowerBook. I can save that money now and upgrade to a high-end Intel model sooner rather than later.

And perhaps more to the point, the iBook is less “precious”… I’ll feel more comfortable throwing it in my bag and whacking it out on the table of the local coffee shop, not having to worry about sullying its lovely finish.

I’ll be keeping it away from open milk cartons though…

Not such a happy ending after all

Well, some months have passed since my happy ending. Turns out it wasn’t the end, and it wasn’t so happy.

After a few weeks, my screen started playing up again. It was just an occasional flicker at first, but quickly degenerated into being almost unusable. I took the PowerBook back into the shop for another look, but they weren’t too optimistic. In a nutshell, they tried everything short of replacing parts, and the most likely part that would need to be replaced was the screen–at around AUD1,500, not really worth it.

The screen more or less behaves itself when left on for long periods (the problem seems to be partly heat related), so it was ok during the day at the office. But it is pretty useless for the train or coffee shop. So, I resigned myself to having a portable desktop. I bought a 17" LCD display for home, which along with an external keyboard and Mighty Mouse makes for quite a usable office machine.

Sigh. Maybe next time, I’ll get the extended warranty…

Apple Mail.app "not responding"

This morning, my mail server was rebooted by my ISP. This is not extraordinary in itself, but somehow it caused my mail client (Apple’s Mail.app) some confusion. It thought the IMAP server was offline (which it was for half an hour or so), and would not reconnect.

When I restarted Mail, it froze. “Application not responding”. Force quit worked to kill it, but it always froze on restart (even after a reboot). Other IMAP clients (I also use the excellent Mutt in conjunction with offlineimap, and when really desperate, Thunderbird) were working just fine.

I found this article on macosxhints, but its suggestion:

% cd ~/Library/Mail
% find . -name '.index.ready' -delete
% find . -name 'content_index' -delete
% find . -name 'table_of_contents' -delete

did not work. (Well, it obviously worked, the files were deleted, but it didn’t help the symptoms.)

I noticed another indexy cachey looking file in my mailbox directories: .mboxCache.plist. Deleting all of these:

find . -name '.mboxCache.plist' -delete

seemed to fix Mail.app for me.

NOTE I have no idea what this file is for, or what the implications of deleting it might be. It appears to have Worked For Me(tm), but it could also cause all your email to fall out of the back of your computer and make a nasty stain on your carpet.

PHP can't talk to MySQL after OS X 10.4.5 upgrade

I just tried to access one of my local dev sites (that is, running on my powerbook), and received the dreaded “mysql can’t connect to socket” error:

Can't connect to local MySQL server through socket '/var/mysql/mysql.sock'

I was sure MySQL was running (I could access it via the command line mysql tool, and MySQL Administrator). And it used to work… But sure enough, there is no directory /var/mysql, and no mysql.sock file in it. :-/

After a bit of digging around, I noticed that the php.ini file (/etc/php.ini.default) had been updated on Feb 8th, about the time OS X 10.4.5 was released. Hmm.

I don’t remember customising this file, but it certainly didn’t contain any customisation now. The “mysql.default_socket” setting was blank, meaning it would use the compiled-in default. I’m not sure whether PHP was upgraded with 10.4.5 and this changed the default, or if I had customised it previously and I’ve just forgotten. But either way, it was now looking for the MySQL socket in /var/mysql, and my version of MySQL (4.0.24) wasn’t putting it there.

So I created this dir and set its owner to mysql:

sudo mkdir /var/mysql
sudo chown mysql /var/mysql 

and followed the instructions in this Apple support article by adding the following setting to /etc/my.cnf:

[mysqld]
socket = /var/mysql/mysql.sock

[mysql]
socket = /var/mysql/mysql.sock

(The last two lines are not mentioned in the Apple article, but are required for the command line mysql utilities to work.)

A quick restart of the mysql server later, and all is good again.

Know your bugs

From Wil Shipley:

I never, ever fix a bug, even from another user, unless I can say with some surety that I can see the circumstances that led to that person writing that bug. It may be as simple as “oh, copy and paste error” or “this person was tired and overlooked this edge case, and that didn’t come up until now.” But if you see a bug and think, “How in the hell did this code ever work?” then you’ve got a lot more work to do (assuming the code did ever work), because you aren’t allowed to move on until you can answer that question.

Understanding your code, and the underlying code of the environment you’re in, is more important than fixing any one bug.

Sage advice.