Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
Eventually. There are over 76k sites using the 6.x version of the Backup & Migrate module, but only 8 using this plugin. There doesn't appear to be a huge amount of interest in general in spite of an article on the Rackspace Cloud Blog, so it's not one of my "hotter" projects on my todo list right now.
If you've got module coding experience and would like to take a crack at it, let me know!
Nope, I wasn't even aware of that sandbox project starting up... Looks like they took the exact same approach I did for the base backup. This module has a bit more functionality for tagging the metadata on the Cloudfile in addition to a whole lot more error trapping... ;)
I'll try to look at the D7 port soon as it appears for some reason interest has started to pick up in this module (just noticed the usage stats are doubling every couple weeks). It might be relatively painless since it strictly relies on the hooks invoked by the Backup & Migrate module, and makes very little use of Drupal core hooks. If the D7 implementation of Backup & Migrate maintains those hooks (fingers crossed) then a simple branch and new .info file might get me 90% of the way there...
So far, so good! I copied the D6 branch over to a clean D7 installation, ran Coder on it and fixed a couple things it didn't like for D7 contrib modules (all coding standard changes). After a couple additional changes to update the token APIs I have backups saving to and restoring from my Cloudfiles account. Looks like pretty much all the hooks I implemented were specific to the Backup & Migrate module, not so much Drupal core - and the couple I did use port cleanly. Whew.
I am getting some strange "undefined offset" errors from deep within the Rackspace Cloudfiles PHP library, so need to track those down and make sure I'm not passing something it doesn't like. So far they don't appear to be harming anything in the backup or restore process, so hopefully won't be nasty fixes on my end.
Be looking for a D7.x-1.x-dev to roll out sometime in the next few days - assuming I figure out how to create a D7 branch (correctly) in git w/out screwing up my entire codebase first... ;)
Ported to D7, the 7.x-1.x-dev release should be available for download once the packaging service susses out what the heck I've been doing to my repo this evening... ;)
OK, found out the warnings mentioned above were being generated by a minor bug in the Rackspace PHP Cloudfiles bindings. If you see either of the following messages, upgrade to the latest code from their GIT repo referenced on this project's homepage:
Notice: Undefined offset: 7 in CF_Object->_initialize() (line 2261 of XXX/sites/all/libraries/rackspace/php-cloudfiles/cloudfiles.php).
Notice: Undefined offset: 8 in CF_Container->_cdn_initialize() (line 1588 of XXX/sites/all/libraries/rackspace/php-cloudfiles/cloudfiles.php).
Oddly enough, these don't surface under D6. From the GIT project's commit logs, it doesn't appear to be a functional issue but a case of a PHP list() assignment that RS isn't always returning the last (optional) element for.
Comments
Comment #1
arpieb commentedEventually. There are over 76k sites using the 6.x version of the Backup & Migrate module, but only 8 using this plugin. There doesn't appear to be a huge amount of interest in general in spite of an article on the Rackspace Cloud Blog, so it's not one of my "hotter" projects on my todo list right now.
If you've got module coding experience and would like to take a crack at it, let me know!
Comment #2
waverate commentedIt looks like work has already started here:
http://drupal.org/sandbox/dsnopek/1268812
Do these projects have similar goals?
Comment #3
arpieb commentedNope, I wasn't even aware of that sandbox project starting up... Looks like they took the exact same approach I did for the base backup. This module has a bit more functionality for tagging the metadata on the Cloudfile in addition to a whole lot more error trapping... ;)
I'll try to look at the D7 port soon as it appears for some reason interest has started to pick up in this module (just noticed the usage stats are doubling every couple weeks). It might be relatively painless since it strictly relies on the hooks invoked by the Backup & Migrate module, and makes very little use of Drupal core hooks. If the D7 implementation of Backup & Migrate maintains those hooks (fingers crossed) then a simple branch and new .info file might get me 90% of the way there...
Comment #4
arpieb commentedSo far, so good! I copied the D6 branch over to a clean D7 installation, ran Coder on it and fixed a couple things it didn't like for D7 contrib modules (all coding standard changes). After a couple additional changes to update the token APIs I have backups saving to and restoring from my Cloudfiles account. Looks like pretty much all the hooks I implemented were specific to the Backup & Migrate module, not so much Drupal core - and the couple I did use port cleanly. Whew.
I am getting some strange "undefined offset" errors from deep within the Rackspace Cloudfiles PHP library, so need to track those down and make sure I'm not passing something it doesn't like. So far they don't appear to be harming anything in the backup or restore process, so hopefully won't be nasty fixes on my end.
Be looking for a D7.x-1.x-dev to roll out sometime in the next few days - assuming I figure out how to create a D7 branch (correctly) in git w/out screwing up my entire codebase first... ;)
Comment #5
arpieb commentedPorted to D7, the 7.x-1.x-dev release should be available for download once the packaging service susses out what the heck I've been doing to my repo this evening... ;)
OK, found out the warnings mentioned above were being generated by a minor bug in the Rackspace PHP Cloudfiles bindings. If you see either of the following messages, upgrade to the latest code from their GIT repo referenced on this project's homepage:
Oddly enough, these don't surface under D6. From the GIT project's commit logs, it doesn't appear to be a functional issue but a case of a PHP list() assignment that RS isn't always returning the last (optional) element for.
Comment #6
arpieb commented