Should Code Revisions Be Added to the WordPress Core?

What would you think about the possibility of WordPress being able to keep track of code changes made in the dashboard theme and plugin editors? Any mistakes you make could easily be reversed using the new revision viewer introduced in WordPress 3.6. Should this feature be added to the core? This discussion is currently on the table.

The idea was proposed by Alexander Höreth in one of the most controversial Google Summer of Code projects to date. His completed Code Revisions plugin adds native revisions for the dashboard theme and plugin editors.

Code Revisions plugin in action
Code Revisions plugin in action

I chatted with Alexander about his experience creating the plugin. He wasn’t surprised by how much controversy and discussion the proposal generated.

I expected it to be very controversial. It wasn’t the only project I proposed, because I actually expected it to be hard from a community point of view. The initial idea for the project was from Andrew Nacin from GSoC 2011. Back then someone actually already worked on revisions for the theme code editor, but he had a very different, more dev-focused, approach. While I expected the criticism, it still was quite heavy when I dropped my first post on make/core. But quite a few people also supported me so I did not have to deal with the critics all by myself.

Those opposed to the inclusion of code revision capabilities are concerned about possible security risks. Many developers who joined in the discussion are wary of giving users any access to the built-in code editors, given how easily an untrained person can break things when tinkering around.

Alex believes his plugin is a good introduction for new WordPress users who want to start experimenting with their code without having to worry about breaking something. “I think the code editors are an important launch pad for WordPress users (not developers) to get into touch with their site’s code base,” he said. “Using them is a first step on the way to submitting a patch to core in the future.”

The plugin has a built-in way for checking PHP files for fatal errors when updating them using the code editors. Alex said that this was one of the most challenging aspects of getting it all to work:

WordPress by default checks for fatal errors in plugins when they are edited or activated. The plugin was intended to enhance this functionality and also bring it to themes. I expected this to be easier than it turned out to be. PHP once had a function which was capable of doing so, but it was removed some time ago. So I ended up adding functionality which is not available on all hosts.

The decision to add Code Revisions to the core has not yet been made. Alex is hopeful that it will be included but he recognizes that there are many strong opinions on the subject:

I expect it to be quite a discussion and it depends on how much complexity it adds to core. Core is moving into a more modular direction. Therefore many people maybe will want to leave it as a plugin and don’t include it. The code revisions plugin was coded with the idea of staying as close to core as possible without adding new complexity to the user interface – it won’t be a big deal to include it into core.

Now that GSoC is concluding, Alex is working on working on a single page application, using a custom JSON REST API for his study in Cognitive Science at the University of Osnabrück. He said that he is really looking forward to the JSON REST API project being added to core.

The fate of his Code Revisions plugin has not yet been decided. The good news is that either way, none of this work will be lost. If you love the idea of code revisions and it never makes it into core, you can still use the plugin version. What do you think? Would you like to see Code Revisions added to the core? Do the benefits outweigh the risks?

