close

Drupal 8. Why is it so 'special'?

go

As soon as the official support of Drupal 6 was stopped on February 24 2016, learning the new Drupal 8 version became a necessity. There are many text and even video training courses on the Internet which can help you get started with the creation of Drupal 8 projects.
On the March 3 2016, the latest Drupal 8.0.5 version was released. So, what’s the difference between Drupal 7 and 8? Is it time to make new sites on the latest version of Drupal 8? Here are some answers to those questions.

Differences and features for site builders

Many modules were moved in Drupal 8 core.

For example, the module Views is available by default. Also, most of the Drupal administration screens now use Views, which makes them easy to customise. Multilingual support includes four key modules in the core. Once those modules are enabled, you can almost immediately start translating your site. Web services are also in the core. Enable the four Web Services modules, go to Views and you'll immediately be able to create a REST export.

Mobile first and responsive images.

Drupal 8 allows you to choose different styles for individual images. The various styles will be used for different device sizes.

Improved authoring experience.

  • Drupal 8 ships with CKEditor out of the box
  • Quick Edit. If you're logged into Drupal and looking at content, you'll be able to edit text directly from the front-end of your site.
  • The new flexible Admin menu and many other features.
  • No more (core) support for IE 6,7 & 8.

Configuration Manager.

The new Configuration Manager module in Drupal 8 makes it much easier to export and import the features that you build. For example, if you create a new content type, you can export it from your test site and easily import it into a live site.

HTML5 Forms and Fields.

New fields and forms are in core (Date, Email, Link, Reference, Telephone). Fields are used everywhere. You can now add fields to nodes, blocks, comments, contact forms, taxonomy terms and users.

Comments.

Different types of comments can be created. For example, you can have one type of comment on public-facing blog posts and another type of comment for private feedback from admins. The comments can be added to blocks, contact messages, content, taxonomy terms, users and even to comments! Each comment can have its own set of fields.

Tour.

Drupal's explanatory text was always hidden away under the "Help" link. Now, thanks to the Tour module, you can click the "Tour" link and see pop-ups that explain how Drupal works.

Skills for developers

One of the biggest differences between Drupal 7 and 8 for developers is the way the code is written.

OOP

Drupal code is still PHP but it's now much more object oriented. Global procedural functions are still in place but most of the logic happens in classes. Classes are used everywhere — pages, forms, blocks, etc. are all now object oriented.

"Hello World" in Drupal 7

example.module

function example_menu() {
  $items['hello'] = array(
   'title' => 'Hello world',
    'page callback' => '_example_page',
    'access callback' => 'user_access',
    'access_arguments' => 'access content'
  );
  return $items;
}
function _example_page(){
  return t('Hello world.');
}

"Hello World" in Drupal 8

example.routing.yml

example.hello:
  path: '/hello'
  defaults:
    _content: '\Drupal\example\ExampleController::hello'
  requirements:
    _permission: 'access content'

src/ExampleController.php

<?php
  namespace Drupal\example;
  use Drupal\Core\Controller\ControllerBase;
  /**
  * Returns responses for Example module routes.
  */
  class ExampleController extends ControllerBase {
    public function hello(){
      return new Response($this->t('Hello world.'));
    }
  }

PSR-4

Drupal 8 implements the PSR-4 standard and makes use of it to discover code and to load the code on an as-needed basis, rather than requiring every single file in Drupal's code base to be loaded for every request. Let's assume we've got a module named Markus. Each Drupal module has a namespace that corresponds to that module's name and is mapped to the src/ directory for the module. Anything following the module's namespace maps directly to the directory and file structure:

Drupal\markus\Clothes\Pants → modules/markus/src/Clothes/Pants.php

Want to do something with Markus's pants in your code? Simply instantiate a copy of the class using its fully qualified namespace, anywhere in your code, and Drupal will take care of locating the file and including it.

$pants = new Drupal\markus\Clothes\Pants();
$pants->putOn();

Would use: modules/markus/src/Clothes/Pants.php

Symfony

