Wysiwyg

In progress

• Remove the teaser splitter: Yes, we can.
• Default input format per role and make access to filters first class permissions: Simplifies the input format configuration by moving input format access permissions to the regular user permissions form.
• Filter options based on CSS attributes, not just HTML tags: Allow to configure HTML attributes in HTML filter to allow and/or strip only certain tag attributes.

In reverse chronological order:

• List of current editor integration modules in contrib
• Gábor Hojtsy: Do not let WYSIWYG editors rule our textareas!
• Fields and places in Drupal core that should support input formats
• Comparison of contrib modules to control input formats

smk-ka and me worked on the next generation of Wysiwyg API today. Stunning results! Which are still compatible with D6 and D5.

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.

Thought some folks around here might be interested in this...

http://drupal.org/node/300643

I have used TinyMCE as my wysiwyg editor. I have, however, noticed some downsides:
-every time I hit enter I get p-tags into my html source. Some times I don't want to start a paragraph, I just want to keep line short or something like that.
-when I use layers things look fine in the editor, but the resulting page looks very different; the layers jump all over the place

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.

I have created a Draft TinyMCE User Guide. I'm wanting to get it reviewed by as many as possible before attempting to include it in the Drupal Documentation.

To get comments I have placed this draft version in the General Discussion Group Forum. Please review it at

http://drupal.org/node/281221

Please help with CONSTRUCTIVE comments placed into node/281221

Personally I think a Drupal specific solution would be very beneficial (if done correctly). I had begun development on this solution which can be found at http://drupal.org/project/editor

It is nearing the first beta release and is fairly functional for the most part (I currently use it on a few sites), although there is a VERY large todo list. Unfortunately I have next to no time to work on this module at the moment but if anyone is interested let me know.

I've hacked together an integration module for the EditArea rich code editor: sort of a What You Hack Is What You Get kind of experience. As such, it's got a more limited user base than FCK/MCE would.

Vast progress on Inline/Wysiwyg API:

After digging through TinyMCE module's issue queue and finding some RTBC patches containing major improvements to the module, languishing in the queue for more than one year (!), I decided to fork TinyMCE module into Wysiwyg Editor module. Most importantly, I've implemented Nedjo's patch to use jQuery to initialize the editor. This was an important step in the right direction, because Wysiwyg's goal is to support not only TinyMCE in the future.

However, for now the most exciting new feature is: I've re-rolled my hook_wysiwyg_plugin() patch, which allows any module in contrib to add its editor plugins to the editor configuration. So the time of installation steps like the following in Image Assist's README.txt is finally over now:

There's one big problem with the current development of Inline API: Filters do not know what "type of text" they are acting on. For example, the "old" Inline module allowed to embed images/files in a node's content, which are attached to the same node. Because filters don't know what they are doing, Inline needed to run via hook_nodeapi() in the past.

In Inline API, I coded around this limitation, but it's still ugly. So I went ahead and checked, how many times check_markup() is actually invoked in Drupal core. Here's the stunning result:

<?php

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.

There are a few Drupal-specific stuff that would be great to see in the wysiwyg toolbar but that won't be found in any out-of-the-box Rich Text Editor.

1) Internal links

Drupal has nodes. A user in MediaWiki, for instance, uses [ [Name of the article] ] to create an internal link to another article. We could adopt a similar concept and create a "link internal" that open an auto-complete form, allowing the user to select a node in the list. In fact, it isn't a new idea and it's been already implemented in a contributed project: http://drupal.org/project/easylink

There are a few Drupal-specific stuff that would be great to see in the wysiwyg toolbar but that won't be found in any out-of-the-box Rich Text Editor.

1) Internal links

Drupal has nodes. A user in MediaWiki, for instance, uses [ [Name of the article] ] to create an internal link to another article. We could adopt a similar concept and create a "link internal" that open an auto-complete form, allowing the user to select a node in the list. In fact, it isn't a new idea and it's been already implemented in a contributed project: http://drupal.org/project/easylink

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.

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.

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)

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)

