I thought there was some discussion of not giving the user too many options, otherwise they would end up making a mess of the style consistency provided by the theme. I believe images of Christmas trees and candy stores were invoked. 
That’s why I like the idea of using filters. You need a certain level of knowledge to implement them and (hopefully) you have an understanding of the implications.
Do we have any numbers for how much weight this will add to CP?
I am definitely in favor of providing the full Tiny experience, and then allowing users to disable (or maybe just hide) things they don’t want or won’t use. Otherwise we’ll be guessing what we should keep and what we leave out.
If we can get this to work with all the current WP/CP filters, those who want to could still disable it altogether, of course.
Does anyone know (or care to look it up) whether the Tiny plugins have translations for user facing text?
I thought I’d add the searchreplace plugin as default, but then I thought about languages, so I need to know how to proceed or if this makes a difference.
Is this what you’re looking for?
Is this helpful?
As a last course, we could do even the translation in PHP and localize the translated value to the script.
I don’t think very many of the plugins have text to translate, but it would be nice to know how that is handled for those that do. Then I can copy that for searchreplace or others.
I’m wondering if this might be it…
The wplink plugin is translated here:
The console shows two objects for wplink – one has a bunch of functions and the other has the translated texts.
So they pulled the strings from the Tiny plugin and translate in PHP, then load those in JS.
I saw some code in the compat3x plugin that was for translation, but I didn’t follow the trail of it.
I’m thinking we should be fine to use this same method.
As a followup, I want to mention that there is existing code to translate all the core Tiny plugins, even the ones that are not loaded by default.
See _WP_Editors::get_translation() | Method | ClassicPress Documentation for details. That is one less thing that CP plugins have to do (unless they want to change some of those texts).
I have deleted the plugins that don’t make sense to have (where CP is already handling that):
code, fullpage, help, imagetools, pagebreak, preview, save, autosave, wordcount.
I also deleted spellchecker since it was deprecated in TinyMCE 5.4, legacyoutput since we don’t want old, and colorpicker, textcolor were incorporated into Tiny itself.
The core-editor chat in WP Slack had a request for review of a PR for a Table of Contents block, so it reminded me of the Tiny plugin. The remark that caught my eye was about handling page breaks. I had not thought of that. I haven’t looked at the code for the Tiny toc plugin, but I wonder if it does work with the Tiny pagebreak plugin. And I wonder if the pagebreak plugin (which I deleted) is doing the same thing as CP does (in the wordpress plugin) for the nextpage quicktag.
Still to be decided:
Advanced List (can conflict with themes, might impact code I saw in wordpress plugin)
Anchor
Autolink
BBCode (isn’t this dead yet?)
Code Sample (CP doesn’t affect front end, so this should be plugin)
Emoticons (can we remove smileys?)
Import CSS
Insert Date/Time (too lazy to type a date?)
Nonbreaking Space
Noneditable (non-useful)
Print (would this conflict with the browser’s Print?)
Quick Toolbars (could conflict with existing handling of links, images)
Search and Replace
Table (code is 3 times the size of next largest plugin, 10x most)
Template (security concerns - can specify URL)
Text Pattern (CP has subset, this is generic pattern making)
Table of Contents (seems suited to CP plugin for options, styling)
Visual Blocks
Visual Characters
You can look at the Commands page in the Tiny docs. The menu there has each plugin listed.
For the Import CSS plugin, there is very little code and it could work for theme CSS. I put something like this in my theme. The drawback is that the content gets tied to the theme’s classes. If we established some standard classes that are useful, then switching themes wouldn’t matter (to this). The trick is whether the theme or CP loads the CSS on the front end.
I saw today that the WP folks have been working on a Table of Contents block. (in case that might influence any decision on adding that plugin)
Also, I read in the Tiny release notes that bbcode was deprecated, so I will be deleting it.
Another thing I saw at WP today was a discussion of a security issue in wp_check_filetype() and mention of how this happened with emojis in 4.1.2. There’s a video about it at Curing a Critical Security Bug – Gary Pendergast
I’m bringing it here to raise awareness about hacks that can be in SVG files, media files, and even emojis. This should be kept in mind when deciding on what to add to the editor (and the burden of maintenance of what is added).
I found a page listing changes coming in TinyMCE 6.0.
One of the things is
TinyMCE 5.10 will include the final release of the Table of Contents (
toc) as an open source plugin. The Table of Contents plugin will be removed from the open source bundle and be available as a premium plugin for TinyMCE 6.0.
So I think I will remove the toc plugin from this list of possibilities. The version I am working with is 5.9.2. (Edit: 5.10 came out today, so I’ll update to that.)
With no more input, I’m going to make a command decision and say that these plugins that don’t have any downsides could be added, if there is room. The directionality plugin went from one button on RTL sites to two buttons on all sites, so that takes up more space. Some don’t have to be buttons, but could be keyboard shortcuts.
Anchor(button), Search/Replace(button), Visual Blocks(shortcut)
The rest either need custom code (more maintenance for core) or are tangential to the main focus of the editor.
Let me know if I’ve missed something, and whether the Anchor and Visual Blocks are worth adding.
This makes sense. It’s your decision what to put in the plugin but here is my opinion.
Search/replace seems like a definite win. Possible downsides of the others:
This is for setting the id= attributes to allow jumping directly to a part of the page. Do the anchors created this way show up in the Link dialog? Is there a use case for this other than manually creating a table of contents?
Personally I would not include this, in favor of users who want it installing a plugin that does it more automatically, like we did on the docs site: code | example
This doesn’t sound great. What’s the use case for it? Sounds like something that should be more automatic as well.
99% (or more) of ClassicPress sites will be in a LTR language. Of the remaining 1% (or less) of sites, I would expect most of them to be exclusively or mostly RTL text. Doesn’t seem worth it to add a button (or two) for such a small percentage.
Is this similar to wpviews? Sounds like it would be complicated to integrate with the rest of the system.
Thanks for answering!
Yes, the anchor plugin is for adding id attributes, which can easily be done by switching to text mode, of course. But it makes it easy. It also shows the icon in the visual mode so you know where they are and you can drag the icon to move the target. I don’t think a table of contents is the only use case. I think linking directly to information from other pages is very useful. It could be that more people would use it if it was easy to do. There might be an argument that it would be better to add ids to all headings, but some people write without using headings.
I didn’t think the toc plugin was appropriate since it needs styles (and manual update when you change a heading), but it was deprecated so they can make it premium only in 6.0.
The directionality plugin puts dir="ltr" or dir="rtl" in the selected element. It is for showing only some text in the opposite direction of the site, so it can’t be automatic. I have seen WP forum questions about how to do this. In 4.x, it was truly a toggle button, so the LTR button was shown only on RTL sites. That seemed a bit odd to me, since a majority of sites are in LTR; couldn’t they have an easy way to show RTL in a paragraph? The 5.x buttons, are not toggles. They simply put the attribute in, so you need both buttons if you use any at all (although the opposite button removes the attribute if necessary).
If this isn’t needed, I can remove it, but as is, 5.x directionality is two buttons. I would say that RTL sites need the buttons more, since code, emails, and URLs are always LTR but those aren’t always identified in a way that they can be styled correctly and themes often don’t know to style them that way.
For visualblocks plugin, it is simply an editor feature that shows dashed outlines around the HTML blocks so you can see the structure. I thought it might help with moving them around as blocks, but it doesn’t. I don’t know if it’s useful for anyone.
(wpview plugin is for showing the context toolbar for galleries)
Ok, well I think people have generally been in favor of including more features at least as available options to enable. I say go for it for the plugins you think make sense to include 
I was thinking that instead of adding buttons, I could make sure everything is in the menu. Then there could be a toggle for the menu, like 4.x has a toggle for the second row of buttons. (I might have to go back to that toggle button because the full height calculations don’t get the toolbar height correct.)
But I haven’t seen a way to turn on the menu except for in the initial configuration. Surely there would be a way to do it dynamically.
