Template Versioning for WordPress

This is the “Template Versioning” idea from the GSoC ideas list.

I’ll build a versioning system for templates that will store different revisions for individual template files. This would be in principle similar to the post versioning system that is already a part of WordPress. Additionally, users will be able to save revisions for the template as a whole.

Whenever the user will make any changes and update a theme’s template file in the theme editor, a new revision for that template file will be created. The template file revisions will be displayed immediately below the theme editor when the user will be editing that particular file. The user can also, at any point, save a new revision for the template as a whole. The template revisions will be shown in the “Manage Themes” page under the heading “Revisions for current theme” so that the user can easily preview and switch to any revision of the current theme.

The Template Versioning system will consist of the following features:

  • Revisions for each template file

    Revisions will be stored for each template file. Whenever the user updates a template file, a new revision for it will be created. This will be essentially similar to the post versioning system that is a part of WordPress. There will be a single table ‘wp_theme_files’ in which the records of the revisions for each modified template file will be saved.

    In the ‘wp_theme_files’ table, ‘theme_file_revision’ will contain the revision number, ‘theme_file_type’ will indicate if it is the current version or a revision and ‘theme_file_content’ will consist of the template file’s content, besides other fields.

    The latest revision, will be stored both in the database as well as in the file system.

    Also, there will be a hook in place for when a template file’s revision is created. This hook can then be utilized by plugins to integrate WordPress with SVN, git or other versioning systems.

    Example Use Case:
    If a user has a SVN checkout of the theme, when this revision is created, changes will be automatically committed to the SVN repository.

    Here is a preliminary mind map: http://www.mindmeister.com/47136302/template-versioning-in-wordpress.

  • Revisions for a template as a whole

    Users can manually mark/tag important points in the lifecycle of a template by creating a revision for the template as a whole. This will be similar in concept to svn tagging/branching.

    Revisions for templates will be stored in a separate table in the database, ‘wp_themes’. An entry will be added for each new template revision created. ‘wp_theme_files’ will have a field ‘theme_id’ that will point to the revision of the template to which the particular template file’s revision belongs (if any).

    When the user chooses to create a revision for the template, all the template’s files’ latest revisions’ ‘theme_id’ field will be updated to point to the new template revision.

    When the user removes a template, all records of revisions for that template and template files belonging to it will be removed from ‘wp_themes’ and ‘wp_theme_files’.

  • Diff View for template files

    The user will be able to visualize the difference in code between any two revisions of a template file, similar to the way two revisions of a post or page are compared at the moment.

  • Diff View for templates

    The user will be able to compare the difference in code for two revisions of a template. When the user selects two revisions to compare, she will be taken to a view where she will see the template files whose revisions are different and will be able to compare their code by going into the diff view for those template files.

    In addition to this, she’ll also be able to preview how a particular revision of a template looks in a modal window (Similar to the current preview template feature).

  • Annotate a template revision

    User will be able to annotate a template revision at the time of its creation. The advantage of this will be that the user will be able to describe a particular revision, so that if she ever needs to turn back, she will know the significance of that revision.

  • Autosave

    Similar to the autosave feature when the user is writing a post, this project will also provide for an optional autosave feature while editing template files. Whenever the user is editing a template file, it will be automatically saved after a specific time interval so that the user doesn’t lose any changes in case the browser crashes or something else happens.

  • Clear template revisions

    Since template revisions will add some overhead in terms of additional storage requirements, users will have an option to clear all revisions or limit the number of revisions to a small number i.e. if the limit is set to 5, then, when the template file is edited the 6th time, the 1st revision will be removed and replaced with the 6th revision.

Work so far: I was able to brainstorm this idea with Thorston Ott who gave me several suggestions on different parts of the project. In addition, I have also looked into the implementation of post versioning to frame ideas for this project.

Plugin: I’ll approach this project as a plugin, since that way it’ll be easier for me to gather feedback from the WordPress community.

Potential Mentors

  • Thorston Ott: He has been really helpful and went through my proposal and offered his feedback. Also, we discussed code approaches and implementation details of the project. Both of us are pretty confident about the scope of the project since I will be able to reuse a lot of existing code.

Schedule of Deliverables

Since most of the mentors on WordPress are on a different time zone than me (IST), I would need to adjust my work timings to ensure regular interaction. If I am selected, this project would be my primary work activity during the summer, and I would be willing to move around my work hours to a happy setting for both my mentor and me.

  • April 20 to May 22 – Community Bonding Period. I intend to do the following during this phase:

    • Get acquainted with parts of the WordPress core that I will require to understand for my project.
    • Take a look at how versioning and diff views are implemented for posts in WordPress so that I can reuse code and maintain consistency.
    • Discuss my project’s implementation details with my mentor and publish my goals to gather more feedback from the WordPress community.

  • May 23 to 10 June – Build versioning for template files. This will include creation of a revision when the user updates a template file, restoring of a revision, etc.. Provide changes to mentor and community for review.

  • 11 June to 18 June – Diff view for template files. Provide changes to mentor and community for review. Bugfixes for last phase.

  • 19 June to 12 July – Build versioning for template as a whole. This will include adding revisions to ‘wp_themes’, restoring of a template revision, diff view and preview for template revisions. Provide changes to mentor and community for review. Bugfixes for last phase.

  • 13 July to 22 July – Implement annotation for template revisions and Autosave. Provide changes to mentor and community for review. Bugfixes for last phase.

  • 23 July to 2 August – Implement features like deletion of all records of revisions when the user removes a theme, add options, etc. Test all the above-implemented features and fix any withstanding bugs.

  • 3 August to 10 August – Buffer period to implement any left out features and refine the above features. Also, to complete any feature that crosses it’s deadline. Implement any bug fixes and improvements.

  • 11 August to 17 August – Testing of all the above features by the community. Implement any bug fixes and improvements. Code will be well documented and a video will be created of the working of the versioning system.

© 2010 Ankit Ahuja | WP