[development] Why Drupal 5.x must have built-in WYSIWYG Editor?

Robrecht Jacques robrechtj+drupal at gmail.com
Fri Oct 6 15:45:04 UTC 2006


Just to step in. I'm not sure we need a #wysiwyg property. I think we
need a #html property. This would say: it makes sense to put HTML
codes inside this textarea. If not set, one would be "required" to
input plain text. This makes the property *semantically* correct and
could even be used inside core.
Is the log message even suppose to be HTML or not? Is the description
of a taxonomy term plain text or not? If you have a textarea where you
input the paths blocks appear on #html would 0.

But thinking of wysiwyg (or quicktags or img_assist etc), I always
wondered if instead of adding a property to a form element (or rather
like Bèr said, try to detect by element-id and/or path), it is not
better to "connect" (eg in hook_form_alter()) wysiwyg behaviour to
input formats (eg check if there is an input format form beneath it).
I know tinymce has profiles, but these are for users/roles. The README
of tinymce even suggests you make a "rich-text editing" input format
that allows all html tag to use for tinymce enabled textareas.
Now, would it not make more sense to attach those profiles to the
input format instead? I would expect that if my input format was set
to "filtered html", the things wysiwyg shows is more limited then when
I select "full html". I don't care what role is editing the node, I
just care about what input format the user is *currently* using (and
because the formats a user can use depends on the role he has, it
indirectly maps to users/roles too).

As tinymce (or any other quasi-wysiwyg solution) needs javascript
anyway, it should be "easy" to change the profile of tinymce *when the
user changes the input format*. As the default input format is
"filtered html" users are puzzled that the node they are previewing
doesn't look like the one they were editing "wysiwyg" until they
realize the input format is not set to "full html" (or "rich-text

I was thinking of developing exactly such a (contrib) module.

Think of the way the gmail mail-editor works (there is a "Rich
formatting >>" button above the textarea, and until you click it, you
are editing in plain text). In some way drupal has the same (filtered
html/full html), but the wysiwyg modules don't seem to use it.

Together with something like rememberfilter, it would make the
behaviour of wysiwyg editing in drupal much clearer/cleaner.

It would be nice to see the wysiwyg modules authors come together
*first* and develop a clean, common way of doing this before someone
utters a word about it again on drupal-devel ;-)


On 10/6/06, adrian rossouw <adrian at bryght.com> wrote:
> On 06 Oct 2006, at 3:05 PM, Michelle Cox wrote:
> While I don't agree that Drupal needs a WYSIWYG built in, I do like this
> idea. If I'm understanding right, it's basically a hook to call whatever
> editor the user has installed or a plain text area if none. From my non-dev
> perspective, that sounds like a useful thing. Would be especially nice if
> there was a way to make it so that, for example, my users get BBCode and I
> get QuickTags. And that they only show up when editing the main text of a
> node. for the longest time i've advocated that the tinymce module etc just
> extend the form
> and add a '#wysiwyg' => true property, to whatever field they want.
> this means anyone else can also go and add that property to any form they
> feel like.
> if the element is set , and the module is not available, it is just ignored.

More information about the development mailing list