CSS styling breaks when 404 page is served on nginx server

[itsjusttriz]

Context

incase you need to check on the production site. https://docs.itsjusttriz.com/

Bug description

Im having an issue with getting the default 404 page to render?

If the url path is not valid, its just breaking the page altogether instead of rendering the builtin 404 error. Yet it works in dev?!

Related links

• Reporting a bug

Reproduction

Im not actually sure if there's any specific steps ive done differently other than creating my mkdocs project, and then importing things from material & using them?!

However, the repo is here if you wanna take a look. - https://github.com/itsjusttriz/ijtdev-docs
The only thing ignored from this repo is the site/ directory.

Steps to reproduce

1. Read above

Browser

No response

Before submitting

• I have read and followed the bug reporting guidelines.
• I have attached links to the documentation, and possibly related issues and discussions.
• I assure that I have removed all customizations before submitting this bug report.
• I have attached a .zip file with a minimal reproduction.

[squidfunk]

Thanks for reporting. Yes, yes, yes, we need a reproduction, because without it, we can't investigate. You might want to check why assets are not loaded. I'm converting this to a discussion, so others can help you. It is, very likely, not a bug.

[itsjusttriz]

Im not 100% sure how to do the reproduction? Ive looked through the "minimal reproduction" section and i dont fully understand it... and I also know nothing of Python. I just copypasta'd the steps needed to use mkdocs from the beginning.

[kamilkrzyskow]

You're once again being too ambiguous with saying "Im not 100% sure how to do the reproduction?" just like before with "im not exactly sure how to go about this thought ;-;", which just leads to nothing of substance.

You need to be way more specific with explaining exactly what instruction isn't clear enough, what you did and when you got an error etc., and no I don't mean just posting screenshots of your website.
The point of the minimal reproduction is that you create a clean template project with the mkdocs new . command and then add the theme with features one-by-one until you encounter the error, then you create the zip using the info plugin, which you enable like all other plugins in mkdocs.yml. This zip allows running the example on our machines to check if it's a bug or a problem with configuration or your setup etc.
Since your issue is related to deployments then you also have to deploy the minimal example somewhere temporarily (e.g. repository with GitHub actions) to make sure the problem persists.

Setting up the minimal reproduction from scratch basically:

• Assures you didn't misconfigure anything
• Assures that we're on the same page when it comes to understanding what the issue is
• Assures it doesn't have any unnecessary fluff
• Allows to run the example on our machines without having to analyze the deployment

---

But alas, having said all that I did check the deployment and the assets on the 404 page use relative urls instead of absolute 🤔
assets/stylesheets/main.50c56a3b.min.css =/= /assets/stylesheets/main.50c56a3b.min.css
And when I build or serve your main branch of the repository locally the generated 404.html page does have absolute urls, so the public configuration doesn't have any issues.

So perhaps the issue is in the deployment 🤔 I doubt that the back-end server somehow converts absolute link to relative ones, because what for 😵 but still it's worth investigating.
How do you deploy to your https://docs.itsjusttriz.com/, you upload the site/ directory you build locally, and it does contain a 404.html with absolute links?

EDIT:
After having a second look at it, I've noticed that your 404 page contains the Coming Soon... text same as your index.md. This means that you did override the 404.html template because the default message is just a plain not found. This means to me that the GitHub repository source isn't the same as the source you used to deploy.

[itsjusttriz]

im not entirely sure how ive managed to override the 404 page, if this is the case, cus i dont fully understand the whole partials/templates thing yet?! I got help with overriding the copyright part, but when using mkdocs serve, if i go to an invalid path it shows the default 404 page, yet when i push to production, i get the broken website issue?! Im not sure how youre managing to see the Coming soon on the 404 page as i dont even know how to edit that?!

Whatever is shown on the github repo is exactly as is, on my pc & my server. The only thing missing from this repo is the items listed in the .gitignore file. Each time i run mkdocs build, i completely destroy the site/ directory so that everything is fresh in the build.

[kamilkrzyskow]

You're right that https://docs.itsjusttriz.com/404.html does exist, so it's my fault for not checking it thoroughly. If it's not an override then the previous idea still stands, check your deployment settings / process etc.

Doing a diff compare of the HTML source between view-source:https://docs.itsjusttriz.com/ and view-source:https://docs.itsjusttriz.com/123/123/ results in a prefect match. So the web server implementation serves the /index.html file in case of a invalid path (it doesn't even send the 404 status), and it should serve the /404.html file, as it contains the absolute paths to assets.

So contact your server provider, though serving 404 on invalid path should be the default anyways, so perhaps your server is some custom built NodeJS with Express app. If so, you need to handle the invalid URLs yourself in the app logic. This is beyond the scope of this discussion board.

Only 200 status despite invalid 123 path

[itsjusttriz]

nah im using ubuntu on my server and have nginx managing the routing. I just tried adding

# Custom error page for 404 errors
    error_page 404 /404.html;
    location = /404.html {
        root /var/www/html/ijtdev-docs/;
        internal;
    }

to my nginx.conf and reloaded and im getting same issue.

[itsjusttriz]

Well keep in mind this is not the only static frontend im serving from my webserver. So your implementation of the error_page may be different from what i need.

[itsjusttriz]

Also i just ran that exact curl and it shows 200 for me?

[kamilkrzyskow]

It's still 404 on my side despite the HTML being loaded, but I doubt it's what you should focus on.

Well keep in mind this is not the only static frontend im serving from my webserver. So your implementation of the error_page may be different from what i need.

True, I only used the default.
So copy the .conf from your remote server and then try to replicate the behaviour locally instead of using mkdocs serve

Shell Log

$ curl -I https://docs.itsjusttriz.com/404.html
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0 15431    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0HTTP/1.1 404 Not Found
Server: nginx/1.18.0 (Ubuntu)
Date: Thu, 25 Jan 2024 11:55:39 GMT
Content-Type: text/html
Content-Length: 15431
Connection: keep-alive
ETag: "65b2196d-3c47"

Firefox Dev Tools

[itsjusttriz]

i think my changes might not have overridden what was cached, as when i try it all now, it shows the default mkdocs 404 page as it should.

[kamilkrzyskow]

Great, I shall select your comment as the answer then, as this solved it (?) you can edit it later to add more context for the fix or any other pointers if you want to.

[itsjusttriz]

Answer: I re-configured my nginx config as follows:

server {
        server_name docs.itsjusttriz.com;

        root /path/to/site/root;  # Adjust based on your actual setup
        index index.html;

        location / {
                try_files $uri $uri/ =404;
        }

        error_page 404 /404.html;
        location = /404.html {
                root /path/to/site/root;  # Adjust based on your actual setup
                internal;
        }
}

This is relying on my 404.html being in the same directory as my index.html

Keep in mind, the problematic view may still be cached and served. You'll need to check on it every now and again.