One of the main points of contention in the Drupal 8 development cycle was the introduction of Symfony components. It is a great modular framework and knowing its concepts will really help you out in understanding how Drupal 8 is built (for the components it uses).

Composer (for libraries)

Drupal 8 uses Composer to manage external PHP libraries and dependencies (such as Symfony components, Guzzle, etc).

Caching (BigPipe)

Drupal 8 core has support for cacheability metadata, that aids dynamic page cache module. When we talk about caching sections of a page, there could be sections that cannot be cached or caching them is an overhead. Drupal can now identify such sections of the page based on a few conditions automatically. These sections are replaced by placeholders by Drupal core. So now while preparing the HTML response, Drupal doesn't need to wait for these non-cached(uncacheable) parts to pull fresh data. Rather, it can send out the skeleton markup with the non-cached parts of the page rendered as placeholders.

Events (more events, less hooks)

Pros and cons of events and alter hooks:

  • Object oriented.
  • Stopping propagation. Like a JavaScript event, the event dispatcher allows any single event to stop propagation, preventing subsequent event listeners from firing. This can't be done with an alter hook.
  • Firing twice on the one event. By default with the hook system, your hook is fired based on alphabetical sorting. If you want to alter the order in which the hooks fire, you can alter the module's weight in the system table - which applies globally for all hooks or implement hook_module_implements_alter to reorder on a per-hook basis. What you can't do however, is fire your hook twice. With the event system, you can register two listeners for the one event, from the one module. This means you can have your event listener fire first and last when the event is dispatched.
  • One thing the event system doesn't easily allow is for one module to remove another module's implementation. This can be done with hook_module_implements_alter in the hook system. So for your particular site-build you may find one module's implementation of a hook problematic or even broken. With the hook system, you can implement hook_module_implements_alter and remove a particular implementation and re-implement it in your own way. To do something similar in the event-dispatcher system would require you to alter the container definition and remove the event listener you don't want.

Twig

PHP tags are not allowed. PHPTemplate is now Twig (friendlier syntax for designers, variables auto-escaped for better security).

7.x:
<div id="page-wrapper">
  <div id="page">
    <div id="header">
      <div class="section clearfix">
        <?php if ($logo): ?>
	  <a href="<?php print $front_page; ?>" title="<?php print t('Home'); ?>" rel="home" id="logo">
	    <img src="<?php print $logo; ?>" alt="<?php print t('Home');" />
	  </a>
	<?php endif; ?>
      </div>
    </div>
  </div>
</div>
8.x: page.html.twig
<div class="layout-container">
  <header role="banner">
    {% if logo %}
      <a href="{{ front_page }}" title="{{ 'Home'|t }}" rel="home">
        <img src="{{ logo }}" alt=" {{'Home'|t }}" />
      </a>
    {% endif %}
  </header>
</div>

Plugins

Many old Drupal 7 implementations of various concepts have been transformed to plugins: info hooks, blocks, field formatters, views handlers, etc. Understanding plugins is therefore very important for being able to extend default Drupal functionality.

Dependency injection and the service container

Drupal 8 uses the Symfony dependency injection container to manage service instantiation and injection into classes that need them. This helps decouple functionality and increases testability.

YAML in .info files

7.x:
name = Example
description = "Example module"
core = 7.x
files[] = example.test
config = admin/config/example
dependencies[] = node
8.x:
name: Example
type: module
description: "Example module"
core: 8.x
config: admin.example
dependencies:
  - node

TO BUILD SOMETHING NEW, WHICH VERSION OF DRUPAL SHOULD I CHOOSE, 7 OR 8?

We recommend choosing Drupal 8 because of its improvements. But consider criteria such as: deployment schedule requirements, whether you can accomplish most of your requirements with core and the expertise of your team. Ultimately, the right version for you depends on your code, configuration and your organisational needs and capabilities. You can find statistics of usage Drupal versions on https://www.drupal.org/project/usage/drupal.

For more information we recommend VISITING:

Author:

volha2
Volha
  • drupal
  • symfony
  • tutorial

Get in Touch