Improve plugin related names #5145
Conversation
|
why cms/tests/test_frontend.py → cms/tests/DISABLED_test_frontend.py ? |
| for field in new_class._meta.fields: | ||
| if field.name == 'cmsplugin_ptr': | ||
| app_label = new_class._meta.app_label | ||
| model_name = new_class._meta.concrete_model._meta.model_name |
There was a problem hiding this comment.
huh? are you not already skipping non-concrete classes?
There was a problem hiding this comment.
Yes. strangely, _meta.model_name still comes back with the ..._deferred_path bit... This fixed it.
There was a problem hiding this comment.
that's very strange.. I advise to look into why it happens.
There was a problem hiding this comment.
@mkoistinen could you clarify more this point? What do you mean with ..._deferred_path bit?
|
Currently there is an issue with MTI: the plugins that inherit for a parent plugin overwrites the related_name, which must be kept to the parent one. |
|
@mkoistinen @czpython I opened a PR to your branch mkoistinen#2 |
|
This is failing integration tests inside of the call to Django's https://gist.github.com/mkoistinen/028dd9690d19f6ac1f86a6f791fa4545 Any ideas how to make this work? |
|
@mkoistinen seems you reproduce this locally. what django version did you use? |
|
Django 1.8 and Python 3.4 |
We relied on the data stored in the cms-plugin divs, now we rely on data stored on cms-draggable divs for moving/editing. Ref django-cms#5085
…-that-have-no-dom Fixed an issue where plugins with no DOM weren't editable.
czpython
force-pushed
the
feature/improve_plugin_related_names
branch
from
027782f
to
6c17d1b
Compare
This is the continuing saga of Django 1.9 vs. cmsplugin_ptr. The changes in this PR were initially contributed by @yakky's #5032.