Weekly update – 28 October 2022 – TinyMCE Inputfield released

[ryan]

This week I'm happy to report that the InputfieldTinyMCE module is now released. It is currently released in the modules directory and GitHub but the plan is it will be merged into the core, likely before the end of the year. No need to wait till then though, as you can start using it today. Please consider the module in beta for the moment, though the TinyMCE library itself is in a stable state. 

A lot of the work that went into developing this module went into the configuration aspect. Here are a few a more details that weren't covered in last week's post:

After installing the module, on the module configuration screen, you can decide whether several settings should be configurable for each field, or if you want to just configure them with the module (affecting all fields):

One of things that I thought was important was to make it a lot simpler to add custom classes/styles to the editor. I always found this kind of a pain in CKEditor. So in TinyMCE, I made it so that you can just define these custom styles with the field settings using just simple CSS definitions. InputfieldTinyMCE takes care of converting to a format that TinyMCE can understand (for its menus), as well as the styles to show in the editor. For instance, I wanted to add some common Uikit text classes to a custom "Uikit" group in the Styles dropdown:

And here's the result in the editor:

The markup produced has the correct Uikit classes in the markup so that on the front-end of my site the output is Uikit ready. 

You can add 3rd party or your own custom plugins from the module settings:

And then you can enable them for any field in the field editor:

These are just a few interesting tidbits, but there's a lot more. Also, if you didn't see last week's blog post, that covers a lot more too. Either way, I'd encourage you to download InputfieldTinyMCE, give it a try and please let me know how it works for you. If you come across any bugs, please open an issue report. Thanks for reading and have a great weekend!

[BitPoet]

That's great. Can't wait to find a bit of spare time to take it on a test drive. Cool that the module is already on TinyMCE 6.2, as that release comes with a more flexible autocomplete api. This is going to shave a lot of (or almost all of the) JS code from my autocomplete module.

[cb2004]

@ryan I haven't tested this out yet but from what you are saying (you sound very passionate about the change), I am as excited as you have been to jump in. We start a new build next week and I am going to take the leap as it is going to be merged in the core. The site won't be live for a few months so it will be a good opportunity for us.

Just as an early question, one thing my clients always ask for is the ability to embed social media posts or similar, it's the only thing they miss from another CMS which I think you can guess what it is. Is TinyMCE geared up for this as I always found CKE a complete nightmare to manage this?

Finally, I am guessing with old sites everything will have to be reconfigured with regards to toolbars/settings? Thats fine, but the core code will obviously have to contain some instructions that CKE is EOL, and some documentation will have to be created. I am sure you have already considered this, but we obviously have A LOT of old sites that will need reconfiguring, and lots that use Combo now as well.

[Ivan Gretsky]

Great news!

1. I've just installed the new Inputfield on a testing installation. It seems to work well. I've tried both standard and inline modes. Pwlink and pwimage are working, same classes are added for alignment as before.
2. I can't see HTML Purifier. I guess content managers will be happy now inserting all the pink h1's everywhere they love so much) Is it planned or will this be abandoned?
3. As @cb2004 said migration instructions from CKEditor are indeed needed. Hope they are planned.
4. And I guess we should politely ask (beg?) the CKEditor-related module authors to create new versions for TinyMCE. I am talking about:
   @Robin S and his HannaCodeDialog,
   @FireWire and his Fluency Translation...
   Please, please))

[cb2004]

Oh yes, forgot about helper modules. Good shout @Ivan Gretsky

[ryan]

@cb2004

Quote

I haven't tested this out yet but from what you are saying (you sound very passionate about the change), I am as excited as you have been to jump in. 

Well my preference would have been that CKEditor continue developing and improving CKEditor 4, but now that I've worked with TinyMCE 6 for 3 weeks it's been a pleasant surprise and even more of an upgrade than I think CKEditor 5 would have been. 

Quote

Just as an early question, one thing my clients always ask for is the ability to embed social media posts or similar, it's the only thing they miss from another CMS which I think you can guess what it is. Is TinyMCE geared up for this as I always found CKE a complete nightmare to manage this?

TinyMCE comes with a media plugin and toolbar. Though I've not used it and am guessing you'd have to turn off the Purifier option in order to use it (since it would insert iframes or scripts). I don't think iframes and scripts belong in richtext since it would be very difficult to discern malicious scripts from legit scripts. So I'd rather just disallow them completely (which is one thing Purifier does).

