Pet peeve #1 - the comparison operator

| Comments

I have a lot of pet peeves when it comes to programming, databases, web content, food, beer, and, well just about everything. I am thinking of making a series of pet peeves here on this site. Some will seem like plain rants, and others will be more like tips.

When making comparisons, switch the order of the things you compare like this:

if ('book' == $node->type) {
// Stuff happens.
}

You might think why? And that looks weird! Yes, it does look a little weird. But I do this to not accidentally assign the $node->type the value I am comparing it with. It is hell to find an error like this when debugging:

if ($node->type = 'book') {
// Stuff happens whether you like it or not.
}

See what happened? I only put one = instead of two. PHP will not complain about this, I will just not get what I expect. If I had switched the items, PHP would have complained as I tried to assign an object to a non-variable.


Social media meta

| Comments

I am doing some integration with facebook these days. I don't use facebook much and I certainly no not want all kinds of test data on my profile so I made a test profile using names that just came to mind :-P

On the facebook developer pages there is a demonstration of the like button. That you can like... Gotta love the meta! meta


Upgraded to Drupal 7

| Comments

I updated this website to D7 this weekend. Mikkel upgraded his site and urges others to do so now, so I thought I'd give it a shot too. And it was good fun! OK, granted, this site is 4 posts and pretty much nothing else, but that makes it a perfect time to upgrade.

I actually never did an actual core upgrade via the upgrade path before. The sites I have upgraded from D5 to D6 have pretty much all had such a complex data structure that I had to do an upgrade with a data migration. While that is a lot of work (and requires a programmer), I still like the opportunity it gives to clear out a data model that might have grown a little too organically. For this site though, that would be gross overkill. So my approach was simply to read UPGRADE.txt and follow the steps.

Modules

I don't use any of the big modules like CCK, views or panels. In fact I ended up with only 3 enabled contrib modules.

  • On D6 I had a tag cloud that the tagadelic module made, but I simply removed that because I couldn't see a 7.x branch on d.o. It turns out that there is work in progress to port it, so in this issue I found that development is going on github. I really like that module so I might take a look and see if I can help.

  • The twitter module does not have a 7.x branch either, but there is work going on. I decided to go for the easy choice so far and just this twitter-widget and embed the code in a block. In fact for my need that is just fine.

  • I have always loved the admin_menu module even though the fancy menu that sits on the side and awaits your click in rubik is nifty, I still like the overview that admin_menu gives me better. Luckily there is a 7.x branch and it also packs a neat integration with the top toolbar that D7 ships with.

  • Google analytics has a 7.x branch and I had no trouble with that other than some problem with actually writing the tracking codes. But it turned out that the theme was not doing that.

  • The Mollom module was not working, but I think I upgraded it wrong. As soon as I uninstalled it and installed it again it was fine. It threw errors at me when I enabled it after the core upgrade, so I must have missed something there.

  • I use ecto as a blogging client for my D6 sites. The blog API module was taken out of D7 and now lives on its own here. I tried to make it work, but I can see that it will take me some time. I will have to spend more time playing with that.

Theme

I really like the Corolla theme. I knew I wanted to use that so I didn't even browse around for a D7 theme. Configuring color and all that was easy, and the only problem I ran into was the theme not printing the footer with the google analytics tracking codes.

So what's it like?

I like D7. A lot. I have been playing around with it for a long time, but always with test data, the standard theme, and not so many contrib modules. It's great to see it all come together. One thing that took me a long time to get used to is the overlay. At first I hated it, but during the last 6 months or so it's grown on me. I am still not sure I would keep it enabled on any site, but it gets a chance on my site for now.

Another thing in D7 that really threw me off during the upgrade was that the core modules are listed first on the modules page. For a while I thought that drupal was just not finding my contrib modules. I would probably put them at the bottom if I was to sort them other than alphabetically.

I am excited to finally run Drupal 7! And I can't wait to play with more contrib modules more and see what cool stuff comes out of all the new opportunities in D7.


Backup and migrate module + Dropbox = peace of mind

| Comments

