WordPress 4.9 Protects Users From Fatal Errors Created in the Theme and Plugin Editors

Over the years, there have been many discussions and debates on whether or not WordPress should have a built-in file editor for themes and plugins. The file editors, while convenient, allow users to easily trigger fatal errors that can be difficult to fix, especially if they don’t have FTP access.

Instead of removing the editors from core, the WordPress development team has enhanced them by adding fatal error protection in WordPress 4.9. When a user accesses the theme or plugin editor for the first time, they’re presented with the following warnings. The warnings are a result of a three-year-old trac ticket.

Plugin Editor Warning
Plugin Editor Warning
Theme Editor Warning
Theme Editor Warning

If you try to save changes to a file and WordPress detects a fatal error, the change is not saved and a warning message is displayed that explains where the error occurred. Although the changes are rolled back, the code in the editor is not replaced with the original. To replace the code, simply refresh the browser tab.

Fatal Error Detected
Fatal Error Detected

In addition to safety features, the code editors are powered by CodeMirror, an open-source, JavaScript powered text editor that adds features such as line numbers. The plugin editor includes the ability to look up documentation for filters, hooks, and actions with many of the links pointing to the new WordPress Developers Resource site.

Even with the addition of CodeMirror in core, the file editors in WordPress are not a replacement for an integrated development environment. However, the warnings and fatal error protection are huge improvements that will prevent many users from creating a White Screen of Death situation on their sites.


