TextPlugin ignores templates in CMS_PLACEHOLDER_CONF

[John-Scott]

Assume the following settings:

CMS_PLACEHOLDER_CONF = {
    'content': {
        'plugins': [
            'TextPlugin',
        ],
        'text_only_plugins': [
            'FilerLinkPlugin',
            'FilerImagePlugin',
            'FilerFilePlugin',
        ],

    },
    'custom_page.html content': {
        'plugins': [
            'TextPlugin',
        ],
        'text_only_plugins': [
            'FilerLinkPlugin',
        ],
    },
}

If I add a TextPlugin on a Page that uses 'custom_page.html' as the template, it will actually have all 3 'text_only_plugins' enabled from the bare 'content' configuration and not the more limited set in 'custom_page.html content' key. 

The reason is that TextPlugin never actually looks up the configuration by the template + placeholder name, only by the placeholder name ('content' in this example).

CMSPluginBase.__init__() sets self.page = None and so TextPlugin only ever passes None as the page parameter to plugin_pool.get_text_enabled_plugins(). This in turn results in get_placeholder_conf() only looking up the placeholder settings by placeholder and never by template + placeholder.

When you add a TextPlugin to a page, the plugin instance does not yet have a db relationship with a Page instance, only the Placeholder. I'm pretty sure at that point, there is no way for it to discover the current page instance (let me know if there is a way).

On edit, there will be a db relationship so it could then correctly pass in a page parameter. And this case can be fixed without any special code, just change it to pass `self.placeholder.page` instead of `self.page`.

What is the purpose of the CMSPluginBase.page attribute? Is this ever modified anywhere and set to a non-None value? 

Appreciate clues on how to handle the case when initially adding a TextPlugin. I'll create a pull request once I have a comprehensive solution that handles both add & edit.

Thanks,

John-Scott

[John-Scott]

Sorry to ping the thread but would really like to resolve this bug and need some core-dev input as some of the architecture and intentions behind it are a little opaque to me.

Thanks,

John-Scott

[Iacopo Spalletti]

> <https://github.com/divio/djangocms-text-ckeditor/blob/master/djangocms_text
> _ckeditor/cms_plugins.py#L80-L84> as the page parameter to
> plugin_pool.get_text_enabled_plugins()
> <https://github.com/divio/django-cms/blob/develop/cms/plugin_pool.py#L244>.

> This in turn results in get_placeholder_conf()

> <https://github.com/divio/django-cms/blob/develop/cms/utils/placeholder.py#L
> 50-L66> only looking up the placeholder settings by placeholder and never by

> template + placeholder.
>
> When you add a TextPlugin to a page, the plugin instance does not yet have
> a db relationship with a Page instance, only the Placeholder. I'm pretty
> sure at that point, there is no way for it to discover the current page
> instance (let me know if there is a way).
>
> On edit, there will be a db relationship so it could then correctly pass in
> a page parameter. And this case can be fixed without any special code, just
> change it to pass `self.placeholder.page` instead of `self.page`.
>
> What is the purpose of the CMSPluginBase.page attribute? Is this ever
> modified anywhere and set to a non-None value?
>
> Appreciate clues on how to handle the case when initially adding a
> TextPlugin. I'll create a pull request once I have a comprehensive solution
> that handles both add & edit.
>
> Thanks,
> John-Scott

For how the currently implementation of plugin handling works, the plugin is
always in "Edit mode" when the form is shown to the user as the plugin is
created in the background and *then* the changeform is opened.
So self.placeholder.page should never be None if the plugin is added to a
page.
Thus by changing that line you should be able to fix the error.


--
Iacopo Spalletti