This is the working group to discuss and coordinate the integration of client-side editors in Drupal core.
Developers and maintainers of client-side editors (aka. WYSIWYG) integration modules and other interested people are invited to join in and share their ideas and participate in the current efforts to build a Wysiwyg API that seamlessly integrates with Drupal core.
More information on the current status of the module can be found on the Wysiwyg project page.
Live discussions on development and support happen in #drupal-wysiwyg.
The current status, progress, and roadmap of all efforts are summarized on a special page:
Draft TinyMCE User Guide: Constructive Comments Wanted
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
Please help with CONSTRUCTIVE comments placed into node/281221
Read moreDrupal Specific WYSIWYG
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.
Read more
Rich (code) editor?
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.
Read more
Yeeeeha! or: hook_wysiwyg_plugin() is out!
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:
Read moreAdd context for check_markup()
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
Read more
Associating a Textarea and the input format
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.
Drupal stuff that an out-of-the-box Rich Text Editor doesn't include
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
Read moreWYSIWYG : The FCKeditor proposal
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.
Read more
Better input format support in Drupal 7
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)
Cleaning up text and format association in Drupal 7
Last updated by gábor hojtsy on Thu, 2008-02-21 10:06
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.
Read moreCutting through the input format clutter
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.
Read moresun's vision for handling embedded/inline content and Wysiwyg in Drupal
.
.
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)
Read moreSupporting WYSIWYG editing better, a Drupal battle plan
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...
Read moreRelevance-Enhanced Image Reduction and image presets
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.
Read moreDrupal 5 WYSIWYG Comparision
As part of the GHOP contest, I've put a <a comparision of the WYSIWYG editors available for Drupal 5 in the handbook.
Let me know what you think :)
Dan
Read moreGetting WYSIWYG
Last updated by johnbarclay on Mon, 2008-12-01 20:25
The WYSIWYG problem
The problem in allowing a Graphic User Interface editor to become What-You-See-Is-What-You-Get is that unless it is told the current CSS styling and the current CSS context then it is impossible for the editor to know what the end-result is supposed to look like. No matter how capable the editor is of being WYSIWYG it will fail unless it is supplied with enough information to know what styling it should be rendering, otherwise it is just a "pretty" editor and not a "WYSIWYG" editor.
Read moreWysiwyg editor settings of all editor modules
All wysiwyg editors are implementing more or less the same settings to control and adjust an editor's features, look and behaviour. A long-term goal of wysiwyg module is to centralize editor settings for all wysiwyg editors in one module.
Some editor settings differ, because either they do not support a certain configuration option at all or the maintainer was not yet able to implement the functionality (or: duplicate the code from another editor). Please bear in mind that many options are Drupal-specific only and others just alter a Javascript settings array that is generated to initialize an editor.
Let's list all configuration options available in editor modules here to get an idea of what wysiwyg module would need to support.
Read moreWhich editor (if any) do you use for your Drupal site(s)
