I feel like this plugin (once it’s well tested) would be a good candidate for actually being bundled with ClassicPress as it extends TinyMCE which is what CP will continue to use as stated.
I don’t think it needs to be integrated into core as such. Gutenberg in WP arguably should have been kept up a plugin - so I’m sure with ClassicPress a better practice would be preferred. However I think there is merit in bundling this plugin with core package download (eg. as Hello Dolly/Akismet were.) Is there a list of plugins under consideration for this?
Obviously with most plugin (feature) areas there are many good existing plugin options and showing this kind of preference would not be desirable (cough GB again.) However, something like this that is well tested, maintained and highly inline with the intention for CP could be. I’m not sure I can think of any other plugins right now that would be suitable in this way. The criteria for inclusion would have to be very strict to avoid any kind of bloat, but it maybe worth coming up with that in case other suitable candidates for this come up in the future.
I like the idea of bundling it with core, maybe a petition would be a good next step: https://petitions.classicpress.net/
I have installed the plugin on all the sites I manage - so I guess I am a bit biased.
It’s a really popular plugin. It was my hope that it would help gain new users to my other plugins… this wouldn’t be likely if it was bundled in core, so, that’s where I’m coming from…also biased.
That makes sense from your point of view, so fair enough! It will still be one of the first plugins I install
I’m a fan of the WYSIWYG Advanced plugin, but I wouldn’t like to see it made part of core. I’d love to see CP get as lean as possible, with a wide array of core plugins and special purpose plugins available for installations that need or want them.
I wasn’t suggesting part of core, I was more suggesting it would be a plugin that is bundled with core. But I understand @Code_Potent’s point that it wouldn’t drive him any traffic to his other plugins that way
I think I misunderstood what you meant by bundled. It’s a gateway plugin, for sure.
The basic editor is fine as a default. If people want more features they can choose to install an advanced editor.
The WYSIWYG Advanced plugin is a renamed TinyMCE Advanced 4.8.x, so, it’s already pretty battle-tested. It would be cool if it was integrated into core in that I would have one less thing to think about, but, as @azurecurve mentioned, the default editor is already a suitable default. At this point, I’m still calling the plugin a beta because if you download it from GitHub it appends
-master to the directory name. This is going to be corrected by creating a release version soon.
Started a new petition for this here:
In general, what’s the thinking behind bundling something with core?
Is it that we are assuming it’s likely to be required by the majority of users and will save a minute or two in installation time? How much of a majority? How do we even know what the number is? Because the people who don’t want it will just have to uninstall it, which is more steps for them.
I’ve always found having to uninstall Akismet and Hello Dolly with every WP install to be slightly annoying.
Well my thinking firstly is bundling would only be for so something universally used and in line with the project goals (eg. Editor) that it would truly make sense. Obviously to avoid package bloat the criteria would have to be super-strict like this (who knows perhaps there won’t be anything else that would ever meet it.)
Which is why Hello Dolly/Akismet are great examples of what not to bundle, I mean, they wouldn’t even make it to a list of must-have kind of plugin… but even for must-have plugins there are many existing options. (Sure there are other editors out there too, but they diverge from the basic editor compatibility significantly.)
I can see definite advantages for bundling this:
- to bring awareness to the availability of Advanced Editor options while still allowing them to be truly optional. This kind of exposure helps a “feature” plugin like this evolve due to more attention and contribution
- to have a place in the project (plugin) where the Editor could be further improved without it having to affect the stability of the basic editor
- along similar lines, adds the possibility of merging other editor features (such as a frontend editor, improved autodrafts) in the future
- to demonstrate this is a better workable approach for an improved editor experience (contrasting to Gutenberg inclusion in WP core)
All good points majick. Thanks for the detailed reply.
I especially like the last one… to show how it should be done.
I guess I’m fundamentally against including anything with the core as I’d like it to be as light and clean as possible. But an advanced editor would possibly be one case where I’d make an exception. As you say, it may turn out to be the only one that is warranted.
bundling would only be for so something universally used and in line with the project goals (eg. Editor) that it would truly make sense. Obviously to avoid package bloat the criteria would have to be super-strict…
Virtually every site has a contact form, an about us page, and an FAQ page, but, like an advanced editor, they don’t belong in core. The criteria is already strict – streamline the thing, don’t add bloat – which is why an exception would have to be made to get an advanced version of existing functionality added. Additionally, I think giving every average joe user an advanced HTML editor is not a good idea – this advanced functionality should be installed on a case-by-case basis.
@Code_Potent If it were bundled with core, would that mean the plugin would be managed differently? I’d think it would just get it more attention and improvements, and there could be more devs brought on board so you wouldn’t have to do all the support and improvements yourself.
I’m just not in favor of bundling advanced functionality where there is already completely suitable functionality in place. It would also set a bad precedent. For example, ClassicPress takes basic security measures…why not bundle an actual security plugin? Another example, end users can create an FAQ page with basic markup…why not include an FAQ plugin? My point is simply that plugins shouldn’t be bundled, no matter how useful they might seem.
Improvements are only of use if you are actually using the plugin in the first place. It’s something I might install on one or two sites, but mostly I just don’t need it, and if it came bundled in with core the first thing I’d do is delete it.
I definitely don’t want to be known as the developer behind a Hello Dolly…