Should TinyMCE 4 be a module?

[Joss]

Just been looking at TinyMCE 4, which now offers inline editing and other goodies (probably)

I am wondering if TinyMCE should now move to be a module rather than in the core to make updating and customising easier?

I am sure this has been discussed somewhere before, but can't remember where.

Joss

[teppo]

I seem to vaguely remember someone saying something about decoupling TinyMCE from core at some point. (Emphasis on "vaguely"..)

Personally I wouldn't mind TinyMCE not being included with core, especially since I haven't really used it since CKEditor module came out, but I'm wondering if not having "built-in" RTE in ProcessWire might give bad impression to some folks just getting used to PW -- even if it's available as a module?

I'm probably just overthinking this, though.

[Joss]

Well, just because it is not in the core does not mean it cannot be in the modules folder by default, ready to install or uninstall as wished. 

I have to say, in the last two projects I used CKEditor - but I have found it harder to get extra things working on it - TinyMCE seemed easier, somehow.

I rather like the new look of 4 as well.

[teppo]

Joss: I think I was being a bit too vague there

Did you mean that it would actually be in default site profile's modules directory or still bundled with core modules, only not "permanent", or something else? I'm not sure if this would really be beneficial compared to current situation -- seems to me that the biggest issue with having TinyMCE and/or CKEditor built-in is that they're actually pretty damn big (TinyMCE 4.3M, CKEditor whopping 14M).

[Joss]

I think it should be in the site/module directory - not sure whether it should be installed or not.

That way, it can be uninstalled and chucked in the bin, or (more to the point) it can be updated and customised directly without touching the wire directory.

There is an argument, really, that if you want a wysiwyg you just download it, and I think with a blank profile of any sort, that should probably be the case. 

So, maybe the demo profile has it in the module directly and installed, and the blank profile does not have it at all.

[Manfred62]

....

I am wondering if TinyMCE should now move to be a module rather than in the core to make updating and customising easier?

I am sure this has been discussed somewhere before, but can't remember where.

maybe you have seen it here...?

[Joss]

Oh, I was thinking about a conversation around a year ago. My elephantine memory is getting a bit closer to the mammoth .... wooly!

[Pete]

I was wondering if this could be part of the installer - an additional step to tick some additional, oft-used modules and choose an RTE?

It's not making an assumption about how you're going to work that way, but some thought would need to go into the list of immediately useful modules (I generally always go with PageLinkAbstractor, Thumbnails and CKEditor nowadays before I do anything else). It wouldn't need to be an exhaustive list as there could be a sentence at the bottom saying there's more when you login.

I think this goes along with another idea I had a while back about part of the install process involving asking what profile you'd like to install and it then going off and downloading that, but that depends on server capabilities - though I'm not sure I've heard of anyone having issues with the way modules can be downloaded in the admin lately?

[Martijn Geerts]

Sorry to go offtopic but, I'm thinking loudly here. Should there be a way for $modules to set a minimum browser requirement , that can be picked up bij ProcessWire ?

public static function getModuleInfo() {
	return array(
		'title' => 'Module Title',
		'summary' => 'Great Module',
		'version' => 100,
		'compatibility' => 'IE8' // minimum IE8
	);
}

( I think compatibility problems has almost al the time to do with the browsers from our friends in Redmond, so this could be tight to IE).

Especially for wysiwyg editors, the weight of the source code can drop dramatically when they can use native browser features not available in versions of Explorer.

[Joss]

@ Martijn - The biggest trouble I have had with wysiwyg editors over the years has been with Chrome, interestingly enough. 

@ Pete - I thought about this when I wrote the original post, but was not sure whether it got in the way of installing. Since installation has occasionally thrown errors for people, I think it is sometimes easier to keep it as simple as possible.

(this from the person who once suggested you could pick a profile as part of installation)

So, it might be better to offer it as a post installation stage:

"ProcessWire is not fully installed and ready to go. However, you may wish to just quickly install one or more of these modules voted as some of the must haves by our community - or you can install them later."

Then have a list of a few, including RTEs.

I don't think there is a best way through this really though - very subjective.

[Martijn Geerts]

I'm not using WYSIWYG long enough I think. Only the 2,5 year i'm working as web developer. When I first started with a CMS and WYSIWYG, MODX Revolution was already released. So only used the one in MODX Revo, and those in ProcessWire.

Thank you to bring "install with profile" back to life.

[teppo]

@Joss: I guess it boils down to what most users need. RTE (or WYSIWYG, though the term itself is bullshit) has, in one way or other, been a part of each site I've built within last ten years (those that have included any kind of CMS capabilities at least). I'm sure that's not true for everyone, but if that's the case for most users then I think we should definitely have one built-in.

@Martijn: I'm afraid that this would only be helpful for couple of modules. These days there's also a lot of speech about ditching browser sniffing in favor of checking specific capabilities (though I don't fully agree with that -- it sure helps when you're checking for features, such as geolocation support, but not actual bugs).

