YADC – Yet Another Drupal 7/8 Comparison

DrupalCon has been a good resource for learning how Drupal 8 is going to work. It’s a chance to hear directly from the creators of specific modules how and why they used a particular approach for Drupal 7 and how that’s changing for Drupal 8. Here are a few changes I’ve picked up on over the last few days that strike me as particularly significant.

Rules

The Rules module has been around for a while. It’s one of the most installed modules – 1 in every 4 Drupal websites uses Rules.

The D7 version was a pretty custom feature. It was using a custom storage system, custom events and providing a custom API in order to extend the Rules components.

In D8 this has been addressed. Now Rules uses most of the in-built D8 services, perfectly integrating with the new system and the new way of coding.

• Describe your rule
  • D7: hook_rules_data_info(), hook_rules_data_info_alter()
  • D8: use Core Hooks and APIs.
• Event invocation
  • D7: Custom Rules implementation
  • D8: Core Event API
• Provide conditions
  • D7: hook_rules_condition_info() hook
  • D8: Condition Plugin
• Write Actions
  • D7: hook_rules_action_info() hook
  • D8: Action Plugin
• Typed Data API
  • D7: Custom Rules implementation
  • D8: now integrated in the core
• Export a rule
  • D7: external module
  • D8: uses core Configuration Manager Initiative (CMI)

Entity Field and Storage

Entity is a content data storage unit developed first for Drupal 7. It creates a common low level container structure – an “entity” – for upper level content like nodes, users, taxonomies, etc.

One of the most powerful tools in Drupal, it provides the ability to easily attach additional field types to its content: images to Articles, Contact Details for Users, Descriptions for Categories.

And sharing the same low level structure means you can share the fields across any entity types. For example, you can use the same “Main Image” fields and all its settings on Articles, Users, Categories.

Here’s how things are changing for Entity with Drupal 8.

In D7:

• Storage is field-based, field data can live in NoSQL storage and remote storage;
• Every field is configured independently;
• Fields and Properties are managed in different ways and Properties are always stored in the SQL database (problematic when querying the entity);
• Fields can be shared among entity types.

In D8:

• Switch from field-based to entity-based storage;
• Storage (entity-based!) is still swappable;
• Fields and Properties are now Base Fields and Bundle Fields;
• Logically there is no more different between Base and Bundle fields, so Entity Querying now works nicely;
• Fields can NO longer be shared among entity types.

So modules should not assume SQL storage anymore. They should use the Drupal 8 Entity CRUD API (the successor of Entity Field Query System in Drupal 7).

Cache

Drupal has always had a good caching system, but things have changed since the page cache was introduced (Drupal 3.0.0 🙂 ). More and more content now needs to be user-specific (“Hey John, this is your website saying Happy Birthday”) and/or context-specific (“Hi/Hola/Ciao/Bonjour/Namaste/你好 John”).

The Drupal, and specifically Drupal 7, caching system is not enough.

Drupal 8 introduces a new caching system with dependencies for the content you want to cache. That means the system can easily, immediately and, most importantly, automatically react as soon as one of the dependencies of your cached content changes.

The new features are

• cache tags – the data dependencies for your content, which invalidate your cache when they change;
• cache contexts – the context dependencies (i.e. language), which invalidate (or swap) your cached content when they change;
• cache max-age – time dependencies, which invalidate your cache after a specified period of time.

Which means – in practice – you always have to think about cache-ability:

• I’m rendering something?
  • Needs cache? Use cache keys:
    • content varies by permissions, urls, language? Use cache contexts.
    • what causes data to be outdated? List it on cache tags.
    • do we know the max period of time? Specify it on cache max-age.

Lazy Builders and Placeholders

Drupal 8 has just got Lazy Builders and Placeholders added to the core.

Lazy Builders allow you to specify some less important or slow content to be rendered on the load later. Drupal will then give priority to other elements of the page, lazy building your module later according to your strategy.

The HTML render engine will use a temporary placeholder instead of your content (the standard format is a <drupal-placeholder../> tag) which will be replaced with the real and final content as soon as this is ready.

As said above: you define your strategy, and it can be changed per-content base. You can choose the default approach which will replace the placeholder right before serving the page OR the more intelligent and faster BigPipe, which will use javascript to load your content in a separate request.