Recent Changes - Search:
PITS /

00421: WYSIWYG editor (like FCKEditor) integration

Summary: WYSIWYG editor (like FCKEditor) integration
Created: 2005-04-12 16:48
Status: closed
Category: Feature (Maybe this should be cookbook? -Russell?)
From: Pm
Assigned:
Priority: 5521
Version: pmwiki 2.0.beta29
OS:

See PmWiki.WYSIWYG for Pm's overview of this topic.

Done on pmwiki 2.1.26 FCKEditor

Description: It's an excellent, open source, browser-based WYSIWYG HTML(!) editor:
http://www.fckeditor.net

It comes with

  • multi-language support
  • skins support
  • toolbar selection

It's really lightweight and doesn't require any kind of installation on the client computer.

Actually, what I would like to see more is a fully visual editor that allows mapping the visual elements to the appropriate wiki markup. IE, instead of forcing page saving HTML format, let us chose things like the bold and italics attributes, and tell it what markup to use.

I've played with a couple of wiki's and CMS/portal systems that allowed integrating HTMLArea, but it always seemed more cumbersome than it was worth, and really defeated the purprose of a wiki.

That's just my $0.02. - George

Thats the holy grail of wiki's IMHO. Great Idea, but would break alot of the wiki functions already in place. But some users just need this type of authoring tool. They see the wiki markup, and it may as well be perl code. I myself have already been through trying to convert documents from doc, pdf etc into wiki format, and guess what? Its a real pain. It would be nice to just be able to copy and paste, without as much addition formatting intervention. FCKEditor seems to handle this pretty well. But like I said this would break existing wiki features. We would need a modified version of FCK (to handle wiki features not available directly in html) and a html to wikicode converter to even begin considering something like this. Anyone seen any working html to wiki converters out there? - JT

Converting HTML to markup would be a royal PITA.

It would be nice if FCKEditor could be coaxed into emitting PmWiki markup instead of HTML markup, but that doesn't currently seem to be an option.

Extending FCKEditor to recognize and emit arbitrary markup would be great, but it would definitely require a whole lot of work: it would need an interface to the parse engine of the wiki in question, and the UI would need to be reconfigured for each markup (no need to have a smiley window if there is no smiley markup, for example.)

The alternative would be a stripped-down FCDEdit that emitted only rather specific kinds of HTML, and have *that* converted. And we'd need a way to convert PmWiki markup to that stripped-down version of HTML. And we'd need a way to interface the markup added by Cookbook recipes into that. Doesn't sound very encouraging either.

I'd really love to see any of this done though...

Joachim Durchholz April 04, 2005, at 06:04 AM

Walking on this way, I suggest a flexible interface (assembled buttons like the existing GUI buttons) to allow adaptions to a (webform based) "skin" system.

The UI should fit to modules like, drawing tools, slide show editors and more to come.

CSS for text could be created online and assigned to available classes. nice.

scoid? May 08, 2005, at 07:04 AM

Here is an HTML -> Wiki parser and also here - referenced from this page at MediaWiki on this same topic.

I have wanted WYSIWYG in wiki for a long time. I sincerely believe the popularity of the first wiki medium to really implement it well (cross-platform, no download) would skyrocket.

