Normally, when you utilize Django’s built-in development server  from the command line by issuing the command runserver . Whenever you make a change to one of your site’s files, say your, the django runserver automatically detects that change and reloads the file.

However, there is a bug in Django 1.3 that will cause an error if an IDE tries to issue that same command without using the –noreload argument, which, as the parameter name indicates, prevents the Django runserver from autoreloading the files.

The solution is to make the following change to your django installation’s file:

The bug fix. Credit kmtracey. See

Now you can have a fully functioning runserver even if you’re using an IDE like yours truly. I hope this helps someone out there.


My new preferred way is just to issue the command python runserver from the terminal. I just leave the terminal open on one of my monitors so that I can see all the output from the runserver . This way I don’t have to go through the hassle of editing for every django installation. Yes, I’m that lazy 🙂 .


Idea Description from

Template Versioning (0)

WordPress saves post revisions, but changes to theme files are not recorded, though the presentation layer is sometimes just as important. Build a versioning system for template files within the theme editor.

For a starting point, see last year’s project, Andrew Nacin – Theme Revisions.

My Approach

I propose the creation of a plugin which would specify an interface through which various version control systems could be integrated into the WordPress theme editor.

Any VCS such as Git, mercurial, SVN or a database-backed system could be integrated into WordPress through the creation of “adapter plugins” which would conform to the interface specified in the API.

As part of this project, I will create a database-backed  version control adapter plugin based on custom posts as suggested by Dion. By creating a database backed plugin which focuses  on ease of use and simplicity, I hope to offer  the main benefits of  VCSs to even novice users who do not know what a VCS is.

The integration into the theme editor would be in the form of a basic interface and an advanced interface for power users who have experience with VCSs and understand version control terminology.

Wordpress Theme Revision Viewer

Mockup of the Advanced Revision Viewer

Advanced Theme Editor

Mockup of the Advanced Mode Theme Editor


  1. UI Integrated with Theme Editor
    • Basic UI
      • Automatically commits changes to a file every time a user updates the file.
      • Basic revision viewer
    • Advanced Mode UI
      • Revision Viewer (see mockups)
      • User decides when to commit, can commit changes to multiple files at once.
      • Commit button, prompts for commit message etc.
      • Displays revision information
      • Commit-Status Display (have you committed since page was updated)
  2. API for VCS Adapter Plugins
    • VcsController Interface
      • commit()
        • Commit changes to all files
      • commit($file_name)
        • Commit the changes to the file with name $file_name
      • revert()
        • undo all local changes since last commit
      • revertTo($revision)
        • revert all files back to the state in the revision
      • revertTo($revision,$file_name)
        • revert the file with name $file_name back to the state it was in the given revision
      • getRevisions($num_past_revisions)
        • get the last X revisions, return all revisions if num_past_revisions is greater than the actual number of revisions
      • getRevisions()
        • return an array containing  all the revisions
    • Revision Class
      • Revision($commit_message, $file_name_array)
      • getRevisionID()
        • returns an identifier for the revision- either a revision number or a hash
      • getCommitMessage()
      • getRevisionContent()
        • returns all of the files in the revision
      • getFileFromRevision($file_name)
      • returns the file with $file_name as it was in the revision
  3. Default Adapter Plugin
    • Database-Backed, uses custom posts
    • implements VcsController interface


Week 1


  • Setup dev environment
  • Determine schedule of milestones/deliverables with mentor
  • Explore code base
  • Learn about/play with custom posts
  • Research various VCSs and alter API design if needed

Week 2

  • Code interfaces, Revision class
  • Code a “dummy” adapter plugin to use in testing, get the UI to display the dummy values correctly

Week 3

  • Begin coding Default Adapter (custom-post backed)

Week 4

  • Finish coding default adapter
  • First deliverable ready

weeks 5

  • Add support for diffs to main plugin

week 6

  • Code UI for diffs in main plugin

week 7

  • Test/debug everything so far
  • Midterm eval

weeks 8 & 10

  • Test everything!
  • Refine UI

weeks 11 & 12

  • Further testing, anddebugging
  • Priority #1: Document everything extensively!

Anticipated challenges

  • Providing a simple, yet robust interface and Revision Object that can work with various VCSs given the differences among the VCSs
  • Making the basic UI simple enough for the most novice users to understand.

What I’ve done already

  • Met with Daryl Koopersmith, afterwhich time I completely redeveloped my proposal
  • Researched which PHP svn library to use and why
  • Posted a link to this description on wp-hackers mailing list with a request for comments.
  • Created UI mockups
  • Added a basic mode UI and made the initial UI the “advanced mode” as per feedback received via the wordpress-hackers mailing list
  • Asked a few WordPress users I know if they think this would be a useful feature (they all said yes)

Plugin vs Core

This will definitely start out as a plugin, with the hope of it becoming a community developed plugin. Eventually I’d love for it to be integrated with the core if it is lean enough to fit with the lightweight, less is more philosophy of WordPress regarding the core.

Potential Mentors

Daryl Koopersmith has expressed interest, and I’d love to work with him- during our discussion he provided a ton of very valuable feedback and really helped me hash out the idea and how it would fit into WordPress.

Aside from Daryl, since Andrew Nacin worked on a similar project last year I would also be particularly interested in working with him.

Closing Comments

Why I Want to Build It

Having recently spent a lot of time doing WordPress site admin for I quickly found myself frustrated that there was no integrated svn support.

While this is not as much of an issue for users who have their own separate workflow outside of the theme editor, even they could benefit from this plugin if they want to make a quick change to the theme within the editor.

For novice users or more advanced users who do not use outside editors, this plugin would represent a huge gain in productivity.

I set up a repository and put the theme under version control via command line but ended up not committing nearly as often as I should have given the magnitude of the changes I was making, and often found myself writing code as if I weren’t even using svn at all. In order to gain the full benefit of a version control system, it MUST be easy and quick to commit changes. When I saw the posting for this idea on, I was immediately excited- both to  undertake the project and to use it once it’s finished.

Relevant Experience

I’ve used Subversion for about 3 years now, and in that time I’ve come to know how indispensable version control systems are to streamlining the development process, especially when multiple people are working on a project. I’m well-acquainted with using subversion both via command line and via the Subversive plugin for Eclipse. In addition I have a decent amount of experience with PHP, and some specific experience with WordPress due to my role as an admin of

I believe that my experience thus far and my interest in the project make me the perfect person to implement this idea and make an important contribution to the WordPress code base.