Bye, bye hook, hello Symfony: fields, widgets and formatters in D8

Article updated August 2013 and again in March 2014 to reflect the latest core D8 changes. Complete module example (see attachment) is also up-to-date.

"I woke up this morning and all my shrimps was dead and gone. Someone's been fishing in my pond…" -- Robert Johnson

A few days ago I woke up to the latest version of D8 core, only to find that "everything" in my freshly ported fully operational D8 module was broken. While getting to the root course, I couldn't help grumbling the above words by the late great bluesman in his wonderful Dead Shrimp Blues. Replace "shrimps" by "hooks" and think of that "someone" as the D8 core team and you have a wonderful analogy.

One by one the hard-working core team are killing off our trusted hooks, replacing them by equivalent Symfony classes and their magic annotations. Your implementations won't be called any more. Say sayonara to your hooks.

It's all for the greater good, of course.
But initially the mind boggled.

To get a grip and make my module work again, I went back to basics. I wrote a minimum code base to programmatically create a field with associated widget and formatter. It has become my "field+widget+formatter starter pack" when implementing fields in D8.

The commented code is attached as a fully functional module and we posted it to drupal.org, as well.

All the field, widget and formatter hooks have been retired. Here's what you'll have to add to re-instate the D7 functionality provided by your field type, widget and formatter hook implementations.
In the /modules directory you need to create the following files, each holding a class and its essential annotations.

  • modulename/lib/Drupal/modulename/Plugin/Field/FieldType/ModuleNameItem.php
  • modulename/lib/Drupal/modulename/Plugin/Field/FieldWidget/ModuleNameDefaultWidget.php
  • modulename/lib/Drupal/modulename/Plugin/Field/FieldFormatter/ModuleNameDefaultFormatter.php

Tips to avoid the Dead Hook Blues:
o Don't have superfluous trailing comma's in your annotations -- the effect is calamitous.
o In your field_type class, implement isEmpty() correctly or you may find that submitted form values don't save!
o Once you've mastered the starter pack, have a look at the source of core's Telephone and Link modules for a step up in complexity and in becoming a D8 pro!

File under: 
Attachment: 

Putting out our trash

Read More »

Comments

Bye bye love
Bye bye happiness
Hello loneliness
I think I'm-a gonna cry

So bye bye, D7, bye bye

fwiw neither the plugin system, the field/formatter/widget implementations, nor annotations are from Symfony. Annotation parsing is from Doctrine common, and the rest is home grown.

I guess it takes a core insider and pro like you for that to be obvious. It's not to mere mortals like me. So if Symfony isn't providing this stuff and a lot of what is new in D8 is home-grown, does that mean that D8 is doing a so-so job at "getting off the island" and all that?

I don't believe Drupal 8 was ever intended to be "Symfony CMS", there is already something along those lines: http://cmf.symfony.com/

Drupal 8 is an evolution of Drupal in which we use some parts of Symfony that make our lives easier (and saves us duplicating code).
There is still always going to be new functionality that is Drupal specific, however a lot of that Drupal specific code is also starting the great migration to OO (among other changes).

Despite how it might sometimes seem from some Drupal - Symfony articles around, it is not a matter of Drupal < 8 is bad & Symfony is good so we're swapping. Some Drupal code is great and in some places Symfony provides better alternatives so we can merge them both where it benefits us.

We're not getting off the Drupal Island, we're making it more accessible (to non-Drupal developers) - and making it better in the process.

Yep, I get it, rooby. Like you say, there has been so much publicity about Drupal D8 embracing Twig and Symfony that it is easy for the layman to think that nearly everything different from D7 must belong to one of these. The migration to OO, "containers" and annotations is ultimately for the greater good and those who have come across it before (e.g. Java Spring anyone?), you'll be alright. But I feel that same OO migration may send a few shock waves through the part of the Drupal developer community that have so far only dabbled in procedural, Drupal-style PHP with a few hooks thrown in. Let's hope contributors will pick it up soon, as Drupal D8 core, just like Drupal D7 core, needs contrib to become a viable base for great web sites. It will happen, of course it will, but the sooner contrib catches up the better for all.