In this series, in which all entries are linked to at the bottom of this post, we have examined the technical implementation of creating your own WordPress repository. But we have yet to say why it might be worth it.
I’ll be honest, in most cases there is no good reason to do it. The WordPress core code is generally very good. Security issues happen but are generally addressed quickly. The code is light and agile and generally optimized. There are plenty of hooks for plugins to do weird things that you might not otherwise get WordPress to do out of the box, and if no hooks exist for some aspect of the core, it’s usually not a problem to get the development team to add them. So in most cases, there’s no really compelling reason to have your own WordPress repository.
However, there are a few scenarios where you might want to do this.
- Blog Network – The natural candidate for doing these things are blog networks. b5media is probably the predominant WordPress-powered network. Weblogs Inc uses their own custom platform (which of course is now property of AOL), Blogsmith. Gawker and Know More Media both use Movable Type. Some smaller networks do use WordPress however, and many mainstream media outlets such as the New York Times blogs and the Boston Herald blogs also use WordPress to power their own networks of blogs. Folks invested in WordPress on an Enterprise, or close to Enterprise level will have different needs for their blog software than the average user.
- Advanced WordPress Ninjas – The ironic part about me naming ninjas is that they don’t need this series. They already know how to do this and probably do this regularly for further development on the core, creating patches, testing patches, etc. But certainly, folks in this category could use a customized build of WordPress.
- Custom WordPress plugins/packages – Folks like Denis de Bernardy, who created the Semiologic suite might have interest in this. I’m fairly certain that Denis falls into #2 above, but folks interested in creating a suite of their own plugins for bundling with WordPress may find the need to fix dependencies or add your own hooks.
So there are very real and legitimate reasons for creating your own WordPress build. The issue is when WordPress changes versions and you grab the latest code, you’ll have to make sure you apply all the patches again and in some cases, those patches will have to be recreated if the WordPress code that is being changed has been changed between versions. I hope that made sense. ;)
Thanks for following this series. It’s been a fun one, if somewhat advanced technically. I’d love to hear your feedback on the series, so feel free to comment! I love comments.