Sometimes, it takes a horror story to realize even the smallest enhancements can make the biggest differences.
My friend Lauren Rabaino updated a client’s site to WordPress 3.0.2, updating Twenty Ten in the process. She was using a child theme, but had been accidentally making modifications to Twenty Ten instead, because the theme editor shows you the files of both themes at once.
She was forced to redo some work, even though she believed — and rightfully so — that she was doing everything right.
This really bothered me. I spent a long time with the theme editor over the summer, but too little of it was ready for 3.1. (I plan to revisit it all for 3.2.)
At first, I suggested a quick fix in the form of a small warning. But talking with Jane Wells led to a series of small enhancements that make the theme editor experience just a little bit better. Every incremental improvement counts.
I ventured to WordCamp Savannah this weekend. It was an awesome group of people, and even with my WordCamp schedule (see the sidebar) growing, it’s going to be a really tough event to top.
I spoke three times at Savannah: two presentations (both posted below), and I sat (stood?) on a core team Q&A panel with Matt Mullenweg, Jane Wells, and Mark Jaquith.
The first presentation was Contributing to WordPress. With a few core contributors and a solid group of developers in the audience, I had to kick it up a few notches once I got going, but I think I adjusted that well.
In the second presentation, I presented the goals of my Google Summer of Code project, theme revisions. I received some great feedback from Mark (on FTP integration), Matt (on SVN integration), and many others. I also confessed that my first experience three years ago was with the file editor, in version 2.3.2. It hasn’t changed much, but I tried my best to convince the crowd that a lot more could be done.
Daryl Koopersmith also showed off his visual theme editor, and John James Jacoby demonstrated EventPress. We also discussed scribu‘s project that is now soaking in WordPress 3.1-alpha, and Justin Shreve‘s project on the ideas/suggestions theme.
Thanks to some Google Summer of Code proposals, there have been some conversations on the wp-hackers list about roles and capabilities, and how we can improve them. It’s important, though, to understand exactly what the current API allows — it’s much more complicated than many realize.
Here’s how an end user generally sees it:
A user can be given one of five roles: Administrator, Editor, Author, Contributor, Subscriber.
There’s much more of course behind that. Hopefully, a developer just getting started with WordPress does not notice the long-deprecated user levels. If all goes well, budding developers will also realize that:
Each role is made up of a number of capabilities, such as manage_options (only for Administrators), moderate_comments (for Editors and Administrators), and edit_posts (for Contributors, Authors, Editors, and Administrators).
Of course, a more experienced developer, or a blog administrator who has downloaded one of the various capability/role management plugins will also realize that:
You can create roles and give those roles a set of capabilities. Example: You can give the Editor role the activate_plugins capability.
You can grant individual users a specific capability that their role does not otherwise give them. Example: A user with the Editor role can be given the activate_plugins capability.
A user can have capabilities removed from them, negating capabilities they would otherwise have through their role. Example: A user with the Editor role can be stripped of the unfiltered_html capability.
But wait, there’s more:
A user can have more than one role. Thus, a user could have both the Editor role, and the Administrator role. (Since all capabilities in the Editor role are also in the Administrator role, then this example would have no effect.)
This last one is not supported by the core WordPress user interface. No publicly released plugins use it (that I know of). In fact, the main use case would be for a membership plugin (which is, incidentally, the rare use case for using your own table).
The problem is, this system cannot scale well due to the overhead. But, since most of our performance woes are from features that aren’t used, the best solution is to remove those features.
A diagram of the complexities of the roles and capabilities system. Right, the proposal currently on the table.
The current consensus — see Trac ticket #10201 — would be to eliminate user-specific capabilities (both additional capabilities, and negation), and we would force users to have only one role.
It would be an admission that the current roles/capability system, in a desire to be leaps and bounds over the original 0-to-10 user levels, went a little too far.
In a later post,* I’ll talk about the schema — how we store roles and capabilities now, how we may store roles and capabilities in the future, and how we’ll bridge the two on an upgrade. Some alternatives should also be discussed, but in the context of the schema.
* While drafting this, I’ve also been replying to that wp-hackers thread, so my thoughts on most of this are already out there.
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.
