Easy now. Put down the pitchforks and the torches for a minute while I explain what I have on my mind.
I’m usually pretty good about not shooting my mouth off, especially as it pertains to things like WordPress core, which I’ve admittedly never contributed to, and might not ever contribute to from a code standpoint. But today I’m going to make an exception because I’ve seen way too many fails directly related to the file editor in WordPress, and I think it’s time we get rid of it… mostly.
Why the File Editor Has Got to Go
Let’s completely ignore the fact that being able to write files from within the WordPress dashboard can potentially open up your site to all sorts of malicious behavior, and be a really simple backdoor for anyone who gains access to your site. Defacements and large scale spam attacks are often started from within the WordPress file editor when bad usernames or weak passwords are cracked by brute force attempts. That’s bad news, but that’s not the reason I’d like to see the file editor go away.
At Site Care we go through a lot of broken websites. A lot. I’d say that easily three out of every ten cases that we take on, could have easily been prevented if users weren’t trying to make code changes in their WordPress dashboards. The story is always the same:
I found this tutorial online, and it told me to copy this code into my functions.php file. I clicked Appearance –> Editor, chose my Theme Functions file and pasted in the code from the tutorial. WHEN I CLICKED UPDATE EVERYTHING BROKE. And now I don’t have a way to restore it.
How Do We Fix This Problem?
There have been several attempts at solving this problem, and pretty much every attempt I’ve seen involves throwing more code at the problem. There’s even an IDE WordPress plugin that has syntax highlighting and all sorts of other craziness.
It’s true, the editor can be disabled with one quick line of code in wp-config.php, but it seems to me like a feature that should be opt in only, not opt out like it is right now. We wouldn’t hand the keys for an Indy Car to a 16 year old kid, so why would we give that supreme power of unintentionally bricking a website to a WordPress beginner?
@ryandonsullivan @rob_neu I think the better answer is some sort of validation on edits. Like when activating a plugin.
— Josh Pollock 🎃🌵🌲 (@Josh412) January 12, 2015
Josh suggested we include some type of validation for code that’s added through the editor. I don’t think that’s necessarily a bad idea, but I honestly don’t know why the editor needs to be turned on at all. Teaching people to edit their files locally, or even to cowboy code with a text editor seems like a much better way to go. In the end the overall perception of WordPress could actually be improved because people will be more confident making changes if they have a little bit of safety net.
Using the file editor is like eating at a taco stand. It could be amazing, but it’s probably going to end with regret.
How About a Compromise?
At the very least, having the editor disabled by default on new WordPress installs would be a big win. I actually found this little gem when I was working on a site at GoDaddy today.
Using @GoDaddy Hosting today. Clicked Appearance -- Editor, and this showed up. Would love to see this in core! pic.twitter.com/bN4cnMwVRg
— Ryan Don Sullivan (@ryandonsullivan) January 13, 2015
I’d love to see a similar procedure and warning worked into WordPress core. It’s just enough information to let people know they should proceed with caution, but still gives access to users for the occasional (but rare) occurrence where the WordPress file editor can come in handy.
So what do you think? Are you ready for the file editor to go like I am? Or will we have to pry the file editor out of your cold dead hands? Hit me up in the comments.