In tutorial part08, Django debug toolbar shows up in admin site but not in public site

[lucaremdev]

If you are a newbie like me and follow exactly the django tutorial, when you get to ​part 8, then you don't understand why Django debug toolbar shows up in admin site (​http://127.0.0.1:8000/admin/) but not in public site (​http://127.0.0.1:8000/polls/).
As mentioned on django discord ​here, the solution consists in making each template a full HTML document with a body element for the debug toolbar to show up in the public site as well.

So, you could either show full HTML documents with body elements from the beginning in the tutorial,
or
in ​this part of the tutorial, after the sentence "Once installed, you should be able to see the DjDT “handle” on the right side of the browser window when you refresh the polls application.", you could add something like: "note that for the django debug toolbar to show up correctly, you should properly make each template a full HTML document, as we mentioned it to be best practice earlier".

The aforesaid "mentioned earlier" is ​here in the "note" section, when said: "To make the tutorial shorter, all template examples use incomplete HTML. In your own projects you should use complete HTML documents."

These are just suggestions of course! Do as it seems better for the whole community!
And thank you anyway =)

[Illia Petrov]

I think such things may happen in any section and it is really hard to keep the track of all the updates that would lead to such a potential room for an issue as soon as new releases come.

What I think could be nice is:

1. Add the "note" section with a message that HTML snippets may be incomplete at the beginning of every part where it contains new HTML updates.
2. A link to a code source repo attached at the end of every section demonstrating the state of the code at the end of every part of the tutorial.

Curious to hear what others think.

[Mariusz Felisiak]

Thanks for the ticket, however we would very much like to avoid describing caveats in 3rd party packages. I don't want to open Pandora's box by accepting this. Django Debug Toolbar here is just an example of a useful 3rd party package that we want to keep as generic as possible. I hope that makes sense.

[lucaremdev]

Replying to Mariusz Felisiak:

Thanks for the ticket, however we would very much like to avoid describing caveats in 3rd party packages. I don't want to open Pandora's box by accepting this. Django Debug Toolbar here is just an example of a useful 3rd party package that we want to keep as generic as possible. I hope that makes sense.

Yes, sure, I understand, that does make sense. Thank you for your answer, and have a very nice day!

[Teemu R.]

First of all, thanks for the great tutorial! I just finished going it through in one sitting and I was confused enough for a while about this problem to start looking into if I could contribute to get it fixed.

For a simple solution, maybe the wording should be changed to point the reader to test it on the admin page (i.e., "when you refresh the polls application" -> "when you visit the admin page")?
While not a great solution as it leaves open the question _why_ it isn't working with the newly created app, it might still better than to confuse readers by describing that it _should_ be working now.

A much nicer but more extensive change would be to introduce how to create a base template (and describe extends, like in ​https://docs.djangoproject.com/en/4.2/ref/templates/language/#templates) in tutorial03.
This would be much more invasive as many other parts (e.g., css static hosting in tutorial06) would need to be adapted, but maybe it's worth the effort considering how common practice it is to have something like base_generic.html?

What do you think, would one of those changes be acceptable for inclusion?