It’s Time to Get the File Editor out of WordPress

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?

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.

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.

36 Comments


  1. I had some long discussion / debate with Otto about this once. I agree with you that it’s better off just not being there, but he had some decent reasons about why I was wrong.

    However, we did agree on something: there is room for some built in syntax checking and perhaps some safety precautions that would prevent, say, someone from completely borking their site. I think the struggle is that this is a) an easy thing to take out b) a difficult thing to do *well* and leave in c) even easier to just ignore.

    Most people hyper-alert to the WordPress world know not to screw with this editor. Out of sight, out of mind. However, that probably doesn’t reflect the true state of how this editor plays in day to day users: a big source for hacks and fails.

    Glad you brought this up! It’s a worthy debate.

    Reply
    1. Ryan

      Yeah, there are a lot of moving parts and the more I thought about how it could potentially impact those edge cases where having an editor does make sense, the more empathy I had for the decisions that the core team has to sift through every single day. Another big part of this is education. Tutorial sites need to stop pointing people to it, or take the approach that Bob mentioned and actually roll their solutions into a plugin. It’s not that much more work. I’m sad you’ll never see this reply, Brian 😉

      Reply

  2. Hey Ryan, I’m with you on this as I experience the exact same things. And I might even take it a step further.

    I think anyone that has the knowledge and expertise to add these code snippets without the earth exploding, are likely to access the file another way.

    For those users who do see those snippets. Well, I have had debates with devs on this a lot. They will come into a post I have written about a certain plugin and argue that it’s much better to add this “snippet” instead off using yet another plugin. Well, true in some cases. But most users are deathly scared to add code, and when they do, often what you mentioned happens, or they do it and cannot remember how to remove it if they want to.

    For me, that alone would solve a lot of unnecessary problems that happen when messing with these files.

    Reply
    1. Ryan

      +1 Extracting these types of snippets into plugins isn’t *that much* more work for developers. Dropping a bunch of stuff into the theme isn’t a good solution anyway for all the reasons we know about already. Thanks for chiming in, Bob!

      Reply

  3. OK, Yes, I do agree with this post =).

    I don’t want to say to remove it completely, but having an opt-in is much better then displaying it for every client that wants to play developer and start breaking things.

    Maybe it can even be limited to a specific user, like the developer, which would help things not break so often as they do.

    I remember speaking with GoDaddy a while ago when they started their managed hosting and they had the editor completely gone. For myself, this is no good.

    When time is a factor, it’s much easier to make a simple change in the editor (when you know what your doing) then to have to download, FTP, or take any other steps that begin to make a quick 5 second change into a 5 minute one.

    I’m glad they added that feature.

    Good post.

    Reply
    1. Ryan

      Thanks Jonathan. Access to the editor is already controlled by user permissions, but telling someone they can’t be an admin of a website that they own it kind of a tough sell. So I figure some kind of warning like “YO, THERE’S A GOOD CHANCE YOU’RE GONNA BREAK STUFF IF YOU PLAY HERE” seemed like a good middle ground to me.

      Reply

    2. Jonathan, the big problem with any approach involving the code editor on a live site, among other things, is that your local development version (which is a must for professionals) will then be out of sync with the live version.

      It takes practice with the workflow, but I can make a code change in <1 minute with Git. FTP only takes a little longer.

      Reply

  4. I’m not sure why it was ever included in the first place. It seems to be nothing but trouble to me. I can’t ever imagine writing code in that thing, and I certainly wouldn’t recommend it to someone else, let alone a complete n00b.

    I would go a step further, and totally remove it form WordPress. Existing users can be prompted to add it back via a plugin if they desire.

    I would also remove the plugin and theme installers too. Although I think the pitchforks would definitely be brought out for me then.

    Reply
    1. Ryan

      Yeah, I’m not entirely sure either. I suggested the plugin route on twitter a few nights ago and the pitchforks came out quick 😉 Some people really do see the need for it. I don’t understand it myself, but to each their own I suppose.

      Reply

  5. I tell my clients that for day to day management of their site, they should just use an Editor role and then I change their user to that. Then I make them a ‘developer’ User account and give them the password and tell them to use that if they need to do administrative things.

    I think it brings home the fact that if they want to do something a developer would need to do, they’re taking on a greater responsibility. I don’t think anyone has ever used it, they generally just call me if they need something done that involves code, or setup a maintenance plan to keep the site updated.

    Reply
    1. Ryan

      That’s a great approach and brings up another important part of the discussion, that we’re all responsible for educating folks about the “powers of the editor” and using best practices (local development, etc) too. Thanks for stopping by Kronda 🙂

      Reply

  6. Ryan-

    This is a good post, and while I still do not agree with you that it should get yanked from core, I do see your point.

    I sort of like the way Godaddy, does it but I don’t think thats adequate. I think it is a missed opportunity for a real teachable moment. Just saying “bad stuff can happen” isn’t enough. Using it as an opportunity to teach people about local development and testing servers would be a lot more effective in my opinion. Still, not fully human-proof, but it would be a better intervention.

    Reply
    1. Ryan

      Well, Josh… http://bit.ly/1ynj7oD

      Haha, but seriously. I see where you’re coming from completely. But for the type of work I do every day, I’m definitely anti-editor 🙂

      Reply

  7. I enjoyed this article and learned from it. Thanks to @Krogsgard for tweeting the link. I’m a relative WP newbie (although learning more every day). I like the screenshot from above (the GoDaddy screenshot) and it has my vote for the way to do with core.

    Reply
    1. Ryan

      Right on, Marcus. Keep digging in and learning. Happy to have you here!

      Reply

  8. I usually go Kronda’s way. But sometimes there are clients that simply don’t understand the different rights user typs have. They want complete control. I gave them .. and in 2-3 days they call me with: “Something is wrong with my site”

    If by default we can’t turn that off … I would love to have an plugin to disable the file editor for certain users. 🙂

    Reply
        1. Ryan

          Nicely done! Thanks for sharing it Cornel!

          Reply

  9. This is a case for user_has_cap.
    In response, I just created a plugin for this, but it uses filters rather than a UI:
    File Editor Control

    Fork, copy, etc, (and see my referenced article in the README)

    Reply
    1. Ryan

      ABOVE AND BEYOND. Gonna start messing with this now. Awesome work Mannie.

      Reply

  10. Agree on an opt-in, but actually, I can’t think of any case one should use the editor to make theme or plugin changes. It seems just bad practice to me.

    Reply
    1. Ryan

      Very few reasons to have it enabled, but I have heard of a few edge cases where it *might* be useful. Otto calls it “necessary”. *shrug* I do know that the current state is no good 🙂

      Reply

  11. Yes yes yes yes yes!

    One of the central paradoxes I see in the file editor’s existence is that:
    – Those who shouldn’t use it don’t have the skills to disable it.
    – Those who should use it do have the skills to enable it.

    That seems like a really good argument for at least shipping the default wp-config.php file with the editors turned off.

    Further more, when looking at the WordPress philosophy, it seems that the File Editor’s existence violates many of the core tenets including “Design for the Majority,” “Decisions Not Options” (there’s another long and tired debate…), and “Clean, Lean, and Mean.” From the first one:

    >Many end users of WordPress are non-technically minded. They don’t know what AJAX is, nor do they care about which version of PHP they are using. The average WordPress user simply wants to be able to write without problems or interruption. These are the users that we design the software for as they are ultimately the ones who are going to spend the most time using it for what it was built for.

    Where’s the file editor in that? And from “Clean, Lean, and Mean:”

    We are constantly asked “when will X feature be built” or “why isn’t X plugin integrated into the core”. The rule of thumb is that the core should provide features that 80% or more of end users will actually appreciate and use.

    80%!?!?!?! The file editor is plugin territory.

    Reply
    1. Ryan

      Maybe I should have had you write this post instead haha. Great thoughts, Mark and I 100% agree.

      Reply

      1. Haha. That’s a little generous, but I appreciate the sentiment! Btw, “should” in that second bullet of my comment should be in quotes…

        Reply

      1. I hear you, but if this was considered a serious security issue, it would’ve already been taken out. It isn’t, so, what’s the next best thing?

        Reply
    1. Ryan

      That’s actually not a terrible idea 🙂

      Reply

  12. The one use-case I know of is the client who only remembers his wp-admin login credentials, but not server/cpanel/ftp info. I’ve even had clients who didn’t know where the site was hosted. That kind of thing can usually be tracked down eventually but not always. And yes, I’ve had this kind of client quite a few times over the years. Mostly, though, I agree with the concept of discarding the editor or at least making it opt-in only.

    Reply
    1. Ryan

      Yeah, I’m sure that as soon as we remove it completely there will be some type of edge case that comes up for why someone somewhere needed it. Moving it that direction should definitely be the goal though IMO.

      Reply

  13. I hate the file editor too. Really hate it. However, even if you disable it, there’s nothing to stop an errant user or uber hacker from installing malicious scripts via plugins or themes.

    I re-purposed a lot of code, but I have a snippet that is opt-in for each user. It disables the editors, and also the ability to add plugins and themes. It also disables update notifications for when the client insists on admin access, but freaks out every time they see an update notification.

    You can check it out here: http://www.ronalfy.com/wordpress-selectively-disable-plugin-theme-editors-updates/

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *