Feature Proposal: Directory re-structure to separate upstream files AND make it easy to enable/develop TMCE plugins

Motivation

• TinyMCE 3.2.7 was released with two new plugins relative to 3.2.2: autoresize and wordcount. As the number of "standard" plugins grow, it should be made much easier than it is now for users (and admins) to select optional (default: off) TMCE plugins they want.
• Additionally, we need better infrastructure for Foswiki-specific plugins like TinyMCEUsabilityUpgradePlugin to enable themselves (without having to modify TinyMCEPlugin.pm, or plant files in its /pub dir).
• We ship with a minimum toolbar that should work for most users. However, it's too intimidating for users customise their toolbar - for example, paste plugin offers three different buttons that you can add (paste plain, from word, select all).

Taking plugin initialisation and toolbar definition outside of the TINYMCEPLUGIN_INIT variable would have the nice effect that it should lead to fewer wikis defining their own such variables (undesirable because these wikis may then miss out on important _INIT changes between upgrades).

Description and Documentation

Solution: Skins & Templates

Justification

• It should be easy for users (and site admins without configure access) to customise their own experience, without depending on the foswiki guru who does the installation.
• When you ask for a plugin to be enabled, we need to know where its files live (among other things), now that we will be moving foswiki TMCE plugins outside of the /pub/System/TinyMCEPlugin directory.

The end result should be that the user (or admin) are able to activate TMCE plugins via SKIN and COVER settings (thanks to SvenDowideit for this suggestion on irc).

There would exist a .tmpl for each TMCE plugin that would make appropriate %ADDTOHEAD% calls to load the TMCE plugin JS and populate the foswiki object via proper <meta/> tags so that foswiki_tiny.js will know to initialize them.

Examples

Eg:

• Set SKIN = tmce_foswikilinks, tmce_mozbulletsfix, mysiteskin, pattern

or

• Set COVER = tmce_foswikilinks, tmce_mozbulletsfix

Solution: Variables

Justification

• Offering skin templates/covers are a slightly strange way of doing things. And working with templates is never fun.
• Setting a variable is easy.

However, a simple comma separated list of plugins isn't enough. TinyMCEPlugin would have to offer a perl api that would register the plugin names the user may wish to select in their lists.

Examples

• Site default plugins, I imagine these would be set in SitePreferences. TinyMCEPlugin should set TINYMCEPLUGINS_DEFAULT so that it can be rendered in TinyMCEPlugin system topic as a default list for admins to work from.
  • Set TMCEPLUGINS = paste,safari,spellchecker...
• User (or web, topic...) plugins which are added to TMCEPLUGINS list
  • Set TMCEEXTRAPLUGINS = foswikilinks, pasteplain
• User (or web, topic...) may want to ensure a plugin listed in TMCEPLUGINS is disabled. This could accomplish that:
  • Set TMCEDISABLEPLUGINS = spellchecker

Some plugins require additional parameters beyond just enabling it.

TinyMCEPlugin would have to provide an API in perl for tags to be registered of the form

• Set TMCEPLUGIN_SPELLCHECKER_MODE = googlespell

Solution: Template Topic & JQREQUIRE style tag

Justification

Too many vars gets unwieldy.

Examples

• Set TMCEPLUGINTEMPLATE = TinyMCEPluginTemplate

it would have %TMPL:DEF{"tinymce"}% with a bunch of %TMCEPLUGIN% tags, Eg:

%TMCEPLUGIN{addPlugin="safari"}% %TMCEPLUGIN{addToToolbar1="pasteplain"}%

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

Have yet to properly flesh out the appropriate .tmpl schema.

Question for discussion: Should these tmce_ templates cover for edit only? Or view as well? I suspect nobody wants the latter case (custom TMCE usage should have its own plugin selection arrangements).

-- Contributors: PaulHarvey - 18 Oct 2009

Discussion

+1 to the idea of a more modular TinyMCEPlugin.

-- MichaelTempest - 19 Oct 2009

Tasks.Item1419 means we should also consider easier toolbar customisation as well.

-- PaulHarvey - 21 Oct 2009

Added Tasks.Item2297

-- PaulHarvey - 27 Oct 2009

This is overlapping (entirely?) with EditorAPI. Continuing this work there.

-- PaulHarvey - 30 Dec 2009