I have no idea how you can possibly approve this PR so quickly. There are a LOT of changes that need to be tested. In particular the whole idea of the child templates which I am yet to see to be able to comment fully on. When this PR is finished I will test it.

When this PR is finished I will test it.

@brianteeman this is a POC so basically it's down to the maintainers to respond with an approval or rejection or something in between. The fact that I provided actual working code instead of pseudo here was just to help people with the decision (fewer things to imagine). I don't expect anyone to test this PR at this state...

Edit, added also an RFC tag, to help anyone that wants to contribute their ideas here

which I am yet to see to be able to comment fully on

there's a Cassiopeia clone here that is following all the requirements for the new mode (child templates):
https://github.com/joomla/joomla-cms/files/7229879/cassy.zip

@brianteeman I approve of that little change I commented about, not the entire commit. I probably shouldn't play with those buttons :)

I'm going to dig into the entire commit as soon as I get some strength. I would probably try and hook into the branch itself and do some contributions myself. I think so far the direction is going somewhere and this time we might actually have some results.

I'm interested in having a TinyMCE instance specific to each template/module in the sense that:

• front-end template will override the instance of TinyMCE editor for content items, aka articles
• site modules with <filed type="Editor"> set into their moduleName.XML file will override the instance of TinyMCE for its own specific config

Also I'm interested in overriding the entire stuff: TinyMCE javascript init, plugins, toolbars, templates, everything.

Sounds good?

Also I'm interested in overriding the entire stuff: TinyMCE javascript init, plugins, toolbars, templates, everything.

