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.
Overriding Core Drupal
Keep on Learning!
If you liked what you've learned so far, dive in! Subscribe to get access to this tutorial plus video, code and script downloads.
With a Subscription, click any sentence in the script to jump to that part of the video!
Login SubscribeNow 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:
| # 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:
| // ... 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!
| // ... 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:
| 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!
| // ... 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!
| 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:
| // ... 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!
Nicely done... I've been doing Drupal 8 since D7 and finally understand how Parameters work!