Feature Proposal: Directory re-structure to separate upstream files AND make it easy to enable/develop TMCE plugins
- 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
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
changes between upgrades).
Description and Documentation
Solution: Skins & Templates
- 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
calls to load the TMCE plugin JS and populate the
object via proper <meta/> tags so that
will know to initialize them.
- Set SKIN = tmce_foswikilinks, tmce_mozbulletsfix, mysiteskin, pattern
- Set COVER = tmce_foswikilinks, tmce_mozbulletsfix
- 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.
- 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.
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
Too many vars gets unwieldy.
it would have
with a bunch of
Have yet to properly flesh out the appropriate .tmpl schema.
Question for discussion: Should these
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
+1 to the idea of a more modular TinyMCEPlugin
- 19 Oct 2009
means we should also consider easier toolbar customisation as well.
- 21 Oct 2009
- 27 Oct 2009
This is overlapping (entirely?) with EditorAPI
. Continuing this work there.
- 30 Dec 2009