I want to modify the default Django error reporting template TECHNICAL_500_TEXT_TEMPLATE to provide custom error message. Read doc on modifying the filter tried
DEFAULT_EXCEPTION_REPORTER_FILTER = 'path.to.your.CustomExceptionReporterFilter' but it's about filtering data but I would like to override the default template itself.
Tried overriding DEFAULT_EXCEPTION_REPORTER_FILTER and defining custom get_traceback_text and hence passing custom template instead of TECHNICAL_500_TEXT_TEMPLATE in the method.
Any suggestions would be helpful
I started noticing the change in the emails after upgrading from 1.7 to 1.9. I used the approach in the following answer. I basically removed the 'settings' section from the templates, including a few other lines that weren't needed.
Django error email is too long. How do I truncate it?
Related
I have to change an already existing StaticBlock to a StructBlock:
class SomeBlock(blocks.StaticBlock):
pass
class Meta:
...
to:
class SomeBlock(blocks.StructBlock):
...
class Meta:
...
However if the wagtail page has already SomeBlock configured in it, I receive the error:
NoneType is not iterable
Since I don't have anything inside the StaticBlock. I need to write a custom data migration for this.
Based on Schema Operations listed, I couldn't find a way to change the actual block type. How do I approach this?
StructBlocks and StaticBlocks live inside StreamFields so you need a Wagtail-specific method for converting blocks within a StreamField. Please see https://wagtail.org/blog/google-summer-of-code-toolkit-for-streamfield-data-migrations-in-wagtail/ for a discussion of the issue. Then you can use the project described https://github.com/wagtail/wagtail-streamfield-migration-toolkit Or, if you want to try out Wagtail 4.2rc1, you can try the built in migration helpers: https://docs.wagtail.org/en/latest/advanced_topics/streamfield_migrations.html#streamfield-data-migrations
I am thinking of an Idea to implement. Usually, I just wrap my view function code in a try-catch block, so if the view fails, I render a default error page with error name. I am wondering, can I create a decorator or a similar one-liner code, in which I could do the same(if the code in function crashes, load the error page with error code).Note I am already using the #login_required decorator
There is no need to do this. Django captures all errors already. You should simply provide a custom 500.html template at the top level of your templates directory - see the docs.
Yes, Daniel is right, just adding links to the right posts. We can use a template processor, pointed out in the following answer, and pass the status code.
Django raising 404 with a message
or we can create a new default error page and pass in the error like they did in the following post.
How to return 404 page intentionally in django
We are currently on Ember Data 1.0.0-beta.18, Ember 1.12 and CLI 0.2.7.
Since this last update, we are getting ember data assertion warnings like the following:
[Warning] WARNING: Encountered "open_requests" in payload, but no model was found for model name "open-request" (resolved model name using vault#serializer:appuser:.typeForRoot("open_requests")) (vendor.js, line 15423)
I also noticed that a console log we included in the appuser serializer is no longer called:
export default DS.RESTSerializer.extend( {
typeForRoot: function(root) {
console.log('appuser serializer called', root);
if (root === 'open_requests') return this._super('openrequest');
return this._super(root);
},
});
I can confirm that TypeForRoot was called prior to this update. We have had a number of other issues since upgrading and it seems that they could all be related in some way to the serializers, so the questions are why are we getting these warnings and why is typeForRoot no longer being called?
Ember Data switched to modelNameFromPayloadKey, typeForRoot is no longer used in the code unless you are specifically calling it.
http://emberjs.com/api/data/classes/DS.RESTSerializer.html#method_typeForRoot
beta.18 introduced a potentially breaking change - looks like it caused your app to break..
Short answer: rename typeForRoot to modelNameFromPayloadKey
From the CHANGELOG
[#3034] POTENTIALLY BREAKING CHANGE if you override typeForRoot currently introduce modelNameFromPayloadKey and deprecate typeForRoot #fivetanley
RESTSerializer#typeForRoot has been deprecated. You can use RESTSerializeer#modelNameFromPayloadKey instead.
Added RESTSerializer#payloadKeyFromModelName. This allows you to
typeKey on Snapshots and Model classes has been deprecated. Use modelName instead. specify the outgoing root key for a JSON payload.
From the Blog Post
DS.RESTSERIALIZER.TYPEFORROOT IS NOW DS.RESTSERIALIZER.MODELNAMEFROMPAYLOADKEY
To gain more consistency in the naming change of typeKey to modelName, typeForRoot has been renamed to modelNameFromPayloadKey. The function serves the same purpose, so this should be a quick refactor you can achieve via search and replace in your project. While calling typeForRoot will trigger a deprecation warning, overriding in a subclass won't.
I've just plugged this old JSONField model snippet into my django application. It looks like it's working, but throws this warning whenever the server revalidates:
$ sudo python manage.py runserver
Validating models...
/opt/bitnami/apps/django/lib/python2.6/site-packages/django/db/models/fields/subclassing.py:80:
DeprecationWarning: A Field class whose get_db_prep_save method hasn't been updated to take a `connection` argument.
new_class = super(SubfieldBase, cls).__new__(cls, name, bases, attrs)
0 errors found
What does this mean? How do I fix it?
It's a warning telling you that the the custom JSON field implemented in that snippet hasn't included the connection argument that has been introduced in django 1.2 due to multiple database support being implemented.
With regards the method itself: If you are writing a custom model field, you can use the get_db_prep_save to convert the python object you are working with (in this case a JSON object) into a form that the database backend can manage (in this case a string) before it is saved to the DB. Here are the release notes mentioning it
With regard the connection argument, it refers to the current database (at the time of execution - to get the default you can call django.db.connection) and it is included to ensure that the correct database is provided when calling that method so that any custom backend logic or convertions can be carried out before the value is saved to the db. You can read more about connections and cursors here
You can also use http://pypi.python.org/pypi/django-jsonfield, it is basically a packaging-up of the code snippet you mention.
(I had an older version that gave me the same connection error you mentioned; the newer versions have fixed this).
You can also try this one: https://github.com/vialink/vlk-django-jsonfield
We are using it in some projects and it is working fine.
I already create properties and add them to property group.Then I assign to my new product.But django show me
TypeError at /manage/update-product-properties/1
save() got an unexpected keyword argument 'using'
Yeah, as you point out in your comment to your OP, the problem went away by using a different version of Django. using is part of the machinery for multi-database support in Django 1.2