Drupal 8: to embrace or to brace yourself?

Seven tips and traps that make D7 developers go :-) and @#$&*!

When a steam train like D8 rolls your way, resistance is futile. You either jump aside --and some "big" names have done so-- or you jump aboard.

For D7 developers wanting to join the D8 ride, this article critiques some common D8 misconceptions, hopefully making onboarding less precarious.

1. "I need to learn a lot about Symfony."
FALSE! Unless you work on core you need to learn just as much about HTTP Kernel and Symfony CMF, as you learned about the internals of D7's core menu system, i.e. nothing.
And isn't that little, easy-to-find and easy-to-read .routing.yml file an improvement over the now much leaner hook_menu() ? So stop whinging.
Oh, and if it makes you feel better... a lot of code perceived to be Symfony, is in fact home grown core D8.
D8: +1

Woman riding tiger in surf
2. "I'm using my debugger to step through all this container code, trying to figure out how dependency injection is implemented and I'm getting frustrated and don't understand."
Stop doing that! Just accept that when you put your class in the right spot, it will be sucked into the system automagically and leave it at that. Ride the tiger, don't fight the tiger. You didn't need to know how a Views filter handler in D7 got "injected" either, but that didn't stop you writing one.
D8: +1

3. "My hooks are dead and gone and I need to put my implementations into classes."
Yeah, so what? "Opgeruimd staat netjes!"*) is a Dutch saying that is harder to translate into English than copying your functions from .module and .inc files and pasting them into a .php file that resides in a well-organised auto-findable class file structure. Then put class … extends … {… } around the contents and adjust the method signatures where necessary.
Get over it and get coding. Start here: D7 to D8 upgrade: fields, widgets and formatters.
D8: +1

4. "Ok, so I've started on my first D8 field formatter (or widget or field_type or whatever) class and I get error messages I don't understand."
You mean like this one:
Doctrine\Common\Annotations\AnnotationException: [Syntax Error] Expected PlainValue, got ')' at position 649 in class Drupal\leaflet\Plugin\field\formatter\LeafletDefaultFormatter.
Yep, not very clear I admit. "At position 649…" -- are they expecting us to count the number of characters? And from where? What about a line number? This error is probably due to you inserting a superfluous comma before your closing parenthesis. This is precisely what the Drupal coding standards insist on for arrays, but it's bad in Doctrine annotations.
However worse than a vague error message is no error at all and your class not working. For classes other than the stock standard, it can be tedious to find the correct spot in the directory hierarchy for the class to be noticed by the auto-loader. Some diagnostic tool would be welcome.
D8: -1

5. "Because D8 requires PHP 5.3.10 or later can I now safely employ some of the language features that 5.2.x didn't have ?"
Yes! Most notably const, javascript-style closures (anonymous functions) and the nifty binary shorthand for the tertiary conditional operator ?:
     $value = somelongarrayname[$key][0]['name'] ? somelongarrayname[$key][0]['name'] : 'empty';


     $value = somelongarrayname[$key][0]['name'] ?: 'empty';

D8: +1

6. "{{Twig}} is breaking by back."
Oh come off it! Twig is easy and syntactically not a great departure from PHPTemplate. But your templates end up cleaner and easier to work with for themers. Check out this one-page tutorial. See? It's not hard.
Then copy an existing core .html.twig template and adjust to fit your needs.
D8: +1

7. "I need to learn Oh-Oh..."
Yes, Object Oriented basics would be good. Copying & pasting and following patterns found in other modules will get you started producing working D8 code. To understand what overriding is and not to forget to call the parent in the first line of the function body will be a bonus. So read up and don't be baffled by symbols like :: and -> or the use of camelCase.
Also, look at it this way: in the process of learning D8, you'll learn how the rest of the world does programming. Not a bad skill to have...
D8: +1

To summarise, in the words of the goddess of victory: Just do it!

Add your own D8 tips and traps to the comments below!

*) After publication a few translations have been suggested for this Dutch phrase. The one that seems to suit best is "Good riddance to bad rubbish!"

1st picture: Western Maryland Railroad
2nd picture: SodaHead

File under: 

Has mobile mapping evolved?

Read More »


$value = isset(somelongarrayname[$key][0]['name']) ? somelongarrayname[$key][0]['name'] : 'not set';


$value = somelongarrayname[$key][0]['name'] ?: 'not set';

no it does not. isset is still necessary if you do not know whether it's set. Your code throws a notice. The shorthand can only be used for

$value = somelongarrayname[$key][0]['name'] ? somelongarrayname[$key][0]['name'] : 'empty';

Code example updated.

another great positive article, thanks

Awesome article.

Thats the best you can do? Go ahead and insult those that don't drink the cool aid and have legitimate concerns all you want. https://drupal.org/node/2067087 and https://drupal.org/node/2066783 as well as all chx's posts speak for themselves. When the drupal contributor community, which now includes boatloads of non cool aid drinkers, is cut in half, and modules go abandoned, we'll see how great this was for 'Drupal' or whatever it really is now.

No need to take anyone's word for it though.... time will be the judge, it always is. And yes, I actually hope I'm wrong.

Take it easy

Sentiments like "stop whinging" and "get over it" are incredibly dismissive and the opposite of community building. But so is characterizing the people who donate enormous amounts of their time and energy trying to evolve core as "cool aid drinkers."

It's easy to let our frustrations take over, but it's precisely at that moment that we need to remind ourselves that the people we're talking about earnestly want what's best for Drupal. That's the starting point.

"The opposite of community building"... Come on! Get o'..... oops... If taking offense to the lightness of touch and a bit of fun with the English language is the only thing you take away from the intent of this article --which is for all of us to be constructive and get on with the job that is D8-- then you are 1) boring and 2) standing by the sideline. How many hours do you think I invested in porting my own and other people's modules before I summarised my experiences above, so that others would be able to avoid the pitfalls I fell in? I too want "what's best for Drupal". Point us to what you have done to "build this community", Les.

Of course you want what's best for Drupal, and the last thing I want to do is dismiss anyone's contributions. My comment was intended to be taken both ways; I wasn't singling you out.

Here's all I was trying to say: what you intend to be tongue-in-cheek, or fun, on the internet, can easily be misunderstood. I think the response of the commenter I was replying to demonstrates that. Likewise, I think his/her "drinking the kool-aid" swipe and general doomsaying isn't particularly constructive, either.

Neither is asking me to show my credentials, by the way. I do what I can to help.

And no hard feelings on either side, I trust. Contrib has a long way ahead if we want D8 to be used "soonish" after core is officially released. So whatever language is used to shake people out of the false sense that it will all happen by itself if fine by me. My language can be colourful and so is that of just-passing-thru, see http://www.flink.com.au/comment/281#comment-281 It's all good!

A good, well worth reading article. Thanks.

I'm not a core developer, but I still have that "need to know" regarding the internals of Drupal 8. I want to architect my modules around Drupal 8, not simply move functions around from file to file to bring what I've done into Drupal 8. That requires understanding things like request / response objects, routes, and dependency injection. Much better to learn than to be left in the dark, especially if you're developing with community code developed by maintainers who may have forewent the learning process... ; )

However, I agree with the sentiment, but I would state it less dismissively. None of the individual changes in Drupal 8 are monumental on their own, but the sum total does represent a paradigm shift. The best strategy is to start learning new concepts one at a time... and I've been collecting a link library that perhaps I'll turn into a learning list in the near future. Until then:

- Symfony2 Components Tutorial Link / Code: https://github.com/rszrama/symfony-tutorial
- effulgentsia's D8 Hello World: http://effulgentsia.drupalgardens.com/content/drupal-8-hello-oop-hello-w...
- D8 Route Controllers / Dependency Injection: http://previousnext.com.au/blog/using-drupal-8s-new-route-controllers
- D8 Route Access Checks: http://previousnext.com.au/blog/controlling-access-drupal-8-routes-acces...
- D8 Field API: http://realize.be/drupal-8-field-api-series-part-1-field-formatters
- D8 Module Dev Intro: http://getlevelten.com/blog/ian-whitcomb/drupal-8-module-development-par...
- D8 Forms: http://getlevelten.com/blog/ian-whitcomb/drupal-8-module-development-par...
- D8 Plugins: http://getlevelten.com/blog/ian-whitcomb/drupal-8-module-development-par...
- Doctrine Annotations Docs: http://docs.doctrine-project.org/projects/doctrine-common/en/latest/refe...

Thanks so much for your impartial feedback and all your references, Ryan! That's what is pushing the community forward!

I agree with Ryan.

I'm slowly starting to read up on D8 development and I'm hitting a wall too. I've noticed that the one thing that makes me a better developer is not merely use an API, ie merely copy code which implements ContainerInterface, but also to understand what ticks behind it and why it works that way, so that I can apply my knowledge to knew problem spaces. That means diving in and chipping away at all those new concepts bit by bit.

However, internalizing a system is a slow process: One cannot hope to achieve knowledge & experience overnight. It takes time to do so. I do agree though, with each iteration, Drupal specifically forces developers to go through this process again. But noticing how painstakingly gained knowledge becomes obsolete can be frustrating. The experience, however, you don't lose: having transitioned from D5 to this point, I've come to believe that keeping an open mind towards change is the best defence against such frustrations.

Thanks for the links, by the by! ;-)

+1 voor het nederlands :)

Number 4 sounds like a perfect candidate for either a drush add-on, or a symfony2 console based tool. Symfony2 has a lint parser for twig files, and doctrine 2 has a checker for entities who can also be described using either yaml or annotations. Parsing them and then throw human understandable errors is something that should be in contrib. But if the core devs decide it should be in core, then please make it in a separate module that can be turned of in production mode. But I can imagine that it needs to run without bootstrapping drupal first so it can do the lint/check without throwing errors in a browsers. Hence the need for it to be command line based.

Some interesting thoughts, but this:

"Just accept that when you put your class in the right spot, it will be sucked into the system automagically and leave it at that"

... is absolutely the worst advice you can give to any developer. If you don't understand how something works, then you have no business using it. "Magic" is not acceptable. Take the time to understand what you're working with, and you'll be a tenfold better developer than anyone that simply accepts the "magic" at face value.

... but it helps when you need to fix it. Lots of Drupal developers have contributed wonderful modules used by many, many happy users. Many of those developers do not know the details of say, menu-routing in D7. Or how Views generates and execute the SQL, then parses and themes the results. Or what happens during bootstrap. Sure, if they spent time to understand all that magic, it would further enhance their developer skills. This is true for D7 and D8. But the gist of the article is this. There is a lot of technical debt to clear in the Drupal contrib space. But with all these new names and concepts thrown about it can be so overwhelming and make developers lose the desire to even attempt to start. What I'm saying is: "Don't be daunted and watch from the sideline. Don't wait until you understand how all the magic works before you roll up your sleeves and get cranking. You CAN port D7 modules to useful D8 modules now. I've ported a handful of other people's modules myself, see http://flink.com.au/ramblings/combatting-technical-debt-drupal-d8. And I found that more satisfying and more useful, at this stage of creating D8 community momentum, than reading Symfony2 and Twig manuals and trying to understand how these have been wired into D8 core. By just getting started, using some of the brief references above, and coding it, one learns a little about the D8 magic on the way. And if one wants to learn more and become tenfold better, then of course that would be wonderful for both the developer and for those that have the privilege to enjoy the fruits of their labour.