Code Editor: Auto scroll or click button to go to error.

[paaljoachim]

It would be good to have an auto scroll to go to error that the code editor notices. (Or a button the user can click.) After fixing one error the user can click the button again to go to the next.

The Update File button should not be disabled.

Originally ​https://github.com/WordPress/better-code-editing/issues/95

See conversation at ​https://wordpress.slack.com/archives/C0381N237/p1505425698000437

[westonruter]

Bumping priority to high for visibility and alignment with 4.9 goals, and given proximity to beta 1 deadline.

[melchoyce]

I've been look at this issue, and at this point my two options feel like:

1. Add something that looks kind of hacky and crappy that lets you scroll between errors
2. Or, create a whole new "find" interface, like the one in browsers/major editors like Google Docs

I think 2 is viable, but not in the time we have. I'd want to spend some time working on it and testing it, so I'd need probably 1-2 weeks. Since we're coming up on the Beta 1 deadline, I think we should punt this and explore making improvements in a future release.

[westonruter]

In 41721:

File Editors: Introduce sandboxed live editing of PHP files with rollbacks for both themes and plugins.

• Edits to active plugins which cause PHP fatal errors will no longer auto-deactivate the plugin. Supersedes #39766.
• Introduce sandboxed PHP file edits for active themes, preventing accidental whitescreening of a user's site when introducing a fatal error.
• After writing a change to a PHP file for an active theme or plugin, perform loopback requests on the file editor admin screens and the homepage to check for fatal errors. If a fatal error is encountered, roll back the edited file and display the error to the user to fix and try again.
• Introduce a secure way to scrape PHP fatal errors from a site via wp_start_scraping_edited_file_errors() and wp_finalize_scraping_edited_file_errors().
• Moves file modifications from theme-editor.php and plugin-editor.php to common wp_edit_theme_plugin_file() function.
• Refactor themes and plugin editors to submit file changes via Ajax instead of doing full page refreshes when JS is available.
• Use get method for theme/plugin dropdowns.
• Improve styling of plugin editors, including width of plugin/theme dropdowns.
• Improve notices API for theme/plugin editor JS component.
• Strip common base directory from plugin file list. See #24048.
• Factor out functions to list editable file types in wp_get_theme_file_editable_extensions() and wp_get_plugin_file_editable_extensions().
• Scroll to line in editor that has linting error when attempting to save. See #41886.
• Add checkbox to dismiss lint errors to proceed with saving. See #41887.
• Only style the Update File button as disabled instead of actually disabling it for accessibility reasons.
• Ensure that value from CodeMirror is used instead of textarea when CodeMirror is present.
• Add "Are you sure?" check when leaving editor when there are unsaved changes.

Supersedes [41560].
See #39766, #24048, #41886.
Props westonruter, Clorith, melchoyce, johnbillion, jjj, jdgrimes, azaozz.
Fixes #21622, #41887.

[batcatforever]

Mocked up a few ideas on how to handle errors out of view in the code editor. Please feel free to comment on them directly in Drive or here!

Link to Mockups: ​https://docs.google.com/drawings/d/1f035E5YbFCu3pSJnUjuDQ2lpLSyG5nyeEnyyDc8DXoY/edit?usp=sharing (no login required)

Attached PDF version as well

[boemedia]

Hi @batcatforever ,

I looked at your mockups and I think it may be more consistent to move a search/skip box to the top for a more consistent layout that matches search and filter as used in pages/posts.

Not sure if it should be a notification/error layout/design either in this case. The errors are marked in the code. In more looking into a search (and replace) type of function as used on the web or in Microsoft Office programmes, or how we do spell/grammar check in these programmes too.

[paaljoachim]

What should we do with this trac ticket?
Close it as a wontfix?
As this was never added to WP core.

[peterwilsoncc]

@paaljoachim We discussed this in a triage session today.

We decided to close it off, as you indicated it doesn't have much in the way of traction.