Multiple HTMLEditorConfigs

[Martimiz]

 Hi,

I know it is possible to define multiple configurations of the HtmlEditorFields, but it looks like you cannot switch between or add to configurations dynamically in the 3.x CMS.

Example: I have a page with a has_many relation to a Newsletter object. I'm using a GridField on the page to edit the Newsletters and I need a couple of different options for a Newsletter's HtmlEditorField instance.

I thought to use HtmlEditorConfig::setOption() in the Newsletter::getCMSFields function - but that works only on reloading the CMS - and then it persist on all other editors again, as AJAX doesn't refresh it :(

Sofar I have been able to work around this by adding a custom class to the Newsletter HtmlEditorField and then use Entwine to change the redraw behaviour for it - but that feels like a cumbersome hack to me. So I was wondering if I'm missing something? And if not, would solving this be of any interest?


Martine

[Ingo Schommer]

Hey Martine,

That's due to the TinyMCE config being passed to the client as a JavaScript global (ewwww).

A remnant of the 2.x setup, and not the best solution for this.

This ssTinyMceConfig global is pretty large (3000 chars), so I'm a bit reluctant

to duplicate it for every TinyMCE instance you put in a form.

I've seen setups with 10+ editors, which is already terribly slow.

The duplicated config would add another ~30kb of data which needs

to be transferred and parsed on every load/save of the form.

My suggestion is to add HtmlEditorField->setConfigName(),

which defaults to HtmlEditorConfig::get_active().

The CMS then renders all defined configs on the initial load,

so similar to the process at the moment, but keyed by their "name".

You wouldn't be able to do HtmlEditorField->getConfig()->->enablePlugins('media')

etc on an instance, but I think that's an acceptable limitation.

Other ideas?

Ingo

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Hamish Friedlander]

This is how I solved it for 2.4: https://github.com/silverstripe-labs/silverstripe-recipes/blob/master/forms/CustomConfigHtmlEditorField.php

(sorry for brevity, on holiday ATM)
Hamish

[UndefinedOffset]

You know I think this would be nice to have merged into the core for sure. I can see it being useful the odd time.

[Nathan Cox]

On 8/06/2013 3:22 a.m., Ingo Schommer wrote:

My suggestion is to add HtmlEditorField->setConfigName(),

which defaults to HtmlEditorConfig::get_active().

The CMS then renders all defined configs on the initial load,

so similar to the process at the moment, but keyed by their "name".

You wouldn't be able to do HtmlEditorField->getConfig()->->enablePlugins('media')

etc on an instance, but I think that's an acceptable limitation.

I think this is basically what I did here: https://github.com/nathancox/silverstripe-customhtmleditorfield. It's not super pretty but it seems to be working.

Basically it puts all the configs in a javascript array on page load then uses a data- attribute on each HTMLEditorField to determine which one to apply.

[Martine Bloem]

Thanks for all your input. So looks like adding multiple configs has already been solved, great! 

Nathan: I'm going to try your solution as soon as I get back from my - short :( - vacation. Thanks!

In my case I used one and the same config but just changed a few options. I used a custom entwine -> redraw, using an extra custom class for the HtmlEditorField to force priority. Not difficult - just remember to reset the options after redraw - but only  usefull in cases where it's just a couple of options. Only it would be far better if it would be possible to use setOptions() in some way...

It reduces the resources though.

martine

--

[Martimiz]

Hi,

Nathan: I've been working with your solution and it works really well, apart from some small issues, that I more or less solved for 3.05. I'll fork your version later when I find the time and maybe you'd like to take a look atmy contributions :)

One problem though: in SS3.1 HtmlEditorConfig::$configs and HtmlEditorConfig::$current have now been made private, and there are no getters. We need $configs for (optional) cloning, but more we need $current to retreive the active config identifier, so it can be added to javascript as the default value. instead of just using 'cms', since the active identifier seems also to depend on the current Member...

Ingo: Any possibility that getters might be added to v. 3.1? Or am I too late :)  I'm not sure this is actually a bug, just a nuisance :)

Martine

Op 8 jun. 2013 om 23:56 heeft Nathan Cox <m...@nathan.net.nz> het volgende geschreven:

On 8/06/2013 3:22 a.m., Ingo Schommer wrote:

My suggestion is to add HtmlEditorField->setConfigName(),

which defaults to HtmlEditorConfig::get_active().

The CMS then renders all defined configs on the initial load,

so similar to the process at the moment, but keyed by their "name".

You wouldn't be able to do HtmlEditorField->getConfig()->->enablePlugins('media')

etc on an instance, but I think that's an acceptable limitation.

I think this is basically what I did here: https://github.com/nathancox/silverstripe-customhtmleditorfield. It's not super pretty but it seems to be working.

Basically it puts all the configs in a javascript array on page load then uses a data- attribute on each HTMLEditorField to determine which one to apply.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.