Closed (won't fix)
Project:
Provision
Version:
6.x-1.1
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
22 Jun 2011 at 04:37 UTC
Updated:
26 Aug 2011 at 16:54 UTC
The problem is that the "files" table used in D6 have been renamed to "file_managed" in D7, while Aegir rewrites paths only in the "files" table and in the node_revision table etc.
Comments
Comment #1
omega8cc commentedOK, so I applied this patch: http://drupalcode.org/sandbox/omega8cc/1111100.git/commit/ee8bc04
But - surprise! - it doesn't work.
What is weird, the log for the migration/rename task says:
Changed paths from sites/new.domain to sites/new.domainWhile it should say obviously:
Changed paths from sites/old.domain to sites/new.domainWTF?
Note that it works for D6 sites without issues.
Comment #2
omega8cc commentedThis needs work.
Comment #3
AquaticDisorder commentedsubbing
Comment #4
anarcat commentedHmm... I thought D7 wasn't affected by those problems, and that you simply *didn't* have to change those paths, as they were now relative to the files dir.
Are you sure the "files_managed" directory has the sites/foo path?
Comment #5
omega8cc commentedYes, there are sites/foo paths for sites migrated/upgraded from 6.x. That is how we discovered this problem (or rather one of our clients). So it is confirmed to be a critical issue. Changing the title to reflect this.
Comment #6
omega8cc commentedAnd steps to reproduce the issue:
1. Clone the site in the 6.x platform to prepare for 7.x upgrade (so you have to use temp subdomain).
2. Step nr 1 will cause paths change from sites/domain to sites/temp.domain.
3. Migrate/upgrade the cloned site to 7.x platform and make sure everything works.
4. Rename original, live site to old.domain.
5. Rename upgraded temp.domain site to domain.
6. Now all paths to images/files are broken, as they are still sites/temp.domain.
Comment #7
omega8cc commentedSo, maybe for D7 upgrade we just need to remove the sites/foo from the paths? We could check for "file_managed" table existence to know when we need to do it, however it sounds a bit dangerous to me.
Comment #8
omega8cc commentedOK, what a dumb mistake - I tried to patch deploy.inc while it should go to deploy_7.inc.
I will try how it works when added in deploy_7.inc, but I already discovered we didn't introduce Drush 4.x compatible changes in deploy_7.inc at all, so it could be broken already long time ago and went unnoticed only because paths in D7 are now relative to files system path.
Comment #9
omega8cc commentedI'm attaching commit for review. The reason there is also
filestable is that the table is always copied as-is from D6 to D7 on migration/upgrade and it is better to maintain paths changes there, if the table exists.The question is however if we should replace paths or just drop them if existing in the
file_managedtable.Note that this patch fixes also issue with bad paths written in variables before - due to lack of support for both Drush 3.x and 4.x.
The commit: http://drupalcode.org/sandbox/omega8cc/1111100.git/commit/0d3e49f
Comment #10
omega8cc commentedThis is not critical, IMO. Without this patch there are still correct paths set in variables and in the settings.php and only task log displays wrong info: "Changed paths from sites/new.domain to sites/new.domain" which is cosmetic, tiny issue only.
We need others testing if this patch helps them in the D6 to D7 upgrades. It works for me and resolves a few clients issues, but I have no idea how site specific it is, so let's leave it in the needs review status.
Comment #11
anarcat commentedOkay, so if i understand this correctly, sites/foo shouldn't actually *be* in the files table in D7, so why don't we simply remove it instead of replacing?
Comment #12
omega8cc commentedI think we can skip this entirely, as it is specific issue for some upgrades only. Furthermore, D7 has many more issues, because the D6->D7 upgrade path doesn't exist in fact.