Proposed new feature: hiding plugins

43 weergaven
Naar het eerste ongelezen bericht

Neil Ashton

ongelezen,
19 okt 2016, 08:59:4519-10-2016
aan django CMS developers
Hi all,

There has been discussion in the past  about adding a feature to make it possible to "hide" plugins, i.e. "to not show them to the ordinary site visitor without having to delete them" (in @creimer's words; https://github.com/divio/django-cms/issues/4512).

The Django CMS board met to discuss this feature on Monday (https://github.com/divio/django-cms/pull/5723#issuecomment-254366883) and agreed that it would be a good feature to have at the plugin level, with a number of concrete ideas for how it should be implemented:

  • Create a new model with a relationship to CMSPlugin class.
  • Add a disabled = BooleanField(default=False) field to this class.
  • Create a plugin on this app whose only purpose is to extend the global plugin menu actions, this plugin is not renderable or even shown to the user, it's only used internally. I'm not too fond of this approach (abusing plugin to extend menu only) but I think it's the easiest solution for now, anything else would require a big change on the core to allow non plugins to extend the plugin actions menu. The alias plugin is a good example of how to achieve this.
  • An advantage of using an internal plugin is that you can use the get_plugin_urls() method to register the ajax endpoint that will be called when a user activates/deactivates a plugin.
  • Naming-wise, we suggest "disable" and "enable" as the action names, "hide" and "show" are used by the structure board already and this can confuse some users.

As suggested on that Github thread, I'm opening a thread here so that we can continue collaboration around that feature and discuss how to move forward. I'm doing work for a client who is strongly interested in having this feature, so I am quite motivated to help bring it together. :)


The unresolved questions related to this addition are (per the GH thread):

  • Somehow get the cms to know about the disabled field and not render the plugin.
  • Performance impact per plugin
Also the design of the feature.

I look forward to working together with anyone interested in helping with this feature!

-Neil

Neil Ashton

ongelezen,
26 okt 2016, 11:38:5126-10-2016
aan django CMS developers
So if I've understood the proposal correctly, the suggested implementation is that this feature be implemented as a Django app whose purpose is just to define and register an extension of CMSPluginBase with a get_extra_global_plugin_menu_items method that adds "Enable / Disable" for all plugins. So far so good!

Now I think we need to unpack this part of the suggestion: "Somehow get the cms to know about the disabled field and not render the plugin." How do we do this without a field on the base plugin model and some change to the base render method? Are there existing examples of plugins that perform this kind of external modification on another plugin's rendered content?

czpython

ongelezen,
2 nov 2016, 09:37:4102-11-2016
aan django CMS developers
Hello Neil,

Thanks for the followup.
Getting the cms to know about this disabled field and not render a plugin will be tricky and it will have to be something in the core of the cms.
I'd like to help with these changes.

We're planning on doing an unofficial remote sprint from November 18 to November 20, I won't be able to join for the whole sprint but I'm hoping to attend at least a day.
If you're interested, we can meet then to discuss this further and hopefully get something going.
Allen beantwoorden
Auteur beantwoorden
Doorsturen
0 nieuwe berichten