I'm often migrating my Drupal db between a local version and a live/dev-version on another server. Sometimes the migration goes from Windows to Linux or vica versa.

Thanks to this fantastic module, it works generally without problems. However, everytime I migrate to another system, the temp-folder settings gets overwritten (as long as the variables-table is migrated), resulting in annoying temp-folder errors. With Windows to Linux this happens all the time (going from f.e. "C:\www\tmp" to "\tmp").

The temp-folder can be fixed manually very easily by visiting "admin/settings/file-system" ... and this is what I've done for a few years now. Today I realized that this annoyance is rather easily fixable. So I did one (against the latest dev-version).

All it does is add a simple checkbox on the restore page at "admin/content/backup_migrate/restore". When it is checked, the old temp-folder value gets restored right after the migration is done. Only a few lines of code, but it works well. The patch might need some cleaning up. For example I used "$_POST['restore_tmp_folder']" directly to check if the checkbox was checked, which maybe too dirty (even though it doesn't create any security risk or such).

I believe I can't be the only one annoyed by this small but unnecessary task. I couldn't find another issue about this, so I posted my own. Still, I'm sure lots of people have found this annoying (but were maybe too lazy to complain?).

(Another small migration annoyance, actually totally unrelated and happens in Drupal 5 only: after each migration I had to visit admin/build/menu to update the menu link structure of admin_menu, if the base_path was different between the versions. In Drupal 6 this seems to be automatically fixed. Don't know if the fix was in core menu, admin_menu or backup_migrate.. thought I'd just mention that too.

CommentFileSizeAuthor
backup_migrate-dev-27.9_temp_folder.patch1.79 KBbibo

Comments

ronan’s picture

ronan commented

Thanks for the patch hopefully it helps some people. This might be a little be too specific for inclusion in the module itself, but maybe if I get time I'll work this into a more general variable modifying filter.

How I usually solve an issue like this is to override the variables in my local settings.php in the conf array. This is a nice way to set variables per environment in a way that won't get overwritten when the database is restored from live.

bibo’s picture

bibo commented

Thanks for the tip. Didn't think about the conf-array. I thought those settings would be overwritten too.

Going to use conf array for now. I also hope you find the time to do that general variable mod filter sooner or later :).

jaysonragasa’s picture

jaysonragasa commented

I noticed this issue too when I migrated from local to live site. I was actually going to report this but good to know you already did. thanks for the patch

mototribe’s picture

mototribe commented

that's a great option - it doesn't look like this got ported to D7. Would this patch work on D7?

thanks

bibo’s picture

bibo commented
Status: Needs review » Closed (works as designed)

Although I made the original patch, I don't recommend anyone to use it.

Using settings.php is much easier, works for all Drupal versions and any variables that are fetched with variable_get(). The values get applied on every page load. Meaning you cannot change it via the admin_ui, since you're auto-overriding them.

This is how to do it. Write to the end part of your settings.php:

$conf 'file_directory_temp'] = '/home/tmp';

or any other location that makes sense. That's it.

dgorton’s picture

dgorton commented
Status: Closed (works as designed) » Closed (won't fix)

See #1 and #5 for a better way to handle this in settings.php. Thx @bibo for both noting the hassle and the best solution!

mototribe’s picture

mototribe commented

thanks a bunch. The first bracket was missing:

$conf['file_directory_temp'] = '/home/tmp';