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:
The Input Format Mis-Design in Drupal
In Drupal, an Input Format is a chain of Input Filters.
The term Input Filter is quite accurate when it is describing Filters for security. It is rather important to filter out dangerous HTML code, such as XSS scripts, masquerading, overwhelming CSS, etc.. to protect a site from malicious content.
There are also other types of Input Filters, but these are not really filters at all, but rather, Converters or Renderers.
Read morePage Lang
Two years ago I created a module to increase the relevance of my webistes/pages for search engines, using SEO techniques.
This module doesn't increase the general relevance, but increases the relevance in a particular country without changing the relevance elsewhere. For example, if you have Spanish schools in Canada and your clients are Canadian you have to specify some code in the header of your page such as “en-ca”.
Read more
Proposal for D7 input format system
Through building and maintaining the Better Formats module I have gained insight in many different ways that I and others would like Drupal's input format system to work. There are 2 key points that make the current system in need of help.
- Every site has different needs and use cases.
- Current format system is not extensible.
There are 3 categories of features that site admins need to be able to control.
- Allowed formats
- Default formats
- Display options
Question Regarding Wysiwyg API Usage
I need to implement a significant set of custom functionality on top of a Wysiwyg editor. The basic concept is to allow the user to select text and then press a button to define that text as a "pull quote" which is then stored and can be used for special display purposes. I will maintain a list of icons on the side, one for each defined pull quote, and clicking on one will highlight that pull quote within the textarea.
Read more
Break plugin for TinyMCE
I feel like I'm missing something obvious but how do you get the TinyMCE break plugin to work in the WYSIWYG api?
With the full TinyMCE module you had to edit a PHP file and add a couple lines as well as copy the break folder into the plugins folder of TinyMCE. I see that there is a break folder under WYSIWYG so I copied it into the tinymce plugins folder.
I can see it as an option when I edit the permission of the filter type and I have checked it's box. However it never shows up on the editor.
What am I doing wrong?
Read moreUsefulness of WYSIWYG API for module developers whose module provides editor buttons
I've recently committed a project that provides an input filter that is inlining node titles, field values and taxonomy terms by ID.*
To utilize this the module has to provide buttons for editors that uses the filter tags and there the WYSIWYG API comes in mind. To provide those editor buttons (list of certain nodes/fields/terms) I return the data of a db query (for details see link) (1) and the output is forwarded to different buttons (autocomplete field, select list etc.) (2) and then sent to the editor by an additional function (3) because each editor uses a different "button format".
Is it possible to do step 3 with (a planned version of) WYSIWYG API, so the raw data of the db query or better the themed button containing that data can be submitted to WYSIWYG which then initialize this button for every editor supported? Currently I have to write an extra button for each editor and provide it by self written submodules.
Read more
Font families for the web
Hi,
I'm trying to compile a set of CSS classes for using in WYSIWYG editors to let users choose different fonts, but these classes would have to be as cross-browser / cross-platform as possible.
Here's a site with lots of information about this subject:
http://www.codestyle.org/css/font-family/index.shtml
And here's what I have compiled to date:
.font-arial {
font-family: Arial, Helvetica, sans-serif;
}
.font-lucida {
font-family: "Lucida Sans Unicode", "Lucida Grande", Lucida, sans-serif;
}
.font-tahoma {
font-family: Tahoma, sans-serif;
}
What would be the best approach to have a WYSIWYG for wikitext syntax?
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,
Read more
New WYSIWYG editor from 37signals
Just in case someone hasn't seen this already.
37signals is working a new WYSIWYG editor. From the blog post:
Read moreWysiHat is a WYSIWYG JavaScript framework that provides an extensible foundation to design your own rich text editor. WysiHat stays out of your way and leaves the UI design to you. Although WysiHat lets you get up and running with a few lines of code, the focus is on letting you customize it.
Next steps for Drupal 7 WYSIWYG
Now that the #input_format key is in Drupal 7, I'd like to propose a hook_content_editor() or something which would at first, let Drupal get the "markup support" information from visual editors. That would let tinymce or fckeditor tell Drupal that they support HTML, so Drupal would offer them to be set up for input formats "of this kind". Also, bbdeditor would report it supports "bbcode", etc. This would be great to help admins set up editors for formats. There are a few interesting bits here though:
Read moreHow to extend filter_xss() to parse style properties safely?
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%.
Read moreImprovements to Wysiwyg API
In progress
- Allow to configure advanced editor settings: Move most of the current profile configuration form into a callback function for each editor.
- Allow to sort editor buttons: Provide a jQuery based UI to sort editor toolbar buttons via drag'n'drop.
- Handle compatibility of (native) editor plugins to expose certain plugins for certain editor versions only.
Improvements to core
In progress
- 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.
See also all issues tagged with 'wysiwyg' and 'FilterSystemRevamp'.
Todo
Read more
Next generation Wysiwyg API: Edit like a rock star!
smk-ka and me worked on the next generation of Wysiwyg API today. Stunning results! Which are still compatible with D6 and D5.
Read moreAnnouncing Wysiwyg API - major milestone
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.
Read more
TinyMCE Plugin for Video Filter
Thought some folks around here might be interested in this...
Read moreAbout TinyMCE and other wysiwygs
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
First patch for FCKeditor support hit Wysiwyg's queue
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.
Read more