For years I have been annoyed (slightly, but still) that Git diffs for PHP classes always just contained the class header instead of the method header as the function context. I finally got round to doing a bit of research and it turns out that the solution is astonishingly easy: just one small and simple config file and it will magically work.
The greatest thing about all the refactoring in Drupal 8 is that, in general, a lot of those special Drupalisms used nowhere else were thrown out and replaced by sound design patterns, industry best practices and concepts that newcomers from other branches of programming will have an easy time of recognizing and using.
But, of course, this has already been discussed in a lot of other blog posts, podcasts, sessions, etc., by a lot of other people.
What I want to discuss today is one of the few instances where it seems this principle was violated and a new Drupalism, not known anywhere else, introduced: plugin derivatives.
The new plugin system is another large and important change in Drupal 8. While you were pretty much on your own if you wanted to provide some kind of plugin system in Drupal 7 (which a lot of modules do – think Views, Rules, etc.) there is now a very sophisticated framework to easily implement plugins and to define your own plugin types in a clean, extensible and very flexible way. And the good news for everyone familiar (code-wise) with the Search API in Drupal 7: the system is very much in line with how Search API implemented plugins itself, so the switch is pretty easy for us.
Even though there was somewhat of a delay since my last post in this series, it seems no-one else has really covered any of the advanced use cases of Drupal 8 in tutorials yet. So, here is the next installment in my series. I initially wanted to cover creating a new plugin type, but since that already requires creating a new servive, I thought I'd cover that smaller part first and then move on to plugin types in the next post.
I realize that now already a lot more people have started on their Drupal 8 modules, but perhaps this will make this series all the more useful.
Most people who regularly use the Drupal.org issue queues will probably (or hopefully) be familiar with Dreditor, Daniel Kudwien's incredibly useful user script which streamlines the UI, helps you to easily review patches and also contains autocompletion for HTML typed in textareas on the site.
Since that last feature would also be very useful for any other site where you can enter (possibly filtered) HTML, I went and "ported" the autocomplete part of his script to also work with other Drupal sites. See the full post to get it.
In Part 1 of this series, I explained how to create a basic configuration entity in Drupal 8. But the task wasn't completely finished: you should also always specify the schema for your configuration entities (as well as for other configuration). So in this (slightly shorter) tutorial part, I will cover the general new Configuration API as well as configuration schemas.
The 8.x version of Drupal has entered Alpha stage and people everywhere are telling you to port your modules now. However, proper documentation is scarce and existing tutorials or examples only explain the simplest steps. Bad for modules like the Search API, which use things like entity types and plugins, and aren't as easy to port.
Still, I decided to venture into the unknown and start porting now. It was about as bad as I'd feared and I'm still far, far from finished, but I nevertheless wanted to share the first advanced pieces of updating wisdom I've found. Hopefully it will help others get started more smoothly than I did.