· Hacking · 5 min read

Porting a module to Drupal 8

· Drupal 8 GSoC Drupal Planet

I am porting a drupal 7 module named securesite to drupal 8 under of Google Summer Of Code’14. It has been two weeks into the coding period and I am thoroughly enjoying it. This is my first port in a series of posts that I plan to write during this period.

One look at a drupal 8 module is enough to make you realize that there have been some major changes in its architecture. If you observe closely, you will find ample use of OOP constructs, YAML files, and a directory structure totally different form its drupal 7 counterpart. There is enough mention about the big changes in drupal 8 on the web to scare anyone. With this series of posts, I aim to simplify this process of porting a module to drupal 8 for everyone - new to drupal or already experienced in drupal 7. I will also clarify some of the less documented things about drupal 8 which perplexed me while porting.

Development Environment

First step is to set up the development environment for the project. I prefer phpstorm IDE, even though it is not free, due to its excellent drupal support. The following link explains how to set up phpstorm for drupal module development -https://drupal.org/node/1962108.

Currently, drupal 8 support is avaliable in phpstorm-eap. The IDE is awesome enough to not only point out the syntax errors, but even mark the functions you are using that have been deprecated or don’t exist drupal 8.

OOP, Namespaces and YAML files

I feel that the best way of learning on how to make a d8 module is by looking at the existing d8 module in drupal core. They make up for the lack of documentation in many places.

On looking at a d8 version of a d7 module, first thing you need to figure out is - where did all the code and hooks in .module file go? The concepts of PHP namespaces and PSR-0 standards are very lucidly explained by effulgentsia in http://effulgentsia.drupalgardens.com/content/drupal-8-hello-oop-hello-world Reading above removes a lot of confusion about so many directories and files in the module and the use of namespaces. Some other useful points to be noted from the above blog post are

Configuration Management

One of the bigger changes in Drupal 8 is the Configuration Management Initiative which completely replaces the Drupal 7 variables. One of the reasons for this is to be able to store configuration in files rather than database which helps in easier import-export of the configuration.

Key Takeaways

.install file

hook_enable and hook_disable have been deprecated. https://drupal.org/node/2193013. To port to d8, all the tasks that were being performed in hook_enable are to be performed in hook_install. Same with hook_disable and hook_uninstall. If you have not developed a drupal 7 module before, the difference between disable-enable and install-uninstall can be confounding. Disabling a module leaves its configuration untouched, along with any data like variables it may have created while uninstalling deletes all the data. Due to removal of disabled state in d8, some of the tasks performed in hook_enable may become unecessary.

I hope someone finds this useful. I will write about forms, tests and authentication in my next blog post.

  • LinkedIn
  • Tumblr
  • Reddit
  • Google+
  • Pinterest
  • Pocket