Preambel

We should rethink the way how to handle the methods to determine which Plugin is eligible to become a child of another plugin.

Currently, when we open the CMS in structure mode, the Placeholder and its attached Plugins know which plugins may be added as children to an existing plugin. This is determined by each plugin through its attributes parent_plugins and child_plugins. These attributes may be either None or a list of strings. In the former case, all plugins are allowed as parent/children,
whereas in the latter case, only the named plugins are eligible as parents/children.

This static assignment has some drawbacks

1. In an ecosystem of plugins from different vendors, beforehand we don't know, who may want to become the child of a plugin from another vendor. This could cause one vendor having to add his plugin to the list of allowed children from another vendor.

2. Computing the eligible parent-children relationships is time consuming. Therefore django-CMS caches this information internally, which removes the possibility to determine dynamically, for instance by evaluating the current context, which children plugins can be added to an existing plugin.

3. In structure mode, when rendering a deep tree of plugins, each plugin comes with its own list of eligible children plugins. This can add many kilobytes of additional data to the payload, when transferring a CMS page in structure mode.

4. This rigid system of parent-children relationships, does for instance not allow to add kinds of intermediate plugins, such as wrappers or logical segments.

Therefore I want to propose a different method to determine which plugins are allowed as children of another plugin. Instead of computing this list statically before the CMS page is rendered, we should add a REST endpoint, which computes this relationship dynamically and based on the current context.

This list then is transferred from the server to the client and is used to render a list of possible
children plugins. The computation of this list should work as follows:

• The plugin being asked for, iterates over all plugins registered in the pool.
• It then invokes a method, say allowed_as_child_of() for each of the plugins of the pool,
  passing its own instance and the current context.
• Based on the given parameters, this method returns a boolean, which determines, whether a plugin can be added to the current plugin or not.

This computation can now be much more time consuming. This is because we only have to do it
whenever the user clicks on the + symbol inside the plugin editor, rather than having
to do it for all plugins inside the pool. Even if such a computation requires 200 milliseconds,
since this it is part of the user's interaction, this would disturb.

Possible new Features

Plugin systems, which map the Bootstrap grid, usually encounter the following problem:

A row may be part of a container, and columns may be part of that row. An accordion, carousel,
panel and similar elements can either be children of the container, the row or the column.

Depending below which of these elements an accordion panel is placed, its own children then
shall either be either rows, columns or plain content. This means that whenever
allowed_as_child_of() of an element is invoked, that method could check its potential
parent element, and if that does not contribute to the Bootstrap's grid structure (such as said
accordion, carousel, panel, etc.) it can go up a further level in the tree.

This feature would also make it possible to allow plugins depending on the siblings context.

Backwards Compatibility

Since we don't need the complicated caching functionality anymore, I even believe that it
reduces the amount of code. By adding an overridable method allowed_as_child_of() to the
base class CMSPluginBase, this feature could even be implemented in a backward compatible
manner. This method then just would have to examine the plugin's attribute parent_plugins
and the attribute of its ancestor child_plugins to determine whether it is allowed of
being added or not.

Implementation

In case the django-CMS community agrees on this proposal, I will implement this feature so
that it is available in a future major release. With this in mind, I'd like to open a discussion
about it.