Allow theme to specify richeditor settings

[bennothommo]

I think this has been discussed before, but couldn't find the discussion/issue, so adding it here for future reference.

Since the rich editor widget is generally meant as a representation of how the content will look on the CMS-facing website, it would make sense for the theme to be able to play a part in defining the settings and styling of rich editor config so that rich editor content more closely represents how it will look inside the theme.

Currently, the only method of modifying the settings or styling of a rich editor is through the "Editor Settings" settings page in the Backend, but this method is non-transferrable unless you copy the database over, and isn't necessarily correlated to the theme.

A theme should be able to do the following:

• Define the custom stylesheet to style all elements within the rich editor.
• Provide options for all Markup settings (Link classes, table classes, paragraph tags, etc.).
• Import fonts into the backend as necessary, if the theme uses custom fonts.
• Allow the user to override these defaults through the "Editor Settings" screen.

I think the simplest implementation of this idea would be to add a button to the "Editor Settings" page to "Use theme defaults", which will act like the "Reset to default" button, but instead populates the entire settings page with the theme's given settings. From there, any modifications made to these settings will deviate from the theme.

[damsfx]

A theme should be able to do the following:

* Define the custom stylesheet to style all elements within the rich editor.

* Provide options for all Markup settings (Link classes, table classes, paragraph tags, etc.).

* Import fonts into the backend as necessary, if the theme uses custom fonts.

* Allow the user to override these defaults through the "Editor Settings" screen.

Is the idea to use the theme.yaml file of the theme to set all these options or another file?

I think the simplest implementation of this idea would be to add a button to the "Editor Settings" page to "Use theme defaults", which will act like the "Reset to default" button, but instead populates the entire settings page with the theme's given settings. From there, any modifications made to these settings will deviate from the theme.

Would it be possible to inform the user that the settings have been changed from the "Editor settings" page before performing a reset from the settings defined in the theme?

[bennothommo]

@damsfx

Is the idea to use the theme.yaml file of the theme to set all these options or another file?

It will definitely be part of theme.yaml. No real need for it to be in a different file.

Would it be possible to inform the user that the settings have been changed from the "Editor settings" page before performing a reset from the settings defined in the theme?

Good suggestion - will see what I can do on this.

[damsfx]

@mjauvin , I'm really a fan of this evolution. To me it seems logical that the theme should drive the editor configuration.

I have created a ThemeAddOns plugin for my needs that allows me to get the options for some fields in this way:

    backgroundClass:
        label: 'Background color'
        type: dropdown
        options: getThemeOptions

Combined with a configuration file [your theme]/configs/themeaddons.yaml (I didn't dare to use the theme definition file) where options can be set :

    backgroundClass:
        '': 'None'
        'bg-red-500': 'Red'
        'bg-blue-500': 'Blue'
        ..

    your_field_name:
        'value1': 'My value 1'
        'value2': 'My value 2'
        ...

This allows me to have predefined options for the customization form fields attached to the theme, but also when using page variables within the static pages plugin. My idea was to go as far as configuring the editor options from this file for formatting, available css classes per element (headings, paragraphs, ordered list ...).

---

• Import fonts into the backend as necessary, if the theme uses custom fonts.

If the theme style sheet contains the definitions, it may not be necessary? Unless you're looking at independently loaded fonts with their own tags from the layout eg :

<link href="https://fonts.googleapis.com/css2?family=Archivo:wght@300;400;700&display=swap" rel="stylesheet">

If I can help you with these new features, feel free to ask so.

[mjauvin]

@damsfx did you mean to tag @bennothommo ?

[damsfx]

@damsfx did you mean to tag @bennothommo ?

Whoops! ¯\_(ツ)_/¯

[bennothommo]

@damsfx

If the theme style sheet contains the definitions, it may not be necessary?

We'd need a mechanism for the Backend to load the font file, so that the font file can be used in the editor. For example, the project I'm working on at the moment has a purchased font, and the only way to load it into the Backend at the moment is to hack it in through the Back-end Settings area, or by creating a new skin for the Backend, both of which aren't the most natural way.

[damsfx]

@bennothommo

If the theme style sheet contains the definitions, it may not be necessary?

I was more thinking of the fonts declared in a stylesheet loaded by the editor:

    @font-face {
        src:  url('../fonts/Manifesto.ttf.woff') format('woff'),
        url('../fonts/Manifesto.ttf.svg#Manifesto') format('svg'),
        url('../fonts/Manifesto.ttf.eot'),
        url('../fonts/Manifesto.eot?#iefix') format('embedded-opentype');
        font-weight: normal;
        font-style: normal;
    }

Reading you, I better understand the needs for this feature.

[bennothommo]

@damsfx I don't particularly want people to be able to inject full stylesheets into the Backend from the theme - there has to be a separation between a CMS theme and a Backend skin. However, I'm thinking of allowing people to define custom fonts in the YAML file which we'll then create the @font-face rule automatically for them.

[LukeTowers]

I don't particularly mind if people inject custom CSS into the backend from the theme, it'd be up to them how much they want to use/abuse such a feature. I wouldn't really want to go down the rabbit hole of reimplementing a bunch of different CSS options through some other interface just to avoid them injecting full CSS into the backend from a theme.

[bennothommo]

Well, I suppose we do give them the ability to add a custom stylesheet for the Backend, so I guess we could just make that something that the theme can populate.

[github-actions[bot]]

This issue will be closed and archived in 3 days, as there has been no activity in this issue for the last 6 months. If this issue is still relevant or you would like to see it actioned, please respond within 3 days. If this issue is critical for your business, please reach out to us at [email protected].

[LukeTowers]

@bennothommo what's the status on this?

[bennothommo]

I haven't done any work towards it, but it's still a good idea I would like to see into fruition at some point.

[LukeTowers]

I'll archive it for now unless someone wants to work on it.