Need some help with your project? Contact me

6 steps for new Drupal 8 developers

So you are taking the plunge into learning Drupal 8 for the purpose of developing sites, modules, themes, etc. You're a great Drupal 7 developer, familiar with many drupalisms but you don't have tons of experience with modern PHP frameworks, principles and practices. Well, Drupal 8 still includes many of the old drupalisms but still attempts to keep in line with times and modernise itself.

In this article I want to outline 6 steps I believe you should take to get started learning how to develop custom modules and/or themes in Drupal 8. On top of these 6 builds everything else.

The first three are PHP related in a more general fashion, while the last three target aspects of Drupal 8 itself.

1. Learn Object Oriented Programming

One of the biggest difference between Drupal 7 and 8 for developers is the way code is written. It's still PHP but it's now much more object oriented. Global procedural functions are still in place but most of the logic happens in classes.

In case you don't have much experience with Object Oriented Programming in PHP, this is the first thing you need to learn, brush upon or revise (depending on your level). There are many resources available out there, all scattered as hyperlinks in this section. There are also courses you can take, both free and paid.

Without quite a solid OOP foundation, you won't be able to understand much of how Drupal 8 modules are built.

2. Learn how to use Composer

One of the consequences of modernizing PHP has been the introduction of the Composer package manager. Projects are no longer built without it as it does a great job of installing, updating and managing in general the external libraries and dependencies of your project. Not to mention its very helpful autoloader.

Drupal 8 uses Composer to manage external PHP libraries and dependencies (such as Symfony components, Guzzle, etc) and there is talk about the ability to handle also contrib modules. So make sure you know how Composer works and even start using it in non-Drupal projects.

3. Get familiar with Symfony

One of the main points of contention (back then) in the Drupal 8 development cycle was the introduction of Symfony components. Some people didn't really agree with this great shift from the Drupal way, but others embraced it wholeheartedly. I am in the latter group as I love Symfony and used it even before developing anything in Drupal 8.

Drupal 7 developers are often being told that knowing Symfony is not required in order to develop in Drupal 8. While technically true, you still end up learning a lot of it through the Drupal experience. That being said, I strongly recommend learning some Symfony before. It is a great modular framework and knowing its concepts will really help you out in understanding how Drupal 8 is built (for the components it uses I mean). Once you can build a small website in Symfony, you'll enjoy developing in Drupal 8 that much more because concepts will be similar a lot of the time. Not too mention that you can use Symfony to build apps on its own.

4. Routing and controllers

Just like with Drupal 7, when starting to learn Drupal 8 you need to create the obligatory hello world module (creating a page with a parameter in the URL( usually world) that displays the text Hello + parameter). This example introduces you to many important things:

  • Module folder structure
  • Routing (no more hook_menu) through routing.yml files that map to Controller methods
  • Controller classes which have various methods that can be mapped to routes
  • Access arguments for these routes
  • Rendering markup to the page inside the Controller methods
  • etc

So I really recommend giving this a go.

5. Plugins

Another important concept you'll need to get familiar with is Plugins. Admittedly, this is not the easiest to grasp, but it is super important because it's everywhere. Not to worry though, it's not rocket science.

Many old Drupal 7 implementations of various concepts have been transformed to plugins: info hooks, blocks, field formatters, views handlers, etc. Understanding plugins is therefore very important for being able to extend default Drupal functionality.

6. Dependency injection and the service container

The last step I am going to mention here is dependency injection. Drupal 8 uses the Symfony dependency injection container to manage service instantiation and injection into classes that need them. This helps decouple functionality and increases testability.

However, many people are scared of this concept, mainly because they don't grasp it. I wasn't super comfortable either before understanding it. But you should definitely learn what it means, why we use it and how we use it. Because it is a very simple concept that is used all the time in procedural code as well.

You can already find many tutorials out there on Drupal 8 that load services statically through the \Drupal class. It is much faster to write so people (me included) prefer it when writing about D8. I usually also tend to make a note that using dependency injection is preferred in theses cases.

Not understanding what the service container and dependency injection is will easily let you fall into the habit of just statically requesting services and coupling your code like it was procedural. Once you are clear on this point, this will hopefully not happen any more and the sight of a \Drupal::get('some_service') will make you think twice.


There you have it. What I think are the first 6 steps you should take when learning Drupal 8 for the first time. Of course there are many other important things to learn and do but I believe they build on top of this foundation. Of course, this is me writing so others may have different opinions (very much welcomed in the comments). So let's discuss.


Maybe, 7.- install the drupal console project

