Using production images with www. prefix

[joelworsham]

I pulled down a live site to work on locally, and selected Yes for using images from the production server.

A lot of the images still come up as 404. I realized that any image that was hardcoded into the site with the prefix "www." comes up 404. If there is no "www.", then it pulls from production fine. I even went in after the page loaded and, via chrome inspector, manually removed the "www." from one of the broken images, and then it immediately loaded the production image fine.

How can I fix this so that it loads from the production server for both the url not containing "www." but ALSO the url that does contain "www."?

[chriswgerber]

Images are hardcoded into WordPress, so it's hard to fix the problem locally. It would be easier to solve the problem on the production server.

Have you considered setting up a www.example.com. DNS record on your production server to point to the same document root as example.com.? Do you have any reason to not have non-www traffic pointing to www or vice-versa?

[joelworsham]

I don't believe that's the issue. The images on the production server will still load even with the "www." prefixed (EG: "www.example.com/some-image.jpg" and "example.com/some-image.jpg" both work).

My best guess is that nginx isn't noticing the images locally because they are "different". The exact url of the development site does not have the "www.", so "example.dev", whereas some of the images on the page are referencing "www.example.dev". So it seems that nginx isn't attempting to "re-route" them.

Though I don't know much about nginx server configuration, so I'm not sure.

[chriswgerber]

What happens if you define WP_Home and WP_SITEURL in the local wp-config.php?

define('WP_HOME', 'http://example.dev/');
define('WP_SITEURL', 'http://example.dev/');

[joelworsham]

Nothing seemed to change. Still broken images ONLY when the source is prefixed with "www."

[joelworsham]

Just to further clarify exactly what's happening.

In the first image (broken), you can see the broken image and the img tag associated. It has the "www." prefixed.

In the second image, I didn't even refresh the page, all I did was manually edit the src tag via Chrome inspector and remove "www.", and the image immediately loaded.

[chriswgerber]

So you have images loading that are pointing to both http://example.com/ and http://www.example.com/, and the images that are causing problems are those pointing from http://www.example.com? Does the local URL contain the WWW and production does not? Just trying to make sure I'm understanding this correctly, because I think I'm missing something.

It seems like it's something to do with the Nginx proxy configuration. Check the conf file for the site: vagrant-local/config/nginx-config/sites/site-name.conf. Is it properly set up to route www.example.dev (local) file requests to www.example.com (prod)?

[joelworsham]

Correct. Typically, prefixing an image path with "www.", even when the site does not contain "www.", will still work, it just has to redirect to the correct domain. So users and admins have made some image paths to "www.example.com" and some to "example.com". I would like for BOTH references to pull images from the production site, but it seems that for any image with a src that has "www." nginx doesn't even attempt to pull an image.

And, yes I believe so, but not for www. I'm not sure how to set it up to detect images on the local site from both www. and without.

This is the current contents of that section:

# Directives to send expires headers and turn off 404 error logging.
    location ~* .(png|jpg|jpeg|gif|ico)$ {
        expires 24h;
        log_not_found off;
        try_files $uri $uri/ @production @productionwww;
    }

    location @production {
        resolver 8.8.8.8;
        proxy_pass http://ncantonlibrary.org/$uri;
    }

[chriswgerber]

Do you have anything for the @productionwww location? try_files searches in those 4 locations for a file before moving on. http://nginx.org/en/docs/http/ngx_http_core_module.html#try_files

Does adding the below block to the end of the conf file (and restarting nginx) help?

location @productionwww {
    resolver 8.8.8.8;
    proxy_pass http://www.ncantonlibrary.org/$uri;
}

[joelworsham]

Oh, actually I added that "@productionwww" previously when tinkering with it, and I had a location for @production like that, but it didn't work, because it's not an issue with finding the production file, it's an issue with nginx even deciding to look at all.

[chriswgerber]

Can you paste your entire conf file for the dev site to a gist?

[joelworsham]

https://gist.github.com/joelworsham/520ad2dabd44eb96ba17

[chriswgerber]

What happens when you send all www.example.dev requests straight to example.dev by adding another server block just before the main server block?

server {
    listen       80;
    server_name  www.example.dev;
    return       301 http://example.dev$request_uri;
}

server {
    listen       80;
    server_name  example.dev;
    ...
}

[bradp]

I'd suggest checking out VV, we've gotten image proxying working pretty well without a problem.

[joelworsham]

+1 @bradp I do actually use that now.

@ThatGerber Thanks for all of your help! I didn't end up getting it in the end, but I also haven't been able to give the issue much time lately.