I decided to give this a bit of a shot with Xinha ( http://xinha.python-hosting.com ). I wrote a quick JavaScript to parse headings, bold and italics from my wiki's markup to HTML.

My goals:

  1. Make wiki contribution easier on the non-technical end-user, by providing familiar tools and feedback for common formatting options.
  2. Leave markup for the things markup is good for. In accordance with the first goal, I'm not trying to reinvent text editing- quite the opposite, in fact. I'm trying to make it more familiar. Short version: don't try to render or simulate stuff like (:include:), just text formatting options.
  3. Don't use the standard PmWiki wiki -> HTML parsing. Tempting as it may be, many of the text transformations are not easily reversible. You sculpt with fresh clay, not by smashing vases back down.
  4. Don't worry too much about tables during this experiment, as they're not too common on my wiki. That said, I'm not sure PmWiki's advanced table structure is much of an advantage over working in HTML, so switching to HTML table syntax doesn't sound so bad.

My results:

  • The most complex piece of code (which isn't saying a lot) on the wiki -> HTML journey is the lists. DOM makes this a relative snap, though.
    • On the subject of lists, the rudimentary HTML -> wiki bits I put in had a little trouble with lists, too. The following PmWiki markup

      ** Test

      produces

      <dl><dd><ul><li>Test</li></ul></dd></dl>

      when run through PmWiki's renderer, but, when used to create a similar effect (a second level list with no parent), Xinha produces the unsurprising

      <blockquote><ul><li>Test</li></ul></blockquote>

      . This is a minor issue, and easily hacked around, but it's the most significant issue of non-whitespace differences introduced by the WYSIWYG editing process.

Open issues:

  • What about HTML you don't want? Scrubbing it is easy enough, but how do you interact with the user on the subject of changing their text? Rewrite it silently? Notify and show the edited version with a preview before saving?
  • What markup should be available?
  • What's the best way to designate content (such as internal wiki links) that should be rewritten by PmWiki? For test purposes, I've been using id="convert_wikilink".
  • With the current crop of DHTML editors, non-Gecko or IE browsers are out of luck. For Opera (a personal favorite) this isn't a big deal- who's using desktop Opera who doesn't have access to IE or Firefox? More troubling, perhaps, are the likely problems with Safari, which is pre-installed on a lot of Macs.

Stuff that would be cool:

  • Displaying the entire structure of a wiki is pretty easy. It'd be cool to have a popup window to help the user insert valid wiki links, with two-pane navigation a la Windows Explorer.

My conclusions:

  • I consider this a promising success, and I'll continue to pursue it. It'd probably be worthwhile for the cut-and-paste from desktop word processors alone.
  • If I were starting from a fresh wiki, and intended the primary markup to be a small subset of HTML, integrating a WYSIWYG editor would be fairly easy- the only spot requiring conversion would be the PmWiki documentation and some of the configuration variables, and that would only need to be on read. However, given the need to maintain compatibility with hundreds of pages of existing markup, and to permit end-users to use the "old standbys" if they like, conversion is much more complicated.
    • Supporting a subset of HTML for basic text styling isn't a bad idea in any event. Tags like <b> and <i> are familiar to a lot of people, and have less ambiguous meanings than conventional wiki markup.
  • Another good option to consider would be a syntax-highlighting control, since those parse their own grammars already.

Russell

Update: The CPAN Perl Wiki Converter module is pretty effective at generating PmWiki markup- including Simple tables- from HTML. I've fed it some fairly unpleasant markup (generated by exporting a Word document via OpenOffice.org) and gotten a clear, accurate wiki version.

I'm going to whip up a PHP wrapper for PmWiki to call it.

Russell

I've started to implement FCK Editor in PmWiki. The main problem i'm confronted to is the convert from the HTML produced by FCKEditor to PmWiki markups (FCK Editor cannot produce PmWiki markups instead of HTML code). I may release a beta version at the end of next week.

JeremieLePevedic?, 2006-09-08

Hi,

I just wanted to let you know... This might be the single most important extension to pmwiki yet. No matter how much some like to keep the markup. I'm extremely interested to reduce any obstacle for joe wikiuser. And this would make it as simply as firing up Wordpad.

Please keep up this topic. If you're looking for a beta tester, I'd gladly volunteer.
Axel, 2006-10-23 axel_groll(at)selbst-doku.de

Why is this closed? Is there no hope of this tool being integrated into pmwiki in the future?

(shameless competitor ad) Perspective http://high-beyond.com is excellent, and better than fckeditor. ( http://high-beyond.com/perspective.aspx?action=view&page=perspective:Welcome )

http://tinymce.moxiecode.com/ ThomasP October 22, 2007, at 11:51 AM

See also Category.Wikiwyg, Category.Wysiwyg

So...this is oficially death? come on this is a great tool