I gave a talk this week at DjangoCon US on the User Model. One of my points was that startproject’s lack of a login template or signup view/template/url is deeply off-putting to newcomers. To whit, this is my most popular tutorial by far. Step back and think about how off-putting it is to need to first find a tutorial like this and then implement it as one of the very first tasks with Django.
So I propose two things:
Add a login.html template. We already have the URL and view files. Why not include a basic login template?
Add a basic signup option as well, which means a view, template, URL.
If we want to go crazy, include a basic form for logout, too, which now requires a POST request and I can assure you also confuses people.
Question: would this be the first template(s) included in the startproject command? If so, then I would the TEMPLATES[0]["DIRS"] setting would need updating.
Assuming we as a community agree on this, I would also suggest including some very minimal default styles. However I am aware not to scope creep the original proposal and that needs to happen first before we consider some default styles.
I agree. We need to be mindful of scope creep. My thought was, yes, login.html would be included and you are correct that requires updating TEMPLATES. I think using a project-level templates folder is a very, very common pattern so, to me, it’s worth having. Especially since a user has to configure templates anyway on their own if they want login. Better to have a canonical way starting out that people with more experience can easily customize if so desired.
There is a separate discussion about things we could do to make startproject more generally local-friendly for newcomers that I’m happy to have but I don’t want to jumble that here with simply having default login/signup/logout available for new projects.
I think this is the right approach. (A part of me is tempted by having django.contrib.auth define the templates, but that’s likely to result in folks having surprises.)
It was long-argued that Django wouldn’t provide these template because styles were too varied, and so on. I think we just have to be clear the goal is just to get you bootstrapped, and that you should edit/replace these templates quite soon, quite likely. Whatever wiggles are there, the current situation is suboptimal, and we’ve left it too long already.
Just a hunch, django.contrib.auth already provides login for the staff, why not use the same template and direct the non-staff user to LOGIN_HOMEPAGE (defaults to ‘/’) which has the URL for homepage of Logged-in users.
As a beginner I would find this very appealing, both in the specific example, but also more in general in other cases like it.
Edit: an other Example could be passing the crsf-token by default in forms
One thing I’m curious about is what the history behind NOT including it originally. That might help the path towards implementation, but this is a curiosity question for me more than anything else.
It could just be plain html without styles. As an example, Django-oauth-toolkit provides basic form templates for creating OAuth tokens without any styling, just labels and input boxes.
Regarding the suggestion to use the same styling as the Django admin login page, I’m unsure. I worry that newbies might find it confusing, seeing same login page that takes you to different pages. As an experienced user, I know the difference of Django admin login, and regular user login. But sure how it would be from first comer’s perspective. Having different styles would have make it obvious that these are two different things.
I wasn’t present for the very beginning, but I do know that Ellington – the news CMS from which Django was extracted – had its own user-registration system which stayed in Ellington rather than Django. Though a few artifacts of it stuck around in Django for a while (that’s not the only Ellington reference that accidentally wound up in Django – maybe one day I’ll write up all the ones I know about).
I’m actually in the middle of rewriting django-registration’s core forms and one of its backends for the next release, though, and I will say that if it had just been part of Django all these years it probably would not be able to evolve like this and would be a much worse implementation as a result. User signup is one of those deceptively simple problems that leads you to wake up one day and realize just how much work has to go into seemingly small parts of it.
So on those grounds, I’d argue that django-registration and other things that serve the same purpose probably shouldn’t be in Django itself – it’s a bit like the Python standard library in that once something is in Django it basically becomes frozen forever.
I found the talk compelling and we should link this here when available.
I think we could acheive this in steps.
The first step being adding a “How-to” guide on login/logout/signup to the docs which provide basic template examples.
As Carlton mentioned, adding to core means being very clear of the goal/scope.
When folks come to trac and ask for different features to be added to it, we want a link on how to extend/override it to be documented that we can point them to.
To me, the goal is to have a minimal working (and accessible) example with basic functionality.
This helps folks (especially beginners) get started faster but does not aim to fit everyone’s use case or be state-of-the-art.
The docs would need to show how to override/extend with a some examples.
… 1 and 3 seem less invasive: they’re about providing (minimal “do edit”) templates for the existing views in django.contrib.auth. 2 is getting into the land of Django-registration, which maybe (? — just a thought) is better as a how-to, showing something simple, but pointing to ecosystem options.
I guess I’d say it’s 2 that merits more of a If we want to go crazy... than 3, which is (again) just the template really.
Related: ref linking to external packages, a discussion at DjangoCon revolved around how we guide folks to Ecosystem Batteries if we keep Django core itself small. pip works great, but you need to know what to pip
I think it would be great to include basic login and logout templates to Django core. Not sure if this question is too deep in the weeds, but would these two templates be completely self-contained, or would they inherit from a base.html template? The existing templates included in Django all appear to be self-contained, but have different approaches to the default HTML that’s included. Inheriting from a base.html template might make it easier to integrate through the template-loading hierarchy - e.g. my own base.html would be used instead. But that might be over-complicating things…
I think the templates should be included in the created project and not stuffed away somewhere in core. Sure they could extend a base, but that would then also be included that you can then edit to become your own base.html.
Rather than a form, what about a template tag (e.g. {% logout %}) to render an empty form & submit button, with perhaps a parameter or two for customization or styling options.
I’m +1 to the simplest possible form of login/logout. In my view, that is something along these lines (unpolished but functional diff and proposal follows):
a +1 for copying the default_urlconf.html. If it’s a symlink I can already visualise some newcomer asking how to customize that template within Django itself.
That seems like it would lead to a bit of a cascade into adjusting the tutorial. That may be OK but, can I suggest a two-stage approach here to not require too much of a lift to make progress.
Step 1: Add only the project level directory to TEMPLATES, and the simplest login/logout templates.
This would allow “Add login/logout” to be only ‘add path("accounts/", include("django.contrib.auth.urls")) to your urlpatterns and you’re done’ — which is a good win already. (90% of what was needed).
Step 2: Pre-route all that, like you suggest, and adjust the tutorial etc.
Small steps being much easier to get done quickly.