@Pete: downloader would be awesome, but that wouldn't help us who prefer to clone latest version directly from GitHub. In any case I really think that such a tool would be nice addition. CKEditor site has pretty sweet implementation of this already: http://ckeditor.com/download 

[Joss]

Morning Teppo

If it were a module (as in the site directory rather than in wire) it could still be part of the normal distribution. But it does give the opportunity to hack at it more easily without going near Wire, which for me is something I avoid completely.

[teppo]

Morning Joss!

That makes sense, though from my point of view there's also some very real value in having built-in, always up-to-date RTE coupled with PW.

Again I'd like to stress that decision like whether or not something is a part of core should depend on what's best for most users. If a module is something that all (or almost all) users need and/or use, I really think it should be included with core package unless there's very solid reasoning against that.

Having it as a part of default site profile is almost as good, only real difference being that users would have to keep it up-to-date manually. But then again, if the real issue is that it's not configurable enough, wouldn't it be better to focus on improving it's configuration settings instead..?

[Joss]

Dont you have to keep it up-to-date manually anyway? It is only updated if PW is updated, and then your site is only updated if you update PW.

Using Soma's wonderful Module Manager you would be able to update anyway to whatever is the latest version of the module, or you would be able to manually update it if you are a bit ahead of the curve by downloading from the TinyMCE (or whatever) site. Also, this means that is can be independently updated without having to update the entire Wire directory.

[teppo]

What I meant by that was that the RTE module wouldn't have to be updated separately of PW itself. Updating PW is usually just about as much work as updating each individual module (not to mention that it's the one thing even I tend to keep always up to date, as it's super rare for core updates to break anything.)

You're of course right in that modules manager would make things easier. If it was a core feature this "easy update" argument would be almost entirely invalid.. or, to be honest, almost everything I've mentioned here so far in favor of bundling an RTE 

This is a bit off-topic, but I'd actually prefer PW to have more modules manager features built-in. Obvious downside is that especially newcomers may have hard time evaluating whether particular module is of high enough quality for their needs. Generally the quality of PW modules is very good, but there are exceptions to this rule too.

Perhaps we need new "Ryan seal of approval" badge that could be granted for modules that fulfill certain criteria and only those could be auto-installed?

[pwired]

Perhaps we need new "Ryan seal of approval" badge that could be granted for modules that fulfill certain criteria and only those could be auto-installed?

I definitely agree on that one to keep good quality of modules.

 Personally I wouldn't mind TinyMCE not being included with core,

For pw beginners and clients there has to be an editor out of the box. I think tinymce as it is included now

is a good choice for pw beginners and clients.

I don't like the idea of extending the core just to have ckeditor, inline editing or whatever extra wysiwg.

The power of pw is it's low level abstraction architecture (api) and therefore anyone can do whatever you want with pw. If somebody needs another editor or inline editing or whatever it should be done either through the api or as a module.

[Soma]

This thread title is wrong. TinyMCE IS a module like almost anything in PW. *Hides behind stone*

[Joss]

Yeah, I know that! Just need it to be a module in another hole!

And you ear are sticking out from behind that stone....

[ryan]

I love the idea of getting TinyMCE out of the core and as a module that's installed separately. But the reality is that the marketing folks wouldn't let us do it. They love to be able to say "includes rich text editing!". Lots of people look for this in the features list when evaluating a product and don't bother proceeding if it doesn't include a rich text editor. When people are evaluating products, they don't necessarily know about the module ecosystem and how easily things can be added. Just recently I read someone slamming Drupal because it didn't come with a rich text editor. Obviously that's a silly statement, but perceptions like this matter in growing a product. 

The other side of it is that providing a really good rich text editing experience means integrating the editor into the system more tightly than most other modules. For instance, our rich text editors (TinyMCE and CKEditor) are integrated into the image and link selection modules. Making sure this all stays working smoothly dictates that it's best kept in the core and upgraded with the core. By this token, I'd like to have CKEditor integrated into the core too, but bundling two rich text editors is probably just too much. 

As for upgrading to TinyMCE 4, I'd like to do this soon. I had tried to already in the past, and ran into all sorts of issues (they have changed a lot, but it was in beta when I tried it), but this will happen sooner or later. Because of the significant differences, we may have to produce TinyMCE4 as a separate module... or rather keep TinyMCE3 active as a separate non-core module, if we replace the core with TinyMCE 4. That's because the two aren't totally compatible with each other, and anyone that's doing anything complex with their MCE installation may be dependent upon version 3 already. Because switching to TinyMCE 4 is nearly a different rich text editor, we may consider replacing it with CKEditor for our core rich text editor, given that this module is already pretty much in a stable state. Whether the core includes TinyMCE 4 or CKEditor 4, people will have to reconfigure their editors after the upgrade either way. I hate creating upgrade hassles for people, so maybe the best thing to do is just keep TinyMCE 3 where it is in the core and develop other rich text solutions separately. I don't really know, just a whole lot of factors and compromises no matter which direction we go.

[Joss]

Hehe!

Actually, as a marketing person, if it is in the modules directory as part of the standard download, then it still qualifies as coming with the product. 