Basically, embedding social media or media players directly in markup from a richtext editor opens a lot of security concerns. On the other hand, using modules like TextformatterVideoEmbed, HannaCode, or others that let you embed service specific stuff — this is a good way to do it. It's relatively simple to convert the embed scripts/codes from nearly any social media service into a HannaCode, and even simpler if there's a dedicated module for the service you are wanting to use. So for your client, I would ask them which social media posts they are looking to embed, find out the company's recommend way of doing that, and convert it to a HannaCode, dedicated Textformatter module (one of the simplest kind of moodules to make), or even just ready.php hook after FieldtypeTextarea::formatValue.

Quote

Finally, I am guessing with old sites everything will have to be reconfigured with regards to toolbars/settings? Thats fine, but the core code will obviously have to contain some instructions that CKE is EOL, and some documentation will have to be created. I am sure you have already considered this, but we obviously have A LOT of old sites that will need reconfiguring, and lots that use Combo now as well.

I think you'll find that configuring individual TinyMCE fields is very simple and there's not really much, if anything at all, to converting a field using CKEditor to one using TinyMCE. I thought that I could also have TinyMCE recognize some of the CKEditor settings and convert them automatically (like toolbar, available headlines, and plugins). On the other hand, I think it's better to configure TinyMCE yourself as there's a lot of useful stuff that wasn't there with CKEditor. But if you just want to convert a defaults configured CKEditor field to a defaults configured TinyMCE field, there's basically nothing to it other than selecting "TinyMCE" rather than "CKEditor" for the "Inputfield type" (Textarea field settings dropdown on the Details tab). 

One of the nice things about changing a CKEditor 4 field to TinyMCE is that saving a page with an existing value doesn't usually result in any changes to the markup value. CKEditor 4 and TinyMCE 6 seem to markup things exactly the same, just plain simple HTML. 

Also I should mention that CKEditor 4 isn't going to stop working at any point either. I've been thinking that both TinyMCE and CKEditor will live in the core until CKEditor 4 is completely EOL, and at that point it'll move to a 1st party module. So there won't ever be a case where you will be required to convert all of your CKEditor to TinyMCE fields, unless you want to. In my case, I'll probably keep some installations using CKEditor 4 until it needs some other kind of major development or redo. 

Quote

...and lots that use Combo now as well.

ProFields Combo, Table and Textareas will all support both CKEditor 4 and TinyMCE 6. I don't see any reason to ever drop CKEditor 4 support in ProFields. So long as the module is installed, it'll be selectable as an option. I'll be adding TinyMCE support to these modules soon as well. 

@Ivan Gretsky

Quote

I've just installed the new Inputfield on a testing installation. It seems to work well. I've tried both standard and inline modes. Pwlink and pwimage are working, same classes are added for alignment as before.

Thanks for testing it out! The intention is that everything works just as before, so there isn't any learning curve. 

Quote

I can't see HTML Purifier. I guess content managers will be happy now inserting all the pink h1's everywhere they love so much) Is it planned or will this be abandoned?

