Skip to content
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

Revive compatibility with third-party plugins (with a compat patcher?) #6700

Open
pakal opened this issue Jul 6, 2019 · 0 comments

Comments

Projects
None yet
1 participant
@pakal
Copy link

commented Jul 6, 2019

Hello,

the last time I upgraded my Django-CMS install to 3.6.0, early 2019, I had lots of troubles with compatibility breakages, regarding the numerous plugins and bridges I used on my project.

cmsplugin-zinnia, cmsplugin-simple-gallery, django-cms-jplayer, cmsplugin-rst and others, while still providing correct and secure features, had been broken by django-cms changes, either because of low maintenance or because they specifically targeted a different django-cms version. I spent 3 days forking and patching.

In a perfect world all plugins would stick to the latest version of their target framework (django and django-cms); however in this one, to avoid some "dependency hell", I think it'd be extremely precious that django-cms keeps a longer backwards compatibility with its ecosystem, and account for these minor plugins, since it enourages the use of plugins for all content handlers and apphooks.

From what I've seen, breaking changes seem trivial to fix, be it changes in plugin filenames conventions, or in the manual renderer API.

Compatibility shims could be put in main source code, but they could also be outsourced to a companion application, eg. I've had much success with django-compat-patcher to make zinnia and lots of other libraries run on DJango2.2.

I could help creating a similar compat patcher for Django-cms, using the mini-framework https://github.com/pakal/compat-patcher-core, but would the django-cms team be willing to cooperate with this compatibility effort, and contribute shims in it for (potential) future compatibility breakages?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.