Right, why is it that I’m getting server error 500 when implementing the error 404.html?
Why is is doing this, despite following these instructions to the letter W3Schools
These are currently my settings - a per the tutorial, and I have set up a page named 404.html which is in the templates folder and is set up correctly in the templates directory in the settings.py
DEBUG = False
ALLOWED_HOSTS = [' * ']
Of course, this doesn’t work. Because for this to work would just make my life just that little bit simpler for once - apparently we can’t have that.
So why?
…and now I’m getting this
Please show everything that you have created or defined relative to your 404 handler.
Also show the directory structure of your project and where you have placed your 404.html, along with showing how you’re running your project and the complete error / traceback you’re getting from your server.
Edited to include the file directory and having set the debug back to true there are no errors in the terminal
Changing debug=True to debug=False causes multiple things to happen within Django.
If you want us to help you resolve this issue, you’ll need to change it so that debug=False and post the complete error being received.
I’m aware I need to change this to False, which was what I did in the first place. I only put this back to True to see if there was an error stack in the .venv Terminal Window t the bottom of the VSC application - which there none. The only thing that happens is that all my bloody CSS has now disappeared/.
Why can’t something just be easy? Why is is that every time I follow a tutorial to the letter it never does what the tutorial says it does? I’m so tired of this!
So is this the real error we’re trying to address here and not a 500?
Actually, that tutorial does do exactly what it says it does. If your only issue at this point is due to the CSS not being included, that’s a different issue and not related to the 404 page.
Note that that tutorial doesn’t show any CSS in the sample 404.html provided.
Beyond that, you won’t find me recommending that site as a source of useful/valid information.
Also, if you’re looking for reliable sources, start with checking out GitHub - wsvincent/awesome-django: A curated list of awesome things related to Django
As a curated list (from someone that I trust), I can say that anything on that page is going to be at least as good as anything you’re going to casually find out on the internet.
There are a lot of sub-par resources out there, and unfortunately, it’s going to be up to you to learn what is and isn’t worth your time and effort to read.
Personally, I always recommend starting from the official docs. For example, there’s a page on Managing static files that covers the differences of what’s necessary between debug=True and False.
But basically, in a development environment, you’re going to want to run with debug=True. Trying to run a development environment with debug=False tends to create more issues than it helps.
For the avoidance of confusion, ignore the CSS issue. I will work this out in due course.
However, I am well aware that there are some crappy sources of information and I absolutely agree that it is down to me to assess what’s good and what isn’t.
Just take a look at the countless YouTube videos with the numerous “it doesn’t work” comments so you’re right & there are some delusional content creators out there who think they’re experts.
However W3Schools is supposed to be a leader in this sort of thing and if this tutorial did do exactly what it says it does, I would not have made a post saying that it doesn’t - in fact - I wouldn’t have made a post at all because I would be in danger in keeping what’s left of my sanity.
Whoever wrote this post for W3Schools is clearly clueless and whoever assigned him or her to write this tutorial needs firing.
If whoever wrote this tutorial tells us that Django looks for a file called 404.HTML & I have created a file called 404.HTML’ then I would be reasonable to believe that my 404.html` will materialise when your enter an non-existent URL into your address bar.
I am well aware that in the development stage of a web app that Debug = True should be set, however, W3Schools tells us to set Debug = False, hence the snippet of code I pasted into the original post.
It is definitely a 500 error & the only explanation is that W3Schools is wrong, so I’ve come in here to explore if anyone else has had similar issues and how they solved this.
So, I can start by saying that if I do what’s in the tutorial, it acts exactly as described.
Resolving the 500 error then means trying to find the root cause for that 500.
If you post your settings file, we can look at it to see if there’s something in it that might be wrong.
(Note: In your original post, you have the ALLOWED_HOSTS setting commented out. It is required with DEBUG=False.)
Please don’t quote me out of context
You wrote:
And so, I replied:
And I stand by that statement. If I follow the instructions as written in that tutorial, the 404 page works exactly as the tutorial describes. It produces the output precisely as shown.
More importantly for this discussion, I don’t get any 500 errors.
They are (for their convenience), ignoring static files in that tutorial. (I’m amused that I find myself defending this tutorial, because I never recommend that site - always recommending alternatives, and usually find myself commenting about its lack of quality. This is an example of that - while the tutorial is technically accurate, it ignores a lot of contextual information in the process.)
Ok, so now we are back to addressing the static files issues.
The behavior of the runserver command with respect to static files and DEBUG is documented at The staticfiles app | Django documentation | Django (In particular, see the section on this page about the runserver command) and at How to manage static files (e.g. images, JavaScript, CSS) | Django documentation | Django
Side note: In my opinion, this behavior makes sense. In a production-quality deployment, you do not want Django serving static files. That’s a job for your web server. Nor do you want DEBUG=True in production. By having DEBUG=False disable the staticfilefinder, it helps avoid the situation where you have your Django application unintentionally serving those files.
