Porting Drupal Blocks from Drupal 7 to Drupal 8

We are looking into porting our site to Drupal 8 and we have over 30 custom modules, so it's a pretty big undertaking. I thought I'd blog about the adventures in the hopes of helping others tackle porting to D8 as well as notes for myself.

Back in April, I took one of our sites and used Drupal Upgrade module to get it moved into D8, following these instructions. I really haven't touched it since then, so I can't really remember how that went. So I just blew the dust off and upgraded from 8.0 to 8.1 in the process. One of the first things I noticed is that comments were turned off, so I had to navigate into the various content types and edit them and edit the comments field to change it from Closed to Open.

Then I was looking through our custom modules and trying to figure out where to start first. Some of our stuff builds on top of each other, so I need to look at the hierarchy to determine what is something that isn't dependent on other things.

One of my first steps was to create a custom modules folder and copy my D7 custom module into that. I then copied the folder as a backup. Then I used the Drupal Module Upgrader (DMU) to generate an upgrade info report as well as attempt the upgrade process. Then I renamed that folder to append -auto and then I created a new folder where I will start work in earnest.

cd /path/to/drupal8 ;
mkdir -p modules/custom/gated_content ;
cp -r /path/to/drupal7/sites/all/modules/custom/gated_content modules/custom/gated_content ;
cp -r /path/to/drupal7/sites/all/modules/custom/gated_content modules/custom/gated_content-orig ;
drush dmu-analyze gated_content --path=modules/custom/gated_content ;
drush dmu-upgrade gated_content --path=modules/custom/gated_content ;
mv modules/custom/gated_content modules/custom/gated_content-auto ;
mkdir modules/custom/gated_content ;

So my first custom module handles what we call "gated content," which is a collection of PDF files that our website users can request to download, which takes them to a request form and after they fill it out, it emails them a link to the PDF.

The module also has a block that shows the most recent gated content entries, which we include in our sidebar.

So I just wanted to start with the block and the block's settings.

The Block

One of the reasons I wanted to start from scratch is that this module is pretty big with lots of code that needs addressing to work in D8 and I'd like to incrementally get stuff working without having all the old stuff in there. So I copied the module's .info.yml and .permissions.yml files into my blank folder to start. No .module file. At least for now.

Blocks have a different way of doing things. You create a plugin. You don't need to point to your plugin through some .yml file. You create a src/Plugin/Block folder in your module and then create a php file for your plugin class. The filename needs to match PSR-4 specifications, which is the magic that autoloads all of this. So I called mine GCListBlock.php. One of my first lessons is that my namespace has to match the module name. My module name is gated_content and I initially used gatedcontent, which resulted in the block showing up in the list, but once you tried to place it in a region, it would result in an error.

Another odd thing is that the phpdoc is very specific with double quotes vs. single quotes. Use double quotes.

Using single quotes resulted in this error:

Doctrine\Common\Annotations\AnnotationException: [Syntax Error] Expected PlainValue, got ''' at position 18 in class Drupal\gated_content\Plugin\Block\GCListBlock. in Doctrine\Common\Annotations\AnnotationException::syntaxError() (line 42 of /Users/jason/Sites/devdesktop/fnmd8-dev/docroot/vendor/doctrine/annotations/lib/Doctrine/Common/Annotations/AnnotationException.php).

Another hiccup I ran across is I had t() calls through my block code that I had to change to $this->t().

I think there was some sort of 8.1 update, which wasn't reflected in the Blocks doc I was pointed to from the DMU report (I added a comment), that says $form_state is now a FormStateInterface. This also means you need to update accessing the form_state values to use $form_state->getValue('FORMFIELDNAME').

Finally, blocks don't just show up in the list of blocks on the blocks page like you might expect from Drupal 6/7 days. You have to click the Place Block button to pull up a list of available blocks and you should see it there. This is pretty neat because you can add a block more than once to a region or across multiple regions. I'm sure there's some way to differentiate the build based on its own order and region, but I don't have to worry about that for now.

The Settings

I initially thought I needed to create a settings yml file, but actually, since the settings aren't used outside of the block code, they can be all specified and used in the block's class. You can provide the defaultConfiguration() method to specify the default values (return an array of keys to values).

Bonus: Devel Module

One of the hiccups I faced was how to get the devel and dpm() calls working like I was used to in D7. One of the cool things I undercovered while getting devel setup is the webprofiler submodule, which adds a nifty toolbar at the bottom of the page with lots of development information and options.

I couldn't get dpm() (or dsm()) calls to show anything, so I stumbled across the kint submodule, which looks even better. You basically enable it and then use kint() vs. dpm(). One bonus is that kint() allows for multiple variables in the same call. It outputted the variable in a narrow region, but there's right arrow you can click on to open it in a new tab. And there's a useful stack trace beneath the output. One other thing I read is that dpm() doesn't have access to protected data, but kint() does.

Also, if you're not seeing output from either dpm() or kint() calls, try doing a cache-rebuild (drush cr). If that fixes it, you may want to setup local development configuration overrides so you don't have to rebuild manually every time.