-
Notifications
You must be signed in to change notification settings - Fork 346
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve error message when template is rendered without request context #300
Comments
Thanks, we imagined there could be some unexpected edge case related to this. |
FYI @karolyi |
Yes, we use the tag |
I built in a preliminary check for the middleware in the code, but it didn't seem to be enough. I can come up with some mods for this. |
So, originally I knew this change would be a can of worms that we just opened: in order for the deduplication code to know which chunks have been rendered, you need some kind of a variable that is local throughout the generation of the template(s). There are a couple issues with this:
All I took care with my using of the To be constructive, I'd suggest the following optional resolutions:
Of course, these users will need to understand the reason why a request is necessary. I can add this to the documentation and point to it from the error that is generated when Suggestions? |
Thanks for the inputs and suggestions @karolyi. My suggestions:
Please LMK your thoughts. |
I am specifically that edge case: my templates stopped functioning with Jinja because of the multiple chunk inclusion, so I vote against removing it from Jinja. The forcing of one-entry-point-per-template is very unwarranted in my opinion, YMMV of course. I can support the ignoring of I can make the changes for that, if necessary. |
I see, I think it would be great if you could make a PR for the ignoring of |
Alright, coming up hopefully within a couple days. |
Hello, the last version (1.4.0) raise KeyError when trying to render error pages (500 / 403).
|
you can roll back to the latest version before this one or wait until I'll make the necessary changes. |
So, a pull request is made now, merge, bump version and release and you're good to go. |
1.4.1 released with those changes: https://github.com/django-webpack/django-webpack-loader/releases/tag/1.4.1 |
Django provides the ability to render templates outside the request context even if the
django.template.context_processors.request
middleware is activated (see Template.render or render_to_string).So it took me a bit to figure out the cause of the following error happened after updating from 1.3.0 to 1.4.0 (see digitalfabrik/integreat-cms#956):
Traceback
Source: https://app.circleci.com/pipelines/github/Integreat/integreat-cms/2610/workflows/c4feb10f-3d0d-48b8-b094-681db5a6d8d0/jobs/19913
I would suggest to throw a more helpful error in this case, stating that it's not possible to use Template.render without passing the current request to the template context. (Or, if somehow possible, allow the rendering without the request object...)
Thanks!
The text was updated successfully, but these errors were encountered: