Back in Drupal 5...

It's been a long time since I've looked into Drupal, but it's still a very popular platform. When I first touched Drupal, it was in the context of an "old" site that had been in operation since before Google debuted in '98. Even then, it was running on an outdated version of Drupal, version 5. The easiest way for me to learn the framework was to understand the request lifecycle.

Drupal 5 (and Drupal 7 for that matter) had no concept of object oriented programming at all. The entire framework was built off function calls and callbacks. Migrating from 5 to 7 wasn't exactly effortless, but they did share the same fundamental, basic structure.

So...it's been a while and I won't claim to be a Drupal expert, but I am curious about how things have changed.

Why Drupal, Anyway...?

Like many pieces of software, Drupal was first started as a personal project. Hell, PHP itself was first started as a personal project! From a modern perspective, there's merit to the idea that something like a CMS is better powered by technology other than PHP. So why is it still so popular?

In my opinion, the difference between technology stacks is usually centered around three very important ideas in software engineering: concurrency, typing, and ecosystem. Yeah, PHP has one of the worst models of concurrency and that's why its popularity has suffered since 2009. Yeah, it's an interpreted language so compilation happens with every request.

However, it has a massive ecosystem of projects that have greatly evolved since their early days, including Drupal and Laravel. I think as engineers we tend to underestimate the real value of ecosystem; it can absolutely be more important than technical performance. Maybe this is a topic for another post, but it does frustrate me when engineers talk about how bad PHP is because it has a simple model of concurrency (unless you're talking ReactPHP, which has a similar non-blocking I/O model as node) and is an interpreted language.

Performance is not just an engineering concern, it's' a business concern. Sometimes the better choice is to run less efficient software to build a product faster...realistically, is hardware really more expensive than the opportunity cost expended inflating dev time because of less robust ecosystem? Probably not.

Familiar Bootstrapping

If you've ever looked at Laravel's source code, you'll notice it uses Symfony components. Starting with Drupal 8 and beyond, the Drupal developers opted to also use Symfony components. Hardly a shock; just about every major PHP framework uses Symfony components: Magento, PimCore, CakePHP, even Google and Meta SDKs.

Much like Laravel's bootstrapping, Drupal has the same general steps (as you can easily follow from the normal entry point, index.php). It initializes autoloaders, sets up the service container, then creates the Symfony-based request object and dispatches that request. It even happens in about the same order. Clearly, Drupal is no longer a purely procedural, functions-based framework.

The meat of the bootstrapping process occurs in the DrupalKernal class (/lib/Drupal/Core). There's a lot to this, but you won't find a lot of surprises, here. Like with Laravel, this is fairly boilerplate setup and a lot of it is focused on the service container. While I think the Laravel version of bootstrapping is cleaner, having this understanding means we can expect similar levels of features and functionalities.

Also, Drupal is...old. Laravel was meant to be an MVC framework from the start...Drupal used to be nothing more than functions with no notion of objects. In other words, legacy support is a real mess. Looking through the code, you can see comments about legacy support. The entire lib/Drupal.php file is dedicated to legacy service container support.

That's not my favorite thing to see in a framework, and it makes me think that "things will get worse before they get better" as every major version introduces wider and wider gaps between old versions and new, requiring ever-more lingering, legacy code.

Drupal 7 is still alive...?

Speaking of legacy, Drupal 7's end of life has been pushed back a few times thanks to its enduring "popularity" ... if I was migrating to "new" Drupal back in the 2010s, it's (almost) surprising that Drupal 7 still has so many people using it. The end of life is now in 2025, despite the "original" end of life being set for 2021. Actually, it's not a surprise at all that people are still using Drupal 7, because for all its great features, Drupal is not a framework that cares much about breaking changes between versions. I mean...we're talking about going from a framework that's 100% a collection of classic functions to finally using OOP in 2015...of course it isn't as simple as clicking "upgrade"!

This is where I dislike Drupal -- if you're going to develop a complex application with it, you'd best use the latest version, because there's a chance you'll be locked into it indefinitely. If Drupal truly needs people to upgrade, they need to pay more attention to breaking changes.

MVC vs. PAC

Working with Laravel, you will learn about the MVC philosophy. Drupal isn't an MVC framework, it's based on "PAC": presentation, abstraction, control. At first glance...this seems like it is annoyingly the same exact thing as MVC with a slightly different acronym. Presentation is the same as a view, abstraction represents the retrieval and processing of data (okay, a model), and control...do you think it might be the same idea as a controller? Oh, it is!

PAC was developed in 1987 (MVC was introduced in 1979), but it isn't as widely recognized or popular. Forget about the acronym. The acronym is useless; it breaks down into the same concepts as MVC.

The main difference between MVC and PAC is the way these concepts are structured and insulated. In PAC, "models" (abstractions) don't communicate with the presentation layer, ever -- that's not true in MVC, where views do have access to models. In PAC, all communication happens via the controller. PAC has an agent-based focus, where each agent is a triad of presentation, abstraction, and control -- and as mentioned, these triads can only communicate via the control layer.

Curiously, one of the often-cited reasons for implementing PAC is the way in which it can enable multithreading, as multiple agents can run in parallel in different threads. This is irrelevant in the context of PHP, which is single-threaded. Every PHP process already has its own isolated memory. Maybe there's low-level details I'm missing, but PAC in PHP wouldn't have better concurrency than MVC.

But Technically...

The technical delineation between MVC and PAC is honestly not that important. It's easy to get mired in terminology and dissect exactly what is or isn't "technically" an MVC, and it really doesn't matter. Is Drupal a "pure" PAC? Is Laravel a "pure" MVC? Meh, probably not, but who cares? What matters to me is understanding the rationale behind these architectural philosophies. There's about a dozen-odd other "flavors" iterating on similar themes like MVVM or MVP or ADR or HMVC. These are variations on a theme; it's good to understand the difference, but also taken with a grain of salt because these concepts can overlap.

Conclusion

Drupal has changed a lot over the years, from being a long mess of functions to finally embracing OOP and Symfony in Drupal 8+. I may do a deeper dive into Drupal because it is still widely used and popular and I'm personally interested in learning more about the ins-and-outs of PAC architecture compared to MVC.