I am getting a template error during rendering, which I think would be easy to fix if I could just see what's in the context that is passed into the template that is being rendered. Django's debug error page provides a lot of information, but I'm not seeing my context anywhere. Am I missing something? Also, I am using Django-debug-toolbar, but that only seems to come up if the page successfully renders. Not being able to see the contents of the context that is passed to the template makes debugging some types of template errors hard! What do I need to do to be able to see it in this scenario? (Note that I'm not asking for a fix to my specific error, which is why I'm not providing more information about it).
From the comments:
I think you need to walk up the stacktrace (in the django debug page) to actually see your context variables. I don't understand your problem exactly. If I have a template error I can inspect my context somewhere in the traceback.
Yes, setting a "breakpoint" in django can sometimes mean just inserting a non-defined variable at the point you want to inspect. The last entry in the traceback is usually the one for this variable. It will give you all context details in the traceback of the debug page.
The easiest way to do this is with the Django Debug Toolbar. it will give you a popup tab on the right hand side of your screen that you can use to inspect various things about the current page's request. Things like SQL statements, versions, logging, and all the templates that were used to render the page, and the context available to each of them.
Related
I am new to Django, and having a difficulty soting out a problem. My code is processing extra method in views.py even without being called.Below is an example:-
When I am cliking on Home button on my page.
Landing Page:
I am being redirected to correct view method i.e., index.
IndexMthod in views.py:
After loading the page my code is hitting another method edit content, without being called with a param favicon.io
Concern Method
which is my concern.
Though it is not affecting my django app, but still it's annoying to see extra method being called everytime.
Please let me know, if I have done something wrong here or if any more info is required from my end. Thanks in advance.
So, I've recently inherited a large code base that is fairly obfuscated. When I navigate a page on my local machine is there any way to determine which template/view is actually being called to create the view that I'm seeing at that moment?
I would like to get a better idea of where certain parts of the page are actually coming from, but the project is so large and disorganized that going through present templates is simply not feasible.
Is there any nice way to get around this? Worth mentioning that the defined urls all seem to be poorly written, obfuscated regex, (not to mention incredibly long) so direct examination of the urls file is not extremely feasible.
When I try to run resolve on the url of the page I'm trying to view I get a 404, and I'm not really sure where to progress from there, since the page clearly works.
Any help would be greatly appreciated.
Personnaly I use this : https://github.com/django-debug-toolbar/django-debug-toolbar
The Django Debug Toolbar is a configurable set of panels that display
various debug information about the current request/response and when
clicked, display more details about the panel's content.
Currently, the following panels have been written and are working:
Django version
Request timer
A list of settings in settings.py
Common HTTP headers
GET/POST/cookie/session variable display
Templates and context used, and their template paths
SQL queries including time to execute and links to EXPLAIN each query
List of signals, their args and receivers
Logging output via Python's built-in logging, or via the logbook module
There is also one Django management command currently:
debugsqlshell: Outputs the SQL that gets executed as you work in the Python interactive shell. (See example below)
If you have ideas for other panels please let us know.
Note: The Debug Toolbar only works on Django 1.3 and newer.
0 code to add, only a few minor changes to settings.py
You will get what you want and even more.
Is there a way to make AppEngine show the errors from the log console in the page that I'm trying to load? The idea would be to avoid going to the log every time...
File "test.py", line 14
title = r.getElementsByTagName("title")[0].firstChild.data
^
IndentationError: expected an indented block
In general, you can catch all Errors, including syntax errors, with a catch-all (except:) clause of a try statement. If you can employ this tactic in your code and then show the exception in, for example, an alert message (or any other way), you got what you asked for.
Also, Have a look at this question and the accepted answer. If you override handle_exception as instructed there, you can put code that modifies the response to the request in a way you'd like.
If you're using the webapp or webapp2 frameworks, you can do this by adding debug=True to the WSGIApplication constructor.
Note that this is generally a bad idea, though, because it exposes internal details of your app to users, and presents them with a particularly unhelpful 500 page.
I'm supplying a Django project to a client, who has requested a 'debugging' page that will show useful information.
[UPDATE for clarity: We'd like this page so we can use it for debugging in future: the clients are not very technical and I won't have direct access to their servers. In the event of future issues, it would be very useful if I could check out this page without asking them to edit the Debug setting or do any other server-side fiddling.]
The project will be running in production, so I can't set DEBUG=True.
What I would like is a page similar to the Django debugging page but without any sensitive information in.
I guess I can simply write my own, but does anyone have any ideas? Anything standard in Django I could use?
Thanks!
Googling 'standard Django debugging page'
Isn't as effective as reading the Django source itself.
Look in base.py for code like this
from django.views import debug
That will provide you some hints as to how they do it.
Then you can look at django/views/debug.py for the "technical_404_response" view function. You can use this function in your code, also.
You can use Django Debug Toolbar and enable it only for choosen IPs
I know that HttpResponseRedirect only takes one parameter, a URL. But there are cases when I want to redirect with an error message to display.
I was reading this post: How to pass information using an HTTP redirect (in Django) and there were a lot of good suggestions. I don't really want to use a library that I don't know how works. I don't want to rely on messages which, according to the Django docs, is going to be removed. I thought about using sessions. I also like the idea of passing it in a URL, something like:
return HttpResponseRedirect('/someurl/?error=1')
and then having some map from error code to message. Is it good practice to have a global map-like structure which hard codes in these error messages or is there a better way?
Or should I just use a session
EDIT: I got it working using a session. Is that a good practice to put things like this in the session?
You are right about the auth messages. They are deprecated but as the docs suggest you should use the django messages framework instead, which I think is the exact soultion for your case.