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.
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?
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.