I’ve created a 404 in Blocs and in nginx have set things up to point to it. Everything works great except once I start going into subfolders in my site hierarchy. For example something like:
…comes back with the 404 file being loaded but due to the internal CSS being relative, the style sheets never load. I could of course do a rewrite in nginx but I’m looking for a Blocs specific solution.
I tried adding this to the header:
<base href="https://mysite.com/">
…but unfortunately Blocs adds this after the CSS lines. Things do work if I add this to the Page - Before code section in Blocs, but this is bad HTML form.
I can’t think of a native solution using Blocs,
Off the top of my head, the first thing that comes to mind is .htaccess and redirects using mod_rewrite. I’m sure there are people (@brechtryckaert) here on the forum who know more about .htaccess.
The .htaccess file can be edited directly in the Blocs code editor, so it’s somewhat native to Blocs
Many thanks and dealing with this at the web server level would definitely be an option.
I’m starting to wonder though if this might even be a bug or maybe feature request. At least in the projects I have, the style sheets live at /css, JavaScript at /js, etc.
If this hierarchy is consistent across Blocs projects, maybe this should always be an absolute path instead of a relative one?
The problem here would be the use of NGINX which, in its default configuration, does not support .htaccess.
On the other hand I would try to avoid using absolute paths wherever you can, as this can be quite a pain if you ever need to move to a different server (and the absolute path changes).
Am I correct in my assumption that you’ve created a 404 page in Blocs (so probably a 404-folder in the directory structure)?
Because if this is the cause, I think a redirect can be realized in the NGINX configuration.
On the other hand I would try to avoid using absolute paths wherever you can, as this can be quite a pain if you ever need to move to a different server (and the absolute path changes).
Yes, I would agree, but considering the /css folder is static and doesn’t move around from Blocs project to project, my guess is that this would be relatively safe being absolute.
Am I correct in my assumption that you’ve created a 404 page in Blocs (so probably a 404-folder in the directory structure)?
Yes, that’s correct. Hence when 404 gets displayed further down in my folder structure, the relative path to /css is then off. An nginx rewrite might be the best plan.
But frankly I’m sort of bringing this up here, as this could be an architectural problem with Blocs itself. 404 is an unusual case as it can occur anywhere in a site’s hierarchy. As such, it might be helpful to have this comprehended by Blocs directly rather than the world + dog having to hack something together in Apache or nginx. @Norm Maybe a feature request?
Many thanks Jannis. Unfortunately this doesn’t really change the situation much. My 404 page comes up just fine. The problem is that when index.html loads it has this:
Also I apologize if I’m burying the lede, but my point in this whole conversation is NOT to try and solve this technically on the web server side. But instead up level the conversation, as this is an issue that all Blocs users are going to run into when serving 404 pages regardless of whether they’re Apache or nginx users. In either situation a rewrite rule can be crafted, but why should every Blocs user have to do this when Blocs itself can solve the problem for all?
This feels like car headlights being aimed a bit off at the factory. Every driver can compensate with brighter bulbs, fog lights, or driving slower, but the right fix is to aim the headlights correctly before the car leaves the factory. A custom 404 page is expected to be displayed from arbitrary missing URLs, so Blocs should have a way to export that page with root-relative assets instead of making every user patch nginx, Apache, or hosting rules.
@Norm Maybe an easy fix for this, while also improving the situation for other scenarios, would be a checkbox in the Page Settings for “Use root-relative asset paths for this page”. Of course ON by default and one could turn it on when needed.