Sarah and Jeffro over at wptavern.com are talking about WordPress 3.7 and my recently completed Code Revisions Google Summer of Code project. For the Code Revisions part start listening at around 11 minutes in. Jeffro is struggling quite a bit pronouncing my last name.. Well, german umlauts!
My Google Summer of Code project at WordPress, Code Revisions, finally is available in the WordPress.org plugin repository. It is not final yet, but close to. The whole development process was and still is accompanied by weekly posts on make/core. Features and bugs are kept track of on the WordPress gsoc trac. If you find a bug don’t hesitate to report it there.
Go get it: http://wordpress.org/plugins/code-revisions/
WordPress end-users mainly are interested in doing quick changes to integrate a plugin into their theme (main support question for my featured video plugin) or implement a bug fix they read about in the support forums for a not so well updated plugin. They should not need to know how to use FTP or external editors. Developers won’t, no matter how highly the WordPress integrated code editors are extended, rely on those for their daily development routine. Therefore I do not think it is necessary to blow up the code editor with features like GIT/SVN functionality or other fancy stuff full featured editors ship with. The WordPress editors should be quickly accessible for small changes and act as launch pad for to-be developers.
There are already awesome plugins out there to enhance the functionality of the code editors. Code highlighting, line numbers etc. But something, which is part of WordPress core since version 2.6 (according to wp-includes/revision.php), is not available for the code editors yet. Code revisions would be of high interest when something breaks after editing a file. This is one reason many users do not try editing code directly. When being able to smoothly go back to an older revision this concern would be arbitrary. Post revisions got much attention in the WordPress 3.6 release cycle. I think it is time to bring them to the code editors.
Everything I propose here should be able to start off as a plugin. But I also think my approach to this would smoothly fit into core and would not add much new complexity because I want to stick to already available workflows.
My approach is to stick to the new revision viewer with a custom post type. When a file is modified the first time the plugin will add a new post to the database containing the current (new) state of the file. Furthermore a revision from before the file save is created. WordPress already ships with plenty of functions which should be also usable for a code revision system, as soon as we associate a file with a post in the database. A problem here is to associate a post in the database with a specific file on the server. This requires the creation of a UID from filename + theme/plugin slug + author for connecting posts with their corresponding files.
The new revision viewer uses backbone.js – while I am not native coding backbone I feel comfortable reading it. From what I got until now the new revision viewer code seems very flexible and should be nicely portable to a new code revision page.
A mentor native with the new revision management and backbone would be awesome. Other than that, I do not have any preferences here. I think nacin initially suggested the idea..?
Update: I got accepted to GSoC with this project! Follow the progress on make/core!