And this does give the opportunity of offering different profiles with different RTEs or, as has been mentioned on other stuff, choosing which you would like as part of the installation.

One of the benefits of having TinyMCE as part of the core is that it is all ready to go.

The big downside is that it can put off people who prefer something else. So there are marketing negatives too.

With my marketing hat on, being able to say "And you can choose from a range of the most popular RTEs or decide not to have any" is a much stronger marketing position.

Car dealers have had the same problems with Sat Nav. In the UK there are two main makes, Tom Tom and Garmin. Car dealers have learned that if they wed them selves to just one "We will throw in a tom tom free" it puts off all the people who hate Tom Tom and want a Garmin - they go buy the car somewhere else.

Customers are wonderfully fickle!

[teppo]

I'd like to point out (again) something I mentioned earlier:

Did you mean that it would actually be in default site profile's modules directory or still bundled with core modules, only not "permanent", or something else?

Removing "permanent" status from TinyMCE would take us past at least some of the issues mentioned in this thread; that way anyone could simply uninstall it and then install another RTE or none at all, whatever they prefer.

Bundling it with site profile instead of core is, again, almost as good -- though personally I dislike the idea that pretty much every site profile out there would need to include an RTE after that. Sure, they could choose one of their own instead of what default site profile uses, but still

@ryan: sounds like it would make most sense to combine the switch to TinyMCE 4 / CKEditor with release of either 2.4 or 2.5 (depending on your timeline here), especially if there's a possibility that existing fields don't work as expected after upgrade?

Regarding differences between TinyMCE 3 and 4, they do provide "compat3x" plugin to make transition less painful. Might be worth checking out if issues mentioned above were somehow related to plugins.

[Manfred62]

because of marketing etc.: MODX also hasn't preinstalled any RTE. It's up to the developer to choose and install a RTE.

I like this idea (RTE as separate modules), but of course it's Ryan's decision. He knows what's possible without breaking something.

[ryan]

Removing "permanent" status from TinyMCE would take us past at least some of the issues mentioned in this thread; that way anyone could simply uninstall it and then install another RTE or none at all, whatever they prefer.

 

Good idea about removing the permanent status–I will do that. 

Bundling it with site profile instead of core is, again, almost as good -- though personally I dislike the idea that pretty much every site profile out there would need to include an RTE after that. Sure, they could choose one of their own instead of what default site profile uses, but still 

I think it's best to leave the RTE in the core due to the fact that it's tightly integrated with other core components (ProcessPageEditImageSelect, ProcessPageLinkEdit). Updates to those modules and TinyMCE usually go together. Though the ImageSelect and LinkEdit modules can be used by other editors too (CKEditor), but whatever RTE is bundled in the core is what sets the core integration available to all RTEs.

@ryan: sounds like it would make most sense to combine the switch to TinyMCE 4 / CKEditor with release of either 2.4 or 2.5 (depending on your timeline here), especially if there's a possibility that existing fields don't work as expected after upgrade?

Or perhaps better to tie it to a more major version (3.0) when there will be more understanding of an upgrade involving more than a /wire/ directory replacement. I'm thinking 3.0 is also the version where we move everything to namespaces as well. If we go this route, I'm not sure how many more 2.x versions there will be after 2.4, as we may start working towards 3.0 sooner rather than later. But if we make that switch in 3.0, I think we've got to keep TinyMCE 3 as an available module for install, even if not in the core, for legacy use. Many (most?) people don't care about the differences between TinyMCE 3 and 4 like we might, so they might prefer just to keep using what they've already configured even after the rest of ProcessWire is upgraded.

Regarding differences between TinyMCE 3 and 4, they do provide "compat3x" plugin to make transition less painful.

Thanks, I will check that out. I'm not sure that I was available when I last played around with TinyMCE 4. 

because of marketing etc.: MODX also hasn't preinstalled any RTE. It's up to the developer to choose and install a RTE.

Good, because that adds another point in our favor for people that want a CMS that already includes an RTE (even if that doesn't mean anything outside of marketing).

I like this idea (RTE as separate modules)

I also like the idea of just including both in the core (TinyMCE and CKEditor). But considering these RTEs represent the largest use of disk space in the CMS, I'm guessing others wouldn't agree with that strategy. Personally, I don't care about the disk space issue, as disk space is essentially free these days. But bundling two big RTEs might be considered bloat by some, so I'm shy about doing that.  

[Joss]

Bundling it with site profile instead of core is, again, almost as good -- though personally I dislike the idea that pretty much every site profile out there would need to include an RTE after that. Sure, they could choose one of their own instead of what default site profile uses, but still 

Not if it also available as a module - the they can either chose to include it in their profile or not since users can always choose one from the module catalog

I think the point from my perspective is that if the philosophy is to not touch the core (which is a good one as far as I can see) then any functionality that people might want to tamper with should be in the site directory.

Now obviously, you can always override stuff (and if it is not permanent, then it can be uninstalled), but having it available as a module in the same way as CKeditor is just makes it more obvious that you can play without messing things up. 

And of course, this also allows for updates that do not rely on updating the core, but just the module available through the module manager.