[WiP] Implement four-level CMS_PLACEHOLDER_CONF

[yakky]

Currently CMS_PLACEHOLDER_CONF only allows values for placeholder and template+placeholder keys
Sometimes a global configuration would make things much nicer / simpler
@ojii suggested a for level structure like (in increasing order of precedence)

CMS_PLACEHOLDER_CONF['*'] (global)
CMS_PLACEHOLDER_CONF['template'] (if template is given)
CMS_PLACEHOLDER_CONF['placeholder']
CMS_PLACEHOLDER_CONF['template placeholder'] (if template is given)

This is backward-compatible and allow a few neat tricks.

We can also add wildcards to placeholder configuration:

CMS_PLACEHOLDER_CONF['placeholder-*']

this will recognize placeholder-foo and placeholder-bar.
We need to make * (or %) reserved to avoid clashes (this will also solve the @ojii's comment regarding '*' being a valid placeholder name). We can use wildcards also for templates.

Changes needed

• 4-level configuration
• tests
• documentation

On top of this is easy to implement plugin blacklisting (see #5000, #4979), list of plugins to show in text editor and other plugin configuration options

[ojii]

Thinking about this a little more, I think the "global" tag should be None, not '*', as '*' is technically a legal placeholder name.

[yakky]

any comments @divio/django-cms-core ?

[carloratm]

May be an idea to use regexp as CMS_PLACEHOLDER_CONF keys?

[yakky]

@ratmcarlo It may look weird, but it totally makes sense to me

[czpython]

@yakky I like the idea, however I share agree with @ojii that * can be problematic.

[yakky]

Using regexp as suggested by carloratm can solve this as we can use None as default, and rely on regexp to handle wildcards

[yakky]

@czpython @ojii have a look at this proposal from @fmarco yakky#16
It uses general purpose regexp and it does not dictate any specific syntax or reserved keyword

[coveralls]

Coverage increased (+0.002%) to 88.462% when pulling d3acd9c on yakky:feature/global_placeholder_conf into 9c92ccb on divio:develop.

[yakky]

@divio/django-cms-core can I have a feedback on the proposed implementation? It still has rough edges, but before proceeding I'd like a yay / nay if it's the way to go

[coveralls]

Coverage increased (+0.01%) to 88.474% when pulling a609c3a on yakky:feature/global_placeholder_conf into e753f72 on divio:develop.

[czpython]

I'm a bit skeptical about supporting regex, I'm not sure if this feature balances out with the extra technical implications.
I think the original idea (4 level conf) is good just not sure about regex.
If anything I'd say that regex in the template might be a bit too much.

[ojii]

I'm a bit skeptical about supporting regex, I'm not sure if this feature balances out with the extra technical implications.
I think the original idea (4 level conf) is good just not sure about regex.
If anything I'd say that regex in the template might be a bit too much.

I agree. regex seems like overkill and a solution looking for a problem to solve.

[yakky]

Regexp are actually a special case. You can easily use it without them and falling back to the "basic" 4 level structure
This allows to cover cases like "use a specific set of plugins in all the placeholders that starts with 'sidebar-'"
In simple websites this is an overkill, in reasonably sized projects it's almost essential. Especially if you do configure carefully the plugins in placeholders (I may share the regular hundred-lines long CMS_PLACEHOLDER_CONF we are forced to write, sometimes...)

[mkoistinen]

The implementation looks great and while I support the effort here, having this much complexity here, in a setting, makes me wonder if we're going about this all wrong. I don't have any proposed solutions to change from CMS_PLACEHOLDER_CONF, but this seems to be expanding into a lot more than originally intended.

[yakky]

@divio/django-cms-core restructured to use simple key parsing, allowing to customize it

[coveralls]

Coverage increased (+0.01%) to 88.474% when pulling a609c3a on yakky:feature/global_placeholder_conf into e753f72 on divio:develop.

[yakky]

@mkoistinen @czpython could you please provide a comment on this last approach?