[wp-trac] [WordPress Trac] #6531: Recursively search for files in theme and plugin editors

[WordPress Trac]

#6531: Recursively search for files in theme and plugin editors
-------------------------------------------------+-------------------------
 Reporter:  torbens                              |       Owner:
     Type:  defect (bug)                         |  westonruter
 Priority:  high                                 |      Status:  reviewing
Component:  Themes                               |   Milestone:  4.9
 Severity:  minor                                |     Version:  2.5
 Keywords:  theme-editor has-patch needs-unit-   |  Resolution:
  tests                                          |     Focuses:
                                                 |  administration
-------------------------------------------------+-------------------------
Changes (by westonruter):

 * keywords:  theme-editor has-patch => theme-editor has-patch needs-unit-
     tests


Comment:

 I've applied some fixes to PHP code style which were identified by
 [https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards
 PHPCS].

 In addition to @schlessera's great feedback, one thing that became clear
 to me in testing the patch is that we should absolutely ignore certain
 directories from being traversed. I'm thinking `node_modules`, `vendor`,
 and `bower_components` to start. The list of files can get so incredibly
 long that it just becomes impossible to navigate. I don't think we can
 safely throw this on users if we don't also tackle #41729.

 While this is out of scope for this ticket, the latency for recursing over
 all the files is compounded by the fact that every time the user saves a
 file, the result is a full page reload when there really is no need for
 that. In reality the new file's contents should get submitted over Ajax
 (er, eventually maybe REST API) and in that way the user wouldn't be
 continually pinging the server to re-generate the list of files every
 single time, and making the user have to re-locate their scroll position
 after saving. There is crossover here as well with #39766 and #39766 where
 we could avoid the whole need to detect when an PHP error happens and then
 when the plugin editor page reloads to throw in an iframe to try scraping
 for the error message again. The error message can simply be returned in
 the Ajax response and then shown to the user immediately. /cc @melchoyce

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