Template Versioning: Week 4


So far this week I have:

  • Reorganized my repo and tweaked my dev environment further
  • Coded the VCSInterface interface
  • Began writing the default VCS (the custom post based VCS
  • Coded a bit of the revision class, but I may end up scrapping that class in favor of specifying additional VCSInterface methods…. that’s TBD once I have gotten further into coding the custom post based VCS adapter.
  • Written a few functions that will be useful for coding the custom post based VCS and other vcs adapters.
  • Laid the framework (written a function or two, created an array of VCSInterfaces) in order to facilitate the support of multiple VCS at one time
  • Created a few new tickets for the various components of my project.

Triggering Commit Upon Save

I’m currently finishing up what I hope will result in the successful trigger of a commit upon the user saving the file via the theme editor. Right now it’s a bit hackish but here’s how I’m doing it:

  1. In an admin_init hook, check to see that the current page is theme-editor.php and sing the $pagenow global, and to see if $_GET[‘a’] is set. If it is, that means the user has clicked the update button and you’re now on the new page.
  2. Enqueue a javascript file which will (hopefully) allow me to wait until the page has fully loaded and will then do a bit of ajax magic to post the file names to be committed to a php page . I pass the path of the file to be committed from my original php page to the javascript file via wp_localize_script. I do this because changes are not written to the disk yet, since I’m checking the page in the admin_init hook.
  3. The commit_action.php page calls the VCS adapters’ commit methods for the given files 
It’s funny how you get along one line of thinking and continue with it too far… now I’m just hooking into the admin_footer action hook and it works perfectly. Time wasted, lesson learned.If anyone has suggestions as to how I can make this less hacky, I’d love to hear them 🙂

The proposed filter in Trac ticket 16396 would be nice to have, and would render the above hacky way of triggering an automatic commit upon save of a theme file irrelevant.


Right now I’m considering the following questions:

  1. How should I deal with error messages from VCS including svn that say there are no changes since the last commit. Is this a problem I need to support with a main-plugin method such as has_file_been_modified($file_name) or do I leave it up to the individual VCS adapters? The answer to this should become clearer as I code the default VCS, but is worth a little early thought too.
  2. Should the plugin should support multiple VCS simultaneously. For instance could the user take advantage of both svn and the custom post based VCS? Right now I think that it should…. but if I support multiple VCS, then in the advanced mode UI do I let them select which vcs they wish to commit to or revert from, and how could I manage that without it getting messy?
  3. Is the advanced mode UI worthwhile? Would people use it, or would someone advanced enough to understand it just use their own workflow?