Skip to content
This repository has been archived by the owner on Sep 17, 2024. It is now read-only.

django-menu key error #10

Open
sergeyvladimirovichmelnichenko opened this issue Sep 22, 2013 · 9 comments
Open

django-menu key error #10

sergeyvladimirovichmelnichenko opened this issue Sep 22, 2013 · 9 comments

Comments

@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%}
         </ ul>
    {% 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
Copy link

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
Copy link
Owner

rossp commented Oct 9, 2013

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
Copy link

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
Copy link

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
Copy link
Owner

rossp commented Jun 2, 2016

@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
Copy link

@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
Copy link

@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
Copy link
Owner

rossp commented Jun 5, 2016

@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
Copy link

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!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants