-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Fix for re-ordering plugins when JS provides language as empty string #3194
Fix for re-ordering plugins when JS provides language as empty string #3194
Conversation
…dering, use language from the plugin
Just being curious what did you set CMS_LANGUAGE settings to? |
@johnraz I don't have CMS_LANGUAGES set in my settings as it's not a multi-lingual site. The variable is not mentioned here so I assume it's not required: http://docs.django-cms.org/en/latest/getting_started/installation/integrate.html#configuration-and-setup . I do have LANGUAGE_CODE = 'en-gb', though and this seems to be what the plugin instances languages are being set to. |
Ok same thing happen to me without CMS_LANGUAGES... I guess there may be a relation :-) |
@yakky : side note regarding the travis build, same issue as on my other PR ... seems something is broken ❌ |
Please rebase against develop |
…dering, use language from the plugin
…go-cms into fix_for_plugin_ordering
@yakky rebased |
Thanks |
Fix for re-ordering plugins when JS provides language as empty string
I was having a problem where I couldn't re-order plugins within a placeholder, similar to this issue: #3058
This caused an error to popup on move "order parameter did not have all plugins of the same level in it" and then the move plugin would be removed.
I found that the
move_plugin()
method ofadmin/placeholderadmin.py
was not finding the otherplugins
correctly as it was searching for a language of '' (empty string) rather than the language that the plugins had ('en-gb'). This is because the JavaScript POST included aplugin_language
of empty string.As far as I can see, this JS variable comes from a GET parameter of the request so is not reliably there. Falling back to the language of the plugin seems a sensible fix to me.
Maybe there is some extra configuration would otherwise solve this, but I can't find it.