I've got a D7 site (site.com) running on a custom platform, with a site alias domain for development (dev.site.com).

I've got some imported content that I massaged to get the images to show up properly, and they do on the main domain, but they don't on the dev site. I get a 404 instead. The paths are as follows:

http://site.com/files/old/a/filename.jpg (works)
http://dev.site.com/files/old/a/filename.jpg (broken)

In the past (D6, main aegir instance in Barracuda) I remember seeing a symbolic link in the sites directory that I'm almost positive would fix this. But in this octopus instance, I only see sites.php making the site aliases known.

Is this something I should fix by simply creating a symbolic link manually? Why aren't they being created automatically? Is this a bug I should file?

Thanks in advance,
-Joseph

Comments

omega8cc’s picture

omega8cc commented
Project: Octopus » Provision
Version: » 6.x-2.x-dev
Component: Documentation » Code
Category: support » feature

This is how Aegir works, it is nothing BOA specific.

Previously it created symlinks also for D7 sites, but later we switched to use native D7 method - the sites.php file, which obviously can break paths to some files when using domain alias, especially with Nginx, as it never sends those requests to Drupal, because they are handled as static files directly.

Maybe we need to revert it and manage symlinks also for D7 sites, at least to avoid breaking images when Nginx is used (but maybe it is the same with Apache - no idea).

This is why I'm moving this issue to Provision queue.

omega8cc’s picture

omega8cc commented
Title: some images broken on site aliases » Some images broken on site aliases when D7 based platform is used
Category: feature » bug

Changing the title as it affects only D7 based sites.

jtbayly’s picture

jtbayly commented

Thanks, omega8cc! Now I know a bit more about Aegir.

Does anybody know of any reasons I *shouldn't* manually create a symlink? Will it break other things?

Oh, and if I do, are there any special flags I should use?

Any advice much appreciated on this one.
-Joseph

omega8cc’s picture

omega8cc commented

If you will create any symlink there, Aegir will delete it on the next site verify.

jtbayly’s picture

jtbayly commented

Ahh... That's another very helpful piece of info. Unfortunately, it's not the info I was hoping for.

Thanks,
-Joseph

omega8cc’s picture

omega8cc commented

FYI: we reverted this in BOA, so it creates symlinks for D7 sites again: http://drupalcode.org/sandbox/omega8cc/1074910.git/commit/ae88d9d

jtbayly’s picture

jtbayly commented

That's excellent.

Thanks again,
-Joseph

omega8cc’s picture

omega8cc commented
Status: Active » Closed (duplicate)

Update: we have reverted this again in BOA head, so it no longer creates symlinks for D7 sites, after the real issue has been fixed properly: #1544144: Use $server_name instead of $host in all sites/ paths to avoid broken URLs to static files for domain aliases in D7 (Nginx)

d.sibaud’s picture

d.sibaud commented

the real issue seems to be fixed, but the broken image links issue still persist, is it possible to revert the http://drupalcode.org/sandbox/omega8cc/1074910.git/commit/ae88d9d in the head and may be on the next stable release?

thanks

d.sibaud’s picture

d.sibaud commented
Issue summary: View changes
Status: Closed (duplicate) » Needs review

the real issue seems to be fixed, but the broken image links issue still persist, is it possible to revert the http://drupalcode.org/sandbox/omega8cc/1074910.git/commit/ae88d9d in the head and may be on the next stable release?

thanks

PS: sorry for the duplication, I was commenting instead of updating the issue

helmo’s picture

helmo commented

Could this be related to: #2157785: Deploy_7 code lacks functionality from D6 code.

That code is supposed to changed url's in the content on e.g. migrate and clone tasks.

helmo’s picture

helmo commented
Status: Needs review » Closed (works as designed)

@d.sibaud: the commit you mention already seems to be reverted in the 7.x-3.x branch.