I think the console is a very powerful and useful tool but it comes later in the process. You don't really learn what's going on if you have some tool generate a bunch of code for you. Even if you then get a chance to read this code.

Thanks for the comment though :)

I don't think the console comes later. I have used it in presentations where people are talking about D8 concepts to quickly have some code to look at, and it provides the scaffolding to follow along/tinker with. Also, I carry that knowledge/code with me after the talk. Otherwise, I just scratch my head and leave the talk still confused or quickly forget what was being said.

I recently started learning Ruby and Rails and think the generate command is awesome. I get best practices for scaffolding without having to think about where all the files would go. You could make a similar argument for Coffeescript, I think.

I don't see how quickly seeing best practices in code is a bad thing. Just my opinion, but I'd really like to see people promoting this tool rather than telling people to wait to use it, especially when D8 code can be really confusing at first.

Hey Alex, thanks for your input.

Let me address each of your paragraph :)

  1. You are talking about a very specific scenario (the presentation) where it makes sense to use tools for quick code generation etc. But that is not what this article is about. Any presentation you go to only gives you the idea of what you later have to go home and start playing with yourself. You will retain 10% of the code thrown in front of you in a presentation especially if it's so big it requires a tool to generate it. That's why you go home, you remember the topic, some places to look and you do the work yourself. Otherwise you won't retain much in the long run.

  2. Yes, again without denying the power and usefulness of a generate tool, you do get scaffolding but you will not really know best practices. That's because you don't understand them, don't know why they are there, they were just thrown to you in a file. That comes from studying the best practices which the authors of the generate tool have studied and are (hopefully) keeping up to date on.

  3. Slightly related to point 2 this one. Who has ever said that anything related to the console is a bad thing? As for promoting the tool, sure, promote it as much as you can (and I can) because it's a good thing. But can you be honest with yourself and tell me yeah, I don't need to know what an interface is, the code generation tool is gonna do it for me? No!

I have not really used the console yet, not because I think it's bad or not valuable. But because I am still in the stage in which whatever module I write (mostly to learn and share this with people), I prefer to write it myself so it gets stuck in my brain like second nature. Later, when I spin up modules on a regular basis, the console will help me greatly.


Totally agree I don't think the console comes later. You can learn a lot from generating the code and reviewing it.

How could you know which code to write when no documentation or documentation is not updated.

We are planning for upcoming releases a verbose output focused on learning, kinda generate code + additional comments on code explaining what code is doing.

Hey Jesus,

I don't agree, although I am happy about and look forward to using the console. Please correct me if I am wrong but where did you learn how the Drupal 8 API's work? Did some code generation tool teach you? No, you learned yourself, figured it out on your own + tutorials + documentation (the amount available) + core code and now you know how stuff works. And then you create an excellent tool based on that knowledge. And share that knowledge. And that is the correct order.

I also learned Symfony like that. Not from the Symfony console, but from writing myself, looking up docs, looking up code. That's what gets stuck in your head.

And this is just a side discussion around the main target of the article which I will no longer stress after this comment: devs who do not know / are no familiar with modern PHP and practices. There are first steps which people like you and me can be quick to dismiss as being important because we know them. Not sure why no one addresses this?

I refuse to dismiss hard work as a prelude to a successful experience with some code just because there are some helpful tools that can help me out with the code. Just like driving a car: I'm very happy that I have parking sensors but that's not how I leaned to park. And if someone learns to park using sensors now, they are doing it wrong. First you need to know how to do it without sensors...


There is no code generation tool for Drupal 8, that is why I decide to create one.

Even when I agree with you about it , and I am always saying as a developer you should always RTFM a tool that generated some code never hurts ;)

Very cool! I would love to see this feature as I think it can be very helpful to people who are confused about where to begin with developing modules/plugins/etc. on D8.

I also love that the console integrates the idea of unit testing. I like to be nudged to do stuff like this right off the bat, and I think encouraging test first development is an awesome thing to instill.

I don't want to highjack these comment threads with talk of the console, but I just wanted to voice support for the verbose mode and push towards using tools like these in tutorials and courses on D8 development. I hope the console will become like drush and used by every developer in their daily routine.

Thanks for your work, Jesus! And thanks for writing the article, Daniel!

You just need to add the --learning option when executing a generator command.

This new feature will generate code adding extra information to the generated code. Think about this as the commented messages you can find on the examples module code.

The messages are multi-language and at this point, the only command that add a verbose output is the controller generator command generate:controller.

More information about hit s feature at this blog post:

Very Cool, Jesus!

Add new comment

You can post comments in Markdown and basic HTML tags.
For code blocks, wrap your code within '~~~'. For example:
$var = 'my variable';