Drupal 8 is right around the corner; it's time to start brushing off your old textbooks, taking notes, asking questions, and preparing for all the awesomeness coming your way.
For most of us, Drupal 8 represents a departure from what we've come to know about how to create with Drupal. In short, we've got a learning curve we're going to have to overcome before we can be proficient with Drupal 8. But I'm here to tell you: it’s okay, we're in this together, and, given the proper learning environment and a little bit of guidance, you'll be Drupal 8 ready in no time.
In the glorious words of Douglas Adams, “Don't panic!”
While most of us have a tendency to want to jump right into the documentation and start poring over code samples, this is a good opportunity to take a step back and make sure we're ready to learn before we dive in. So let’s take a minute to think about education theory and the environment we put ourselves in when preparing to learn a new technology. How do we remove blockers from the learning process and set ourselves up for success?
Consider:
- What is my motivation for learning this?
- Where can I practice what I'm learning?
- How will I know if I have learned the right thing?
How motivated are you?
Are you learning for fun, or for work?
Because you want to, or because you have to?
Our motivation – and our understanding of it – allows us to decide whether it is worth the investment in time and energy necessary to learn something new today – right now – which we may not use until tomorrow.
One of the best ways to assess whether or not you've learned something is to teach it to someone else. Lucky for you, you're not the only one embarking on the quest to learn Drupal 8; there are plenty of opportunities to share your new knowledge with others. Local user groups, co-workers – even friends on IRC – all represent great teaching opportunities. Moreover, these interactions often turn into discussions, and discussions are one of the best ways to get beyond the how and into the why.
In addition to practicing by teaching, you can also practice your new Drupal 8 skills by assisting with Drupal 8 itself, or helping to improve the documentation and making it easier for the next person to learn.
My third question is: How will you know if you’ve learned the right things? This will, of course, depend on your motivation. If your motivation was to become a better-rounded programmer, and you learn OOP where you only knew functional programming before, I'd say you've accomplished your goals.
I encourage you to stop reading now and take a moment to think about these three questions and see if you can answer them for yourself. It may seem trivial but I believe that knowing why is just as important as knowing how.
Ready to learn?
Great. Here are some excellent resources to help get you started, and some basic terminology so at least you'll know what you don't know.
The following is by no means a comprehensive list of all the things you'll ultimately need or want to know, but it does provide some general background knowledge that will be applicable to everyone writing code for Drupal 8. A lot of it will also be assumed knowledge by many people already working with Drupal 8, so having at least a cursory understanding of these topics will make it easier to follow along with documentation and converse with others on the subject.
In order to take fuller advantage of the PHP language, and what are considered to be best practices for modern PHP based web applications, Drupal 8 has chosen to require a minimum of PHP version 5.4. Doing so opens the door to better leverage modern object-oriented programming patterns, which is good for you because it allows Drupal to be more flexible and less tightly-coupled than ever before. It also helps bring Drupal 8 more in line with the syntax, patterns, and methodologies that many other PHP based frameworks are using. One of the big hopes here is that this will allow Drupal to attract more PHP developers and at the same time allow existing Drupal developers to become better overall PHP programmers.
For those of us making the transition from Drupal 7, this means that the syntax of our modules is going to look quite a bit different: The important thing to remember is that everything you could do in Drupal 7 you can still do in Drupal 8 once you learn the new patterns. One good resource for adapting your knowledge of Drupal 7 to the new way of doing something in Drupal 8 is the change records available on Drupal.org. I've also found that doing a side-by-side comparison between how something is implemented in Drupal 7 core vs. Drupal 8 core can go a long way towards pointing me in the right direction: even if I don't completely understand how it's working, at least I have working code and a better knowledge of what I don't know.
As a developer, make sure you're familiar with basic OOP syntax and patterns, which is now assumed knowledge for anyone doing Drupal 8 development. Also pay particular attention to namespaces (which allow for better compartmentalization of code, and eliminate the namespace conflict problems inherent in Drupal 7's architecture) as well as the concept of late static binding (which allows for the constructor injection used throughout Drupal), both of which you'll encounter early and often.
Speaking of OOP design patterns in Drupal, dependency injection (DI) is a pattern that you'll absolutely want to become familiar with. DI is being applied throughout Drupal in order to ensure a less tightly-coupled system by providing dependencies as arguments instead of hard coding them.
"Wait, what was that?" you say.
Although the pattern sounds complex, it is actually straightforward and, in my experience, is often just giving a fancy name to something you're already doing. Be prepared to hear the term used frequently, and understand the basics of setter injection and constructor injection – the two forms of dependency injection used most frequently in Drupal.
In addition to using the DI pattern, Drupal 8 also provides a Dependency Injection Container; in essence, a global object where you can simply request the service you need, and it'll configure and provide the appropriate object already initialized and usable.
Need to query the database? Get a database connection object from the Dependency Injection Container and it'll already be configured to connect to the appropriate database server using the correct username, password, and other data. As a module developer, that means you can just start making queries, with no need to worry about what database is being used in the background or the specifics of connecting to it with PHP.
PSR-0 and PSR-4 (or PHP Specification Request 0 and 4) are patterns for standardizing the name, location, and content of files, which makes it possible for Drupal to locate and load files on an as-needed basis. Neither standard is specific to Drupal – the standards are put forth by the PHP Framework Interoperability Group with the hope of allowing greater compatibility between PHP code libraries. By adopting these standards, Drupal 8 is able to include third party libraries like Guzzle and components from other frameworks like Symfony 2 in a clean way. At the time this article was written, both PSR-0 and 4 are in use in Drupal 8, though that is subject to change. Either way the patterns are very similar and learning both won't hurt.
Because files are now located in specific known places, and their contents are also known, Drupal can perform auto loading without requiring a Drupal 7 style registry. As a module developer, this allows you to instantiate a new object of a specific type without having to ensure you've loaded the file containing the class definition first. It also reduces the amount of code and thus memory that PHP needs for each request, and increases the findability of a particular file or class definition in the codebase. Once you understand the pattern, you only have to repeat it and Drupal will take care of the rest.
Remember hook_block_info() from Drupal 7?
Implementations of this hook return an array that provides metadata which specifies things like the title of the block and an optional cache granularity setting. For performance reasons, it's best to have this kind of metadata available without having to access a database. Annotations provide a mechanism for encoding metadata about a class within the comments for that class, keeping the configuration and the actual code close to one another for discoverability purposes, and allowing Drupal to access some general information about the block this class represents, without the hassle of instantiating an object first.
Although you can accomplish quite a bit without ever using annotations, sooner or later you're going to encounter it, probably either creating custom blocks or working with the Field API.
While we're on the topic of metadata, it's also worth mentioning YAML. A recursive acronym for YAML Ain't Markup Language, YAML is a human readable syntax for representing configuration in static files. Drupal 8 makes use of YAML in numerous places, including as the default storage mechanism for configuration data provided by the configuration management system, as a way for theme and module developers to describe basic properties of their project (like name and description, replacing Drupal 7 .info files), and as a way, in the routing system, for module developers to define the various ways in which incoming requests to Drupal are mapped to the PHP code they should execute.
The YAML syntax itself is straightforward; learning it will be of huge value and little trouble. Once you've mastered the syntax though, understanding the various configuration options that it can be used to define will require understanding the respective Drupal subsystem that makes use of the YAML file in question.
One of the biggest misconceptions in the Drupal community right now is that you'll be required to learn Symfony 2 in order to be a Drupal 8 developer. I don’t think this is true.
If you're going to start hacking on core, then yes, you'll want to brush up on the various Symfony 2 components that have been included. But as a day-to-day module developer, you're not likely to encounter much that will require you to know Symfony 2.
Bottom line: many of the patterns and concepts that you need to know for Drupal are also used by the Symfony 2 project, so learning Symfony 2 will only make you a better Drupal developer – and a better PHP developer.
I could go on listing topics, but that should be enough documentation to get you going, along with a final bit to keep in mind as you wend your way through all these resources.
About a year ago I was at a company retreat and I posed a question to my coworkers: “How can I help you learn Drupal 8?”
What we realized was that we were all capable of reading the documentation, and content to look at code examples in order to understand how any particular system worked, but that the more important and difficult question was “why?”
Why does CMI use YAML for its default data storage?
Why should I extend FormBase instead of just creating my own class for building a form?
When you can figure out why specific decisions were made, you'll also understand the potential limitations of those decisions, and you'll be capable of pushing Drupal to its limits. So while you're poring over documentation and sample code remember to take a moment to ask, "Why this way?"
Resources
PHP 5.4 - Modern PHP
Importance: Critical
Difficulty: Easy
- A great overview of modern PHP best practices including information about many of the topics in this article. - http://wdog.it/4/1/right
- The "PHP Objects, Patterns, and Practice" book covers OOP in PHP in depth - http://wdog.it/4/1/oop
- PHP documentation on Late Static Binding - http://wdog.it/4/1/lsb
- Background on why Drupal requires PHP 5.4? - http://wdog.it/4/1/why54
PHP - Namespaces
Importance: Critical
Difficulty: Easy
- General information about using namespaces in PHP - http://wdog.it/4/1/ns
- Drupal specifics for using namespaces - http://wdog.it/4/1/drupalns
Dependency Injection
Importance: Critical
Difficulty: Moderate
General information on DI
DI in Drupal
- DI and Services in Drupal 8 - http://wdog.it/4/1/diservices
- Presentation that explains both DI concepts in general and Drupal specifics - http://wdog.it/4/1/di8
PSR-0 & PSR-4
Importance: Critical
Difficulty: Easy
- PSR-0 - http://wdog.it/4/1/psr0
- PSR-4 - http://wdog.it/4/1/psr4
- Usage in Drupal - http://wdog.it/4/1/drupalpsr
Annotations
Importance: Moderate
Difficulty: Moderate
- Annotations in PHP - http://wdog.it/4/1/anno
- Doctrine annotations documentation - http://wdog.it/4/1/doct
- Annotations in Drupal - http://wdog.it/4/1/d8anno
YAML
Importance: Critical
Difficulty: Easy
- Wikipedia documentation on YAML - http://wdog.it/4/1/wikiyaml
- Official YAML documentation - http://wdog.it/4/1/yaml
Symfony 2
Importance: Good to know
Difficulty: Hard
The basic Symfony 2 documentation is extremely good and can be worked through over the course of a couple days. Like Drupal though, mastering Symfony 2 will take much longer, and learning all the moving parts will require actually making use of them in real-world scenarios.
- Symfony 2 official documentation - http://wdog.it/4/1/symdoc
Image: ©iStockphoto.com/lisegagne