45 responses to “WordPress 4.9 Protects Users From Fatal Errors Created in the Theme and Plugin Editors”

      • Another reason for blocking the file editor is so that someone with the right privileges (aka hacker adds themself as admin) can’t also add malicious code.

        Exactly! This should be considered, first and foremost, to be a security issue. So the proposed changes utterly miss the point.

      • Exactly! This should be considered, first and foremost, to be a security issue. So the proposed changes utterly miss the point.

        No it doesn’t, the changes adress the issues around people editing their files through the built in editor, not security. The argument of whether it should be in core or not due to security issues are a different issue altogether.

        Currently WP Core has decided to keep the editor and that makes this change a good one. The security issue is a question if the editor should be in core or not, not about the quality of the editor once the editor is in core.

      • @Kristian,

        It is not only a security issue, it is also a major one. The only sane way to work with this feature is to have the code files writable, which means that any security breach can modify your theme and plugins, and once it is done good luck detecting it and recovering from it.

      • @M

        1. This is web security 101. No one except for an admin of a server should be able to change the code running on it. That simple.

        2. After you were hacked no update will help you

        3. Have you ever read this https://wptavern.com/display-widgets-plugin-permanently-removed-from-wordpress-org-due-to-malicious-code? The idea that that some plugin author might have sold the access to his plugin, or they were phished from him, should keep you sleepless at nights.

        4. And it is not only malicious people which are the problem… how many sites went broken after update to version 3 of ninja forms, yoast and woocommerce (guess 3 is unlucky number in wordpress plugins)

        5. And even without bugs, in one of my plugin I removed support for php 5.2 guess what happened to people that auto updated.

        Auto updating is one of the things that seem like a nice idea on the surface but turns out they have horrible security implications.

      • @Mark,
        I happen to agree with each and everyone of your points, however, my point is that if you remove the editor and let the plugins and themes upload and update functionality, then that is pointless.

        This brings us to, should we also remove those ? Pretty easy for me to say “Good Luck with That!”. Reasons ? I will give only two:
        1- Users and developers are used to it and they will eat you alive before they let you do that.
        2- Do that and “Ease of Use” will go to 0.1% and you will have ended WordPress overnight, Period.

        So to wrap this up, your arguments about the editor also apply to this functionality and since there is no way in heaven nor in hell to enforce them here, they become baseless.

  1. I am definitely not the only one who is guilty for doing bad things with the integrated editor in the past, causing a white page of death by just forgetting a closing semicolon.

    Often, you know exactly in which line something needs to be fixed but creating a whole new staging site for a one liner … nargh … so you fire up the integrated WP editor even though you know it’s not a good idea.

    You make your change and your cat is jumping on the keyboard in the moment where you press the save button:)

    It’s so easy to break things not only by non technical users.

    So i really welcome this new feature.
    For bigger tasks i highly recommend to use a staging site, though.

    WP Migrate DB or WP Staging make this simple.

  2. There is no good reason why anyone should be live-editing your custom theme or plugin files via the WordPress dashboard. I think this is a much-needed feature to “protect end users from themselves”. However, I will still continue to disable the plugins and theme editor anyway, since it is also a security vulnerability hackers can exploit. (I’m anal about security :-))

  3. I personally welcome this! As a plugin author that does support on remote sites, while rare, it’s nice to sometimes dump a variable in the code to help debug edge cases without ftping into the site. Nice to see a safeguard put in place if you make a syntax error.

  4. Interesting, Drupal a very much more secure platform doesn’t allow you to edit files like this through a browser at all. Instead you need to use SFTP or other method.

    I think WordPress should ditch the old method of editing in the browser, especially in the new WP 5.0 vision on the horizon.

    People can hire a coder, it is what we are skilled to do.

  5. Honestly, while that’s nice, I think the #1 feature that ought to be improved, when it comes to customization of appearance, is: WIDGETS EDITING.

    At the present time, with one wrong mouse move, it is possible to send to oblivion entire widgets with their contents, and there is NO restoring them, no “undo” feature.

    It is also possible to save, delete, update the contents of widgets with just anything, and if you screwed up something, you’re in muddy waters, as there is no going back.

    Frankly, I’m getting cold sweat every time I must update widgets on a wordpress blog. Making sure I have a database backup, copy-pasting into save files, triple-checking I don’t make wrong drag and drops…
    Nothing in wordpress gives me negative vibes like that – nothing.

    Here’s to hoping that too is improved in the future :)

  6. I don’t get why they are encouraging non-devs to murk around in their template code.

    WordPress team has always come back with “this functionality can be created with a plugin”. Then they add this b.s. to the core. Yet we cant select what pages a widget is published on without a plugin. WTF?!?!?!!?!?

    If you cant use FTP and a code editor you have no business changing anything in your code.

    • Let me actually give you a good reason because I am sick of all the people saying what others shouldn’t be allowed to do, they sound a lot like religious people…

      I am a dev and sys admin and part of my security measures is that I don’t set an FTP server. So when I need to make some small edits or tweeks to whatever plugin or theme, it’s easier for me to just enable the theme and plugin editors and hack away.

      Till now, when that provoked a fatal error because of some forgotten semicolon (and I always know exactly where I forgot it), I had to locate the file manually through the terminal and edit it in there. So these new Fatal Error check and reversal features are very welcome. Actually, when I started with WordPress, I felt like there was some sort of false advertising because I read that it would disable/deactivate a plugin that caused a fatal error but it did not.

      • “I am a dev and sys admin and part of my security measures is that I don’t set an FTP server. ”

        Oh god. First off, anyone worth their dev credentials uses SFTP. Second, you have to have some way of deploying from dev/test to live. If you develop ON live, you lose all credibility on being a conscientious dev.

      • @Rick,
        I just don’t use FTP, be it SFTP, FTPS or whatever other variant of it.

        Also, I have two kinds of projects. Those which are critical and those which are less. The first kind needs a whole set of measures and reviews before pushing anything live and most (potentially) dangerous features of WordPress are disabled on that. The other kind is less critical and there is less bureaucracy with it.

        And my point here is that most of WordPress users use it for the second kind of projects, otherwise, WordPress wouldn’t have this much marketshare. And this kind of projects gains from having WordPress easy to use by keeping the bureaucracy to the minimum necessary.

        Apart from this, I will not discuss my security measures any further on this comment thread, I brought this just as an example and I don’t feel like explaining all the logic and reasons behind them.

    • Well @M

      1. You should never play “code monkey” on a production site. All your changes should be first tested on test enviroment, in which case it is actually much harder to move the changes to the production by the editor

      2. You should never change the code of plugin and themes you have not wrote, as the next update will remove your changes.

      3. The new feature actually have no way to predict what will WSOD some page on your site, it can just protect against bad syntax. But just being good syntax do not mean that your code will not break essential page like the cart page, or contact forms. Which is why point 1.

      4. revert? I already know too much about wordpress code, I will try to avoid knowing what bad assumptions were done for this kind of feature. The only revert should be from your backup

      5. If you need to modify several files together, you can’t. You can only one by one which means your site is in unstable state during that time. If this unstable state can have an impact on how things are stored in the DB…. well I will wish you luck with recovering out of it.

      • You see @Mark ?

        You are guilty of that same sin again…, you assume I don’t know what I am doing and when to do it. Of course there are cases where you should not use the editor at all, but there are others where it’s much more convenient than going through the process of uploading a plugin.

      • Oy @m.

        All people that overly abuse alcohol, chocolate, drugs and gambling claim that they can just stop and not let it get out of their control, when the reality is that the only sure way to “stop” is avoid starting in the first place.

        It is software development 101 to keep track of all you changes in some sort of “Git”, including comments about the why of the change. Obviously you can not do it with the editor, so what you say is that you love to being an php hacker and do not want to upgrade yourself to be a proper software developer. Which is totally OK, but it is best not to pretend that it is good in any way.
        There is just no real scenario in which a code change need to be done so fast you have no time to open an FTP client and a proper editor to do it.

      • Well, M, you don’t explain yourself, you act like you have some super-secret method that’s just TOO CRITICAL to talk about and frankly, every person I’ve run into who talks like this has some process that’s 8x more complex and fragile than they think it is.

        I don’t CARE how you deploy. If you edit code on a live server you’re doing it wrong. Period.

      • Hey @Rick,

        I have directly replied to you in the subthread above.

        And even though I said that I wouldn’t discuss this further, let me add this to address your latest concern:

        Yes, the process is a “bit” more complex but its strength doesn’t lie in its secrecy, I’m just not motivated enough to go into details, but to simplify it quickly, there are two kinds of projects I work on, the critical and the non-critical. For the non-critical I can do as I explained in my other comments, but for the critical project, I can’t do what I want as I want. In this critical project, the editor is disabled and in order to apply any edit, you can’t even use FTP or any variant of it as you need to connect to an other server and from there connect through SSH (you can’t make a direct SSH connection from your machine to the production server).

  7. When you give user a tool that can potentially mess up their websites, they will use it to mess up their websites, with or without warning.

    Honestly, how many people will actually read through the warning before clicking “I understand”?

  8. Well this is cool. Obviously fixing your site when you caused a fatal error before wasn’t that big of a deal, but this’ll save you from having to get into your site via FTP and undoing whatever the heck it is that you did to break your site!

    Not that I’ve ever done anything like that or anything… ;)


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: