Strange rendering behaviour in template/user/auth

11 views
Skip to first unread message

Lachlan Musicman

unread,
Sep 20, 2012, 10:19:39 PM9/20/12
to django...@googlegroups.com
Hola,

I've noticed for a while that my home/index page wasn't registering
the {{ user }} tag when rendering the page: there was no "Welcome
Username. Change password / Log out" in the top right corner, and the
link to the admin interface that I'd put in the breadcrumbs for logged
in users wouldn't appear.

But that was the only page - every other page showed it fine - so I
wasn't too concerned, and gave it a low priority to fix it.

FWIW the whole site requires authentication (checked and confirmed in
another browser) - so Django knew I was auth'd - it just chose to
ignore some of the base.html

Yesterday I added some thematic changes - a little js and css, plonked
it in path/project/app/static/{js|css} as advised in docs and added
them to the base template with {{ STATIC_URL }}.

Suddenly the lack of auth recognition on some pages (turns out it was
more than one) is noticeable, because the graceful degrading of the
js/css is appalling enough to make it stick out. In particular, when I
"inspected element" I saw that the {{ STATIC_URL }} wasn't being
expanded - the resources were failing on bad paths.

I've tracked everything down that could be the problem - I've
confirmed half a dozen times that the pages in question are extending
the correct base_site.html, which is extending the correct base.html,
I even tried sending the request context in render_to_response with no
luck.

It was only this morning while doing some triage that I realised that
the pages without proper auth (no details in top right corner) where
also the ones with the wonky templating.

Any clues on what I'm doing wrong or new ways to track down where the
mistake is?

Cheers
L.



--
...we look at the present day through a rear-view mirror. This is
something Marshall McLuhan said back in the Sixties, when the world
was in the grip of authentic-seeming future narratives. He said, “We
look at the present through a rear-view mirror. We march backwards
into the future.”

http://www.warrenellis.com/?p=14314

hevok

unread,
Sep 20, 2012, 10:29:59 PM9/20/12
to django...@googlegroups.com
Hola Lachlan,
Are you passing the `context_instance=RequestContext(request)` to all templates? It should provide the user tag.

Bests,
Hevok

Lachlan Musicman

unread,
Sep 20, 2012, 10:49:49 PM9/20/12
to django...@googlegroups.com
On Fri, Sep 21, 2012 at 10:29 AM, hevok <d.a.w...@gmail.com> wrote:
> Hola Lachlan,
> Are you passing the `context_instance=RequestContext(request)` to all
> templates? It should provide the user tag.

Hi Hevok,

Thanks for the reply.

I did attempt to merely pass the request:

@login_required
def index(request):
"""
If users are authenticated, direct them to the main page.
Otherwise take them to the login page.
"""
daily_sessions = []

for session in range(4):
daily_sessions.append([])
daily_sessions[session] =
Session.objects.filter(date=today).filter(session_number=session)

return render_to_response('tafe/timetable_today_detail.html',{'daily_sessions':daily_sessions,
'request':request})

but that didn't work.

I pass the RequestContext(request) for the forms I wrote to satisfy
CSRF stuff - I guess I just add something similar?

...OK, I just added exactly the same as for the CSRF and it worked -
thanks Hevok!

cheers
L.
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/uYEguNGN3CsJ.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.

hevok

unread,
Sep 20, 2012, 11:18:11 PM9/20/12
to django...@googlegroups.com
Hiya L,
Your are welcome!

It is not obvious from the tutorial, but RequestContext as its name suggests also passes the request context to the template. The context_instance uses the auth middleware context processor and provides the user in the view. You could also refer to `{{ request.user }}` in the template, but I wouldn't recommend it. RequestContext automatically populates everything for you with nice variable names.

Cheers,
Hevok

Lachlan Musicman

unread,
Sep 21, 2012, 1:08:31 AM9/21/12
to django...@googlegroups.com
On Fri, Sep 21, 2012 at 11:18 AM, hevok <d.a.w...@gmail.com> wrote:
> Hiya L,
> Your are welcome!
>
> It is not obvious from the tutorial, but RequestContext as its name suggests
> also passes the request context to the template. The context_instance uses
> the auth middleware context processor and provides the user in the view. You
> could also refer to `{{ request.user }}` in the template, but I wouldn't
> recommend it. RequestContext automatically populates everything for you with
> nice variable names.

Yeah, I was just thinking about how I can know enough about Django to
articulate my problem, but not to solve it.

Turns out that the important documentation in this regard is not filed
under R but under D (for django.template.RequestContext):

/path/django-docs-1.4-en/ref/templates/api.html#django.template.RequestContext

And the really important documentation is in the "note".

There's no denying documentation is hard, that Django has excellent
documentation and that making the tutorial (which is fantastic) simple
enough for new users but covering enough ground to get someone started
is a delicate balancing act.

I feel like this needs to be better placed, or to have better
examples. Or maybe that's exactly what the list/IRC is for :)

Cheers
L.
> https://groups.google.com/d/msg/django-users/-/7Y18reXx9R8J.
Reply all
Reply to author
Forward
0 new messages