Replace default editor status option(s) with intelligent logic [#322433]

Currently, we have "Enabled by default" for each Wysiwyg profile, and also in each user account settings form. The whole feature goes back to the time of TinyMCE module, where only one editor and one profile was supported at the same time.

IMHO, the whole configuration option is pointless and also too technical for novice/regular users. Drupal can do better.
So here is what I imagine:

Drop both configuration options (profile and user account settings; the profile option is pointless anyway, since we want to support multiple profiles concurrently)
Each time a user clicks on "Enable/Disable rich-text", perform an AJAX request in the background to store the user's preference for this editor (or profile)
Extend the already existing parameter values for each input format with wysiwyg-status-0|1 based on the stored user preferences, defaulting to 1 (enabled), so this status value gets passed on to the editor attaching/detaching JS functions.
Also support this for anonymous users by storing their preference(s) in the session.

If that is done, also remove the other 2 options, "allow users to choose default" and "Show enable/disable rich text toggle link", from the profile configuration form. Owww, what a nice clean-up. :)

Comments

Comment #1

yan CreditAttribution: yan commented 17 October 2008 at 02:58

Sounds interesting, but one doubt: I need to use the default:disabled setting and if I understood your idea correctly, that wouldn't be possible anymore (or I'd need to disable the editor before saving).

My point: Multiple users use different input formats - some with an editor, some without. My experience with the WYSIWYG editor (in my case: TinyMCE) enabled by default was, that sometimes content that was written without an editor gets completely screwed up by the editor when I access the "edit node" page. (One example was a Paypal button where the html was copied from Paypal's website. TinyMCE just deleted the code.)

Comment #2

sun

German

Karlsruhe

CreditAttribution: sun commented 17 October 2008 at 16:55

You are mixing two completely different topics: a) enabling/disabling rich-text editors and b) validating/invalidating resp. cleaning up user contents, which is a different issue that still needs to be dealt with. Given the goal that we'll support a different editor for each input format, each editor should of course be aware of the allowed markup in an input format, and hence, not clean-up perfectly valid contents.

Comment #3

yan CreditAttribution: yan commented 17 October 2008 at 20:31

Ok, I just didn't get it right. :)

Comment #4

sun

German

Karlsruhe

CreditAttribution: sun commented 22 October 2008 at 06:05

Reconsidered the profile setting based on your point and #322657: "Enabled by default" option does not work when disabled - when a user did not yet click on the enable/disable rich-text toggle link, we can still provide a default status for each profile/editor. However, this will and should be overridden once the user has a "preferred status".

Comment #5

markus_petrux CreditAttribution: markus_petrux commented 9 November 2008 at 17:06

Hi,

Just installed latest snapshot, and it seems the user settings has gone. :(

Maybe you could add a module settings option to let site administrators decide if they wish to allow their users to change this setting from their profiles. Maybe it could work as follows:

a) When users cannot change this option from their profiles, perform the AJAX request updating the user option silently. Good for non-techies.

b) When users can change this option, expose the option in their profiles, and also ask them if they wish to automatically update this setting with the AJAX request (remind my last wysiwyg status option automatically). IMHO, this is a must when your users are mostly techies. ie. this option allows everyone to disable the wysiwyg editor by default, but enable it on demand only, which doesn't necessarily mean the user wants to change the default status.

Comment #6

davidhk CreditAttribution: davidhk commented 24 December 2008 at 06:17

Subscribe.

Comment #7

DamienMcKenna

NH, USA

CreditAttribution: DamienMcKenna commented 23 February 2009 at 21:32

Will take a look at this, see if I can help.

Comment #8

hackwater CreditAttribution: hackwater commented 13 March 2009 at 22:01

Comment #9

Aren Cambre CreditAttribution: Aren Cambre commented 20 May 2009 at 03:32

Issue tags:

+Usability

This is important.

I have some CCK Text area (multiple rows) fields that I need to run through an input filter. This means I have to select Filtered text (user selects input format) under Text processing at admin/content/node-type/platform-change/fields/fieldName.

The bad thing is selecting Filtered text... means I get a WYSIWYG editor even when I don't want it.