CiviCRM Community Forums (archive)

Cool, that makes sense. I think it's fine to keep the hook -- but for now maybe we can cut out the caching of the hook. It feels a little premature, and it should be a null-op on most systems.

Next up: "doSiteMove()", "civicrm/admin/setting/updateConfigBackend", "bin/migrate/move.php", "drush civicrm-update-cfg", "wp civicrm update-cfg".

I don't claim to fully understand these, but a few things pop out in skimming:

• There are several clauses which heuristically adjust paths based on CMS conventions. (Yaaay, brittle!)
• There's some search-and-replace on the non-existent 'url_preferences' and 'directory_preferences' OptionGroups. (There've been one or two hints that these things used to exist... perhaps as predecessors to the URL and Directory setting groups?)
• There's more "$$foo" stuff than I care for.
• It deletes a random assortment of cache data and session data.

Based on #2, this has probably been broken since ~v4.1, but (guessing here) the workflow around using it was so convoluted (*ahem* http://wiki.civicrm.org/confluence/display/CRMDOC/Moving+an+Existing+Installation+to+a+New+Server+or+Location ) that no one could tell whether (a) the tool was broken or (b) they were using it wrong.

Maybe this is wishful thinking, but... can we just delete this stuff in 4.7? With the refactored CRM_Core_Config, we'll no longer use  config_backend (which has been caching the absolute-paths/absolute-URLs). In their canonical storage (table "civicrm_setting"), the URLs+paths have been stored as relative-paths (unless you specifically pointed outside the normal basepath). I'm struggling to see why this would be needed for a typical migration. Just flush the caches.

To be sure... if you've created a funky file structure (with items outside the normal basepath), then you need to adjust path/URL settings... but if it's a funky structure, then... is it really amenable to simple/predictable conversion? Feels simpler/more predictable for the admin to update or delete the settings directly (via drush or bin/cli.php or SQL or $civicrm_setting or whatever).

But I'm biased.

Would anyone miss it if removed? Has anyone used this successfully since v4.1?

I'm not too sure what the remaining problems are - I just hammer things until something works. Pretty sure in 4.6 that if you enter a relative url for extensions dir it miscalculates the full url unless it is under sites/default/files.

This makes some sense. The code which evaluates the relative path is generally based on figuring things relative to "sites/*/files/civicrm" - it wouldn't know how to adapt things outside that.

That code always gave me headaches. I took the habit of overriding the url/directory settings by hardcoding them in a settings.php file.

I think that overriding the settings made doSiteMove() irrelevant/unnecessary... which is consistent with my theory that doSiteMove() simply doesn't work.

A quick tally:

• Two respected/active devs found it easier to fix the settings directly (rather than fix doSiteMove).
• One dev (me) says the code in doSiteMove() looks broken.
• Zero people have spoken up for it. (I reached out to the full civicrm-planning@ to find someone.)
• Zero tests provide coverage of doSiteMove(). (Understandably - it's basically impossible to test without putting the entire stack into a test harness.)

So... I'll remove it and file a bug against the documentation.

The changes have been merged into master.

A side note on test performance -- towards the end of dev on this PR, the test performance seemed to improve (~50min runtimes), which is surprising considering that (a) we've been getting mostly 2hr-4hr runtimes in recent months and (b) I locally benchmarked a couple random pages+tests and didn't see a performance improvement.

Hard to tell if this is causation, an unseen variable, or just wishful thinking. Each is plausible. It'll be interesting to see if we get more 50min runtimes going forward.