[wp-trac] [WordPress Trac] #31779: Warn users before using a built-in file editor for the first time

WordPress Trac noreply at wordpress.org
Fri Aug 18 22:27:37 UTC 2017


#31779: Warn users before using a built-in file editor for the first time
--------------------------------------+---------------------------------
 Reporter:  helen                     |       Owner:  helen
     Type:  enhancement               |      Status:  reviewing
 Priority:  normal                    |   Milestone:  4.9
Component:  Themes                    |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  good-first-bug has-patch  |     Focuses:  ui, administration
--------------------------------------+---------------------------------

Comment (by celloexpressions):

 Replying to [comment:46 cliffseal]:
 > If it's not an option to remove or disable-by-default this editor, I
 think a combination of other simultaneous changes could support this
 effort:
 >
 > 1. Move the Editor into the Tools menu, or into Tools > Available Tools.
 It fits better there anyway: it's not a visual editor for the
 ''Appearance'', as other things are in the Appearance menu), but the other
 problem with Plugins > Editor is it's right beside one of the most clicked
 buttons in the UI (Add New). It's too easy to discover. You could also
 move the warning messages suggested above into a box on Available Tools.
 Instead of a warning, it becomes the context for launching the Editor.
 Plus, what else is going on in that page anyway. :)
 +1
 > 2. To do the above, combine the Theme and Plugin editors into one.
 Separate the edit dropdown with headings for Theme and Plugins.
 This makes a lot of sense. There are functionally few cases where the
 distinction between them needs to manifest in entirely separate editors.
 Much of the text, functionality, and warnings about changes being
 overwritten by updates apply to both plugins and themes. It also further
 promotes the use of additional CSS for visual adjustments, with the
 editor(s) being a place for more involved changes.
 > 3. Make Editor access a setting in Settings > General. I saw the
 argument that having to set the constant doesn't make sense for the people
 using the Editor—this is a solution that still hides the danger by default
 but has a low barrier to enablement.
 In terms of discoverability for the people that benefit most from this
 functionality, it's probably better not to introduce a user-facing option
 for this.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/31779#comment:53>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list