Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Revive compatibility with third-party plugins (with a compat patcher?) #6700
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?