InputfieldTinyMCE should be in /site/modules/

[Nico Knoll]

Hi,

currently TinyMCE is kind of standard implemented into PW. But I think that's no good practice because of the following points:

• (Almost) all of the Inputfields in /wire/modules/Inputfield/ are kind of "natural" html types. Like checkboxes or textareas. But TinyMCE is not.
   
• The size of the whole processwire folder is ca. 5mb and TinyMCE alone is 2.6mb. So TinyMCE is more then the half of the WHOLE system. And if I want to use ProcessWire only as CMF not as CMS I don't need it.
   
• TinyMCE is just one editor. The ACE module is another one but it's not installed by default. So in my opinion it's like IE on Windows (but of course PW is much nicer then Windows!). It's installed by default...

How I would solve this:

The easiest thing would be to move TinyMCE into the /site/modules/ folder. It would work from there as it is working currently. But you would have a stronger line between "naturally" implemented Fields and modules and additional modules (like TinyMCE should be!).

And it would be easier to delete it if you don't need it because you don't have to "touch" the real system folders and files.

Greets,

Nico

[Adam Kiss]

I support this, +1

Additionally, I think ACE Editor should be shipped with PW and used as default edit…

[Soma]

I discussed and almost went for it, but abandoned it. It's possible already to put it outside into your site folder, but then you'll have to maintain it. I also thought this same thing as you but somehow I'm still not sure it's the way to go. SInce it will be shipped anyway I don't get the argument of size.

I ran this setup with 3-4 projects in the past to be able to change some code that will help include custom plugins from within /site/ folder. Since this is now in the core Tinymce, there's no need anymore.

Also since there will be some changes soon Ryan said in the future we want to support other editors, I think this would have to be considered by then.

[ryan]

I think it's a good approach going forward to keep big modules like this out of the core. But doing it now with TinyMCE could create some real upgrade challenges for folks. The TinyMCE module is also a bit of a different animal in that it has a couple of supporting modules in the core as well: ProcessPageEditImageSelect and ProcessPageEditLink. At present, all the site profiles we distribute also use TinyMCE. I think by the time we hit PW 3.0, we'll be at a point where we can look at excluding it. Ideally PW of the future comes with nothing but the absolutely essential core modules, and I think it'll be possible in the future (especially with modules manager as a core module). But right now ease of setup and upgrades takes major precedence over file sizes, as we are still an largely unknown CMS trying to grow our audience.

[Joss]

Yes, I would like to see it as a separate beast in the long term.

Which ever system people use, however, there will always be a need to get to the image and links systems. Is there a way of separating these out a little? I was thinking like:

Editor Module (eg, TinyMCE) <-> Compatibility hook <-> Image System

That means the image or links system is clear of any direct involvement with any editor and can be improved or modified over time, and a simple hooking system then just joins the two together.

Anyone adding future alternative editors then only need to create the hook script as part of their module, rather than a dedicated system.

Just a thought

[Pete]

Without knowing much about the code I'm going to say that it should be possible to abstract it out at some point in the future to make it easier to drop other editors in with their own links into those parts of the core but I can see why ryan would want to leave it til later.

It brings up tricky questions like if it's removed from the /wire/modules/ dir, how do you get the new distribution of /site/modules/TinyMCE to people upon upgrade? Since it wouldn't be packaged with the new version it would have to be done automatically by the then-integrated ModulesManager I think, causing someone yet more fun coding headaches

But yes, I'm going to go out on a limb and bring out that line I like to use: "Everything is possible in ProcessWire".

[ryan]

Which ever system people use, however, there will always be a need to get to the image and links systems. Is there a way of separating these out a little? I was thinking like:

They are available for use by other modules. They actually don't have a TinyMCE dependency. The modules don't know they are being used by TinyMCE. They just have a "some/any editor" dependency. You can use them by themselves if you want, but they aren't that useful, as it's the modal dialog buttons (that we coded from the TinyMCE plugin side) that pull the contents of the fields these modules populate, and use them in TinyMCE. I haven't yet used them with any other editors, but have always planned to. If we were to make a CKEditor module for example, we'd use the same two modules to handle images/links. 

[Joss]

Oh, goody!

Much easier (I suspect) than trying for CKE is to try with one of the simpler JQuery editors out there. I imagine that for general use they will be much more useful for people than either TinyMCE or CKE,

[Pete]

Hehe, shows how much I know - it's already set up that way then

[Martijn Geerts]

If we accept that IE8 and below no longer can access the admin then the way is free for smaller/better editors.

Till that time I think we should stick with TinyMCE. ( damn well configured in processwire )

Rather see those modals updated with a "retina checkbox" & the ability to save a preset for those settings.

If the preset is set, the editor is not able to set the width from within the modal. Or disable the retina setting & alignment.

[Joss]

Martijn, that is a good point - but I was sort of thinking of this as optional modules where you have a bit of control what browser your end user is using! (Even if it means stealing their laptop and installing it yourself...)