Custom assets in /uploads/default/customizations give 404 after upgrade to v1.4.0.beta10 +291


(Lee_Ars) #1

After doing a launcher app rebuild this morning to get onto the latest Discourse, I’ve run into issues with loading some customized site assets that worked prior to the upgrade: self-hosted @fontface assets, and, weirdly enough, my site’s favicon.

I’d created a directory at /var/discourse/shared/uploads/default/customizations to hold this stuff, along with the site’s big and small header images. Looks like this:

As of this morning, most, but not all, of the things in that directory are showing 404. For example, in this screenshot, we’ve got the file d-logo-wide-copse.png, which is the site header image, and it’s definitely being loaded. The woff files aren’t:

I can also successfully grab the site headers out of that directory with curl, while the other files (including the favicon!) return Discourse’s 404 error.

As a workaround, I tried uploading the favicon to a temporary topic in Staff, and that appeared to work; I can do this for the @fontface files, but man, that’s an ugly, ugly, ugly ass workaround. Do you guys have any insight into why the neat and tidy custom location is suddenly puking?

(To forestall a response I’ve seen elsewhere, no, using Google web fonts or another offsite font-host doesn’t give me the flexibility I want—been there, done it, abandoned it.)


(Kane York) #2

Here’s the git log for the nginx file: History for config/nginx.sample.conf - discourse/discourse · GitHub

This might be relevant:


(Lee_Ars) #3

Yeah, not entirely sure if that help me or not, sadly. I was trying to be neat with where I’m keeping custom assets, but afaik the assets directory specified there is inside the container, and that probably isn’t going to work.


(Sam Saffron) #4

The cliff notes is, enter container, edit your nginx conf so it works properly for you and does try file on these files, keep track of your changes, then apply that diff on rebuild with a hook…


(Lee_Ars) #5

This is what I get for not really paying attention to the in-app nginx config! Will give it a shot. Thanks!

edit, a few minutes later:

Looks like that worked! Thanks for the point in the right direction. I didn’t want to get wrapped up into having to maintain a separate hook just for my particular nginx config, but at least for now it looks like it works.

For reference, here’s what I inserted into the in-container discourse.conf file:

location ~ ^/uploads/default/customizations/ {
    try_files $uri =404;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $thescheme;
    proxy_set_header X-Sendfile-Type X-Accel-Redirect;
    proxy_set_header X-Accel-Mapping $public/=/downloads/;
    expires 1y;
    add_header Cache-Control public;
}

I inserted this between the # Cache Emojis location blcok and the ^/uploads/ location block (because, for anyone reading this who has run into similar trouble, nginx processes location blocks in order and I wanted my subdirectory’s config to clobber the inherited config for /uploads/).

Perhaps a more elegant way to supply custom assets like favicons and font-face files would be to allow a subdirectory immediately beneath shared to function as the site asset repository? Not sure if that’s a viable feature request or not, but it definitely would help.

Thanks again guys!


(Lee_Ars) #6

Wanted to revisit this for a more permanent solution on my end and also to apologize to @sam for being dumb, since I’m having trouble figuring out how to implement.

I think the way to make this change permanent is to add another yml file to /var/discourse/templates and use run: to stuff the changes above into discourse.conf, then add that new template to my app.yml file.

It looks like the way to do append the extra location block I want to discourse.conf is with the replace: command, but I am having an impossible time finding what the hell replace takes as syntax. Maybe I’m looking in the wrong place, but I don’t see it in the run reference, the extends reference, the docker-compose.yml reference, or even when I do something like this.

I hate to ask for help on this since I’m sure the answer is simple, but I could use a nudge in the right direction :frowning:


(Sam Saffron) #7

Have a look at some examples: eg discourse_docker/web.socketed.template.yml at master · discourse/discourse_docker · GitHub

This is not docker compose, it is pups

replace will replace a “string” or “regex” with whatever string you want for a particular file.

sorry for delayed replied, we had a team meetup last week