The backup and migrate module is truly sweet. We all know that it is a really good idea to back up data. But if you are like me - you forgot to do it or just don't do it for some lame reason. So backups should be automated. The backup and migrate module does exactly that - it can be configured to run every X hours if you have cron (and you should have) running on your site. The module makes a dump of the database and puts it in a folder in the files folder of the site. Even if you use the public download method, the security is OK - a .htacces file put in the folder by the backup and migrate module and disallows access to the folder's content.

In the unlikely event that my server goes up in flames, I like to have some backups that are not physically on the same server as the site. I really like Dropbox, so I thought I would figure out a way to use that for the database dumps. I found this very nice and simple php script, that will upload files to your dropbox. I used that to write a super simple php file that my cronjob will call once a day. I settled with having daily backups a week back in time, so the filenames are day names. That way monday's file will be overwritten next monday.

Here is what I did:

  1. Enable the backup migrate module
  2. Go to yoursite.com/admin/content/backup_migrate/export and choose gz under compression, put your sitename in Backup file name, and put "D" for dayname under Timestamp format: backup migrate
  3. Download and unzip the latest Dropbox uploader (I used the 1.1.5 version)
  4. Edit the variables capitalized in the php below and save the it to a file called dropbox_backup.php. Put it next to the Dropbox uploader file. The files should be put somewhere outside the drupal installation.
  5. Put a line that in your crontab that calls the php script. It could look like this one, that will run every night at 1 and report to a log file how it went. 00 01 * * * php PATH_TO_SCRIPT/dropbox_backup.php >> PATH_TO_SCRIPT/log.txt And that's it! Easy backup of your database and easy use of the ample storage space that Dropbox offers.
<?php
$site_name = 'SITENAME';
$backup_dir = 'WHERE_YOUR_DB_DUMPS_ARE_PUT_BY_BACKUP_MIGRATE';
$todays_filename = sprintf('%s-%s.sql.gz', $site_name, date('D'));

if (file_exists($backup_dir .'/'. $todays_filename)) {
  // Get todays file from where backup_migrate module puts it
  // and drop it in this folder (just to get it out of the "files"
  // folder in Drupal).
  exec("mv $backup_dir/$todays_filename " . dirname($_SERVER['SCRIPT_FILENAME']));

  // And upload todays file to the Dropbox.
  require 'DropboxUploader.php';
  try {
    $uploader = new DropboxUploader('YOUR_EMAIL', 'YOUR_PASSWORD');
    $uploader->upload(dirname($_SERVER['SCRIPT_NAME']) .'/'. $todays_filename, 'FOLDER_IN_DROPBOX');
    echo date('m/d Y') . ": Uploaded $todays_filename to Dropbox\n";
  }
  catch (Exception $e) {
    echo date('m/d Y') . ": I had a problem uploading $todays_filename to Dropbox\n";
  }
}
?>

Hide Drupal files with .htaccess

| Comments

If one goes to somedrupalsite.com/CHANGELOG.txt - it is normally possible to read the file and see what version of Drupal the site is running. If you don't want everybody to see what version you are running, it is a good idea to cloak the *.txt files in the Drupal install.

Using rewrite rules in .htaccess, the *.txt files in Drupal can be hidden. I use a 403 - forbidden on these files. That is what the [F] means See the Apache documentation on RewriteRule for more options.

# No need for the common visitor to read these files.
# They can just go download their own Drupal. It's
# free and everything.
RewriteRule ^(.*)CHANGELOG\.txt$ - [F]
RewriteRule ^(.*)INSTALL\.mysql\.txt$ - [F]
RewriteRule ^(.*)INSTALL\.txt$ - [F]
RewriteRule ^(.*)MAINTAINERS\.txt$ - [F]
RewriteRule ^(.*)INSTALL\.pgsql\.txt$ - [F]
RewriteRule ^(.*)LICENSE\.txt$ - [F]
RewriteRule ^(.*)UPGRADE\.txt$ - [F]
RewriteRule ^(.*)README\.txt$ - [F]

Put these lines in the bottom of the .htaccess file, but before the </IfModule> "tag". The .htaccess file lives in the root of your Drupal installation.

Using version control?

Metadata folders left by whatever version control system should be hidden too.

# Don't let people pry in version control folders
RewriteRule (^|/)(CVS|\.svn|\.git)/ - [F]

Put the above snippet inside the </IfModule> in .htaccess as well.