Ever since the word Symfony was first whispered on IRC there has been a lot of anxiety in the Drupal community about how much, and what kind of effort will be needed to port a contrib module from Drupal 7 to Drupal 8.
While working on our Drupal 8 projects here at Chapter Three over the last few months we have realized that 'Promoted to Front Page' wasn't going to cut it long term and we needed a robust method for sortable lists of entities with views integration. When researching how we might solve this problem for our clients I was happy to see Andrei Mateescu listed as a maintainer of Entityqueue. Andrei had already been helping us out on a few of our Drupal 8 projects and suddenly a solution was staring me right in the face.
I asked Andrei how much time he'd need to create a functional version of Entityqueue for 8 and set him loose with a budget of 60 hours. The only caveat was that he would need to provide me the details of the ups and downs of the porting process as research for this blog post.
Two weeks later we had a functioning alpha release of Entityqueue for Drupal 8, which is being buttoned up and prepared for a full release.
Here are Andrei's notes on what he learned as his port progressed:
The Drupal 7 version had three contrib dependencies: Entity reference, Entity API and Ctools. The first two and most of concepts from the third one are now in core so Entityqueue is easier to install, although, to be fair, most D7 projects were already using those three modules.
To provide a content entity type in Drupal 7 and expose its "properties" to the Entity API ecosystem three separate hook implementations were needed: hook_entity_info(), hook_entity_property_info() and hook_schema(). In Drupal 8 you only need to write one class that extends ContentEntityBase.
In order to provide an exportable object in Drupal 7 there were at least two choices available: the EntityAPIControllerExportable storage controller or ctools exportables. In Drupal 8 this decision is now far simpler thanks to CMI and ConfigEntityBase.
Ctools plugins were somewhat popular in Drupal 7, but there weren't so many simple and good examples of implementing them. This led to vastly different implementations, making the concept of plugins much more difficult for developers to understand. The plugin API in Drupal 8 is much more structured and provides very good default classes for the most common needs, providing developers a clear path to move forward with implementing their own plugins.
The ability to use Field API configurable fields as entity base fields (entity properties in Drupal 7), combined with all the work on automating the entity storage allows Entityqueue to have a much more reliable way of providing its main asset, the 'items' entity reference field. In the Drupal 7 version of Entityqueue, we had to go through a lot of hoops in order to ensure that the configurable field was available at all times. In Drupal 8 base fields can store multiple values in their own dedicated database table, and their configuration definition can vary by bundle. This is another aspect of Drupal 8 that simplifies a great deal of things for Entityqueue.
Views went into core without too many low-level API changes. Porting the views integration of Entityqueue was a pretty straightforward task, and should be the same for most Drupal 7 modules.
Drupal 8 provides a lot of great code examples thanks to the large amount of base classes. Most of these are made possible by the unification of so many separate systems into a handful of concepts (e.g. plugins, entities, etc.). This means that once you get familiar with these concepts, seeing some new implementation for the first time (e.g. starting to work on an existing D8 project or module) should be a markedly less daunting task each time.
Thanks Andrei for your ongoing support for this crucial module. Chapter Three was happy to help support this crucial juncture in the lifetime of this module and looks forward to where Andrei and the rest of the Entityqueue team take this module in the Drupal 8 release cycle.
