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
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 ?:
$value = somelongarrayname[$key][0]['name'] ? somelongarrayname[$key][0]['name'] : 'empty';
becomes:
$value = somelongarrayname[$key][0]['name'] ?: 'empty';
Better?
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
Comments
isset is not going away
$value = isset(somelongarrayname[$key][0]['name']) ? somelongarrayname[$key][0]['name'] : 'not set';
becomes
$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';
I stand corrected
another great positive
another great positive article, thanks
Awesome article.
Awesome article.
Get over it?
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
Take it easy
The blog post and this comment are both a little tone-deaf
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.
Stick-in-the-mud
Tone is a hard thing to convey in text
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.
Understood!
A good, well worth reading
A good, well worth reading article. Thanks.
I agree and beg to differ
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 for the refs Ryan!
+1!
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! ;-)
number 4
+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.
You don't have to understand how a car works to drive one...