This course is archived!

This tutorial is built using Drupal 8.0. The fundamental concepts of Drupal 8 - like services & routing - are still valid, but newer versions of Drupal *do* have major differences.

> Drupal 8 > Drupal 8: Under the Hood
Buy Access to Course
14.

Overriding Core Drupal

Share this awesome video!

|

Keep on Learning!

Start your All-Access Pass

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

Now that the value we want to change is stored as a parameter, we can override it only on the local machine. Let me show you how.

development.services.yml to Change Local Behavior

Earlier, we created a settings.local.php file, which is itself loaded from settings.php. This file loads a development.services.yml file:

12 lines | sites/development.services.yml
# Local development services.
#
# To activate this feature, follow the instructions at the top of the
# 'example.settings.local.php' file, which sits next to this file.
services:
cache.backend.null:
class: Drupal\Core\Cache\NullBackendFactory
// ... lines 8 - 12

And that's the key: this file gives us tremendous power: power to override services and parameters. These changes will only affect our local environment... well, really, any environment where you've chosen to create the settings.local.php file.

Hey, you know what we should do? Override the parameter! Copy the name and set it to false With any luck, this will turn off the cache:

12 lines | sites/development.services.yml
// ... lines 1 - 8
parameters:
dino.roar.use_key_value_cache: false
// ... lines 11 - 12

Rebuild it:

drupal cache:rebuild

Refresh! OMG, it's so slow! Every time I refresh, it's slow. This is awesome. I mean, not the slow part - but the fact that we can tweak behavior locally.

Parameters are the number one way that you control the behavior of core and third party modules. In fact, check out the core directory - that's where Drupal lives! And hey, look at that core.services.yml file!

1576 lines | core/core.services.yml
// ... lines 1 - 35
services:
// ... lines 37 - 348
keyvalue:
class: Drupal\Core\KeyValueStore\KeyValueFactory
arguments: ['@service_container', '%factory.keyvalue%']
// ... lines 352 - 360
logger.factory:
class: Drupal\Core\Logger\LoggerChannelFactory
parent: container.trait
tags:
- { name: service_collector, tag: logger, call: addLogger }
// ... lines 366 - 1576

All the really important, base services are defined here: they're defined just like we define our services. That's really cool. Most of the services we see in container:debug are coming from here.

Site-Specific Services

At the top, it also has a parameters key with all kinds of parameters stored under it:

1576 lines | core/core.services.yml
parameters:
session.storage.options:
gc_probability: 1
gc_divisor: 100
gc_maxlifetime: 200000
cookie_lifetime: 2000000
twig.config:
debug: false
auto_reload: null
cache: true
// ... lines 11 - 16
factory.keyvalue:
default: keyvalue.database
// ... lines 19 - 1576

These are values that you can override to control core behavior for your app. How? In sites/default, you already have a default.services.yml. If you rename this to services.yml, Drupal will load it. That's thanks to a line in settings.php... that's hiding from me... there it is!

727 lines | sites/default/settings.php
// ... lines 1 - 650
/**
* Load services definition file.
*/
$settings['container_yamls'][] = __DIR__ . '/services.yml';
// ... lines 655 - 727

The config container_yamls.

Overriding Core Parameters

Open up default.services.yml. Hey, parameters!

156 lines | sites/default/default.services.yml
parameters:
session.storage.options:
// ... lines 3 - 9
gc_probability: 1
// ... line 11
gc_divisor: 100
// ... lines 13 - 38
twig.config:
# Twig debugging:
#
# When debugging is enabled:
# - The markup of each Twig template is surrounded by HTML comments that
# contain theming information, such as template file name suggestions.
# - Note that this debugging markup will cause automated tests that directly
# check rendered HTML to fail. When running automated tests, 'debug'
# should be set to FALSE.
# - The dump() function can be used in Twig templates to output information
# about template variables.
# - Twig templates are automatically recompiled whenever the source code
# changes (see auto_reload below).
#
# For more information about debugging Twig templates, see
# https://www.drupal.org/node/1906392.
#
# Not recommended in production environments
# @default false
debug: false
// ... lines 59 - 156

In fact, these are the same parameters we saw in core.services.yml. So everything is setup to allow you to easily control many different parts of the system.

One of the settings under twig.config is called debug, and it's set to false. I want to set this to true, to make theming easier. I could rename this file to services.yml and change that value. But then when we deploy, debug would still be true. No, this is a change that I only want to make locally. That's the job of development.services.yml.

Add twig.config there with debug set to true:

14 lines | sites/development.services.yml
// ... lines 1 - 8
parameters:
// ... lines 10 - 11
twig.config:
debug: true

Cool, that should replace the original value from core.services.yml. Let's clear some cache:

drupal cache:rebuild

Change the URL to the home page where Drupal is using Twig. It looks the same... until you view the source. There it is: the source is now filled with HTML comments that tell you exactly which templates each bit of markup comes from and how you can override them. And with debug set to true, you won't have to rebuild your cache after every template change: Drupal will do that automatically.

This is great! By understanding a few concepts, we're overriding core features in Drupal and actually understanding how it works. That's awesome!