Configure Drupal 8 for development.

These are my findings of trying to develop my first Drupal 8 website

Development Environment

I suggest avoiding Windows for running your Drupal 8 development site, either fire up a Vagrant box, a Docker container, use Ubuntu (or any Linux distro) or Mac OS X

Windows

I’m one of those guys, who is running Windows 10 through bootcamp on my Macbook Pro, and as I quickly wanted to test some modules out, I started my XAMPP and installed Drupal 8.

Turns out, this doesn’t work very well, Drupal 8 has issues with limits in amount of characters of a path on the windows filesystem, and I quickly started to have errors, all in all, most of the functionality worked, but it was really unstable.

Configure Drupal for development

After getting my Dev environment up and running and installing Drupal 8, these are the things I recommend you to do, so you can start developing easily.

Local Settings

You can now have a separate settings file to store you local development settings in. Go to sites/default/settings.php and uncomment the following lines of code near the end of the file.

if (file_exists(__DIR__ . ‘/settings.local.php’)) {
 include __DIR__ . ‘/settings.local.php’;
}

Make sure you have a settings.local.php file in the sites/default directory, there are a few default settings already set, but make sure the following values are correctly set

Setting Development Services

More on that later

/**
 * Enable local development services.
 */
$settings[‘container_yamls’][] = DRUPAL_ROOT . ‘/sites/development.services.yml’;

Disable CSS and JS aggregation

So you can easily debug your CSS and Javascript files

/**
 * Disable CSS and JS aggregation.
 */
$config[‘system.performance’][‘css’][‘preprocess’] = FALSE;
$config[‘system.performance’][‘js’][‘preprocess’] = FALSE;

Development Services

Symfony2 works with services, and some settings can be set through a YAML file. These are the settings I currently have in my development.services.yml in the sites directory (remember you set it in the local settings earlier)

parameters:
  twig.config:
    debug: true
    auto_reload: true
    cache: false

twig.config / debug: true

Includes helpful comments in your HTML for template file name suggestions, this way you can easily find how to name your template files so you can override them in your own theme

Your source code will look something like this:

html source code with twig debug enabled, the X next to the suggestion is the file currently in use for rendering, the * are other possible values

Twig Dump

When debugging your twig templates, you can leverage a handy dump() function, like so.

{# dump entire view-state #}
{{ dump() }} 

{# dump a specific variable in the view-state #}
{{ dump(specific_variable) }}

When the view-state or the variables got too big I ran into memory issues, and causing a white screen of death to appear, turns out this is because twig uses the standard PHP var_dump function to dump variables.

You can fix this by using an alternative Composer plugin named
VarDumper,
I had to edit something in Twig to get this to work (I know, shame on me, if someone knows a better way, please let me know)

1. Install the Symfony2 VarDumper
   component
2. Go to: vendor/twig/twig/lib/Twig/Extension/Debug.php
3. Find the function twig_var_dump()
4. Comment out (or remove) the line ob_start();
5. Change call to var_dump to dump (twice)
6. Comment out (or remove) the return statement return ob_get_clean();

Your twig_var_dump() function should look like this:

function twig_var_dump(Twig_Environment $env, $context)
{
 if (!$env->isDebug()) {
  return;
 }

//ob_start();

$count = func_num_args();
if (2 === $count) {
 $vars = array();
 foreach ($context as $key => $value) {
  if (!$value instanceof Twig_Template) {
   $vars[$key] = $value;
  }
 }

 dump($vars);
} else {
 for ($i = 2; $i < $count; ++$i) {
  dump(func_get_arg($i));
 }
}

//return ob_get_clean();
}

This should turn your {{ dump() }} to something readable, and expandable on the location in your twig template where you used the dump() call, here’s an example.

VarDumper not only works in your twig templates, but also works in your code, the way dpm() or dsm() used to work in Drupal 7, and has now been replaced by kint().

However, i’m not a big fan of Kint, there’s too much information and when
dealing with large variables, my browser tends to get stuck due to a huge
expanded tree and too much data.

This is where VarDumper() comes in, you can use it in your code just as you
would in Twig, by calling dump($variable);