TinyMCE doesn't use Formats configuration from controlpanel

[agitator]

[agitator]

related to https://github.com/plone/Products.CMFPlone/issues/1264

[davilima6]

Any known workaround? Or pointers to fix this?

[davilima6]

Actually, the Formats textarea in Site Setup > TinyMCE isn't supposed to add/configure 1st level items in the Formats menu, as per the screenshot. It serves to define each format in terms of tag and classes used. To make them visible in the UI, you need to reference those formats in the Block or Inline styles textareas in the same configlet.

Reference: http://stackoverflow.com/questions/33828391/plone-5-why-tinymce-disable-custom-inline-styles#comment63397173_33828391

[davilima6]

To add items to the "Quick formats" area (2nd screenshot), you should follow these directions: https://github.com/plone/Products.CMFPlone/issues/492#issuecomment-100435844. If they work I think we can close this issue.

[djay]

@davilima6 the bug then becomes that there was confusion in the first place and how to make it unambiguous. Documentation?

[djay]

Actually looking at in more detail it seems we have two somewhat different ways to get a custom style into tinymce, and they aren't equivalent. This bug should really be about fixing that and making them equivalent. The theme should really be able to control that menu.

• If I upload a theme zip with new table styles, how does tinymce know put them in the menu?
• If my theme doesn't include some of the barceloneta table styles, then tinymce shouldn't be displaying them as options.

[davilima6]

I think they are already equivalent because both enable to insert items in the Formats menu:

1. If you don't have a theme (e.g. you are developing an addon) and want to provide user with css classes for styling or triggering JS plugins/diazo transformations), you use registry.xml (which I suggest we refactor back to tinymce.xml to make for a leaner registry.xml) and the specialized TinyMCE Formats mechanism: https://www.tinymce.com/docs/configure/content-formatting/#formatparameters Imho we're better off not discarding that.
2. If you do have a theme you can use the convenience shortcut from manifest.cfg to add (much) simpler styles in the first level of Formats menu (I call them "quick access formats"). Although quicker, notice this method is more confined: you can't define "A proper title" for your style (the css selector will be listed as title instead), you can't update tags on the HTML, can't add wrappers, nor anything found in the link above.

So, imo it's not overlapping. There are pros and cons but in the end it's just a shortcut consistent with an already in-place mindset: themer can enable or disable additional bundles or add additional resources (but note: only 1 css and 1 js, so also limited) to the implicit (!) diazo bundle.

[djay]

pros and cons == not equivalent == hard to explain == bad UX == bug

[davilima6]

It seems you missed the part that bundles are also only partially manipulable in the ZIP/manifest.cfg story. We'll never be able to do in a ZIP all we can do with Generic Setup and frankly I don't think that's bad.

Well, I gave my 2c. All I can hope now is that more people join this debate.

[djay]

I believe the way modern sites are designed is design led development. The design determines not just how it will look but what semantics a CMS editor can express. Are they allowed to insert videos? Does the frontpage have space for a slider? What attributes do slider panels have, just title and description or an image as well?

IMO a CMS theme is way more than the simple the concept styling or skinning. A website can never be themed like kodi, or cyanagen mod is. This is outdated thinking I believe. I think a theme determines the style and function of the site, its capabilities or plan. The site setup (ie admin roles) and registry should then modify this plan and finally the editors fill in the content based on this plan. Note when I'm using the word theme here I'm not just meaning our current limited implementation of zip with diazo in it. I'm talking about a cohesive package which represents a custom site. Perhaps it would be clearer if I didn't call it a theme but a site integration package or site design or site customisation or site integration. Just look at theme forest and wordpress themes. They do way more than just change the look of what you already have. And they are often designed to customised.

But also there are things a designer perhaps shouldn't control which the registry and GS allow. A theme should have control over what additional things an editor can do such has styles in the format menu, but perhaps not security settings. There are many things have way inbetween where its unclear. For example content types and workflow.

One possible way out is to support installing generic setup in a theme but that has its own issues. Does the GS get uninstalled on each theme deactivation? What if want some GS to remain between switching themes? What if you want some GS to only ever used while the theme is active?

Another solution might be that registry lookup data from both the theme and the current registry. Similar to https://github.com/collective/lineage.registry. But this is going back to using cascading configuration which makes it hard to reason about what the settings are being used at any one time.

@davilima6 yes the bundles story with regard to themes is another example where it only does half of what you need. Which creates the need for complex documentation and people scratching their heads trying to understand why something has hard to understand pros and cons.

[sunew]

See also https://github.com/plone/Products.CMFPlone/issues/1264#issuecomment-368617473

[jensens]

I close the issue, because it addresses Plone 5.1 which is no longer supported. If you think this is wrong please reopen the issue and assign a matching milestone.