If you pay attention to the open source or CMS community, you probably heard about the release of Drupal 8 last year. It was one of the crowning achievements of the Drupal community. Since its launch, there have been numerous articles, talks, and podcasts focused around when sites should begin to look more toward Drupal 8 (rather than Drupal 7).
I feel before I give my two cents on this that I should disclaimer: I started out in Drupal with a deep, deep love for core entities* from the front-end perspective. This includes blocks, regions, template files, and preprocess functions. Over the last five years (and more frequently in the last two), I have come to embrace the powers of Panels and non-core rendering systems.
This is a relevant note because at this point, Panels and other theme-layer modifiers are only in alpha status. Due to the large architecture shift there are many contributed modules that are still under active development. You can see the state of a fair number of popular ones on the contrib_tracker project or in a Kanban view (neat!).
Those statements aside, I still believe that...
...most websites operating at a average web-presence should focus on creating new sites (and porting over smaller ones) to Drupal 8.
My first production Drupal 8 site was NWASAP (launched to nwasap.com) and the biggest wins for me were thus:
- Core has THINGS!
- The $8 per month hosting is not crippling anymore.
- Theme adjustments become less confusing.
Core has THINGS!
If you are anything like me (see also: organized, OCD, giggly) then you probably had a standard installation profile for your starter Drupal projects. This often includes the important ones such as Views, CKEditor, Entity API, et al. Fairly straightforward and not at all a problem when it comes to actually spinning up a Drupal 7 site.
In Drupal 8, we get a lot of these goodies out of the gate and they are in core (meaning they just vibe at the same awesomeness as the rest of the core functionality). Some aspects that truly make the entire experience better is having Views and CKEditor available by default. A fair amount of the envy that I hear from Wordpress users is the ability to download Wordpress and have an effective, intentional environment for content managers to draft up their work. This is a significant step in the authoring experience for Drupal.
I am also a fan of the in-place editing and the way it has been implemented. You are not required to use it, but as you traverse your pages, you will see the ability to just quickly update a custom block or a piece of content. This has been amazing for myself and a couple content managers who cannot stop raving about this feature.
The $8 per month hosting is not crippling anymore.
The current NWASAP website is powered by your standard web hosting options (A2 Hosting, Site5, etc.). Theoretically, these options should be good enough for low-traffic sites that are simply seeking a web presence. When the NWASAP site was running Drupal 7 with roughly 80 enabled modules, it took around one and a half seconds to render a simple page. With a warm Drupal database cache, that increased slightly, but nothing extraordinary. Again, for a low-traffic site this is not the end of the world.
However, when we transitioned to Drupal 8 (not requiring a full bootstrap and being selective with Big Pipe caches) the page load is roughly 700ms and as low as 400ms on a cached page. This is much faster and they have heard several good things about how their site is performing.
Theme adjustments become less confusing.
Do I need to do that in a preprocess function or a process function? Is that a template or a theme? Maybe even just doing a Views field rewrite?
Drupal 7 had a ton of different options available at the theme layer. Almost too much. There was a great talk by mortendk at BADCamp 2015 around the optimizations to the Drupal 8 theming layer (hai, Twig) and several examples such as Vanilla for the frontend developers.
The Golden Ticket
When I first deployed the NWASAP website to production, I was nervous because Pathauto (and by extension Ctools and Token) were not available. However, as of early February, the blockers have been cleared for an alpha launch. After some testing on staging, it looked good enough for our use case. I was not looking to do anything crazy, I just wanted to avoid having my clients need to set the page alias. Boom! The last of my reservations are over. Any basic-level content site should be able to use Drupal 8.
In the end
In the end, as all these debates end, you choose the things that work for you, your organization, and your needs. I totally understand the more complex sites will probably focus on their Drupal 7 stacks - and indeed, I have a few support contracts that will remain on this platform.
For sites that thrive on contributed modules (even the increased subset that are now in core), it is definitely recommended to stay in your Drupal 7 environment. The advice that I continue to keep in mind, is to keep Drupal 8 in sight and dive into the architecture from time to time. The new OOP, Symfony code style can be a little overwhelming. Better to be ahead of your company and the industry.
Some of the buzz around Drupal 8 includes:
- Why Drupal 8?
- 8 Reasons Drupal 8 Will Be Amazing
- Have Your Heard the Buzz About Drupal 8
- Big Architecture Changes in Drupal 8
- Why Drupal 8, Why Now?
- Why You Should Be Excited About Drupal 8
Photo credit helloquence from unsplash.
* Just by reading this I know you are as pedantic as me. I realize that entities was perhaps a poor word choice. Rather than Drupal "entity" I meant a collective of functions, being, etc. that relate to the theme-layer of Drupal 7.