[wp-trac] [WordPress Trac] #12423: Include default code editor

[WordPress Trac]

#12423: Include default code editor
---------------------------------------------+----------------------------
 Reporter:  scribu                           |       Owner:  westonruter
     Type:  feature request                  |      Status:  closed
 Priority:  normal                           |   Milestone:  4.9
Component:  Editor                           |     Version:  3.0
 Severity:  normal                           |  Resolution:  fixed
 Keywords:  has-patch commit needs-dev-note  |     Focuses:  accessibility
---------------------------------------------+----------------------------

Comment (by westonruter):

 Replying to [comment:151 Clorith]:
 > A must have is fatal error detection, we really shouldn't have included
 (with heavy focusing on) the new editor without this (apologies for the
 late input).

 The way I see it, there are three levels of defense for editing PHP code:

 1. Syntax highlighting with automatic brace completion.
 2. Syntax linting to check for parser errors.
 3. Sandboxing of theme/plugin to ensure there are no fatals prior to
 “committing”.

 By introducing CodeMirror, we get the first level of defense as users are
 less likely to try saving a file with syntax errors if CodeMirror is
 guiding them.

 For linting syntax errors, see #41873.

 For the third, you note:

 > The approach we should take is to hit the site with a HTTP Head check,
 and at a minimum look for 5xx errors that are indicative of a server level
 error after the edit, and revert any changes made with a notice to the
 user that their changes were not saved.

 This is complicated, and it goes much deeper than just the editor itself.
 It is really part of the whole install/upgrade system. In fact, there is
 already protection for this built-in to the plugin editor. If you are
 editing an active plugin, you'll see this notice:

 > //Warning: Making changes to active plugins is not recommended. If your
 changes cause a fatal error, the plugin will be automatically
 deactivated.//

 This auto-deactivation does not seem to work reliably, unfortunately. See
 #39766 which I've just milestoned to 4.9. For the theme editor, it's not
 so easy because we can't temporarily deactivate a theme while checking if
 the theme still runs, because if the theme doesn't run then what theme is
 then left to be activated?

 One idea that has been raised is to actually create a copy of a given
 theme or plugin and temporarily activate it to see if there are errors. If
 there are, then the sandbox copy should be deactivated and the old
 theme/plugin should be re-activated. If there are not errors, then the
 changes can be copied from the sandbox to the main plugin and the sandbox
 can be removed. There is a good discussion about this here:
 https://wordpress.slack.com/archives/C0381N237/p1499707763283370

 But this is very complicated, and it's out of scope for this ticket which
 is about upgrading code in textareas to use a code editing component. For
 that, let's use #21622.

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