WordPress Code Architecture talk notes

I’ve presented the WordPress Code Architecture talk at WordCamp Netherlands this weekend in Utrecht and I got lots of positive replies from the local community members – thanks everyone for getting back to me! I’ve invested around 50 hours worth of time/effort in the presentation and I had to refactor it a few times until it gets to the point where it is now.

The slides are available here, and I’ll cover them with a few extra notes here.

Again, this is a personal opinion of mine based on my experience and observations over other frameworks, platforms, programming languages and general concepts. I had a hard time myself getting used to WordPress (coming from other areas of expertise) so it’s always been a hobby of mine digging into the codebase, testing other frameworks and languages, comparing features and opportunities.

I love WordPress and I enjoy working with it in any possible manner, even if I’m not a fan of PHP itself. For all of the zealot PHP evangelists, I’d recommend you to check out “PHP: a fractal of bad design” which is an elaborate and fairly straight-forward explanation for most of the reasons I don’t enjoy the language that much too.

Still, the performance gains one can see in PHP are a good thing, and some of its major cons (compared to other languages) could easily be turned to pros given the right project, context and approach. I’ve mentioned the stateless design of the language and the lack of multithreaded support, but despite of the terrible design pattern solutions (or object-oriented design) related to that, real-world project could easily scale better being built by the right engineers (which is the case with WordPress and the core team behind the project).

Another important thing is the PHP 5.2.4 support in the minimal requirements of WordPress, which would limit us from using namespaces, traits, late static binding and other dynamic expressions available in the latest PHP versions if we want to be as backwards compatible as WordPress is while building plugins for the masses. Check out ExoWP by Mike Schinkel as an example of a flexible design using some best practices in PHP 5.3+.

Unlike numerous frameworks and CMS systems, WordPress was also born from b2/cafelog, and is not inspired by Rails or based on an existing framework, or a popular architectural pattern such as MVC in general. In order to support a larger community (or follow proven practices), most systems try to incorporate the known patterns and extend a given community.

For example, CakePHP and ASP.NET MVC are heavily inspired by Rails, and several CMS were born on the top of those frameworks. Few years ago Joomla migrated to MVC for its components, and Drupal will introduce numerous Symfony-driven components in its core as a sign of acceptance and invitation to the Symfony community. WordPress started from a simple blogging tool that emerged into a CMS and even further to an application framework and a web framework extracted out of the CMS which is fairly innovative.

The slides cover several aspects of the architectural decisions in the frontend and backend, database support, media management and others, compared to other existing systems out there. Personally I think that even if it’s hard for most “existing developers” (i.e. developers coding for other web frameworks/platforms) to get used to WordPress (due to its design uniqueness), most of the decisions so far are fairly awesome and handle the majority of cases, even most edge cases as well.

The WordPress Multisite feature is also something I haven’t seen as well designed in any other platform out there. There is a “multisite” concept in Drupal, and in a few CMS based on Rails, CodeIgniter or CakePHP for example, and a multisite idea behind Django CMS, but none of them seems stable and automated enough compared to WordPress (check the Drupal guide as an example). The template hierarchy is also awesome, even though hard to grasp at first, and there are projects where layout-driven architecture might be better (IMO). Same goes for the user management, compared to regular ACL-driven frameworks (especially when it comes down to replacing the login engine and easily integrating OpenID, Facebook login and others).

My top three concerns of WordPress itself, architecture-wise (even if we can deal with all of them on a daily basis) are:

  1. Too heavily-coupled component core
  2. Lack of helpers – form ones, HTML, JavaScript in core
  3. Media management

More flexibility always helps, as in being able to easily switch to Oracle or even a NoSQL database, but then again WordPress powers 22% of the web and I’ve been spending most of my time with it for a few years now and it’s still the best option for me for the majority of the projects.

In essence, the more options we got – the better, and we better use the right tool for the job. More often than not it’s a great fit for a project.

3 thoughts on “WordPress Code Architecture talk notes”

  1. dsawardekar says: May 22, 2014 at 1:54 pm

    Great points.

    I’m not sure why WordPress doesn’t push for at least PHP 5.3. The number of documented vulnerabilities should be good reason to move.

    Of the 5.3 features, I think Namespaces is probably the biggest for me. Prefixing functions feels just wrong! Closures would be nice to have, but could probably live without them.

    Any idea if moving to 5.3 as the baseline is on the roadmap?

  2. Mario Peshev says: June 5, 2014 at 9:24 am

    Not as far as I’m aware of, this hasn’t been a priority lately although I’d love to see that move happening soon…

Leave a Reply

Your email address will not be published. Required fields are marked *