A note of encouragement for Drupal 8 front end developers

Drupal 8 is approaching beta. Everybody is excited, some are displeased. Here are some of my concerns with Drupal 8 as a front end dev, and a note of encouragement as well. If you are a front dev, you are also involved in writing Drupal modules or parts of modules, that do theming and preprocessing of entities, and formatting of data for output. Some disturbing news and some good news for you are:

Having to learn anew

If you have read the statement, that ‘You can still write d8 modules with using basically same d7 API’ and then try to write a Drupal 8 module, you will realize, that the statement is simply false. You can’t write d8 modules with using basically same d7 API. You will need to do YAML routing, config, and info files, declare the necessary namespaces, and use the changed objects.

Everything, from how user account is treated, to how theming is treated, has changed.

You need to know at least to some extent:

  1. OOP
  2. YAML
  3. PSR
  4. Drupal 8 API
  5. TWIG
  6. Basics of Symfony
  7. New states and config system

Don’t listen to anyone who says you don’t need to know that to do front end in Drupal 8. You can’t do anything serious without getting familiar with the above 7. Even a basic module will touch on these.

Bad news: If you have been neglecting your learning in the process of D8 being written, it can take some time to learn these.

I can hear both complaints about it, and responses to those complaints. “Hey, this is technology. You have to learn!” The truth is in the middle. Yeah, it’s technology. Yeah, a good dev always learns. But - there is a but. Learning has curve, and learning requires time. So, it is absolutely ok to complain about the curve, if you feel it has been too drastic of a change, and you can’t afford to learn all that technology.

Good news and encouragement: There is a certain amount of depth with which you should familiarize yourself with the new technology in Drupal 8, but it’s not as steep for a front developer!

  1. OOP - you will need only the basics, how to work with objects.
  2. YAML - you will need only basics, and will be most likely able to reuse the same YAML file with some changes.
  3. PSR - is easy once you get the basic idea behind it. besides, you will be able to list and reuse the declarations, needed for theming pretty easily.
  4. Drupal 8 API - if you already know Drupal 7 API, you will find the new API an OOP version of the latter, with some changes that are not impossible to learn.
  5. TWIG - sounds scary, but is actually very very easy!
  6. Basics of Symfony - you will need to learn some basic ideas behind routing and MVC, just to understand what part your code plays in the grand whole.
  7. New states and config system is quite easy, and won’t take much time to learn.

So what gives? Yeah, you will need to learn. But no, the curve won’t be as steep for a front end dev, as it will be for a core/module developer.

Having to struggle with the lost ease

There was a certain ease and gracefulness about Drupal 7. You could remove the contrib modules folder, and the system would not fail. If you had an error, that you could not track, you could start removing the modules one by one, or in groups, till you found the culprit. You could clear the Drupal’s temp folder if needed. If you had errors, you would in most cases see a descriptive error or backtrace message, with the error source file and line specified. That was quite easy.

In Drupal 8, you can’t simply remove or change contrib modules, you can’t delete the temp files in the files folder, and the error message tell you the error happened in some class, in some file with weird name, located somewhere in the files folder. With switching to OOP, and with running compiled php code from the files folder, rather than the actual source files, has taken the ease away and made it harder to track.

You may end up running into situations, that you wrote some erroneous code or installed a module with an error, and it got compiled, with it’s settings, into the files folder, and you can’t fix the errors or clear caches, even though the culprit module has been removed, the compiled code stays. This can be vexing, especially if you delete the compiled files in hope, that they will be regenerated if you deleted them.

So what you can do? There are some settings that will lift the problem for you partially. In your site’s settings.php file, find and comment out the settings, that enable debug mode for core and the theming layer. That will lift some of the problems.

A Note of encouragement

If you have mastered Drupal 7 API in the past, then you have what it takes to master Drupal 8 API. You just need to apply yourself. There is documentation starting to form, and you will find some things easier than you initially expected once you grasp the idea. Besides, Drupal 8 is actually getting away from some of it’s esoteric approach, in favor of the common standards and practices.