I sat down and collected a list of how things are filtered in Drupal 7 core as of today. I grouped the table based on different formatting used. Part of the wishlist for Drupal 7 is to make format support available for things like the site mission or footer message as well as clean up the filter usage of other texts. This table shows some anomalies like the user signature changing input formats depending on comment formatting, or action descriptions not escaped but filter_xss_admin()-ed. These probably need more discussion and insight. Check the table below.

I sat down and collected a list of how things are filtered in Drupal 7 core as of today. I grouped the table based on different formatting used. Part of the wishlist for Drupal 7 is to make format support available for things like the site mission or footer message as well as clean up the filter usage of other texts. This table shows some anomalies like the user signature changing input formats depending on comment formatting, or action descriptions not escaped but filter_xss_admin()-ed. These probably need more discussion and insight. Check the table below.

As part of working on implementing easier to use input formats in Drupal 7 (reaching to WYSIWYG sooner or later), I started with cutting through the clutter. A possible rule to follow to simplify the content editing user experience is to remove (hide) filter options when appropriate. How does this work in Drupal?

Drupal core

Drupal allows setting up multiple input formats, each with different filters. The filters have specific (possibly different) configuration in each input format. The default Drupal core options allow admins to restrict filter format access to certain roles, and there should be one format accessible to all roles, so if someone has content submission permissions, she can add content to the site in the default format at least.

Input format clutter

There comes the input format clutter. Many sites have multiple input formats. Least restricted formats are used for site pages, about boxes, blocks, commonly stuff produced by the administrator for. There might be a bbcode format for forums and comments, a wiki format for wiki pages, etc. Some roles have access to multiple input formats, and choosing the right one each time complicates their life. So several contributed modules emerged to solve this problem, hiding certain input formats or prioritizing them by setting the default intelligently depending on configured circumstances. I reviewed four modules in the hopes that we can get some of this functionality into Drupal 7.

Looking for a Developer who shares our passion for Drupal. We are a custom development team in Montpelier, VT. We have many tools in our toolbox including PHP/Drupal, Java, and Flex. If you want to grow into a renaissance person, you've found the right shop. Check us out here (www.bear-code.com).
We’re looking for a PHP/Drupal developer with these skills --
• minimum 1-2 years PHP experience
• at least 6 months experience working with Drupal
• Coding for high-traffic Drupal sites
• Coding web user interfaces with XHTML, CSS and all the trimmings

Looking for a Developer who shares our passion for Drupal. We are a custom development team in Montpelier, VT. We have many tools in our toolbox including PHP/Drupal, Java, and Flex. If you want to grow into a renaissance person, you've found the right shop. Check us out here (www.bear-code.com).
We’re looking for a PHP/Drupal developer with these skills --
• minimum 1-2 years PHP experience
• at least 6 months experience working with Drupal
• Coding for high-traffic Drupal sites
• Coding web user interfaces with XHTML, CSS and all the trimmings

.

.

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)

.

.

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)

I have a blog post up on my blog, in which I try to set a plan for Drupal 7 to tie RTEs to input formats instead of textareas. I think there is a fundamental problem with RTEs, in that they attach themselfs to any textarea seen (or not the right textareas in other cases). Also, by tying to input formats, RTEs could just grab the settings of the input formats, and align their interfaces accordingly (ie. if img is not an allowed tag, do not even think about displaying an image button). More here: http://hojtsy.hu/blog/2008-feb-04/supporting-wysiwyg-editing-better-drup...

I have a blog post up on my blog, in which I try to set a plan for Drupal 7 to tie RTEs to input formats instead of textareas. I think there is a fundamental problem with RTEs, in that they attach themselfs to any textarea seen (or not the right textareas in other cases). Also, by tying to input formats, RTEs could just grab the settings of the input formats, and align their interfaces accordingly (ie. if img is not an allowed tag, do not even think about displaying an image button). More here: http://hojtsy.hu/blog/2008-feb-04/supporting-wysiwyg-editing-better-drup...

Sometimes I've been looking for a module which would let me crop an image visually, though I haven't found one working for the drupal version I've been using, until recently when Imagefield crop became available (Edit: which supposedly will be folded into Imagecrop for D6. The latter module is a later addition which I weren't aware of when I wrote this.)

However, there is still one missing concept and that is Relevance-Enhanced Image Reduction which is what would be the best solution for this.