This is already possible at the moment. create a plugin listening for onBeforeCompileHead and in there change anything tinyMCE related (stored at the plg_editor_tinymce->tinyMCE->default and for each id: plg_editor_tinymce->tinyMCE->articletext . You can always check what PHP send to the browser using Joomla.storageOptions

A more graphical representation:

I know I can create an entire plugin basically a JCE 2.0, what I'm interested is to do that without a system plugin or anything, just using the right structure + code for templates and modules WITH the default Joomla TinyMCE editor plugin. This way end-users have less options to dig in order to enable the editor the developer designed. How cool is that: no need for page builders, hacks or bloatware.

what I'm interested is to do that without a system plugin or anything, just using the right structure + code for templates and modules WITH the default Joomla TinyMCE editor plugin

Exactly what I'm proposing here. Let me explain with a simple use case what's happening (thanks to child templates and the existing architecture which I'm using here):

• You as a template author create a template (front end) and you customize the styles_format.json, format.json, tinyMCE templates and the skin.
• Me as the end user that got the template from you OOTB got a tinyMCE that fits the rest of the template and produces HTML that is optimal for the template (these were your responsibilities as a template author).
• But I'm quite an advanced user and I wanted to modify some of your decisions, can I do it? The answer is yes and it's quite easy. All I have to do is create a child template (that will be a one click thing once the PR is done), assign it as default, and head to edit the files. Copy the template's original skin, the tinyMCE templates, the styles_format.json, and the format.json to the child, edit them to whatever fits my bill and Holla, Job done!!

My site has two templates. What happens now with the editor? The template doesn't get associated with the content until after it is created.

My site has two templates. What happens now with the editor? The template doesn't get associated with the content until after it is created.

There are 2 possible outcomes here:

• Your templates are completely compatible (in the child era, the second template would be just a child where you deviate some options/styles/overrides) and in such case there's no real problem here. Remember editing something in the front end uses the default template, IIRC.
• Your templates using different CSS Frameworks and in such case just use the default tinyMCE config. By default, tinyMCE config is not changed, the changes are coupled to the template and only if the template is supporting the new Mode. And once again using a child to customise the config to whatever you want is still on the table...

Your templates are completely compatible (in the child era, the second template would be just a child where you deviate some options/styles/overrides) and in such case there's no real problem here. Remember editing something in the front end uses the default template, IIRC.

Why wouldnt it be a completely different with a completely different design, structure and even framework. And no, editing in the front end doesn't necessarily use the default template and you dont address creating content in either site or admin.

Honestly I really dont like the way this sounds like its going

Honestly I really dont like the way this sounds like its going

So, what I'm proposing covers 99% of the users. One site one template. This makes it extremely intuitive for all these users, they don't have to do anything (as long as they pick the right template that supports these features). Also, as I said child templates are here to help people deliver more designs using one template. The necessity for multiple templates should be eradicated by the child templates (for almost all cases).

About the 1% that needs something else they can:

• not use the child templates at all, the same situation as the current state
• use the child templates with their own plugin that manages the way that tinyMCE should behave. Joomla can't predict what could happen if someone wants to use 100 templates and quite frankly if you need so diverse templates (apart from the fact that probably there is something fundamentally wrong with the implementation of the site) as I already said DO NOT USE this feature, it's opt in.

(as long as they pick the right template that supports these features).

thats the part that concerns me

thats the part that concerns me

There are some missing switches atm that will override the behaviour (use the defaults), maybe that part makes you think that these are dictated, the user still has control over all aspects (on/off, custom overrides).

That said we can educate users, eg have a very good explanation of what coupling your content to the template's CSS means, and also, ask template providers to help us form this feature so it's not another FOOBAR thing that nobody will ever use. As I said this is a POC so I'm expecting input in order to form this to something that would be beneficial for everyone. Then again maybe you're right and Joomla can only deal with inline styles in tinymce (although I was using these tricks for quite some time on client sites) but that would be a very sad realization that the CMS can't do proper 2021 html...

This introduces a minor change, legacy templates will have the tinyMCE templates in the /templates/templateName/html/tinymce while the ones supporting the new mode will have to get those files in /media/templates/site/templateName/html/tinymce.

The tinymce templates/snippets were deliberately placed in the /templates folder so that they can be created and edited in the template manager. Unless I am missing something moving them to the /media folder prevents that.

This might be controversial but the editor.css that tinyMCE is using IMHO should be an exact copy of the front end template CSS.

It can be today although I personally just include the typography related css

Am I missing something. I have applied the PR, npm i, nstalled cassy, made that default. But when I try to create any content in the site or admin I get the following erors

Refused to apply style from '<URL>' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
create-a-post:1 Refused to apply style from 'http://localhost/joomla-cms/joomla-cms/media/plg_editors_tinymce/css/skins/ui/oxide/skin.min.css' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
create-a-post:1 Refused to apply style from 'http://localhost/joomla-cms/joomla-cms/media/plg_editors_tinymce/css/skins/ui/oxide/content.min.css' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
create-a-post:1 Refused to apply style from 'http://localhost/joomla-cms/joomla-cms/media/templates/site/cassy/css/template.css?3bf64677bb9dd49735cdf5204357a7bf' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
create-a-post:1 Refused to apply style from 'http://localhost/joomla-cms/joomla-cms/media/plg_editors_tinymce/css/skins/ui/oxide/skin.min.css' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
create-a-post:1 Refused to apply style from 'http://localhost/joomla-cms/joomla-cms/media/plg_editors_tinymce/css/skins/ui/oxide/content.min.css' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
create-a-post:1 Refused to apply style from 'http://localhost/joomla-cms/joomla-cms/media/templates/site/cassy/css/template.css?3bf64677bb9dd49735cdf5204357a7bf' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.

Unless I am missing something moving them to the /media folder prevents that.

At the moment Child templates aren't supported in the UI of Joomla but once #32896 is done (which is the prerequisite for enabling child templates) this will be possible. One of the fundamental changes for the child templates is that they should be safer (eg no public access to /templates) and consistent with the rest of Joomla's extensions (eg ALL static assets served from /media).

It can be today although I personally just include the typography related CSS

Placing some STATIC CSS in a file will never be able to accurately represent the styles of a template due to the simple fact that almost all templates allow some kind of colour selection that is stored in the db. By definition this customization cannot be somehow done with static CSS without the need of constantly changing values in multiple places (the template form UI, and the editor.css). This approach just eliminates that, and can still read the editor.css and include that in the response (not sure if I already coded that part right now)

Am I missing something. I have applied the PR, npm i, nstalled cassy, made that default. But when I try to create any content in the site or admin I get the following errors

I probably messed up something. I will check this later on today

Unless I am missing something moving them to the /media folder prevents that.

At the moment Child templates aren't supported in the UI of Joomla but once #32896 is done (which is the prerequisite for enabling child templates) this will be possible. One of the fundamental changes for the child templates is that they should be safer (eg no public access to /templates) and consistent with the rest of Joomla's extensions (eg ALL static assets served from /media).

That suggests that they would only work then for a template that has implemented child templates?

I would argue that these content templates/snippets are NOT static assets at all.

Without being able to test it at all then I can't really make any more constructive comment

That suggests that they would only work then for a template that has implemented child templates?

No, existing templates will continue to expect the tinymce in their /html folder. The change affects only the new templates that will support childs. It's not my intention to break anything here, but the change is needed for security and consistency (assets that can be fetched from the browser need to be in a public facing dir)

I would argue that these content templates/snippets are NOT static assets at all.

They are, the definition is coming from the way you are using them. They are fetched DIRECTLY from the browser thus for Joomla should be considered static assets. In the Joomla relm static is anything that is not served through PHP.

Without being able to test it at all then I can't really make any more constructive comment

Will try to fix it in a bit

index.php:1 Refused to apply style from 'http://localhost/joomla-cms/joomla-cms/media/plg_editors_tinymce/css/skins/ui/oxide/skin.min.css' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
index.php:1 Refused to apply style from 'http://localhost/joomla-cms/joomla-cms/media/plg_editors_tinymce/css/skins/ui/oxide/content.min.css' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.

@brianteeman what's your browser here?

Same result in chrome, firefox, edge

Do you have these files in your installation?

Found the problem - looks like its your old problem of not developing in a folder

Nice, so it's not from the build tools. Could you copy-paste the Request/response from the console on the skin.css

Not at my pc just yet but I can't see how that last change to the skin path (which was working) could fix the path issue with the template.css

Not at my pc just yet but I can't see how that last change to the skin path (which was working) could fix the path issue with the template.css

Probably it doesn’t, I just realized that you last screenshot was not about the skin. I will check it in my lunch break

I will check it in my lunch break

thats why I replied asap ;)

@brianteeman I've updated the front end template cassy_1.0.0.zip

No errors now and I can test it.

probably beyond the scope but cassy is missing var(--cassy-color-primary)

probably beyond the scope but cassy is missing var(--cassy-color-primary)

Here's abetter version:

<?php
/**
 * @package     Joomla.Site
 * @subpackage  Templates.cassy
 *
 * @copyright   (C) 2021 Open Source Matters, Inc. <https://www.joomla.org>
 * @license     GNU General Public License version 2 or later; see LICENSE.txt
 */

defined('_JEXEC') or die;

/** @var Joomla\CMS\Document\HtmlDocument $this */

/**
 * This endpoint returns the CSS content for the template
 */
$this->setMimeEncoding('text/css');
$this->setCharset('utf-8');

$wa         = $this->getWebAssetManager();
$mv         = $this->getMediaVersion();
$fontStyles = '';
$editorCSS  = '';

// Use a font scheme if set in the template style options
$paramsFontScheme = $this->params->get('useFontScheme', false);

if ($paramsFontScheme) {
  if (stripos($paramsFontScheme, 'https://') === 0) {
    $this->getPreloadManager()->preconnect('https://fonts.googleapis.com/', []);
    $this->getPreloadManager()->preconnect('https://fonts.gstatic.com/', []);
    $wa->registerAndUseStyle('fontscheme.current', $paramsFontScheme, [], []);

    if (preg_match_all('/family=([^?:]*):/i', $paramsFontScheme, $matches) > 0) {
      $fontStyles = '--cassy-font-family-body: "' . str_replace('+', ' ', $matches[1][0]) . '", sans-serif;
  --cassy-font-family-headings: "' . str_replace('+', ' ', isset($matches[1][1]) ? $matches[1][1] : $matches[1][0]) . '", sans-serif;
  --cassy-font-weight-normal: 400;
  --cassy-font-weight-headings: 700;';
    }
  } else {
    $wa->registerAndUseStyle('fontscheme.current', $paramsFontScheme, ['version' => 'auto'], []);
  }
}

// Color Theme
$paramsColorName = $this->params->get('colorName', 'colors_standard');
$wa->registerAndUseStyle('theme.' . $paramsColorName, 'media/templates/site/cassy/css/global/' . $paramsColorName . '.css');

// Enable assets
$wa->useStyle('template.cassy.' . ($this->direction === 'rtl' ? 'rtl' : 'ltr'))
  ->useStyle('template.active.language')
  ->useStyle('template.user');

// Get the URLs
$templateCSSUri       = $wa->getAsset('style', 'template.cassy.' . ($this->direction === 'rtl' ? 'rtl' : 'ltr'))->getUri();
$templateColorsUri    = $wa->getAsset('style', 'theme.' . $paramsColorName)->getUri();
$activeLanguageCSSUri = $wa->getAsset('style', 'template.active.language')->getUri();
$userCSSUri           = $wa->getAsset('style', 'template.user')->getUri();
$fontsCSSUri          = $wa->assetExists('style', 'fontscheme.current') ? $wa->getAsset('style', 'fontscheme.current')->getUri() : '';

// Assign the URLs to CSS imports
$templateCSS       = ($templateCSSUri !== '') ? '@import url("' . $templateCSSUri . '?' . $mv . '");' : '';
$templateColorsCSS = ($templateColorsUri !== '') ? '@import url("' . $templateColorsUri . '?' . $mv . '");' : '';
$activeLanguageCSS = ($activeLanguageCSSUri !== '') ? '@import url("' . $activeLanguageCSSUri . '?' . $mv . '");' : '';
$userCSS           = ($userCSSUri !== '') ? '@import url("' . $userCSSUri . '?' . $mv . '");' : '';
$fontsCSS          = ($fontsCSSUri !== '') ? '@import url("' .  (strpos($fontsCSSUri, '/') === 0 ? $fontsCSSUri . '?' . $mv : $fontsCSSUri) .'");' : '';

// The user editor.css from /media/templates/site/cassy/css/editor.css
if (is_file(JPATH_ROOT . '/media/templates/site/cassy/css/editor.css')) {
  $editorCSS = @file_get_contents(JPATH_ROOT . '/media/templates/site/cassy/css/editor.css');
}

echo <<<CSS
@charset "UTF-8";
/** Template CSS */
$templateCSS

/** Template Colours */
$templateColorsCSS

/** Active Language CSS */
$activeLanguageCSS

/** User CSS */
$userCSS

/** Fonts CSS */
$fontsCSS

/** Inline */
:root {
  --hue: 214;
  --template-bg-light: #f0f4fb;
  --template-text-dark: #495057;
  --template-text-light: #ffffff;
  --template-link-color: #2a69b8;
  --template-special-color: #001B4C;
  $fontStyles
}

/* Editor styles from css/editor.css */
$editorCSS
CSS;

I can see how it works now ;)

