Document how to instruct your local to load media from elsewhere

[kadamwhite]

Describe the solution you'd likec

In Chassis we recently implemented a media_fallback extension, which adds an nginx config file to try loading media from another fallback host (e.g. a staging environment) if the file does not exist within the local VM:

# Fall back to a production URL for any local jpg, jpeg, gif, or png which 404s.
location /content/uploads/ {
    # Nesting required to take priority over "location /content/" in Chassis conf.
    location ~* \.(jpe?g|gif|png)$ {
        try_files $uri @productionImages;
    }
}

location @productionImages {
    rewrite ^/content/(.*)$ <%= @fallback_host %>/$1 break;
    return 403;
}

This is really useful, because it means the database itself is the only thing you need to download and import when setting up your Chassis VM — media and images can be ignored, and your local will magically work by downloading the images from the staging site instead of your local.

To speed up local-server setup times for Altis projects, and to reduce the amount of exported data that has to live on your local machine, I propose we document how to do something like this in Altis, as well.

I assume that given Tachyon, this may be more a matter of re-pointing to actual S3 buckets or something, rather than strictly nginx-rewriting ourselves to use production. But I'm not entirely clear on what the solution would look like, so I'm opening this to track a discussion.

Per @roborourke,

the .config/nginx-additions.conf file is supported on local server but you’d have to add it in a location block that matches against the local hostname if you were to commit that file

this is something that'd be easier to do when the docker compose file is generated in PHP

[roborourke]

Yeah as you say, Tachyon is accessed directly and nginx does not handle 404s for those requests. It could be configured with details for the live S3 bucket and given appropriate credentials but would need to handle image paths that aren't served by Tachyon as well.

I'm not keen on being able to upload or interact with media files on cloud stacks, I think it should be read-only as a fallback from the local environment, unless you really know what you are doing.

We could explore having a composer.json config setting for the fallback URL for uploads, and then seeing if it's possible to route 404s to nginx via traefik.

[roborourke]

I think it only supports modifying incoming requests but there's a traefik errors middleware that allows for routing error pages to another service. That might let us route errors to nginx.

Alternatively we'll have to look more seriously at moving to something like Caddy which I think can do response modification, or a Caddy / Traefik combo.

[roborourke]

💥 adding the following labels to the tachyon container worked for redirecting 404s to the nginx container:

- "traefik.frontend.errors.tachyon.status=400-499"
- "traefik.frontend.errors.tachyon.backend=nginx"
- "traefik.frontend.errors.tachyon.query=/tachyon-{status}.html"

I think we perhaps still need #159 first but this approach certainly has legs.

Raises a further question about adding support for custom error pages on our production stacks too 🤔

[kadamwhite]

WP VIP's lando-based environment has a media proxy option which does what we've been describing here: https://docs.wpvip.com/how-tos/dev-env-add-media/#h-proxy-media-files