Decoding Drupal: Navigating the Product-Framework Spectrum in Web Development

Fast Forward to Today

The Internet has evolved a lot since the introduction of Drupal 8. But then, so has Drupal itself.

Part of the development of Drupal 8 included leveraging the test suite (largely introduced with Drupal 7) to basically rip out and replace a lot of Drupal’s own internals, and make them more object-oriented. This, in turn, was intended to make the upgrade cycle from one major version to the next less painful. It is true that the upgrade process from Drupal 7 to 8 was a very significant lift, but, from Drupal 8 onward, upgrades have been rendered almost trivial!

Today, with the recent release of Drupal 11, the vast majority of that movement away from that Drupal 7 world has occurred within Drupal itself, but a significant number of Drupal sites are still on Drupal 7. In parallel, we’ve seen an explosion in the popularity of comparable projects like Wordpress, which takes that product approach and runs with it.

Now that Drupal core has evolved into the powerful framework it is today, the community is no longer faced with an either-or choice. We can, in fact, have our cake (Drupal core) and eat it (Starshot) too.

Starshot: Blending Framework Rigor with Low-Code Ease

Recently, Consensus colleagues Dan Friedman and Brian Sharpe had the chance to talk at DrupalCamp Ottawa about the promise of Starshot. Starshot represents a shift in the Framework-vs-Product conversation, bringing the best of Drupal’s framework into the product development arena. We see this as an opportunity for Drupal to say to those smaller organizations: “We’re going to build something that works for you, for the skillset that you actually have.” In short, “Kill the Webmaster” has become “Low Code/No Code”.

We think this turn toward simplicity and product focus provides some very exciting opportunities.

Automatic Updates will provide an upgrade process that doesn’t require an entire devops team to keep running. Behind the scenes, the Drupal infrastructure team is integrating software supply chain security into their packaging pipeline. The Drupal Association has sponsored the development of a Composer plugin and Rugged, the server-side component developed primarily by our colleague, Christopher Gervais. As a result, out-of-the-box Starshot (and Drupal 11) will provide users the confidence that the software they have requested is in fact the software they are receiving.

Project Browser will allow users to manage installed modules and themes. Because this involves downloading new code into a running site, it has the potential to be insecure. Here at Consensus, we’re also developing Aegir 5, a self-hosting platform in which it will be relatively simple for the user to temporarily grant access for this task, then re-secure the site, from outside of Drupal itself. Other hosting providers will likely follow suit.

Drupal core will be free to streamline the “framework” even further. Its modular approach allows us to selectively enable only the components we need, like choosing not to use Node when it’s unnecessary. This gives us the flexibility to build custom tools and configurations without relying on every part of the traditional Drupal components, tailoring the CMS precisely to our needs.

Drupal as a Product Development Platform

Most of the previous items are “behind the scenes:” folks responsible for maintaining a site wouldn’t normally interact with most of them on a regular basis. Where things start to get really interesting is in seeing Drupal itself as a product development platform.

Typically, a Drupal site is made up of:

• Drupal Core, providing base functionality;
• Community contributed modules, providing additional functionality; and,
• Themes, granting control over the site’s look and feel.

Install profiles, which do all of the initial setup, get us to the point where we have a site that “does a particular thing” – they have always been the thing that we think of at Consensus when we think of a Drupal site being a particular application. But, there are a set of limitations on install profiles that have, historically, held Drupal back from being a product-oriented platform. For example, crucially, once you have installed a site using a certain profile, you can’t shift to a new one (via profiles alone – you need to involve migrations, or other mechanisms). So, if you offer a service that has Bronze, Silver and Gold packages, you can’t move a given client site from one “level” to the next via install profiles alone. They don’t, by themselves, provide a long-term maintenance or sequential migration strategy for any given web site “product.”

In the course of various development projects at Consensus, we’ve had to come up with strategies for automating import/creation of various classes of data, including demo content, default content, test content, and so on. So we’re excited by Recipes that provide simplified content import, among other “low-code” (YAML only) interventions. This provides possibilities for getting past the limitations of install profiles.

Another interesting inclusion in Starshot is the notion of a single-directory application, that further integrates 3rd party tools (javascript libraries, and so on) into a Drupal application, with minimal developer intervention.

All in all, we see Starshot as a tremendously exciting and fascinating next step in Drupal’s evolution toward a product development platform. We look forward to supporting it, both through our ongoing work with the Drupal Association, and our continued work on Aegir 5.