Question 1
There will be a lot of thing to add to the json files for each template. Is it possible to have a fallback json? ie if you miss the aligncenter from your json then instead of falling back to the inline style. This will make the job of the template designer much easier as they will only need to change the json where there own template is different.

There will be a lot of thing to add to the json files for each template. Is it possible to have a fallback json?

The quick answer is YES, but probably it's the wrong one as well. The defaults already exist in the tinyMCE's internal configuration and yes we can combine merge JSON files with ease. The question that needs to be addressed is what consists of the base JSON that the templates will extend? A reminder that some classes might be CSS Framework specific. A few years back when @ciaran and I were proposing a Joomla CSS Framework and that was because we believed (I still do) that some classes should be owned by the CMS and anyone that implements a Bootstrap, Tailwind, whatever template has to extend their code to cover these classes. Right now there's no common denominator so it's kinda hard to come up with a base JSON that covers everybody. But maybe I'm wrong here...

EDIT: The project could invest into a static site that could generate those JSON files in a gui fashion

So my other concern is that the jeditor.php file is very complex (at least for me to understand)

So my other concern is that the jeditor.php file is very complex (at least for me to understand)

That's more a Cassiopeia related issue, in short the jeditor.php is something like:

defined('_JEXEC') or die;

/** @var Joomla\CMS\Document\HtmlDocument $this */

