Drupal notes from helping a client improve her development environment

Keeping a to-do list helps you keep sane. If you don’t have a full-scale issue tracker, use a wiki page, text file, or something like that. It’s really useful to be able to get the list of things you’re working on or waiting for out of your head and into a form you can review.

*Drupal Features help you export configuration into code.* This is much better than creating an installation profile because you can update your features with new settings and apply them to existing sites. Invaluable when working with multi-sites that may need to be updated. You may need to clear your Drupal cache before you see changes applied.

Version control is really handy even when you’re working on your own. The ability to go back in time to a working setup (code + database) can help you experiment more freely and avoid late nights spent recovering from mistakes.

*Drush (Drupal shell) is awesome.* It’s a big timesaver. We use it to download and enable modules (dl and en), clear the cache (cc), run database updates (updatedb), launch a SQL console (sqlc), execute PHP (php-eval), run tests, and so on. I use it a lot because I hate clicking around.

Even more powerful with a little bit of xargs magic so that it’s easy to run a drush command against all the sites. Like this:

cat sites.txt | xargs -n 1 -I {} drush -l {} somecommand

Design decisions: Multisite without shared tables; services or syndication for sharing content between sites; central authentication for admin users…

Bash script to create or clone multisites makes tedious things a little bit simpler. Tasks:

  • Create a database and give access to a user.
  • Create the site and files directory.
  • Create the settings.php with the database settings.
  • Copy the base database into the new database.
  • Create a symbolic link.

2011-06-28 Tue 08:55

  • Hi Sacha, two things:

    1) I agree with everything above, especially what you say about version control – I started using it for my own projects after being forced to for multi-developer projects and can’t emphasize enough, how much that decision has helped me. I strongly believe every developer should learn how to use version control before or while learning how to code.

    2) Contradicting no. 1, I find it really hard to keep database schemas synced to version control, so I usually only use them for code. Do you have any “best practices” on how to make version controlling your database less frustrating, regardless of the CMS used?

  • izus

    instead of :
    cat sites.txt | xargs -n 1 -I {} drush -l {} somecommand

    if you installed drush4 you can just run drush @sites in a multisite installation !

    drush @sites cron runs cron in all sites installed in a multi-site :-)

  • izus: Ooooooooh. I didn’t know about that. That’s awesome! =D

    Claus: Drupal 6 and Drupal 7 database schemas should be updated in .install files using the schema API, so that might help. We version-control database backups as an easy way to go back in time for content or configuration.

  • Roger

    I always like your posts, Sacha.

    What do you use for central authentication for admin users?

  • Arjan

    I second that question: what do you use for central authentication for admin users? (and separate databases, different domains)

  • The client is looking at CAS as a potential way to handle central authentication for admin users across multisites. LDAP may be another alternative.