Problem/Motivation
I recently upgraded search_api to 8.x-1.38. Unfortunately, this broke a view on a site. Because Drupal Core lacks proper JSON serialization of fields I wrote a small custom module that does it. I don't want to get into the weeds, but it bridges the work done in the rest_views module with search_api's fields. The custom module has a hook_views_data_alter() implementation that checked for fields using the search_api field handler. If it found one, then it duplicated the field and added the custom serializer handler.
The problem is that when the Search API text fields were switched from the search_api field handler to search_api_text half my fields broke (the text fields). The view started displaying the "Broken/missing handler" warning in the view for all of them because the alter hook no longer acted on them.
It's kind of a gray area in the BC policy whether this broke it. The BC policy says this about plugins:
Particular plugins, whether class based or yaml based, should not be considered part of the public API. References to plugin IDs and settings in default configuration can be relied upon however.
I'd call this a reference to a plugin ID, though I don't know if Views data is considered "configuration." Obviously it isn't part of the configuration API.
I'm not sure what action should have been taken to warn downstream developers about this change. But I wanted to make certain the problem was documented.
Steps to reproduce
Proposed resolution
At a minimum I think there should have been a change record for #2874641: Select Text Format in Views Field for textual content with values from search index. It's possible that the change should have forced the release of version 2.0.0 too.
Remaining tasks
Decide what action should be taken, if any.
Comments
Comment #2
drunken monkeyThanks for reporting this problem! Sorry this broke your site, and sorry it took me so long to get back to you.
I’m pretty sure the field plugins used for specific Views fields defined by our
search_api_views_data()hook implementation are not covered by our BC policy. Still, I guess there is no harm in having a change record for such changes if it helps a few people. I will try to keep this in mind in the future.I also created a draft change record for the current change in question. Please review and I’ll publish it – better late than never.
Comment #3
dcam commentedNo problem. Thank you for responding.
The CR looks good to me. I think this is sufficient to let anyone with custom code know what to check.
Comment #4
drunken monkeyGood to hear, thanks for the feedback. I published the CR.