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? On Wednesday, October 19, 2016 at 8:59:45 AM UTC-4, Neil Ashton wrote: > > 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 > -- Message URL: https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id Unsubscribe: send a message to [email protected] --- You received this message because you are subscribed to the Google Groups "django CMS developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/django-cms-developers/95cfe33e-9320-483d-86c8-9eb0500560f1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
