[4.0] TinyMCE skins using template overrides

[dgrammatiko]

Pull Request for Issue # .
A redo of #14510

Summary of Changes

This a PR that fixes an old bad implementation of the theming for tinyMCE (I'm the one that did that)
In J3 to use a custom skin you had to upload it in the media/editors/tinymce/skins
That's utterly wrong. The skin is part of templating so the right path is templates/mytemplate/
Also the only ways to reach media/editors/tinymce/skins are either ftp or ssh. By using the template we can use the editor in the template styles at the end the skin is just plain css so it belongs to the rest of our current css...

Testing Instructions

Go to node_modules/tinyMCE/skins and copy the folder oxide_dark to administrator/templates/atum/css/vendor/tinymce/skins/ui. Rename it or leave it as is.
Check it by editing an article.

Expected result

Actual result

Documentation Changes Required

Mild B/C break as we're removing a very idiomatic implementation of tinyMCE theming

This is not conflicting with #29257 That PR is adjusting the inner part of the editor

[SharkyKZ]

This unnecessarily removes the ability to select skin per set.

[dgrammatiko]

This unnecessarily removes the ability to select skin per set.

Yes this is right! the skin should be in sync with the template, it's a css, no need for different sets. Unless you like circus looking sites

Also it's not quite accurate you can still do whatever you want by overriding the tinyMCE options, a known way for getting other options your way...

[Quy]

Also remove "skin":"0","skin_admin":"0" in base.sql in the installation folder.

[Quy]

I have tested this item ✅ successfully on fd7f22b

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/29259.}

[SharkyKZ]

Why accept a random folder name? This reintroduces confusing behavior from before #25493.

[dgrammatiko]

Will only accept one in this case so there shouldn't be an issue now. People seem to like naming things (eg match the template name), hardcoding this is an unnecessary limitation. Maybe the php here is a bit weird because all we want to do here is check if there is a folder in that path and if so then we'll use it.

[Quy]

I have tested this item ✅ successfully on 7ead8a6

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/29259.}

[bonzani]

I have tested this item ✅ successfully on e6c9e69

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/29259.}

[richard67]

@Quy Could you repeat your test? Just to be safe aftert the last commit.

[dgrammatiko]

@Quy please hold your test
@richard67 I think I have messed up the sql's here. Let me fix that

Edit: No the changes from NULL to ' ' is what's in the current branch

@Quy this is fine you can proceed with the testing (thanks)

[richard67]

@dgrammatiko Looks ok now.

[Quy]

I have tested this item ✅ successfully on e6c9e69

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/29259.}

[Quy]

RTC

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/29259.}

[wilsonge]

Why not just Uri::base()?

[dgrammatiko]

Good question 😃 (probably I forgot that this was an option)

[wilsonge]

So I'm in favour of this change overall for overriding a skin at the template level rather than placing into the media directory.

However I think that probably we want to keep the options in the UI.

For two reasons - first of all we've lost the ability to use the oxide-dark default tiny theme. Which for dark skinned templates is probably just annoying that they would then have to keep things synched. Secondly I guess it allows different themings for the different levels (90% of the time probably not a major issue but when you're showing limited options to people I guess situationally could be useful)

[dgrammatiko]

Secondly I guess it allows different themings for the different levels

From a consistency and design integrity point of view people shouldn't roll different skins in a single template. The idea is that the skin is an integral part of the used template. But this is still possible, @Fedik already showcased how someone can override any (that also covers the skin) tinyMCE option. Personally I'm in favour of options that:

• are covering the common, 80% of the use cases. Chasing always the 20% proved to be problematic in Joomla.
• are not allowing/promoting a bad pattern (in this case breaking the UI consistency)

Which for dark skinned templates is probably just annoying that they would then have to keep things synched

I'm pretty sure (I had a little chat with Charlie on this one) proper front enders they will use http://skin.tiny.cloud/t5/ to provide a concrete skin that aligns with their templates colours, etc. So there isn't much to worry about here. (Their tool allows to import JSON data for the compilation not to mention that you can have the source and run it as a step of the rest of the building tools)

Anyways, that was my personal take here, if you insist on having back the options then let's get them back...