20 Comments


  1. we have a proposal to add automatic updates to core, with the reasoning that it will allow rapid fixing of security flaws, and that is better than leaving upgrades to be checked by site managers on a testbed to make sure they won’t break a site.
    now its being suggested it may be worth adding further functionality that may increase security risks in core?

    seems inconsistent to me – I’d leave this as a plugin. Editting the code is probably not a requirement for the majority of users, and for those that want to do it it’ll probably be on a testbed machine anyway.

    Report


  2. The one advantage of this would be for the average user. There are so many tutorial blog posts that recommend changing or adding to the functions.php file to get some added functionality. Or to remove it. I see so many users following the directions, changing their mind, and then not remembering what they did. Just a thought.

    Report


  3. I tested ahoreth’s plugin a couple of times this summer and I’ve got to say that it’s everything I would expect core to do if they introduced revisions to the theme and plugin editors. It has the added benefit of preventing breakage while editing files, just like Core guards against activating plugins that would error out.

    That said, should code revisions be added to the WordPress Core? I say yes, but not yet. This is one of those features that should probably soak as a plugin for a while to gauge interest. However, It seems like a logical next step in the progression of unifying the admin experience for users.

    It’s important to remember that most non-developers probably have no idea what versioning is, so the idea of “cowboy coding” is beyond them. Integrating something like revisions in this space could prove to be nothing but a good thing for all involved.

    Report



  4. Isn’t this more of a debate about whether plugin/theme editing should be allowed at all? It’s already allowed by default and this plugin seems to improve on that, not make it worse.

    So from what I can see, the plugin is a suitable candidate for inclusion (assuming it is good code – I haven’t looked), but only if we continue allowing the code editors.

    I’ve never thought including code editors in core was a good idea. I’ve only seen that causing carnage, not solving any problems. But if it’s going to be there, then it may as well be made useful via a code revision system.

    Report


  5. @Ryan Hellyer – In the past I’ve found it to be really convenient when I don’t have FTP access for a site. But then again making any edits in the dashboard editors can be risky business if you don’t have FTP access. ;) I guess that’s where revisions might come in handy.

    Report


  6. @Ryan Hellyer – I was going to write about this not being a ‘great’ idea and that it should stay out of core then you went and made a great point. We already have this in core so we should make it safer to provide the best experience to most users (which aren’t developers of any huge experience).

    So I say add it but make sure we can just turn off the editors with filter. That may exist already, I just haven’t looked.

    Report


  7. @Sarah Gooding -I don’t think using FTP is very good idea either :P It’s horridly insecure.

    If I don’t have a secure way to edit files on the server, then I just don’t do it. Editing via the admin panel would scare the bajeesus out of me.

    @curtismchale -There are constants for turning the editors on and off. I always recommend turning them off. The worst situations I’ve seen are when clients are given access to their site as administrators and go on an editing spree and mess up sites they have paid lots of money to have built.

    Report


  8. I would prefer to see the editors pulled out of core and placed into a separate plugin, along with this revisioning system and a syntax highlighter. I’m not holding my breathe on that though.

    Report


  9. @Ryan Hellyer

    I would prefer to see the editors pulled out of core and placed into a separate plugin, along with this revisioning system and a syntax highlighter.

    Agreed. (I was thinking of adding a post along those lines.)
    When WordPress was used mainly by developers seeing what it could do, and didn’t have a mature plugin system and repository, then it made sense that editting capability went with the product. Its a bit ;) more mature now, and the percentage of users (even administrators) who will actually want to edit the core is much smaller. Rather than adding stuff to the core that is of use only to a smaller percentage of uses, maybe a better choice is to streamline the core by moving stuff that’s purely of interest to developers into plugins. If a user can’t find and install an editting and versioning system, maybe they’re not ready to edit a live system anyway.

    Report


  10. Admin code editing should be moved into a Plugin altogether.

    It remains in core because it scratches an itch of those who could otherwise decide to remove it – but that’s a double standard of the “80% rule” to which every other feature/option is held.

    Report


  11. @Chip Bennett -It’s also something which can easily be removed without causing any problems. It can be set to auto-install much like the importer did when it was removed to avoid confusion on the part of users.

    Report


  12. Like the core devs love to say, this is “plugin territory”. Is astounding that this feature, which not much common people will use, is being contemplated for inclusion in core while others ( see http://wordpress.org/ideas/view/top-rated ) are repeatedly ignored for years. Sad.

    Report


  13. I love the idea of this project. I just don’t love it as a part of core because I want to see the theme/plugin editor removed altogether for all the reasons others have stated above.

    Take the editor out of core. Mix it with this plugin. Create an awesome plugin for anyone who wants to modify code from their admin.

    Report


  14. Allow me to be the voice of reason….

    This is a terrible idea. The very fact that WordPress has a built-in code editor is a terrible idea. People posting saying that we should do things to benefit “Cowboy Coders” are wrong. People approvingly saying they like “Cowboy Coding” and could benefit from that feature are dumb.

    WordPress needs to be moving in exactly the opposite direction. Make it EASIER to be smart. HARDER to be stupid. Simple to use does not have to equal simple to be stupid. WordPress should encourage separation of concerns, a security-first mindset, and use of version control.

    People who don’t know how to write code don’t care if those things exist. But they’ll benefit behind the scenes. People who do know how to write code will be encouraged and incentivized to develop for a platform that is in bad need of good developers. And people who think features like this are a good idea will hopefully learn they are wrong. Either that or just stop writing code.

    Report



  15. Until the theme editor improves – that is – line numbering, ajax saves, editing of files in sub-folders, the ability to create and remove files etc.. until it becomes a decent dev suite, then the theme editor won’t be the code-editing method of choice for anyone who is proficient enough to develop themes. This seems like a waste of energy until the theme editing environment becomes more like an IDE.

    Report

Comments are closed.