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 Search API Autocomplete module has for some years now been a popular way to add autocomplete suggestions to search fields while the user is typing. However, even though the module was popular, it had several problems and restrictions – primarily, the way the suggestions are computed only reflect the words that are indexed on the search server, not the keywords that users actually searched for. Changing this was possible (as is nearly everything else in Drupal, after all), but cumbersome, and not directly supported in any way by the module.
But, these days are now finally over with the release 1.4 of the module!
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.
There will be up to two Search API in Drupal 8 sessions with me (one for developers with Nick Veenhof and one for site builders) at DrupalCon Amsterdam this autumn. (Update: Sadly, both of these sessions have been rejected, there will only be a Search API BoF.)
There will also be a sprint dedicated to porting the Search API to Drupal 8, more or less throughout the whole week.
Site Search Analysis is a rather recent addition to a site administrator's toolbox, but it has gained a lot of traction in the past few years – and very justly so, in my opinion. Analyzing what people search for once they are on your site, and how they react to the search results you (resp. your site) present them, can tell you a lot about what your visitors want and thus be an immense help in improving your site's content (and search).