Customized WordPress: Reasons for Doing It

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.

Published by

Aaron Brazell

Aaron Brazell is a Baltimore, MD-based WordPress developer, a co-founder at WP Engine, WordPress core contributor and author. He wrote the book WordPress Bible and has been publishing on the web since 2000. You can follow him on Twitter, on his personal blog and view his photography at The Aperture Filter.

2 thoughts on “Customized WordPress: Reasons for Doing It”

  1. I would love to find out how to use svn to maintain a whole array of blogs on different servers – so you add plugins and hacks and themes to the central version and have it displayed on all the blogs in the array. A to-the-point clear tutorial would be awesome if that is not asking too much of you!

    Thanks.

  2. Good series, Aaron! While I am an experienced svn user, I was looking for any hints and ideas I could pick up from you. I’ve been thinking about using svn:externals for a while for some of our internal libraries that we share between web apps. Your explanation of the use makes it clear that it is easier than I was seeing in the documentation. Thanks!

    One thing you should recognize about this series, while most people will never edit the WP core, it is a great example of how to use subversion. I did a similar series on my site, in recommending a svn repo for maintaining the entire code base for a web site. Then there are those that develop plugins or fix other’s plugins, like me. Makes it easier to provide diff’s back to the original author.

Comments are closed.