Aegir Pathologic Files

[niccolox]

I tried to follow, but no doubt couldn't do it properly, the 8 easy steps

the double migration for correcting file/image pathes

not only is it cumbersome workflow and it at the end it didn't work absolutely

what did work was Pathologic and Aegir Pathologic Fies
https://github.com/Lab43/aegir-pathologic-files

I really think these modules should be standard Aegir BOA modules

[omega8cc]

This is too complex workaround. The problem should be fixed via extra rewrites on the Nginx level. We did this before, but then reverted since it conflicted with scenario where sites/default was actually used to share huge files archive between sites on the same platform. So we would need to make it configurable, and default trick like this: omega8cc/provision@a7f3974 -- which allows to completely ignore the issue with possible hardcoded paths leftovers.

[niccolox]

again, like git platform provisioning, this is a major aegir pain point

the Aegir Pathologic Files and Pathologic combination is actually rather easy

I looked at the nginx rewrite and am unsure how to put that in practice

we use Aegir Pathologic Files and Pathologic in production now

we have an older, complex site, with all sorts of strange file folder patterns in HTML

Pathologic itself is a life-saver in this scenario, and I gather from the number of Pathologic users (approx 50,000), I am not alone thinking the configuration complexity is worth the effort

having said that, I would welcome a simpler approach than Pathologic / Aegir Pathologic Files

[macmladen]

I'd support this but not only for the problem of content paths which may be as well present in any field that may contain HTML including blocks, boxes, panels and entities.

Although it is not too relevant, the scheme sites/someverylongsitenameispossible.com/files/image.jpg makes very long URL paths and they are made even longer with image styles and some filefield_path organization.

Some out of the box, enforced solution would make easier transition between different site names and by eliminating site name (with prefix site and postfix files) every file URL would be considerably shorter, clearer to read and would make resulting HTML smaller.

[niccolox]

we migrated off Aegir BOA into Pantheon and stopped using this module

in migration we handled path changes with Drush Search and Replace module
https://www.drupal.org/project/sar
https://www.lullabot.com/blog/article/module-monday-drush-search-replace

its a powerful and useful module and I suspect could be used with Aegir

[omega8cc]

The sites/foo.com/files is a standard Drupal multisite scheme for files paths. It is not different from single site scheme, though. At least I don't see any difference in complexity between sites/default/files and sites/foo.com/files. Plus, nothing stops you from using sites/foo.com/file also when the site is exported and run in another environment. It is still just standard Drupal supported paths configuration.

While using short URLs where possible is nice, it depends on the web server ability to apply expected rewrites.

The problem is, we can't assume that it is always available, because we don't want to break compatibility with standard Drupal paths, in case the site needs to be exported and run in another environment.

There are no plans to enforce any non-standard shorter paths to files.

That is why this is a no-no to me: https://github.com/Lab43/aegir-pathologic-files

Requires an apache rewrite rule to point /files to /sites/example.com/files,
which Aegir provides by default.

[omega8cc]

In short, if you have a mess in the paths to files in any site, the proper way to deal with this issues is:

1. Follow Aegir/BOA best practices
2. Fix the paths in the site if this is not enough

Tricks or extensions designed to "eliminate" the problem by hiding it are not a proper way to deal with paths changes.

[omega8cc]

Furthermore, this is just not true:

Aegir does a good job of rewriting urls in file and image fields, but it doesn't change urls in body content.

[macmladen]

Er... that was not exactly what we both said, it wasn't about that.

His remarks was about the problem that some URL paths in various places, typed as HTML link, does not get translated when domain name is changed and that could, perhaps be solved with some pathologic-like technique.

My remark was that eliminating domain name from the path could eliminate not only that problem but also shorter link would be good for lighter page.

..not that I say it is plausible but I like that idea for my own reason so I was wondering if there is anything more in it.

And thanks for the https://www.drupal.org/project/sar tip, it may come handy not only for but including also a domain change.

[omega8cc]

There are two related but still separate issues mentioned in this thread:

1. Problem with sites/default/files changing to sites/foo.com/files
2. Problem with sites/foo.com/files changing to sites/bar.com/files

Both problems are a result of how Drupal core works. It has to use these paths because it can't expect that the web server will do the magic to point the request to the correct URI behind the scenes.

Furthermore, the magic is possible only for sites/default/files changing to sites/foo.com/files, but it is not for sites/foo.com/files changing to sites/bar.com/files, unless you will use both Pathologic and aegir-pathologic-files modules (but we couldn't enable them by default, I guess).

This would also require changes in Nginx locations and other rewrites, because currently the location ^~ /files/ shortcut works only for static files and not imagecache/styles. Otherwise it could break super-fast 404 in BOA for all static files.

But let's see if we can do that.

[omega8cc]

Related (not tested yet) commits:
omega8cc/provision@b1052c6
omega8cc/provision@c2c4f68

[omega8cc]

Please test and maybe post a how-to?

[drupol]

This module(https://github.com/Lab43/aegir-pathologic-files) is a life saver ! Thanks @niccolox !!!