WordPress comes with a theme and plugin editor screen built in, to many volunteers dismay, both on the wp.org forums, on IRC and various other platforms. The biggest issue with the editor is that it’s right there, the user looks at the Appearance menu item thinking “I want to change my site”, sees a menu item labeled “Editor” and common sense dictates that to edit a site, you go into the editor. This is where it all starts going bad, the editor is a text area with the actual source of your theme (or plugin for that matter), and a single misplaced character is all that’s needed to WSOD (White Scren Of Death) your site, requiring some kind of direct file access to remedy it. For the users who end up using the in-browser editor, this may be unavailable to them or just a completely unknown approach that they have never before performed. How can this be improved? I’ve seen multiple approaches, the most helpful one so far is injecting a syntax highlighter onto the editor, but that can only do so much in helping visualize what is going on. This was bothersome to me, I had a plugin created explicitly for users who struggle when using themes and plugins and wondering why texts that are non-localized show up and can’t be modified. (You should normally never modify themes and plugins without making a child theme or forking the code first, but some times you just want a quick fix while waiting for the maintainer to push a patch to fix your problems), but there are many files, and no easy way to find what you need. I created the String Locator plugin for this purpose, originally I had it open the files in the built in editor, but this has some drawbacks; the editor does not do files from sub-folders, and with many themes and plugins separating code into directories and multiple files for easier maintainability, this was not an ideal approach. It also meant it would suffer the same problem as users accidentally finding the Editor page when going ot make minor changes to their site without knowing the implications. In the latest iteration (version 1.2) I decided to start working to remedy this in a big way, I made my own editor page! This has a few benefits over the normal editor;

• Syntax Highlighting, the color coding makes it easier to read, and easier to spot mistakes
• Details about the theme or plugin you are editing is readily available, linking to the Author to make it easier for you to instead click in and get direct support
• I implemented a featured I aptly named Smart-Scan

Why Smart-Scan? When the user has made his or her edits, if the Smart-Scan is enabled I will do a pass over and look for inconsistencies in the tag match ups, meaning every opening parenthesis, brace or bracket must be closed off. Didn’t close one properly? You’ll get a notice pointing you to the line that is missing a closing bracket, click the line numbers in any such notification to go directly to the line as well. This is my first iteration though, I have a few ideas for how I can make it even smarter and hopefully help even more users not crash their site by accident! So if I think this is so great, why don’t I submit it to core? I’d love to, but I want to ensure it’s actually worth while, and reliable. Core already does plugin first development to test implementations and code before it gets put in, so this is pretty much the same, I’m testing it, I’m seeing how it performs and if I’m happy with it and I see actual value I will eventually propose it.  ]]>