Changing plugin settings results in missing migrations

22 views
Skip to first unread message

Brian Rutledge

unread,
Nov 16, 2016, 2:20:12 PM11/16/16
to django CMS developers
I posted this issue to djangocms-style, but it seems to me that it affects multiple plugins, so I'm re-posting the description here.

I just upgraded to 2.0.0, and discovered that setting DJANGOCMS_STYLE_CHOICES and DJANGOCMS_STYLE_TEMPLATES results in changing the choices for class_name and template, which necessitates new migrations. It looks any djangocms plugin that uses this pattern (-link, -picture, etc.) will display this behavior. I am not an expert on migrations, so it's not clear to me what problems it might cause, but it make me nervous about future conflicts, and having migrations outside of source control.

John-Scott

unread,
Nov 16, 2016, 2:35:23 PM11/16/16
to django CMS developers
This is one of the things I'd like to see on a code review checklist so this could be caught before a release. 

Any field that uses 'choices' needs to have its migrations modified to point to the variable name (e.g. choices=DJANGOCMS_STYLE_CHOICES) instead of the raw values. Otherwise, 'makemigrations' will copy the values into the migrations file, and when the choices get changed in code, the mismatch will trigger pointless migrations later. 

This issue can creep up repeatedly since if you later alter some other aspect of the field (e.g. help_text), it will again copy the raw choices values into the field definition in the migration, so it will need to be edited to point to the variable name instead.

This issue has come up many times with django-cms and related plugins, so it would be great to make this part of the code review checklist so end users aren't having to deal with this so often, if at all.

Angelo Dini

unread,
Nov 17, 2016, 2:09:33 AM11/17/16
to django CMS developers
Thanks for the report here Brian and John,

as soon as I'm aware of the proper solution to this problem, I'll make sure it gets added to the checklist and in the near future to our addon best practices. Any advice is welcome.

Brian Rutledge

unread,
Nov 17, 2016, 6:28:12 AM11/17/16
to django CMS developers
Looks like the initial migration for djangocms-style does what John suggested for class_name and tag_type.

I'm going to take a crack at a PR for this. That said, I looked through the migrations for djangocms-[link|picture|file], and it looks to me like all of them would have this issue.

Angelo Dini

unread,
Nov 18, 2016, 4:13:25 AM11/18/16
to django CMS developers
I'll be porting the fix to the other core addons, will try to release them around early next week.
Reply all
Reply to author
Forward
0 new messages