CodeMirror and the Coding Sandbox Introduced in WordPress 4.9

Of all the updates introduced in WordPress 4.9, the CodeMirror library being integrated into Core just might have the widest-reaching implications.

First of all, it’s a JavaScript library that integrates with the editor to provide error linting, syntax highlighting, and contextual suggestions for code snippets within the WordPress dashboard itself. Essentially, it makes it a whole lot safer for non-coders (and coders!) to poke around and learn WordPress without messing stuff up and whitescreening their websites. (We have a cool walkthrough of the changes here.)

More importantly, however, is the new integration with the CodeMirror library and WordPress APIs so that plugin and theme developers can use it.

Best of all, it’s a tried-and-true library that’s used all over the internet. From Bitbucket and Github to the Firefox and Chrome Developer Tools. This isn’t a halfway done solution. Core contributors found the best library. Then created the hooks WordPress needed to use it. Not the other way around.

WP 4.9 and CodeMirror

Currently, there are two ways for you to work with editors within your plugins and themes. You can use either of these two functions.

• wp_enqueue_code_editor()
• wp_enqueue_editor()

These work pretty similarly to one another, and you can read up on the differences in the Codex. Essentially you can pass a codemirror argument to enable that field to convert from a standard text entry to the new, special code editor for WP by calling a special code-editor.js script.

The Codex documentation puts it like this:

For example, if editing CSS then it will enable linting and if editing HTML it will enable the auto-closing of tags

And it’s not just for CSS and HTML, either. No, no, no.

The file editors now also feature the same CodeMirror-powered syntax highlighting, auto-completion, and error checking. The allowed file extensions in the file editors can edit have been expanded to include formats which CodeMirror has modes for: conf, css, diff, patch, html, htm, http, js, json, jsx, less, md, php, phtml, php3, php4, php5, php7, phps, scss, sass, sh, bash, sql, svg, xml, yml, yaml, txt.

Or in more succinct terms: pretty much everything

That addition alone opens up a lot of new possibilities for developers and designers. Devs and authors can finally expand the kind of control they can offer to users. It’s the same kind of control the new editor and customizer have, too.

Dig Deeper, Dig Safer

One really neat change is that the editors now get to go deeper into the filesystem. With CodeMirror’s protections, the dashboard-based editors dig right down beyond the old limit of two directories. It doesn’t mean a lot to many (most?) users of WP. But this is a freedom that devs can take advantage of.

CodeMirror opens up into a full-on coding environment within the WordPress dashboard. Now you can By being able to dig deeper into the site’s file system. However, by doing so, it opens up for a lot of danger. Not only will users be able to edit the CSS and HTML files (within the protected bounds of the linter), but they’ll also have access to the more delicate PHP files that keep the whole installation running smooth as silk.

And we all know the last thing we want is a non-coder making a kerfluffle out of some PHP.

Get into the Sandbox

The devs have also changed the way PHP files are saved when using a built-in editor. Essentially, this is what you get when you open a PHP file now:

1. Upon opening a PHP file, you edit a new, separate instance of that file. Its content is held within a variable through the use of cookies.
2. If you have changed the file in such a way that a fatal error will occur and make the editor inaccessible, the changes are undone and the original PHP file that you wanted to edit remains unchanged.
3. If there is no fatal error at this point, another check will be made to see if the website itself is inaccessible because of a fatal PHP error. Again, if there is an error, the original file is reverted, and an error message will appear telling you what happened and why.
4. Finally, if there is no error that prevents the site from running on either the admin side or front-end, your changes go live immediately.

And as a final failsafe, the editor sees bad PHP mojo. If there is enough to keep the PHP within a loopback that can’t be resolved, the new code editor is smart enough to stop it and send the user a message that it would probably be best if they were to do commit those changes via FTP.

Let’s be honest here, too. If they can’t make the changes to the PHP files without those kinds of errors within the dashboard, they’re not going to be doing manual FTP updates. Which is yet another, totally divorced-from-WordPress safety feature baked into 4.9.

Think of the Possibilities

The popularity of online coding courses and bootcamps make this inclusion perfect for elearning plugins. With the existing React libraries in use for plugins and themes like Gutenberg, Calypso, and our very own Divi, IDE-style editing is here. (By the way, CodePen already uses CodeMirror for this.)

Being tied directly into the WordPress Core also means that even allowing small adjustments and customizations became a lot safer. For instance, you can now give users access to more direct control of CSS and design within your plugin. And you can do so without fear they’ll totally break something.

By being able to integrate that customization into the plugin itself, rather than simply documenting the classes and IDs that control it, you can then provide better support and UX for the product. Even then, you can control the environment that the users are able to customize your UI, and therefore offer the best experience so that nothing else on their site can be (theoretically) affected by the changes they make.

While technically this kind of option was entirely possible prior to 4.9, there wasn’t much reason to. There were few safeguards. Now, however, with a built-in IDE(ish), you get (and can offer) so much control, the sky’s the limit.

Have Fun, Kiddos!

Between the sandbox we get to play around in and the possibilities and potential that 4.9 brought us with CodeMirror integration, there really hasn’t ever been a better time in the history of WordPress for both developers and users to dive deep into the code. Time to learn how things really work.

After all, what’s the worst that could happen?

What are your plans for integrating CodeMirror into your own plugins and themes? Let’s talk in the comments!

Article featured image by Sarawut St / shutterstock.com