/**  Set the right mime/encoding */
$this->setMimeEncoding('text/css');
$this->setCharset('utf-8');

/** Concatenate and inline all the CSS parts that served in the normal template */
$css = '....';

/* retrun the inlined CSS */
echo $css;

So all the complexity is from the Web Assets, Custom colours, Custom Fonts, etc that are specific to Cassiopeia and the way these were implemented. Another template might have 1/3 of that logic or 4x more code, the sky is the limit...

just wanted to say that I get the benefits of this now. Took me a while - sorry.

I'm happy my issue #35606 has such a successful path. I'm happy to come here for a test as soon as I can.

I get the benefit of this so much more now.

@brianteeman I’m happy to finalize this if it ever gets an approval but I’m also happy that you already did the container part. Btw the tinymce’s docs have some more there: https://www.tiny.cloud/docs/demo/format-html5/

I forgot you had done this and started to do the same exact thing this morning after feedback from my "do more with core" talk last night.

This one could be revisited in v5

I'll get back to this as soon as I can, unfortunately couldn't assist lately. Why close?

#35871 (comment)

@dgrammatiko I'm the one who wrote the code, not you, so please don't be upset and close your PRs :)

@dgrammatiko

I don't share that guy's opinion, if he wants J3 functionality to be forever, he should probably stick to J3.

