Blog posts discussing Search API-related topics.
After more than three years of development (and several blog posts), the Drupal 8 port of the Search API module is finally getting a stable release! The current Beta 5 release will be the last Beta, and there should be a release candidate and the final, stable release within the next two weeks. So, test it now, if you haven't already, to help eliminate any remaining (major) bugs!
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.
While it started energetically enough, the D8 port of the Search API didn't really get anywhere when I tried it this summer, due to a lack of time and, partly, plan. So, this time I'll try to plan ahead, take the time necessary and get everyone on board to help. So the Drupal 8 upgrade of the Search API (second try) will officially kick off at the Drupal Dev Days in Szeged.
If you want to help in any way, be there!
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.
One of the most sought-after features for the Search API has now finally been completely integrated. After Mattias Michaux implemented proximity searches almost two years ago, I was recently sponsored to polish his code and finally integrate it properly with all related modules, especially Solr search. So now, location support for the Search API is finally the just-enable feature it should be, with the Search API Location module and its new Beta 1 release.
Good documentation helps both a module's maintainers and its users, and is quintessential for the success of at least more complex modules. That's why you, as a module maintainer, should not put this (admittedly rather unpopular) task off any further but write some helpful documentation rather sooner than later.
On a related note, I just set a good example by finally expanding the handbook documentation for the Search API, and adding some for the Solr search module as well. Go check it out!
