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
A project on theme revisions is something that has been on the official WordPress list of ideas since last year. My proposal would put this idea on steroids.
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.
I really like this idea – I can see it being incredibly useful all round. I can’t comment much from a technical perspective, but as a concept I love it.
Sounds great! I’ve actually been building something similar that would replace the WordPress Editor. The work I’ve done so far is improving the editor itself and created a child theme generator. I haven’t worked on revisions yet, but that shouldn’t be too hard.
Let me know if you want to work on this, and what’s the deal with codePress?
CodePress is a real time syntax highlighter. Despite the name, it is not part of the WordPress family. It had browser compatibility problems and is no longer actively developed, so it was very short-lived in core (in 2.8, out 2.8.1). I’ve added a link to the SourceForge page.
When we previously talked about this, we talked about using post revisions and a custom post_type for this, and figured that’d be the best way to do it. I’d personally like to see the editor be a unified system, capable of being pointed at theme or plugin files, perhaps with something like a flag that would say “enable revisions on this document” perhaps? Syntax highlighting (and perhaps even a basic toolbar, depending on the document type?) could make things a lot more useful there. I initially did the CodePress integration, bu then there were too many problems with various browsers. There are a bunch of other systems out there now, so perhaps one would make a more suitable starting point. Personally I think it would make sense for the “default” action of a theme editor to be that if you edit something that’s not a child theme, it create and switch to a child theme, then start editing that (or something along those lines).
Sorry for the rambling comments, just dropping some ideas here 🙂
Those are some great thoughts, thanks! In order to support new features, the file editors will need a better UI anyway, so merging them makes sense (though editing plugins gets messy). And the flag to enable revisions makes sense as well.
It may be tough to explain what a child theme is and how it works to users of the file editors, but the “default” action of generating a child theme for edits makes a lot of sense and was more or less what I was thinking. We’d probably want to display child themes in core in a more friendly way.
I was looking at EditArea earlier and it seems to have solid cross-browser support and appears to be in active development (last version Jan. 2010).
Speaking of that – I forgot to mention, I’ve used EditArea and was planning on switching the WordPress editor for that. It has some odd behavior though with certain actions (there are times where you have to disable, then re-enable syntax highlighting) the background text goes out of sync with the highlighting.. can be troublesome. That was… some time last year though, they may very well have fixed that issue. If they did, I’d compare that to a regular text editor in terms of capabilities for syntax highlighting. Would definitely be my first choice to use 🙂
I love the idea. If it would be possible to roll back disastrous theme changes, I’d be in heaven.
Shouldn’t people be using source control for this sort of thing?
I realise that some fairly non-tecchie people use the theme editor, but at what point do further extensions to it become silly? The logical endpoint of these kinds of additions is a web-based IDE, which doesn’t sound very sensible.
Including themes in the auto-updater, on the other hand, is a great idea.
Good questions.
Source control aside, those who rely on the theme editor often do not use FTP. (That, and hosts may not support it.)
A web-based IDE would be pretty cool, no? Really though, if you know what an IDE is, chances are you won’t be using the theme editor.
Does it get to the point where it gets silly? Probably. But I believe there’s a long way to go before we get there. Plus, we have the ability here to integrate this closely with templating, child themes and theme upgrades, all WordPress-specific concepts. A mini IDE for WordPress, if you will.
Regarding theme upgrades, they’re in core already. Look to 3.0 for most of it though.
Revisions could also be tied into SVN for those using it. Now that’d be a cool plugin built off this.
“I realise that some fairly non-tecchie people use the theme editor” – I don’t fall into that group – full out computer person here. Theme editor is basically all I use, not entirely sure why at the moment – but for some reason I just like it more than editing the files directly, and would like it even more so with better support/features 🙂 Especially with a version system built in, would be the best for me.