0

Cheers fellow stackers,

I kinda have to get wordpress running in a self hosted nginx environment.

More or less exactly using the suggested config from NGINX wordpress doc.

server {
    listen 443 ssl;
    server_name _;
    ssl_certificate /var/lib/nginx/PKI/www/server/cert.pem;
    ssl_certificate_key /var/lib/nginx/PKI/www/server/key.pem;
    root /var/lib/nginx/www/wordpress;
    index index.php;
    location / {
            try_files $uri uri/ /index.php?$args;

    }
    location ~ \.php$ {
        include /etc/nginx/fastcgi_params;
        fastcgi_intercept_errors on;
        fastcgi_pass php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
            expires max;
    }
}

Everything works mostly as expected, except for the styling.

Admin login screenshot

(changed background color for visibility)

Also broken on the actual site:

enter image description here

(changed background color for visibility)

Inside of the admin dashboard, everything looks fine.

CSS files are being served properly by NGINX.

4
  • To be clear: I've only downloaded the wordpress tarball, extracted it into the "wordpress" directory thats being referenced in my nginx.conf and fired it up.
    – sxx
    Aug 31, 2021 at 21:28
  • 1
    does the css get applied if you create a simple html file with external css dependencies? this might have more to do with the server than with WordPress, in which case maybe try serverfault or superuser
    – admcfajn
    Aug 31, 2021 at 21:53
  • there's nothing in the browsers dev console? And if you visit those CSS files you get CSS?
    – Tom J Nowell
    Aug 31, 2021 at 21:59
  • I've double checked that all CSS files are available and get served by nginx. I've verified that a simple HTML doc + CSS are working proplery. Also, if I click any CSS link in the wordpress browser source, the CSS file is opened as expected. Nothing in the console.
    – sxx
    Aug 31, 2021 at 22:06

1 Answer 1

1

My nginx config did not include the mime.types defaults.

That seems to be affecting the nginx "Content-Type" response header, leading to it being "text/plain" instead of "text/css" ...

... which is unfortunate because none of the wordpress templates specify the content type in the request, e.g:

<link rel='stylesheet' id='wp-block-library-css'  href='https://censored.net/wp-includes/css/dist/block-library/style.css?ver=5.8' media='all' />

Should probably look anything like this, but oh well

<link rel="stylesheet" type="text/css" ...>
1
  • The Content-Type sent by the server will always override the attribute of the the link element. So you never need it.
    – fuxia
    Sep 1, 2021 at 4:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.