After cloning a site, the filepath column of the files table still had paths pointing to the cloned site.

I did a "update files set filepath = replace(filepath, 'sites/OLDURL/', 'sites/NEWURL/'));" and it fixed the issue.

CommentFileSizeAuthor
#6 provision_fix_clone3.diff355 bytesadrian
#5 provision_fix_clone.diff968 bytesadrian
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Yep, reproduced, this is definitely a FAIL:

Changed paths from sites/files2.mig5-forge.net to sites/files2.mig5-forge.net

So we are obviously not passing $old_url properly. Investigating

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

So the trick is we can even force site_url to be the old url in clone.provision.inc when calling provision-deploy, but what happens is that after the backup has been unpacked into the new site's directory, its drushrc.php is loaded into scope, updates are run and then the drushrc.php is regenerated with a new site_url parameter. This parameter is then interpreted in the deploy.inc for drush_get_option('site_url') for both $new_url and $old_url and that's why the replace doesn't work: it's trying to replace a non-existent value with an identical value which never happens.

A tricky one, because as far as I can see we can't control this in clone.provision.inc: the problem is deploy.inc I think. I might be wrong.

adrinux’s picture

adrinux CreditAttribution: adrinux commented

This bit me on a clone too. My imagecache presets were all working fine though – until flushed – it was actually cck imagefield uploaded image paths that were not updated. So I think the 'breaks imagecache' is a bit misleading.

I used the sql workaround too.

One other thing I've seen is xmlsitemap's cache files - the module stores the filepath in the variables table. So obviously just checking the files table misses that. Easier one to change though.

( Looks like this won't be a problem for drupal 7, but will remain one for 6 "File table includes file_directory_path()" http://drupal.org/node/366464 )

I'm rambling. Sorry.

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Priority: Normal » Critical

marking critical. basically, we need a way to pass the old url to the deploy because the url is somehow changed before deploy happens.

adrian’s picture

adrian CreditAttribution: adrian commented
Status: Active » Needs review
FileSize
provision_fix_clone.diff968 bytes

The issue is in the calling code :


function drush_provision_drupal_post_provision_deploy($url) {
  provision_prepare_environment();
  _provision_drupal_create_settings_file($url);
  provision_save_site_data($url);
  // call the drush updatedb command.
  drush_backend_invoke("updatedb", array('uri' => "http://$url"));
  // We should be able to fully load Drupal now.
  if (drush_bootstrap(DRUSH_BOOTSTRAP_DRUPAL_FULL)) {
    drush_include_engine('drupal', 'deploy');

As you can see, it needs to regenerate the settings.php and the drushrc.php for the updatedb to work properly.

Try this 2 line patch, which sets a process option called old_site_url right after initially loading the config file , so it can't be messed with.

adrian’s picture

adrian CreditAttribution: adrian commented
FileSize
provision_fix_clone3.diff355 bytes

D'oh ..
drush_get_option has the place in the stack as the third parameter.

second is the default (like variable_get)

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Needs review » Fixed

Committed the patch which fixed the value of $old_url, but to compound matters our UPDATE query for the files table was faulty:

db_query("UPDATE {files} SET filepath = replace(filepath, 'sites/%', 'sites/%')", $old_url, $new_url);

should be sites/%s . Committed that too and it all works as it should now.

Thanks guys

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

  • Commit cc83404 on debian, dev-dns, dev-envobject, dev-koumbit, dev-log_directory, dev-migrate_aliases, dev-multiserver-install, dev-newhooks, dev-nginx, dev-ports, dev-purgebackup, dev-restore, dev-services, dev-simplerinstaller, dev-site_rename, dev-ssl, dev_dns, dev_server_verify, prod-koumbit, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-subdir-multiserver, 6.x-2.x-backports, dev-helmo-3.x by mig5: 
    #710652 by adrian - set old_url properly. Also, fix files table UPDATE...