Silverstripe 4 use additional custom HTMLEditorField

In Silverstripe 4 how can we use different HTMLEditor configs ?

I'd like to have two different HTMLEditorFields in the same environment. One with all functionality and all Buttons. And another one (MyCustomHTMLEditorField) with reduced functionality and e.g. only 3 buttons (underline, italic, bold).

How do you use ::set_active ?

How to extend HTMLEditorConfig ?

Yes, i've read the documentation but How can this be archived?

There can be multiple configs, which should always be created / accessed using HtmlEditorConfig::get(). You can then set the currently active config using set_active().

Can you provide an Example?

Any help welcome.

The documentation at https://docs.silverstripe.org/en/4/developer_guides/forms/field_types/htmleditorfield/ goes to length about how to define and use HTMLEditorConfig sets.

HTMLEditorConfig::set_active() is really for if you're intending to set an editor for use in multiple HTMLEditorFields in a given form or admin section, or to override the config for all admin sections. It more-or-less sets the 'default' config. That won't be so useful in your case, as it sounds like you want to set a configuration for a given HTMLEditorField.

Setting configuration

This is detailed in the documentation at https://docs.silverstripe.org/en/4/developer_guides/forms/field_types/htmleditorfield/#adding-and-removing-capabilities

Usually this is done in your _config.php (or in some separate class which then gets called from _config.php - unless you only need it in a very specific section, in which case you could set this up or call your special class from that admin's init() method).

The examples in the documentation here modify the default ('cms') config. This is useful if you want to modify the configuration that is used by default. So do this for your config that you've referred to as having "all functionality and all Buttons".

Setting up a new HTMLEditorConfig

Calling HTMLEditorConfig::get($configName) will get the existing config based on the name you pass it - but if there is no existing config, it will create a new one. So you could call $customConfig = HTMLEditorConfig::get('some-custom-config') - now your $customConfig variable holds a new configuration that you can configure however you so choose (insert buttons, enable plugins, define whitelisted elements, etc).

Note that there is some configuration that will be required for new config - for example, a "friendly name":

$myConfig->setOption('friendly_name', 'Some Human-readable name');

I strongly recommend seeing the _config.php file in silverstripe/admin for a fairly thorough example of setting up a config.

Using configuration

This is discussed in the documentation here: https://docs.silverstripe.org/en/4/developer_guides/forms/field_types/htmleditorfield/#specify-which-configuration-to-use

I've already mentioned the set_active() - if you're going to set up multiple HTMLEditorFields in a form for example you can use that in your getCMSFields() method:

public function getCMSFields()
{
    $fields = parent::getCMSFields();
    $fields->addFieldToTab('Root.Main', HMLEditorField::create('Content')); // This will use the default 'cms' config.
    HTMLEditorConfig::set_active('some-custom-config');
    $fields->addFieldToTab('Root.Main', HMLEditorField::create('OtherContent')); // This will use the 'some-custom-config' config that you defined.
    // Don't forget to reset to the default.
    HTMLEditorConfig::set_active('cms');
    return $fields;
}

You can also, as explained in the docs, set your config by name for a given HTMLEditorField which is preferred if you're using a non-default for one one field.

public function getCMSFields()
{
    $fields = parent::getCMSFields();
    $fields->addFieldToTab('Root.Main', HMLEditorField::create('Content')); // This will use the default 'cms' config.
    $fields->addFieldToTab('Root.Main', HMLEditorField::create('OtherContent')->setEditorConfig('some-custom-config')); // This will use the 'some-custom-config' config that you defined.
    return $fields;
}

Note that the syntax I used here is slightly different to the docs - this allows you to avoid passing in the second and third constructor arguments that you're not changing from the defaults. Keeps things a little tidier.

Disclaimer: All of the code above was written from memory, so it may need some tweaks to work correctly.