I think your PR here is great without even testing it, I've read some code and I like it. I'm sure I'm gonna love it once I've actually tested it :)

So please take it easy man, I'm here.

@joomdonation I'm not gonna close the open PRs that are still valid and I'm also gonna finish the child templates work as I promised because today apparently it's #WorldKindnessDay

@thednp parts of this PR are already implemented with the child templates and also @brianteeman did the base for the JSON in TinyMCE with #35715 so things could at some point reach the point I demoed here. The editor CSS endpoint didn't make it for 4.1, but you could try again in a future release.

@dgrammatiko Happy to hear that and thanks !

Please reopen the PR, I'm going to work on it next on my list. I don't see any reason why this wouldn't make it to 4.1.

@thednp as I said before some parts are already part of other PRs.

If you want to work on the remaining parts these are:

• Introduce style_formats.json and formats.json to allow tinyMCE to use Bootstrap, Tailwind or whatever other CSS frameworks in the produced HTML. (You have to extend the work already started with #35715)

• Templates that support the new mode (child templates) could provide an end point jeditor.php, a copy of their index.php that will return a css representative of the template's styles used

You're more than welcome to use any of the code here, eg

• the endpoint is here: #35669 (comment)
• the style_formats.json and formats.json are in the description
• the few lines needed in tinyMCE could be sniffed from the files in this PR

That said please get some advice either from @bembelimen (4.1) or @HLeithner, I think the features for 4.1 are already fixed (but I might be wrong)

Don't allow yourself be bullied by ignorant fools