Debug = False > Error 500 > "Invalid Block Tag" [content]

Using Django Templates & Frontend
1

Versions
Python 3.11
Django 4.2
WhiteNoise 6.6.0

I’m currently in the process of deploying my website into the big bad world.

I have installed Whitenoise (thenceforth will be referred to as “WN”) from [PyPi](https://pypi.org/project/whitenoise/) and have followed the documentation in installing and setting up WN in accordance with [ReadTheDocs](https://whitenoise.readthedocs.io/en/stable/django.html)

I have then run the python manage.py collectstatic command with no issues and I now have a static folder in the root directory which contains all of my static files - which is what is supposed to happen.

I have set my ALLOWED_HOSTS to ALLOWED_HOSTS = ["127.0.0.1"] and have also tried ALLOWED_HOSTS = ["*"] in my settings.py file.

I hit the python manage.py runserver command & everything up until this point runs the development server with no issues, my website runs as expected and the only console warning is a message stating that third party cookies will be blocked which I don’t believe has anything to do with the issue at hand.

However, I hit the DEBUG = False and once again - as expected - VSC give me the Starting development server at http://127.0.0.1:8000/ message in the console.

I click on the link and it give me the A server error occurred. Please contact the administrator.

Opening the error console back up in the browser, it returns:

Failed to load resource: the server responded with a status of 500 (Internal Server Error)

Helpful! However, I run the settings.py file and it appears not to like the {% block content %} tag because the VSC console returns:

django.template.exceptions.TemplateSyntaxError: Invalid block tag on line 22: 'content'. Did you forget to register or load this tag?

I am fully aware as to what this is referring to - it is a template tag that is widely used in Django to separate content in your base.html and is applied to all templates with which uses the {% extends 'base.html' %}and takes the form:

`{% block content %}

{% endblock %}`

However, I fail to see why this is an issue as I have not only set {% load static %} at the top of every Django template but also this is widely used template tag.

  1. Could this disliking on the part of Django of this content template tag be the cause of the Error 500

  2. if the above is true, how would I go about rectifying this?

Many thanks

2

The console where you’re running runserver should show a complete traceback with an error. It would have the information needed to start debugging this issue.

Note: In 95+% of all cases, it’s not wise to run runserver with DEBUG=False. If you’re ready to be running with DEBUG=False, then you should be using something like gunicorn or uwsgi to be running your project.

Please clarify - what do you mean by:

The settings.py file is not a script designed to be run directly. It’s intended to be loaded by Django during its startup process.

3

In reference to your first point - this is a link to the traceback I’m receiving from the browser:

Screenshot 2024-02-27 082832
Screenshot 2024-02-27 082832971×947 26.7 KB

In relation to your second point, I’m now running the server with DEBUG=False and am now getting these tracebacks in the VSC console : “templates”, “parsers”, “tags”, “get_template”, “templatename”,“Invalid block tag on line 22”,“Invalid block tag on line…”,“Invalid block tag on line 22”,“Invalid block tag”, “Invalid block tag”, “Invalid block tag”, “Invalid block tag”, “Invalid block tag”, “Invalid block tag”

I have never understood the logic behind VSC, I never got these errors when running the runserver command yesterday, now these errors are appearing when I hit the runserver command.

However, this is despite reading and following the documentation to the letter and it sill isn’t good enough. I have done everything that is required in all documentation: Django, Python, Whitenoise, why do they always fail to mention the apparently-crucial element which causes these traceback errors?

(I’ve had to put this as a code dump link because it will exceed the character count - I know, doesn’t bode well, does it?!):

https://www.codedump.xyz/swift/Zd2rpMgJDCldXHIk

I realise it’s not a script to be run directly but if it can reveal issues that could manifest themselves later down the line then surely it can only be a good thing? It may be intended to be loaded by Django during its start-up process but the numerous documentation which defines how to lift a Django website from development into production is also intended to actually deploy the website and not some ambiguous Failed to load resource message.

The forum encourages us to include error messages in our posts where they manifest themselves and this is what I have done. This forum also tells us to read the documentation prior to coming here, this is what I have done.

I write software documentation all the time and the software always behaves exactly how I state it will behave. If I can do it, why can’t everyone else? It just wastes my time and my resources. You should be able to read the documentation of a piece of software just like you would the instructions to assemble a piece of flatpack furniture. You put this screw into this hole, and A goes with B & bam! You have a beautiful, stunning, drop-dead gorgeous Corona Coffee Table.

It should be the same with software: you configure your settings.py the way the documentation tells you to and bam! You have a beautiful, stunning, drop-dead gorgeous website, with all your static files served by Whitenoise, with debug=False, your Allowed Hosts set to * (later on setting this to your domain) and your sanity in tact for another day (just imagine that).

Why can’t it just be that simple?

Further, a common theme for the “whinging” above is this content which is the block tag {% content block %} {% endblock %}. For some reasons Dango or VSC seems to have some sort of “vendetta” against this block tag.

So, this “whinging” that Django is beautifully conveying in the form of the traceback, I’m thinking it’s a template issue, seeing as it mentions the word “template” a lot, it also mentions “invalid block tag” numerous times, despite there being no invalid block tags and my urls.py as well as my views.py have been correctly set up. So in your experience, what is Django not liking to justify my browser failing to load the resource in the form of a 500 error?

Much appreciated & thank you for your time :slight_smile:

Update: do you know the number of a good plumber? I only ask because when setting DEBUG = True, Django tells me:

[27/Feb/2024 09:41:46,371] - Broken pipe from ('127.0.0.1', 62631)
[27/Feb/2024 09:41:46,390] - Broken pipe from ('127.0.0.1', 62889)

:smile:
4

Ok, let’s take a step back here for a moment.

It makes no sense to run any specific individual file within your project.

  • They’re not written to be used that way.
  • They all expect to be run within the context of Django
  • Doing so provides no diagnostic value
  • Doing so provides no useful information
  • Doing so provides no “valid” error messages
  • Doing so does not reveal any issues that could manifest themselves later

You will not find any documentation showing this, because it’s a waste of time to try. There is nothing that you have posted related to doing that above that is of any use at all.

So, let’s try this again, and only with information that is going to help identify the cause of whatever issue it is you’re facing.

We need to see the traceback from the console window where you are running your server for the request generating the 500, not the errors being shown in the browser.

Only use runserver if you’re using DEBUG=True. The runserver command is really not intended to be used with DEBUG=False. If you’re trying to use DEBUG=False (as you should in a production-quality deployment, you should at least be using something like gunicorn.

Changing DEBUG=True to DEBUG=False causes a number of internal changes to take place. Making this change has a lot larger effect than just “flipping a switch”.

Quoting directly from the docs for runserver:

DO NOT USE THIS SERVER IN A PRODUCTION SETTING.

[emphasis added]

5

Hi there,

Forgive me, I come from an MQL4 background so for 10 years I have been running the debug function on every piece of code I have developed or altered, so it’s an alien concept for me to NOT run a .py file such as the settings.py file when I have added additional configurations to it in order to ensure that there are no typos I may have created.

I have created websites prior to this but using Adobe Dreamweaver which - as I’m sure you will be aware - is a whole lot simpler. You just go File > Preview and up it comes on your browser. :sweat_smile:

In reference to the traceback from the console, the only information I have available is the readings in the codedump link. This information was NOT sourced from the client-side browser, but from VSC.

It there is an additional console I am not aware of, I apologise.

I am never looking at a YouTube tutorial again, they all manage to run their websites using the runserver command with DEBUG=False and I was completely unaware that this is not the case. They must be using Gunicorn or something similar, or they’re some amazing special effects going on here.

I was under the impression that with DEBUG set to true will simply tell you where you have gone wrong with any errors you may create, whereas DEBUG` set to false will require a third-party such as Whitenoise that will take over the serving of static files and will result in the error 404 (as opposed to Django’s “Yellow Page Of Death” appearing should you type an incorrect URL.

Just to clarity, when uploading this to a hosting server (such as IONOS), is it at this point which is where you would turn DEBUG to False?

Many thanks.

6

It’s an issue of perspective or mindset here. Django is a framework, not a library.

The importance of that here is that your code does not have control over the process or environment in which it’s being used. Django is the “main” program. Your code is a library being used by Django. You’re defining functions and classes that Django will call to perform specific functions. (From that perspective, it’s most similar to a Java servlet, or web pages created in an ASP.NET project.)

So in this particular case, Django is loading and executing your settings file from within its startup functions, specifically, the django.conf.__init__ file.

This means that a variety of variables and classes already exist before the settings file is called. The same is true for all the other files within your project.

Depending upon the exact layout for your VSCode, there should be a panel on the bottom right with tabs labeled “Problems”, “Output”, “Debug Console”, “Terminal”, and possibly more. When you run runserver from VSC, you should see the output from it in one of those tabs. (I don’t remember which one.)

They may. I never said it couldn’t be done, just that it’s a bad idea, one that is recommended against by the Django docs. I’m not going to speak to mistakes other people make.

That is one of its functions, yes. But there are a variety of other features enabled (or disabled) based upon this setting. Some of the ones I can think of right off-hand include:

Those are the ones I can think of pretty much off-hand, and that’s not including any third-party libraries you may be using.

Not in my case. I keep “staging” environments that best resemble the production environment to test how the projects are going to behave before they are deployed to a publicly-visible server. What I deploy to staging is the “production-ready” image using the settings that will be used in production. That helps avoid surprises when going live.