In the transition to newforms admin I'm having difficulty figuring out how specify core=False for ImageFields.
I get the following error:
TypeError: __init__() got an unexpected keyword argument 'core'
[Edit] However, by just removing the core argument I get a "This field is required." error in the admin interface on attempted submission. How does one accomplish what core=False is meant to do using newforms admin?
To get rid of "This field is required," you need to make it not required, by using blank=True (and possibly null=True as well, if it's not a CharField).
The core attribute isn't used anymore.
From Brian Rosner's Blog:
You can safely just remove any and all core arguments. They are no longer used. newforms-admin now provides a nice delete checkbox for exisiting instances in inlines.
This is simple. I started getting this problems a few revisions ago. Basically, just remove the "core=True" parameter in the ImageField in the models, and then follow the instructions here to convert to what the newforms admin uses.
Related
I'm trying to migrate my Django project from Python 2.7/Django 1.11 to Python 3.7/Django 2.1.
And I'm a little bit confused with one issue.
Django 2.1 marks as errors all models.ForeignKey(...) code strings in my project with:
TypeError: __init__() missing 1 required positional argument: 'on_delete'
It is because since Django 2.x, 'on_delete' method is required for ForeignKey fields
(Getting TypeError: __init__() missing 1 required positional argument: 'on_delete' when trying to add parent table after child table with entries)
If you'll read this post, solution is pretty simple, you just need to add one of 'on_delete' options, for example:
models.ForeignKey(..., on_delete=models.CASCADE,)
But Django complains not only about actual 'models.py' file but also about all (!) migrations that include "ForeignKey" fields adding or alteration.
So my question is, is it safe to modify old migration files in Django? And is it what I should do in this situation?
Yes, that's the intended upgrade path as described in the 1.9 release notes:
In order to increase awareness about cascading model deletion, the on_delete argument of ForeignKey and OneToOneField will be required in Django 2.0.
Update models and existing migrations to explicitly set the argument. Since the default is models.CASCADE, add on_delete=models.CASCADE to all ForeignKey and OneToOneFields that don’t use a different option. You can also pass it as the second positional argument if you don’t care about compatibility with older versions of Django.
To update your code to Django 2
(.*)models.ForeignKey\((((?!on_delete).)*)\)\)
$1models.ForeignKey($2, on_delete=models.CASCADE))
field=models.ForeignKey\((((?!on_delete).)*)\)
field=models.ForeignKey($1, on_delete=models.CASCADE)
(.*)models.OneToOneField\((((?!on_delete).)*)\)\)
$1models.OneToOneField($2, on_delete=models.CASCADE))
You can use these 3 regexes to update your codebase with search and replace feature. Of course, step over by checking each replacement, but having a regex will save you time.
I created a project say foo. And created an app named admin. But it causes an error
django.core.exceptions.ImproperlyConfigured: Application labels aren't unique, duplicates: admin”
So I read this and made changes as mentioned there. I marked the label as foo.admin.
I don't exactly know what the label is, but maybe this is the unique name given to an app to distinguish apps with the same name in case.
So is that mean, everywhere I have to use label instead of name?
But it causes another error.
String model references must be of the form 'app_label.ModelName'.
So I used the name in models as foo.admin in ForeignKey parameter. But the same error comes up. But the error persists.
I googled the error and found this. So I changed the ForeignKey parameter from foo.admin to admin. But in either case, I'm having this error.
So in short I want to ask
How to use apps with the same name in the same django project, like Which files are need to be modified and what to write ForeignKey parameters etc.?
(I'm using django 2.0)
I have migrated my OpenERP 7.0 DB from dev to production and now everytime I try to create a new customder, I get this error:
View error Can't find field 'blocked' in the following view parts composing the view of object model 'res.partner':
res.partner.followup.form.inherit Either you wrongly customized this
view, or some modules bringing those views are not compatible*
Any idea of why I see this error?
I am a magento guy so have no clue whatsoever.
If you have frontend or backend instances. Make sure that:
All code match in both instances
Update your module
check if column exist in your table
I recently switched from PHP to Django. My old site in PHP had Disqus integrated, when I migrated to new site, my blog urls changed from /blog/<year>/<month>/<slug> to /blog/<slug>
All new comments are automatically taking the new url, but there are a lot of old links that are still in the form of <year>/<month>/<slug>
Now what I want it to redirect all /blog/<year>/<month>/<slug> to /blog/<slug>
I tried the following:
url(r'^(?P<year>\d{4})/(?P<month>\d{1,2})/(?P<slug>[^\.]+)', RedirectView.as_view(url=reverse_lazy('view_blog_post'))),
url(r'^(?P<slug>[^\.]+)', 'blog.views.view_post', name='view_blog_post'),
This gives me the following errors:
view_post() got an unexpected keyword argument 'year'
which seems obvious because my view only takes slug as an argument. I don't want to write another view to incorporate this change because it is temporary.
Please help me find a solution on this.
Regards.
The view_blog_post pattern requires a slug, so you can't just do reverse_lazy('view_blog_post') because it does not use the slug.
Instead, you can use the pattern_name argument, then Django will use the args and kwargs to reverse the url.
You also want to make the year and month non capturing groups using ?:, because you do not want to use these to reverse the url.
url(r'^(?:\d{4})/(?:\d{1,2})/(?P<slug>[^\.]+)', RedirectView.as_view(pattern_name='view_blog_post', permanent=True)),
The default of permanent is switching to False in Django 1.9, so it's good to set it explicitly to prevent it from changing accidentally when you upgrade.
I'm using django-threadedcomments from ericflo on github. This app simply extends the native django comments framework. I am running into the same issue with both frameworks. I continue to get an error relating to mysql that site_id cannot be null. I have no use for the Site field in my comments. I tried to extend the Comment model with my own making site both blank and null but I am still getting the same error. What is the proper way to override that requirement? Thanks
I tried:
class Comment(Comment):
site=models.ForeignKey(Site,null=True,blank=True)
I found it easier to just define one Site object. django-threadedcomments is not the only extension which requires that.
You will not be able to change this without monkey-patching the current model, but it shouldn't be a big deal setting the site field to Site.objects.get_current() in the view/form when saving a comment!