WordPress.org

Make WordPress Core

Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#1916 closed defect (bug) (fixed)

"Use the visual rich editor when writing" is inaccurate

Reported by: markjaquith Owned by:
Milestone: Priority: normal
Severity: trivial Version: 1.6
Component: Administration Keywords:
Focuses: Cc:

Description

the option on Options => Writing "Use the visual rich editor when writing" is worded incorrectly... it doesn't correspond with its function. It sounds like a user preference when it is actually a global on/off switch. If the box is unchecked people can't use WYSIWYG even if their preference is set to use it. I think the following wording is better:

"Allow users to use the visual rich editor when writing"

Change History (5)

comment:1 ryan8 years ago

Yes, we should either remove or reword this.

comment:2 matt8 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [3178]) Better wording, fixes #1916

comment:3 markjaquith8 years ago

  • Keywords bg|needs-patch removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

New string is:
"Users should use the visual rich editor by default"

This is incorrectly worded. It suggests that turning this option off just removes the visual rich editor as a default. It does not. It eliminates all possibility of any user using the rich text editor. If checked, WYSIWYG is default, and people can turn it off if they want. If unchecked, no one can use WYSIWYG, ever.

Actually, there is a case to be made for removing the option altogether. What is the point of globally forbidding the use of the WYSIWYG editor? Frankly, it's a bit confusing to have the option in two places. You can turn it off per-user, so why not just leave it at that? If global disabling is is important, you can allow a constant to turn it off, or something... no need to waste an option on this.


skeltoac: Screw it, remove it. That's one less option.
masquerade: +1


comment:4 markjaquith8 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

Okay, my bad... the behavior on this has apparently changed. When I originally reported, it acted as a global on/off, but now it just acts as a default.

I've opened a new bug suggesting we remove the option altogether:
#2033

comment:5 anonymous7 years ago

  • Milestone 2.0 deleted

Milestone 2.0 deleted

Note: See TracTickets for help on using tickets.