WordPress 4.9 and the Code Editor Warning

A new box in the editor

Since WordPress 4.9 arrived in November, opening the theme editor or the plugin editor in the dashboard brings up a warning before anything else.

In effect, it says that editing these files directly is risky, that changes may be lost in updates, and that a child theme and a backup would be wise. A button lets you carry on anyway.

Most people who see it will press the button. It is worth reading first.

What the editors are used for

Under Appearance, WordPress has long offered an editor for the active theme's files. Under Plugins, there is one for every installed plugin. Both change the real files on the live site.

They were meant as a convenience for developers. In practice they get used by anyone with an administrator login and a snippet to add.

• Tracking codes pasted into the theme's header file.
• Style changes made directly in the theme's stylesheet.
• A function copied from a forum into the theme's functions file.
• A quick fix to a plugin that misbehaves.
• A deleted line that seemed to be causing a problem.

The third is the likeliest to take a site down. One missing character in that file can stop every page loading, the dashboard included.

Why live edits break sites

A change made in the editor takes effect the moment it is saved. There is no preview, no undo and no copy of what was there before.

A mistake in a PHP file, the code that builds each page, can leave every visitor facing a blank white screen. If it also stops the dashboard loading, the editor that caused it can no longer be reached.

Fixing it then needs access to the server's files, through the hosting control panel or a file transfer program, which many owners do not have.

So a two-second typo becomes a site that is down until someone with the right login is available.

What 4.9 changed

WordPress 4.9 added three protections. The editors now highlight code and flag obvious errors as you type. The warning appears before you start.

And when a PHP change is saved, WordPress now checks whether it would break the site, and refuses to keep it if so. The release notes call this a sandbox.

On some hosting setups that check cannot run, and WordPress then refuses to save PHP changes from the editor at all, suggesting the file be uploaded another way.

These are real improvements. They catch the typo. They do not catch the rest.

What the warning is really about

The more lasting problem with editor changes is not the white screen. It is that they disappear.

When a theme or plugin updates, its files are replaced with the author's new versions. Any change made directly to them is overwritten without a message.

Editor changes also leave no record. Nobody knows who changed what, when or why, and the next person to look after the site inherits code they did not know was there.

And some mistakes break nothing visible. A tracking code pasted twice, a script that slows every page, a security check removed by accident: the sandbox sees nothing wrong with any of them.

A worked example

A holiday light installation company took quote requests through its website and ran a small AdWords campaign each autumn, ahead of the installation season.

The season before last, someone in the office pasted the AdWords conversion code into the theme's header file through the editor. It worked, and quote requests from ads began to show as conversions.

Last September, someone clicked update on the theme, as the dashboard had been asking for weeks. The update replaced the header file, and the conversion code went with it.

The autumn campaign ran reporting no conversions at all. The office concluded the ads had stopped working and came close to switching them off just before the November rush of installations.

Whoever maintains the site fixed it in under an hour: a child theme to hold changes, the conversion code placed where updates cannot reach it, and the editors switched off.

Where changes belong instead

Each kind of change has a proper place, and none of them is the editors.

Small style changes belong in the Customizer's Additional CSS panel, which survives theme updates.

Anything more belongs in a child theme: a small theme that inherits everything from the main one and keeps your changes separate, so updates leave them alone.

Tracking codes are better kept in one place built for them, such as Google Tag Manager, or added once by whoever maintains the site.

Anything larger should be tried first on a staging copy: a private duplicate of the site where mistakes cost nothing.

Switching the editors off

A single line in the site's configuration file, wp-config.php, removes both editors from the dashboard. Many developers add it as a matter of course.

That has a security benefit too. Someone who steals an administrator password can use the editors to write code onto the server from a browser. Without them, a stolen login is still serious, but less useful.

Ask whoever maintains the site whether that line is there. If nobody at the business needs the editors, there is no reason to keep them.

Who should be changing code

Underneath all this is a simpler question: who changes the code on your site?

If the answer is anyone with an administrator login, the site will collect changes nobody can account for. That is how sites become fragile: not through one big mistake, but through years of small, unrecorded ones.

Better to have one person or firm responsible, who makes changes in the right place, tests them first and keeps a note. That costs a little. Rescuing a broken site in a hurry costs more.

The counter-case

For a developer who knows the code, keeps backups and tests on a copy first, the editor is a quick way to look at a file. Reading it is harmless; saving is what does the damage.

And a business that genuinely needs frequent small changes should have them made properly, by someone on a schedule, rather than stop making them.

The rule itself stays simple: no saved changes through the dashboard editors on a live site.

What to do

1. Ask who uses the editors now.
2. List changes made through them in the past.
3. Move those changes into a child theme.
4. Put tracking codes where updates cannot reach.
5. Switch the editors off in wp-config.php.
6. Set up a staging copy for testing.
7. Name one person who changes code.

Step two prevents the next surprise. Past editor changes sit in files the next update will overwrite, and finding them now costs far less than finding out afterwards.

Checking every change on a phone as well as the office monitor is covered in the phone version nobody at the office has seen.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.