webschuur.com

Attached is a simple script to backup Drupal databases in an incremental-archive-friendly way (1.7KB). Instead of dumping the database into one big SQL file, this script creates many small files; one per table. With a blacklist option to exclude certain tables. It stores the structure (CREATE TABLE statements) in a separate file too.

Lighthttp is a very good alternative for Apache. The exact details on why, how and when are outlined on lighttpd’s website, but I choose it for my development environment; because it is light: having five forked apache processes idling around, merely to develop a simple module is way OTT, I think.

There are many tutorials on getting lighttpd up and running, including a nice, yet complex one special for Drupal.

There, got your attention. Still, this is an often heard complaint, most of the times in nicer words though. Just look at the large amount of requests (with patches) for the statistics module. Nearly all of them cover things such as ‘don’t track this and that’, or ‘also track foo’. And apparently, it seems even Dries agrees. Or at least he seems to need more statistics then only those provided by Drupal:

<!-- Begin W3Counter Tracking Code -->

With a simple addition you can dissalow anyone but you to reach update.php on your site. Off course Drupals update.php is secured and requires you to edit the file in order to update. But at that moment (no matter how short time that may be) anyone can start upgrading your site. Especially when upgrading multisites this can be dangerous: it may take two days to finish all the upgrades: two days that anyone can break any of your databases.

Just add this simple block of accessrules to the .htaccess in your Drupal root.

Sympal Scripts Premature manual

It is a bit strange to write a manual before the features in that manual are all implemented, but I think it is an interesting workflow, to start off with documentation, because it gives me (developer) and my audience (potential users) a clear view of what Sympal Scripts will do. And it shows a clear todo for me too. Below are the common usage parameters and usage concepts. In reality some of the commands can take a lot of advanced parameters in addition to the listed command parameters.

Usage:

install.php        Install new features in a multisite, or a new site.
 --type [site|module|theme]        Site installs a new multisite. Module installs a new module
 --variables site=example.com user=Joe email=joe@example.com etc.
                             A name=value list of variables needed for installation of the module or site. Provide none to see a list of required values.
 --fixtures directory-name   Use the fixtures in the directory directory-name to preconfigure the site.
 --dry-run                   Don't write anything, just output information
 --verbose                   Be more verbose

Yesterday David pointed me at a cool screen-cast of the Civicspace (CS) installer. His question was, how much Sympal scripts and its install system could use from and be used by the CS installer. Because I got this kind of questions more often, here is a summary and a small status report.

Here is what I need and what I have resources for:

• Sympal is all command-line based. Consultants and developers have command-line skills. (or else they should get another Job :)) )