[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