WYSIWYG

Hi all,
I can see there are a lot of activity around the WYSIWYG concept.
However, the support for wikitext format is poor, I noticed an experimental FCKeditor for mediawiki.
But this sounds quite experimental, and not that easy to adapt for drupal.
Before going further in my investigation, I was wondering what would be the best approach to get a wysiwyg editor for wikitext on Drupal (even if this does not cover 100% of wikitext)

Any information will be appreciated,

Hi all,

I hope this is a good place to talk about this subject.

WYSIWYG editors such as TinyMCE are great, but when it comes to provide a secure method to filter what such a tool allows to users, I have the feeling that Drupal core filters do not help much.

If we use Full HTML, then we can do anything with our great WYSIWYG editor, however this is no no solution if we need to allow WYSIWYG capabilities to users we cannot trust. So, Full HTML filter might only be a valid solution for personal sites, or sites where all contributors can be trusted 100%.

I took the time to rewrite the Wysiwyg (Editor) module into a generic API over the weekend. So the primary concerns about TinyMCE-specific code all over the module are eliminated now. Also, you might have noticed, that I have added an example integration for FCKeditor already - which of course is rather a proof of concept than a fully-fledged integration (and it works cleanly 8).

So Wysiwyg has become a real API finally.

I've created a screencast comparing the user experience for entering data via Markdown vs. TinyMCE WYSIWYG:

WYSIWYG vs. HTML Helper Screen Cast at Blip.tv

I have spent the last hours to get a first draft of FCKeditor support in Wysiwyg Editor module.
http://drupal.org/node/282717

It's still very rough and dirty, but it outlines what can be done and what needs to be done for multiple editor support in Drupal via one API module.

Now I badly need some feedback from folks that are interested in centralized Wysiwyg editor support, who know jQuery + JavaScript, and who might have ideas and suggestions on how to solve the outlined design challenges. Of course, all editor module maintainers are implicitly more than welcome.

Greetings everyone! I'm throwing in my hat for participation in the WYSIWYG discussion.

As we've noted in previous discussions, we currently have a serious problem with WYSIWYG editors not being Input Format aware. In D7 we'll get a nice luxury of #input_format (sounds awesome Gabór!), and we'll easily be able to combine the two into a single, well themed element. I've rigged up a temporary solution for D6 that I've posted to the the WYSIWYG project issue queue (patch forthcoming).

Here's a graffle of how I imagine the Input Format system working with the WYSIWYG framework.

Note: this is totally a mockup it is not a new WYSIWYG editor of any sort.

We are starting now the development of V3, the next generation of FCKeditor:

http://docs.fckeditor.net/FCKeditor_3.x/Design_and_Architecture

It is to be rewritten and optimized, including several new features. It will be definitely out of comparison with our current solution. Performance and code size is definitely at the top of the list for us.

I have just discovered that one idea I suggested at tonight's meeting is already being implemented by others. It would be helpful to have a registry of all the text areas in Drupal that WYSIWYG should work with, and lo and behold, one is being envisioned:

http://drupal.org/project/wysiwyg

For those of you interested in following up on the WYSIWYG discussion, this is a good place to start.

Collecting discussions and patches for a better input format support in Drupal 7. My battle plan writeup is at http://hojtsy.hu/blog/2008-feb-04/supporting-wysiwyg-editing-better-drup... and there are groups post here about cutting through the format clutter (http://groups.drupal.org/node/8911) and format association observations (http://groups.drupal.org/node/9072). This list summarizes the patches in different states to improve input formats and support RTEs better.

• For review:
  • http://drupal.org/node/125315 - Add the #input_format Form API construct, so that additional form fields are not required, and metadata is captured for WYSIWYG editors and form altering in general
  • http://drupal.org/node/110242 - Make filter access first class permissions
  • http://drupal.org/node/240873 - Move custom help settings to blocks
• TODO:
  • http://groups.drupal.org/node/8911 - Limit available input filters by "type of widget" used (node type body, comment, block, etc)
  • http://groups.drupal.org/node/9072 - Bring consistency into how we apply formats and provide more format support where it is missing.
  • Move site mission and footer message to blocks / new block regions (in part to add format support).
• Done:
  • http://drupal.org/node/222183 - Make input formats reorderable (committed!)
  • http://drupal.org/node/240988 - Break out HTML escaping filter to make non-HTML input formats (instantly) recognizable (committed)

.

.

As some of you know, I've recently taken over maintenance of Inline and Image Assist, and initiated the Wysiwyg project. That was not only caused by personal interest, but also to take the necessary steps to realize the long awaited Inline API. You might ask yourself, what those three modules have in common or to do with each other at all: They deal with user input, allow to embed complex contents into a content, and provide an interactive GUI for that. If you already had the chance to work with them, you already know that there is a rather hidden, non-obvious hard-dependency between them.

Although I'd really like to discuss both topics (Inline and Wysiwyg support) separately, the gained experience on these topics enforces us to discuss them concurrently. The following mockup hopefully explains why: (see attachment to view in full size)