HTML Purifier is enabled by default unless you turn it off (in "Features"). This is what cleans the markup server-side. Since you mention pink H1s, I'm wondering if you instead mean CKEditor's ACF (advanced content filter)? TinyMCE has something similar (content filtering) that can be configured with various settings like valid_elements, valid_children, valid_styles, invalid_styles, and many others. InputfieldTinyMCE uses the defaults for most of these, but the one that I've focused on as a configurable setting with the module is invalid_styles which is exactly how you could prevent pink H1s, by just typing the word "color" and "background" and "background-color" into your "Invalid styles" setting. It's also a good idea to instruct clients on how to "paste as plain text", or add the plain text paste option to your toolbar (I think it's already in the menubar). If you want even more control over how content is pasted without any instruction to the client, TinyMCE has pretty much thought of everything here, see Copy/paste options. As far as I know, we didn't have this level of control with CKEditor. 

Quote

As @cb2004 said migration instructions from CKEditor are indeed needed. Hope they are planned.

There's not much to add here as there's little or nothing to it unless you've spent a lot of time really tweaking CKEditor settings and custom plugins, etc. And for those cases I would probably just keep using CKEditor 4. But I do plan to have TinyMCE recognize CKEditor settings for toolbar, plugins and block formats, and automatically convert them where there are equivalents. Though I worry a little that by doing that, some might skip over doing any of their own configuration, and thus miss a lot of new options. 

Quote

And I guess we should politely ask (beg?) the CKEditor-related module authors to create new versions for TinyMCE. I am talking about:

I'm going to detail how to build simple plugins in a related blog post. I was thinking of a simple HannaCode insert plugin as a good example. Not as powerful as HannaCodeDialog, but rather just a simple example to get module authors started. The module also comes with a really simple plugin example named hello that just alerts "Hello" every time you click a button on the toolbar or menubar, but this obviously isn't useful for anything other than being a starting point. 

[Pete]

I noticed in TinyMCE it's also possible to have predefined HTML templates for snippets of markup which sounds neat. I can't think of any obvious uses right now and HannaCode is likely more powerful for this, but it does make me wonder if there's a way of combining it with HannaCode so that inserting a HannaCode could also show you what the markup would look like: https://www.tiny.cloud/docs/tinymce/6/template/ ? From what I can see it only inserts parsed HTML so without a way of wrapping it in some sort of ID/data attribute that could be problematic.

[gornycreative]

I always loved working with the Tinymce customization rather than CK, very excited to see how it has evolved!

[adrian]

This is a double full circle for me. I started using TinyMCE, then migrated my custom stuff to FCKEditor (when that's what it was called). Then when I came to PW Tiny was still the default, then it moved to CKEditor and now we're going back to Tiny :)

[dotnetic]

5 hours ago, adrian said:

FCKEditor

You made me laugh ?

[ryan]

FCKEditor actually is what CKEditor was originally called. I think it was a good marketing decision to change the name to CKEditor. ?

It will be interesting to see what editor IP.Board switches to, whether CKEditor 5, TinyMCE 6, some other editor, or if they just keep using CKEditor 4. Currently, this version of IP.Board uses the same exact CKEditor version as ProcessWire (4.19.0). 

[cb2004]

On 10/29/2022 at 2:27 PM, ryan said:

TinyMCE comes with a media plugin and toolbar. Though I've not used it and am guessing you'd have to turn off the Purifier option in order to use it (since it would insert iframes or scripts). I don't think iframes and scripts belong in richtext since it would be very difficult to discern malicious scripts from legit scripts. So I'd rather just disallow them completely (which is one thing Purifier does).

Basically, embedding social media or media players directly in markup from a richtext editor opens a lot of security concerns. On the other hand, using modules like TextformatterVideoEmbed, HannaCode, or others that let you embed service specific stuff — this is a good way to do it. It's relatively simple to convert the embed scripts/codes from nearly any social media service into a HannaCode, and even simpler if there's a dedicated module for the service you are wanting to use. So for your client, I would ask them which social media posts they are looking to embed, find out the company's recommend way of doing that, and convert it to a HannaCode, dedicated Textformatter module (one of the simplest kind of moodules to make), or even just ready.php hook after FieldtypeTextarea::formatValue.

I agree with you 100%, but when I am migrating them from said CMS to ProcessWire and they are used to doing things a certain way, sometimes I don't have the time or energy to argue with them to do it another. At least I can say OK you can post media, but here are the pros and cons.

I am going to give the module a whirl this week and put it in our base install. I am looking forward to it.

Edit: but saying that our base install uses Combo so I need to wait for support in that.

[jacmaes]

I'm about to start developing a new site, and I thought it would be a great opportunity to try out TinyMCE. I agree that it's an improvement so far, and I appreciate the new option to quickly create custom styles, but now I'm stuck with the following issues:

1. In my "Styles" dropdown, I can see the two custom styles that I've set up, "Info" and "Intro". Great, but how do I remove the "Pre" just above that I don't want my editors to use?

 

2. Related to the previous question, how would I remove the "Align" menu item below "Blocks" (I certainly don't want editors to start messing with the justification of text)?

3. In the "Inline" menu item below "Headings", how do I remove "Underline", "Strikethrough" and "Code"? See below:

4. If I replace the "Styles" tool above with the "Blocks" tool, I would expect to see my custom block styles ("Info" and "Intro") to appear here. How would I do that?

 

I've tried messing with some configurations in the module settings, but to no avail…

 

[ryan]

@jacmaes

If you want to replace the entire styles menu on your own, you can do this with the custom JSON option (whether input or file). See the included defaults.json file "style_formats" item.

But it sounds like you just want to remove a few things from the Styles dropdown. In that case, in your Module settings (or Field settings if enabled) edit the "Custom style formats CSS". The instructions there tell you how to add or remove items, but for the specific examples that you want to remove, enter this:

#Align { display:none }
#Blocks (Pre) { display: none }
#Inline (Underline) { display: none }
#Inline (Strikethrough) { display: none }
#Inline (Code) { display: none }

Note this option to remove items in this manner was added within the last week, so make sure you are running the latest version. 

Regarding the align options, I'm thinking we may just remove those since not many seem to want them, and our image plugin (pwimage) already includes the ability to assign alignment classes to images.

For the Blocks tool, I think that is unrelated to the Styles tool in terms of configuration, and I don't think that it is a replacement for the Styles tool. I have built most of our configurable settings around the Styles tool since it offers a lot more flexibility in configuration. But if you want to investigate the Blocks tool further, it can be configured with the block_formats setting specified in custom JSON (input or file). What I would probably recommend instead of the Blocks tool is  just to configure the Styles tool with exactly what you want. Keep in mind the parents (Blocks, Inline, etc.) are optional and you can add options to the root level if you prefer it, or create your own Parents within it. 

[jacmaes]

9 minutes ago, ryan said:

 

#Align { display:none }
#Blocks (Pre) { display: none }
#Inline (Underline) { display: none }
#Inline (Strikethrough) { display: none }
#Inline (Code) { display: none }

 

Wonderful, thanks! This works and is simpler than I thought. This is exactly what I was looking for. I tried the more powerful JSON route, but I got confused quickly.

10 minutes ago, ryan said:

Regarding the align options, I'm thinking we may just remove those since not many seem to want them, and our image plugin (pwimage) already includes the ability to assign alignment classes to images.

That was my thinking exactly.

12 minutes ago, ryan said:

What I would probably recommend instead of the Blocks tool is  just to configure the Styles tool with exactly what you want. Keep in mind the parents (Blocks, Inline, etc.) are optional and you can add options to the root level if you prefer it, or create your own Parents within it. 

Could you show an example of how to achieve this?

• I'm mostly interested in adding custom styles to the root level, and also maybe removing the "Blocks" and "Inline" dropdowns, which can be confusing for editors who don't know our jargon.
• I'd also like to know how to create a custom parent.

Thanks Ryan for your hard work. I'm really liking this new editor.

[ryan]

@jacmaes 

To remove all in an existing parent (i.e. Align), you can add:

#Align { display: none }

To add custom styles at the root level, omit a #Parent. So to add "Red text" at the root level, add:

span.red-text { color: red } /* Red Text */

To add your own custom parent at the root level, specify it as the #Parent for any items you want to add within it, i.e. here's how we add a parent named "Hello": 

#Hello span.blue-text { color: blue } /* Blue Text */
#Hello p.outline { padding: 20px; border: 1px dotted #ccc } /* Outline paragraph */

I prefer the single line rules, but it's also fine if you want to use multi-line rules:

#Hello p.outline { 
  /* Outline paragraph */
  padding: 20px; 
  border: 1px dotted #ccc;
} 

 

[bernhard]

Hey @ryan I just installed TinyMCE for the very first time and was a little surprised that it does not show up on frontend editing. Is it supposed to work there as well? It would really be a dealbreaker for me if not ? 

Or is that just an update coming in the future? Or is it an easy addition that you just didn't have on your radar?

Thx!

[ryan]

@bernhardI just haven't gotten to it yet, as it requires a PageFrontEdit module update rather than a TinyMCE one. I also have to update ProFields Table, Multiplier, Textareas and Combo to support TinyMCE. Once all of these are done we'll merge the TinyMCE module into the core.

[bernhard]

Thx Ryan ? Hope that all the updates go smoothly ? 

[szabesz]

On 10/29/2022 at 3:48 PM, Pete said:

I noticed in TinyMCE it's also possible to have predefined HTML templates for snippets of markup which sounds neat. I can't think of any obvious uses right now and HannaCode is likely more powerful for this, but it does make me wonder if there's a way of combining it with HannaCode so that inserting a HannaCode could also show you what the markup would look like: https://www.tiny.cloud/docs/tinymce/6/template/ ? From what I can see it only inserts parsed HTML so without a way of wrapping it in some sort of ID/data attribute that could be problematic.

Inserting some HannaCode into the editor via TinyMCE Templates could be an easy way to add HannaCode with a simple preview and some description. Maybe something as complex as HannaCodeDialog by @Robin S could be based on the TinyMCE Template plugin.

Anyway, my current issue is, that I could not make TinyMCE Templates work because InputfieldTinyMCE seems to be parsing the template options setting improperly, see my issue report for details: https://github.com/ryancramerdesign/InputfieldTinyMCE/issues/16

[Joss]

How can I customise the three Quick Toolbars?

The new line context bar has two buttons - Image and Table.

However, I don't want the table and the image button just opens up my local file system rather than the normal pwimage dialogue.

I also want to add a couple of extra buttons on there ideally like embed or heading etc.

 

[Joss]

On 12/7/2022 at 1:01 AM, Joss said:

How can I customise the three Quick Toolbars?

Okay, solved it. I put this in the JSON field:

{ "quickbars_insert_toolbar": "pwimage h2 h3 emoticons charmap" }

However, I have another problem now.

If I insert and emoticon then save the page, I lose any text AFTER the emoticon and the emoticon doesn't display.

[ryan]

@Joss Good to see you here! Lots of emoji/emoticons require 4 bytes and thus the UTF8MB4 database charset. This is something you can select at install time. You can also convert an existing DB to use it too, but I think you have to export the SQL, create a new DB and import it, replacing any "charset=utf8" with "charset=utf8mb4" in the SQL dump. This DB charset is needed whether using TinyMCE or any other kind of text field, if you want the emojis support. Though if you are already using utf8mb4, let me know, as it's always possible there's a bug I need to resolve too. Btw also check out TextformatterEmoji https://processwire.com/modules/textformatter-emoji/

[Joss]

9 minutes ago, ryan said:

@Joss Good to see you here! Lots of emoji/emoticons require 4 bytes and thus the UTF8MB4 database charset. This is something you can select at install time. You can also convert an existing DB to use it too, but I think you have to export the SQL, create a new DB and import it, replacing any "charset=utf8" with "charset=utf8mb4" in the SQL dump. This DB charset is needed whether using TinyMCE or any other kind of text field, if you want the emojis support. Though if you are already using utf8mb4, let me know, as it's always possible there's a bug I need to resolve too. Btw also check out TextformatterEmoji https://processwire.com/modules/textformatter-emoji/

Hi Ryan! Good to see you too.

This is on my local machine using Laragon running MySQL 8.

I ran the query:

SELECT * FROM information_schema.SCHEMATA S WHERE schema_name = "aelwenjones";

And it returned:

CATALOG_NAME		def
SCHEMA_NAME			aelwenjones
DEFAULT_CHARACTER_SET_NAME	utf8mb4
DEFAULT_COLLATION_NAME	utf8mb4_general_ci

But if on phpMyAdmin I select one table and click on show create I get:

CREATE TABLE `field_article_text` (
 `pages_id` int unsigned NOT NULL,
 `data` mediumtext NOT NULL,
 PRIMARY KEY (`pages_id`),
 KEY `data_exact` (`data`(250)),
 FULLTEXT KEY `data` (`data`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb3

 

I notice on my host, however, that most of my schemas are latin1, so I need to make sure they aren't, as it were, for this table.

[ryan]

@Joss The utf8mb3 listed on your field_article_text table is the same thing as utf8 I think (utf8 is 3 bytes), so that won't support emojis. Check in your /site/config.php file and look for $config->dbCharset and change it to this:

$config->dbCharset = 'utf8mb4';

Then try creating a new Textarea field that uses TinyMCE. It should now use that utf8mb4 charset, and emojis should work.

If you want to convert your existing field_article_text field, you'll want to export the table and all its data (with phpmyadmin), then edit the resulting SQL file/dump, change the "CHARSET=utf8mb3" to "CHARSET=utf8mb4". Then import to replace the old table. If you get an error, change the KEY length "250" for that data_exact key in the CREATE TABLE statement to "191".