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

omega8cc’s picture

OK, 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.domain

While it should say obviously:

Changed paths from sites/old.domain to sites/new.domain

WTF?

Note that it works for D6 sites without issues.

omega8cc’s picture

Status: Active » Needs work

This needs work.

AquaticDisorder’s picture

subbing

anarcat’s picture

Status: Needs work » Postponed (maintainer needs more info)

Hmm... 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?

omega8cc’s picture

Title: Paths to images are broken in D7 after site clone/rename » Paths to images are broken in D7 after site clone/rename for sites upgraded from D6

Yes, 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.

omega8cc’s picture

And 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.

omega8cc’s picture

So, 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.

omega8cc’s picture

Status: Postponed (maintainer needs more info) » Needs work

OK, 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.

omega8cc’s picture

Status: Needs work » Needs review

I'm attaching commit for review. The reason there is also files table 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_managed table.

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

omega8cc’s picture

Priority: Critical » Normal

This 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.

anarcat’s picture

Status: Needs review » Needs work

Okay, 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?

omega8cc’s picture

Status: Needs work » Closed (won't fix)

I 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.