Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Some modules will store the path of a site in the 'variables' table. For example, xmlsitemap stores the xmlsitemap_cache_directory hard-coded in the variables directory.
The solution was to update the variable in the table manually. (I actually deleted it and cleared the cache since the module then generates the correct value).
Is this the responsibility of aegir or of the module developer, and can aegir handle this issue when cloning?
Comment | File | Size | Author |
---|---|---|---|
#27 | provision-clean_up_path_rewrites-905326-27.patch | 4.31 KB | ergonlogic |
#26 | provision-rewrite_user_picture_path-905326-26.patch | 810 bytes | ergonlogic |
#26 | provision-clean_up_path_rewrites-905326-26.patch | 4.25 KB | ergonlogic |
#20 | provision_905326.patch | 1.21 KB | crea |
#17 | provision_default_user_picture_905326.patch | 850 bytes | crea |
Comments
Comment #1
Anonymous (not verified) CreditAttribution: Anonymous commentedMoving this ticket into Provision, which kind of answers your question: we *do* do some switches when the *new* database is bootstrapped for a site that's in the process of migration/clone.
How we could capture all possible cases is a bit tricky, happy to discuss it here.
FYI, have a look at /var/aegir/.drush/provision/platform/drupal/deploy.inc
The provision-deploy (which is the nuts and bolts of what makes migration/clone work) invokes this 'engine' once bootstrapped, allowing us to do a bunch of queries and variable_sets to account for this sort of thing.
See also this related ticket #791262: Color module & theme logo/favicon paths not updated during site deployment
Comment #2
dsobon CreditAttribution: dsobon commentedI'm working on this (and all site path) issues as we speak.
I will upload a patch once testing has nailed all the instances where it needs to be updated.
Comment #3
anarcat CreditAttribution: anarcat commentedNarrowing this down - we're doing our best to cover most cases here, as mig5 mentionned, but it's possible we missed the variables table or some parts of it. Please document other such instances here even if you don't have a fix for it.
Thank you for your work.
Comment #4
dsobon CreditAttribution: dsobon commentedOK. three instances that I cannot fix are:
1) *.tpl.php files that contain references to /sites/oldsite.com/files/. this must be UPDATED by hand.
2) custom modules written to attempt including files from /var/aegir/platforms/SOME_PLATFORM_NAME/sites/SOME_SITE_NAME/modules/
3) imagecache appears to have a regex that looks for ^/sites/oldsite.com/files/ and replaces it with /sites/newsite.com/files if it matches, otherwise it _appends_ to the original path, ending up with /sites/oldsite.com/files/imagecache/sites/newsite.com/files/imagecache/ or something very similar. So if you install the site with a different sitename, access it, then migrate it, this is the result.
#1 and #2 are web development practice issues. #3 is a module-specific issue. My patch will resolve issues that are database-related. I'll post it early in the week once I've isolated more problems other than the above listed.
Trying to implement a production, staging and development environment requires that path names and hostnames can be migrated with zero issues.
Is there a drupal / aegir best-practices web development guideline? This would reduce time and effort spent trying to undo mistakes, especially if dealing with 100+ sites in a production & development environment.
Comment #5
dsobon CreditAttribution: dsobon commentedOK. #3 is another tpl.php problem.
You may ask why it iterates through all the aliases... this resolves half-baked site-rename manual migrations from broken aegir installations.
Anyway... patch attached.
Comment #6
dsobon CreditAttribution: dsobon commentedComment #7
omega8cc CreditAttribution: omega8cc commentedThe patch from #5 needs review - changing status.
Comment #8
omega8cc CreditAttribution: omega8cc commentedThe patch from #5 doesn't apply to the master. Please reroll and change status to needs review.
Comment #9
omega8cc CreditAttribution: omega8cc commentedAlso, please don't use tabs in the code - replace them with spaces: http://drupal.org/coding-standards#indenting
Comment #10
omega8cc CreditAttribution: omega8cc commentedA quick note: I think you shouldn't limit paths rewrites to
sites/%s/files
, as there can be other URLs used in the sites/domain path, for example paths to themes or modules or private files etc. so it should be alwayssites/%s
.Also, there should be no trailing slash in the pattern, to avoid missed replacements.
Comment #11
omega8cc CreditAttribution: omega8cc commentedUpdated and simplified patch for paths rewrite on clone/migrate:
http://drupalcode.org/sandbox/omega8cc/1074910.git/commit/38a8e47
Comment #12
anarcat CreditAttribution: anarcat commented1. there are whitespace/unrelated changes again (in nginx)
2. i don't think we should update the menu_links, menu_router and system tables - that's get dealt with by the cache rebuilds
3. i do not understand what this is for:
... it seems too broad. The xml_sitemap stuff should be refactored as:
... for simplicity.
Comment #13
omega8cc CreditAttribution: omega8cc commentedYep, I just noticed it got some unrelated bits, sorry.
The replace (3) is probably to replace absolute URLs in the content (it happens often when people are using wysiwyg editors to paste images).
I just rewrote a bit the patch from #5, but will reroll it.
Comment #14
omega8cc CreditAttribution: omega8cc commentedI hope this one is better:
http://drupalcode.org/sandbox/omega8cc/1074910.git/commit/3360cbbdc7dbfc...
Comment #15
anarcat CreditAttribution: anarcat commentedlooking good, committed, thanks.
Comment #17
crea CreditAttribution: crea commentedFollow-up: update default user picture variable
Comment #18
anarcat CreditAttribution: anarcat commentedi don't think the $pattern variable is necessary here, just inject the pattern right in there.
in fact, we usually use str_replace() in the orther locations, why use a preg in this case?
this way this could be shortened to a single line...
Powered by Dreditor.
Comment #19
crea CreditAttribution: crea commentedpreg_replace() is more reliable because you can specify beginning of the string. str_replace() is dangerous because you could mis-replace the pattern in some non-filesystem path.
I would change str_replace() to preg_replace() everywhere if I was you, but I think that deserves a different issue..
Comment #20
crea CreditAttribution: crea commentedAdded smileys module support
Comment #21
omega8cc CreditAttribution: omega8cc commentedI'm not sure we should add fixes for any possible/existing contrib modules, because it never ends then, so I vote "no" for adding it for smileys here, because it is a bug in the module if it stores path to the images in its own table instead of using standard system path to files.
Comment #22
crea CreditAttribution: crea commentedI agrree that making smileys use fid instead of path would be better in theory, however, it's much harder to convince the maintainer to rework the module and it takes time to release new version with upgrade path. Meanwhile we need a fix for existing installations, otherwise we are just forcing everyone either to fork provision (as I did already) or to fork smileys. I'm not convinced that forking is a good solution here.
I see no reason not to include fixes for modules, they are harmless.
Comment #23
anarcat CreditAttribution: anarcat commentedAgreed. No to smileys! :) Seriously, we can't cover all third party contrib modules like this, it would be insane. Feel free to make a custom module for that. I think we should support whatever is in core.
Comment #24
crea CreditAttribution: crea commentedWhen did I ask to cover ALL third party contrib modules ? There will be probably only several which have problems with filesystem path.
I thought Aegir was made to manage real installations, not some ideal-world-all-perfect-code-modules sites.
Get out of your developer sandbox. Welcome to real world, Neo
Comment #25
anarcat CreditAttribution: anarcat commentedWow, what's with the attitude, Morpheus? Want sunglasses with that comment?
Seriously, you need to understand our position here. *You* didn't ask for *ALL* modules, but as a whole, the community is incrementally asking to support more and more of those. I was just suggesting that *maybe* some of those can go into contrib.
Besides, if you want to support the smileys module in Aegir, make an issue about it, do not hijack another unrelated issue.
I am still waiting for a patch that will answers the issues I have pinpointed in #18. I am ready to concede on your point about preg_replace vs str_replace, but you still have an extra variable there.
Thanks.
Comment #26
ergonlogicHere's a re-roll of the patch from #17 removing the extra variable.
I also took the liberty of creating a second patch cleaning up the rest of the file. In this case, I used a variable for the regex pattern, since I replaced str_replace() with preg_replace() throughout, as per #19 and #25.
Comment #27
ergonlogicOops, I made a copy/paste error in that second one. re-rolled.
Comment #28
anarcat CreditAttribution: anarcat commentedstrictly speaking, this regex is not the same as the str_replace: it will replace data only at the beginning of the string, but that may be harmless.
other than that, this looks okay.
Comment #29
ergonlogicThat was the point in #19 to which you were agreeing in #25, no?
Fixed in 0b6bb1b.
Comment #30
anarcat CreditAttribution: anarcat commentedtrue, thanks.