How WordPress Spoils Developers, I get the impression Brian is bullish on the future of WP. He’s right that we have a lot left to work on though, after 2.1 is out the door I think there’s going to be a ton more core development. Update: I agree far more with the developer-friendly bits than the “no room for anyone else” bits. If the latter arguments were true, WP itself wouldn’t exist and the fact that it’s never too late for something new is a point I emphasize in my talks a lot.
I am pretty excited for 2.1 . I do not really feel that it spoils developers if anything I think the dumbing down makes it more frustrating.
Hey, I’m not sure who you were referring to, but The NeoSmart Files is run by CG, but Brian 🙂
The main reason I’m excited about shipping 2.1 is that it frees us up to take on more ambitious issues for 2.2 Once 2.1 ships I’ll post my complete wishlist for 2.2, but I have a rough idea already:
– Malformed plugin protection: right now, activating a plugin that causes a PHP fatal error means that you have to fire up FTP and delete the plugin file. For 2.2, I want to conditionally load the plugin you’re activating, and only if it loads with no issues will it actually be activated. Worry-free plugin activation.
– Draft system: drafts are currently handled poorly, as are drafts by people without publish rights. If you have more than 10 drafts going (with many high-posting blogs do), it can be easy to lose track of things. We need a better way of presenting drafts to the user, and presenting “ready for publish” drafts by unprivileged users to the site’s Editor roles. It seems silly to support “Contributor” and “Editor” roles and “save, but not publish” permissions without some sort of framework to connect the features.
– Simple Role/Caps administration: the role/caps system supports features that WordPress doesn’t support (multiple roles per user, for example). This system needs to have fat trimmed, and basic administration functionality added. For sites that require comment registration, a “Banned” role would be helpful (disallows commenting, but keeps a record of the ban, where simply deleting the user would not).
– Integrated output caching: We don’t have to outright integrate a full output caching solution, but certain pages (front page, the feed, e.g.) would benefit from caching. Other things that take a lot of time to generate, like category trees, should also be cached until they change. No need to be more dynamic than we need to be. WordPress should identify things that are slowing the page down and attempt to speed them up through caching. It shouldn’t take a bunch of hacks and 3rd party plugins to make a WP install survive a Digg.
– Figure out what we’re doing with the preview: I’m thinking that making it part of the tabbed interface might be best. A tab-switch to the preview could trigger an Ajax autosave and then give them an up-to-date pixel-perfect preview, without requiring them to scroll back and forth.4
– Atom 1.0: I think it’s time. We can keep 0.3 for another version or so, of course.
– WordPress update notification: it doesn’t need to be fancy… it just needs to tell people that an upgrade is available and give them a link to download it.
– Plugin update notification: as a second (or third) update to the plugin directory (first iteration coming very soon!), we should tell people when their plugins have updates. Again, it doesn’t need to be fancy at first. Just a little note and a download link.
Mark, you’re on fire!
I’m probably most excited about the malformed plugin protection, integrated output cache, and plugin update notification.
Thanks for the link, Matt 🙂
I have a few ideas I would like to tack onto your list, Mark. I will have to touch base with you in email.
I, do vote for a better Draft handling – or a proper pipeline process for blog posts before they get published.
Until recently, I was running my blog alone, and I had no issues. But now that I have 3 more people starting to contribute to my blog, I find it a wee bit difficult to handle the drafts and the way I can set them up for future publishing.
When can the image handling (upload, resizing, thumbnailing) be addressed? I’m really surprised that the team isn’t interested in going a step further and making it optimal for photobloggers. There may be a lot of plugins out there, but it was halfway there with the image uploader – why stop?
I second everything on Marks’ list, and as Leanne said, the image handling seems ‘halfway’ — making the editor Safari-friendly would also be really nice.
Some kind of simple workflow for the completion of drafts would be good. A contributor could mark a post complete and this would then email an editor to tell them. You could also set it up so people could collaborate on articles, say ask someone to proof read the article before it is published.
Matt: I’m glad to see you address this better in the update. I’ve had that link open since I first saw it here, and I’ve been waiting for a moment when I felt like I could eviscerate it with my poison pen, for all the reasons you state. It’s understandable to be enthusiastic about WP, but that … went a bit too far. 🙂
What is the deal with those irritating popups about some bullish about semi-support for Firefox Beta was going to check out the piece in Safari. What year are we living in? 1999?
Anyway, I look forward to what 2.1 brings to the table. WordPress definitely has a way of saving time for developing sites.
Geof, sometimes when I do the quick link posts I forget I might be assuming a degree of context. Thanks for the benefit of the doubt.
Matt: Oh, the link was worth posting, because it puts the value of WP where it squarely lies: with a community of coders and users who have made it a priority to flay open WP for all to see. No community is without its faults—communities are made of people, and people are, well, human—but the WP community is a good one.
I don’t hold any of the rampant cheerleading there against you at all, to be sure. I don’t find you to be that myopic. 🙂