Drupal 8 Blogdown: First Impressions

Build it with Drupal 8

I remember when I first heard about Drupal 8. The notice came to me with an understanding that a lot of the underlying concepts and code that make up Drupal's plumbing would be replaced for more modern components. There was talk of object-oriented programming, OOP, configuration management, changing the theme layer, and much more as time progressed. Even though the original release timeline of Drupal 8 has come and gone by a longshot, with the amount of changes under the hood, I'm still surprised that it might be released come this fall

After I first heard of all the changes, I was struck with a lot of optimism. The Drupal community joining forces with the larger PHP developer community was encouraging, using more OOP seemed legit, and having Symfony components prop up the plumbing seemed smarter than having Drupal developers spend time re-working such low-level abstractions. I was excited to be a Drupal developer and be forced to step up my skills in order to pay 'dem bills in the future. Other people were more taken aback by all the changes, and Backdrop was born as a Drupal fork because of all the new learning requirements.

The Sheer Scale

Like I said, I was really excited for the next release of Drupal...that was until I downloaded it and tried to start using it. The sheer scale of the project compared to Drupal 7 was something to behold, in and of itself. I used the PHPLOC just to make some baseline comparisons between my current Drupal 7 blog and the Drupal 8 blog I am building right now. 

Drupal 8 codebase:
    Directories: 1695
    Files: 8022
    Cyclomatic complexity/number of methods: 1.98

Drupal 7 codebase:
    Directories: 107
    Files: 297
    Cyclomatic complexity/number of methods: 3.27

As you can see, the number of directories has increased by 1684% while the number of files has increased by 2801% over Drupal 7's codebase. Keep in mind that these numbers also include my custom code and downloaded contributed modules, only in Drupal 7's case, so it's not a 100% accurate comparison of core project codebases, but the numbers are not that far off.

I put cyclomatic complexity vs. number of methods in there just to show that while Drupal 8's codebase has grown, the complexity of the code has trended downward. I'm not going to try and explain cyclomatic complexity or why a lower number here is better, but I just wanted to point out that more files doesn't necessarily mean a bad thing. It can help to simplify parts of the codebase and actually make them more robust and amenable to future development and feature requests.  

The bottom line is that navigating Drupal 8's codebase can be daunting. Most everything won't be where you last looked in Drupal 7; however, most developers rarely looked into Drupal 7's core code since you weren't supposed to hack it, so the sheer amount of files and their locations might not matter much to you in the end. 

You're Gonna Need an IDE for That

Having use of a good IDE will definitely help you though. I have been using PHPStorm for the last year, and before that I used Sublime Text. While I loved using Xdebug inside of PHPStorm after I made my switch, I felt like I wasn't using a lot of the IDE's other features, mainly because Drupal 7 didn't exactly allow you to take advantage of them. 

Since not many functions were methods inside of objects, PHPStorm couldn't tell me whether I was overriding a function of a parent class, what methods I had available to me, or what methods I had to support while implementing an interface. All of these concerns were a moot point in Drupal 7 since most functions were in the global namespace. Remember all those this_is_my_function_and_you_can_not_mess_with_it() functions you used to write? Well thank God those ridiculous names are gone. 

Instead with an IDE, you can tab auto-complete your way to the method you need to use. You can also jump right to the point of declaration for an interface you are going to implement and just copy and paste over those required methods as a starting block. Even though I am just getting into working with OOP code, I find this structure way better than the guesswork you had to do in Drupal 7 to find related functions or implicit interfaces. 

Learn About Auto-loading

I think I was most confused about Drupal 8 when I first looked at a module's codebase. I had found out about the Drupal Console, a great tool to help with code scaffolding, and created a sample module with it. I expected to see some (lack of?) structure like in Drupal 7, but instead I was greeted with what seemed like a recursive folder situation and definite enforcement of structure. What particular folder structure they were imposing I didn't know, and it turns out auto-loading is a crucial concept you will have to learn for proper Drupal 8 development. 

I have to pause here and give a shout out to Buildamodule.com and their Drupal 8 developer prep series. I went into that series and didn't know much about OOP, auto-loading, or dependency injection, but I came out with the all the knowledge I needed to re-design my blog. If you haven't looked at this series yet, I highly recommend watching the free introductory videos and then signing up for a membership!  

What auto-loading does is provide a mechanism for Drupal to only load classes when necessary and know where exactly to find the code to load. The lazy loading of classes reduces memory footprint and the loading conventions allow developers to easily use folders to structure their classes and avoid name conflicts. 

For example, a module function might look like this in Drupal 7: 

/**
 * Function to load block view
 */
function my_module_some_prefix_block_view() {
  ...//code here
}

while the same function in a Drupal 8 module might look like this:

namespace Drupal\my_module\Plugin\Block;
use Drupal\Core\Block\BlockBase;

class MyModuleBlock extends BlockBase {

  /**
   * Function to load block view
   */
  public function block_view() {
    //...code here
  }
}

While the Drupal 8 example might seem like it's more verbose for no reason, the imposed structure can really come in handy pretty quickly. 

Let's say for example that you are trying out different block plugins to see which one you like best. The developers for each module both use a shared interface making each module have the same method names with the same parameters and return variables. To switch between the module's classes in Drupal 8, all you'd have to do is comment out one line:

#use Drupal\some_module\Block\BlockBase;
use Drupal\other_module\Block\BlockBase;

In Drupal 7, this wasn't possible to do. You would have had to use silly prefixes or come up with some other way of trying to quickly switch between the code.

Conclusion

Once you get used to the sheer scale of Drupal 8's directories and files, get yourself a proper IDE, and understand auto-loading, you'll be able to pick through Drupal 8's codebase and actually understand what's going on. Of course, learning OOP is important as well as reading Symfony components documentation, but that stuff isn't immediately necessary to poke around the codebase.  

I will talk about more tangible, detailed things I've noticed in my next post, but until then...enjoy those "src" folders!