Drupal 8 out-of-the-box is designed to support production websites, which is great if you're just looking to build a website using existing components. However, it's a pretty lousy environment to do any Drupal development work in, as all of the production optimizations get in the way of quickly building and developing new code. So, here's a few tips for reconfiguring Drupal 8 to be developer friendly.
Note: You do not want to leave any of these changes in place on a production user-facing Drupal 8 website - they should only be used on a private development environment.
Some Simple Tweaks
Developers will almost certainly want to disable CSS and JavaScript aggregation, which is done via the administrative toolbar at Configuration -> Development -> Performance. Otherwise, you'll have to fully flush your caches every time you modify any CSS or JavaScript, which will greatly slow down your development work.
You may also want to uninstall BigPipe (at least initially) to make debugging faster and less confusing. However, keep in mind that your could should be built to work with BigPipe, so definitely turn it back on at some point and make sure nothing breaks.
The big pain point for BigPipe is any JavaScript that modifies elements in the browser DOM. Since BigPipe loads the page in increments, you have to follow the Drupal model for JavaScript that will run on page load - otherwise, you'll get very erratic results.
Kint
Perhaps the biggest problem in figuring out how to properly code for Drupal 8 is the need to delve into extremely large and complex objects, since Drupal 8 has become as object-oriented as you can get. While PHP has a few tools built in, none of them were ever updated to handle the complexity of object oriented programming. Fortunately, there is a really helpful add-on tool to help.
Kint is a third-party object dumping tool and is provided as part of the third-party Devel module. You don't even have to enable any other part of Devel – just add the module to your site and enable the Devel Kint sub-module, and you're ready to go. Any time you want to explore an object, just do the following in your code:
kint($object_variable);
Reload the page that uses that code, and you'll get a nifty color-coded explorer at the top of the page. Unlike print_r() and var_dump(), kint can handle recursiveness in Drupal objects with ease.
Twig Debugging and Other Features
Additional debugging features can be enabled in your site configuration files. This is a little complex to explain here, but to get started, look at the following files in any Drupal distribution for instructions:
/sites/example.settings.local.php/sites/default/default.services.yml/sites/default/settings.php(Look for "Load local development override configuration" near the bottom of the file)
In particular, the services.yml file, when activated, lets you enable Twig debugging, which provides several useful features:
-
Extra comments in your HTML let you know which template files are being used, and even suggestions for template file names that can be used to override the current template file.
-
A
dump()function that you can use in Twig templates to see what data is being passed to the template.{{ dump(title) }}{{ dump(_context|keys) }} -
Twig caching is disabled, letting you immediately see the effect of changes to template files without having to flush caches every time.
You can also use the files listed above to disable some of the internal caches and further speed up seeing the effects of changes you are making. Just keep in mind that some caches always have to be rebuilt after changes are made, such as the caches for hook functions, routes, and libraries that you define in your custom modules.