django-menu key error

[sergeyvladimirovichmelnichenko]

whether the django-menu version of Django 1.5?

TEMPLATE_CONTEXT_PROCESSORS ('django.contrib.auth.context_processors.auth',   'django.core.context_processors.debug',   'django.core.context_processors.i18n',   'django.core.context_processors.media',   'django.core.context_processors.static',   'django.core.context_processors.tz',   'django.contrib.messages.context_processors.messages',   'django.core.context_processors.request')

{% Block content%}

     {% Load menubuilder%}      {% Menu main_menu%}      {% For item in menuitems%}          {{Item.title}}      {% Endfor%}      {% Endblock%} Error:   KeyError at / blog / 'request' Request Method: GET Request URL: http://127.0.0.1:8080/blog/ Django Version: 1.5.1 Exception Type: KeyError Exception Value: 'request' Exception Location: C: \ Python27 \ lib \ site-packages \ django \ template \ context.py in __ getitem__, line 57 Python Executable: C: \ Python27 \ python.exe Python Version: 2.7.3 whi? Please HELP ME

[jondbaker]

I'm getting the same error, but only after successfully using the login() method of the django.test.client.Client class within my integration tests. Anonymous requests are OK, but for some reason authenticated are not. I did some debugging and it appears that after using login() the context dict used in the menubuilder template tag is empty, hence the KeyError. I'm also running Django 1.5, and I've posted more info within the Django Users google group (no response yet): https://groups.google.com/forum/#!topic/django-users/SvqpvelMSd8

[rossp]

I think there might be a change in the way context is handled in 1.5, but I'm unsure - I don't currently have any projects on 1.5, sorry. I will look into this soon - patches are welcome in the interim! :)

[awechsler]

Hi All, not sure if this is exactly a fix but more like a workaround. Anyway I was stepping through the code and what I noticed is that depending on how you call render_to_response() i.e. using just RequestContext() or if you pre-assign to another var will make a difference in the call to getitem(self, key): (line 65 of context.py). If I simply left my calls using RequestContext(request) then when I look at self on line 65 I only get the following : (Pdb) p self [{'False': False, 'None': None, 'True': True}, However if I call render_to_response(context_instance=RequestContext(request)) then I am able to get to the missing context. Like I said, it's not really a fix but it does help to work around the issue ;-) Hope that helps!

[bodgerbarnett]

Do you have any update on this issue?

The only time I'm seeing it is when my site hits an HTTP 500 error - the context doesn't contain the key 'request' which causes the above error which, in turn, causes my site to not render the proper 500 page which is not ideal.

[rossp]

@bodgerbarnett On my projects I've worked around this by not having menus on my 500 pages - you're right, the issue is caused by lack of a request on the context of those pages. We can probably make it work for static menus (ie menus with a given name) but not for dynamic ones (ie show this nav tree within /products/)... I have not really got the time right now to update & test this, any chance you could put together a PR?

[bodgerbarnett]

@rossp I can certainly try. I don't 100% understand what the code in this area is trying to achieve but would it make sense to check for the presence of request in the context and, if it's not there, set current_path and user to nothing so that the get_items method can avoid trying to check those things, do you think?

[bodgerbarnett]

@rossp Also, the use of first() in that template tag prevents this app from supporting Django 1.5. Sadly, that's the version I'm having to use on this project for the foreseeable future. The old way of doing it (with try/except) works fine.

[rossp]

@bodgerbarnett Sounds reasonable - if the request isn't present, then don't go down a code path that will try to read the request. This will make login-only or path-based menus impossible in those scenarios.

I don't think targetting Django 1.5 is a priority sorry. It is no longer supported by the Django project and trying to include it in here will only complicate things.

[bodgerbarnett]

OK, I've created a pull request - I've never actually done this before so please forgive me if there's something I've missed or done wrong!