I am strongly considering applying for the Google Summer of Code with WordPress. As a core developer, I’m in a unique position, because a stated goal of GSoC is to increase participation in the open source community, recruit contributors, and identify possible future committers. (I’m also the only student on the commit team as far as I know, though Dion Hulse was a GSoC student for two years.)
I was not contributing to core during last year’s GSoC term, and I’ve only really thought about applying to GSoC in the last few months. In the end, the powers that be have said I am welcome to apply. With that out of the way, I now need to come up with a project. I’ve thought about it for a while, and I’ve had a few good ideas, but nothing that I feel I can stretch out over a summer. Problem is, a typical project — one that may span several months of iterations under normal circumstances — might be something I could complete in a caffeine-powered weekend.* A few people I spoke to said that’s definitely something I need to consider.
An Advanced Theme Revisioning System
The main focus would be to develop revisioning, versioning and snapshots for theme files (and themes themselves). Theme revisions would likely be stored as custom post types and assisted by the TextDiff engine, which we already use for post revisions. Those who do not use the theme editor, of course, would not see any benefits from this feature.
As part of the project, I would also aim to:
- Create a sandbox for a theme’s functions.php file, to prevent fatal errors (usually of the parse variety) that can take down a blog and make the admin area inaccessible. (Other theme files would not cause such calamity.)
- Have the grand unified upgrader identify when a theme has been revised. We would need to consider implications of an upgrade as it relates to revisions and a snapshot, i.e. this would potentially introduce a rollback option for theme upgrades.
That said, I have plenty of other ideas and considerations:
- Number of revisions to keep, when to store revisions, and the ability to take a snapshot of an entire theme.
- One-click child theme creation. A revisioning system is bound to increase the number of themes edited, which don’t bode well for theme upgrades. I would want to consider the encouragement of child themes in core, by providing for auto-generation of a child theme template.
- Consider related tickets, including subfolders of page templates, unwrapped text in the file editors, etc.
- Highly unlikely, but consider searching for a syntax highlighter to replace CodePress. We could consider using the SyntaxHighlighter package for file viewing (not editing) as well.
- Consider ability to display and upload theme images.
Some thoughts on project development:
- Planning: Hold early discussions with Jane Wells and the core development team on planned scope, user experience, and implementation. Later discussions would be one-on-one with designated mentors, with other consultations.
- Philosophy: Patch early and often, review early and often, commit early and often.
- Existence: I expect work to begin as a patch for the WordPress core. It may be decided that some of it belongs as a plugin instead (presumably a core plugin if we go that route). We can roll back commits as necessary and add hooks where we need them.
- Timeline: I would be aiming for work to be completed in the 3.1 milestone. If this project is backed by a plugin, it would be released for 3.1. If any features get punted out of scope, ideally the community would assist in additional enhancements in a future release.
So, what do you think? This isn’t a formal proposal yet, and I may abandon this idea for another in a week for all I know. I’d really appreciate your feedback.
* I don’t actually drink much soda or coffee. I simply enjoy late-night programming sprints.