Drupal: Limited drush magic (update)

I was trying to figure out how to create a simple way to keep my 15+ drupal installations clean and up to date with a single mouseclick for a long time now. Of course, drush was the first thing I looked at, but since it is a command line tool and all my clients are on shared hosting servers without ssh access, that didn’t seem quite the solution. My first goal was to create an easy way to keep the codebase up to date with the rather frequently updated sources from drupal.org. My base install consists of around 68 modules, some of them get updated at least every two weeks. If you try to keep up with that on a regular base by overwriting/synching every install by hand, it will take you approximately 2 hours every week to do so, including clicking yourself thru each sites database update procedure. At first, I used an Automator action in combination with Transmit, an FTP client providing plugins to Automator for synching files. This was quite ok, but really slow. Slow because of Transmit, as I found out later. So, long story short, I found the following procedure kinda solid enough for production websites. To be able to execute shell scripts on a webserver, PHP’s exec(); function needs to be allowed to run. Second, you need a fast and scriptable FTP client: I found Yummy FTP to be quite versatile and fast for synching. At least twice as fast as Transmit FTP. Also, since there will be the need for drush, you need that, too. :) I created an AppleScript which works as the core of my update procedure:

The Script takes a predefined directory which has Yummy FTP bookmarks to all drupal installations base directories and loads them into an array which will be looped thru, one by one. Yummy FTP does all the FTP work: connecting, synching, error handling, etc. First action is to switch the current drupal into maintenance mode using drush. Second, the synching of all files takes place. Optional: Possible calls to deactivate/activate certain modules on all installations before the site leaves maintenance mode, emptying the watchdog tables, file actions (checking to see wether the drush script is executable or not), etc. Third, calling drush to update the database after successfull synch and switching the site back to normal mode. The calls are being executed by loading the drush PHP file/wrapper via URL in Safari. I will change that to use a silent wget call later on, just like calling the cron.php serverside via cron-tabs.

All drush executions are being called by a PHP script which I wrote to function as a wrapper using PHP’s exec(). To make it secure, I use a token/secret which can be replaced at any given time on both ends. For now, this will have to do it. The PHP script takes parameters: Initial settings called before the update, optional calls to activate/deactivate modules and finally, the db update calls. Basically, it is possible to call all drush functions which do not require direct access to the filesystem (database dumps and installing modules via drush do not work very well at this point). I was running this procedure a couple of times to see wether it’s ready for production use. I will have to refine the error handling of the AppleScript slightly to have more info on wether the FTP actions actually succeeded or not. So far, if Yummy FTP fails, the whole thing just crashes. The fail-rate is pretty low tho and with some more work, this is basically the only way to have an automated update procedure over multiple sites on shared hostings. Right now, synching about 17 installs takes around 30 minutes, completely unattended. This is all I need. :-) [Update:] I extended the functionality of the script to include

using cURL to trigger the PHP drush wrapper script, needed to send a browser identification string for drupal installations using “boost”-module. create a tgz archive of sites/ and themes/ before any file and update actions take place, download the archive and delete it on remote site. This ensures all user generated content including the daily database backups created by backup&migrate are stored locally before any action takes place. instruct drush to expect “y” for the “update db”-statement Pitfalls: The script now connects 3 times to the server: Pre-Update functions (upload current drush-wrapper, download tgz archive), Synch, Post-Update. Unfortunately, Yummy FTP delivered a number of errors when trying to do all in one FTP session. So far, I don’t know wether that’s an AppleScript problem or a limitation of the AS API Yummy FTP provides.. no idea. :P

[Update 2] I was very productive.

GUI added using XCode (AppleScriptObjC/ASOC). Fancy buttons! :) Textwindow showing the progress and displaying drush/other results and info. Now multiple chunks instead of one big loop: Different maintenance tasks can be launched separately, like wrapperscript update, backup, custom drush-jobs deployed via wrapperscript, codebase synch, database updates, cron.php trigger, … FTP-Actions moved to background/hidden Ability to choose wether the tasks should be run on test servers or production servers

Todo

Add preference pane to configure file locations and ability to generate the wrapperscript on the fly (once I figure out how to do that :P ). Add table view to check individual sites/bookmarks (once I figure out how to do that :PPPP). Make the whole thing localisation-ready

Right now the stuff is all hardcoded which isn’t particularly nice but is enough for me. That’s why you can’t find a download link anywhere here. :) If you’re interested in the project’s sourcecode and want to help me build all the remaining pieces (i really could need some help..), let me know. Note to self: Learn cocoa [/Update2]