Cannot create Search API based views On Drupal 11

There is a Drupal core issue about issues with Views on non-English setups. I have troubles with all the Views at the moment.

See https://www.drupal.org/project/drupal/issues/2987548 🐛 LogicException: The database connection is not serializable. Postponed: needs info .

I think it's a different bug because I've done a test using an english setup.

I am having the same issue on an English setup.

Downgrading from Drupal 11.2.1 to 11.1.8 fixed the issue.

Same issue, fresh installs, english only. Last one is a fresh install with only Gin and search_api as contributed modules. Also reported here 🐛 The submitted value [value] in the [name] element is not allowed. Active .

I took a stab at this, seems the search_api_data plugin is loaded later in 11.2 than before, so in search_api_views_plugins_row_alter() we now create it with too little info, rather than expanding on it. The plugin is only used for data exports, like a rest export view display, and is not available before you create a display like that.

• Tested only on 11.2.2 for now
• Tested that the plugin is available for a REST export display, after enabling core rest module

I was having this issue and the patch fixed it here.
Drupal 11.2.2
Search API 8.x-1.38

I'm having this issue also on Drupal 11.2.2 Search API 8.x-1.38, any solutions? @hfernandes which patch did you use?

Having the same issue on D11.2.2, where a search api view can't be created, because of the "Format" dropdown which includes three options, as mentioned in the issue summary. Once the patch is applied, the empty value is no longer present for selection and Fields or Rendered entity can be selected and view created.

I spent some time reviewing this issue and trying to identify the root cause - and I believe I’ve finally found it.

The search_api_data plugin extends DataEntityRow, which belongs to the rest module.
On websites where the rest module is not enabled, the plugin discovery fails to locate the DataEntityRow definition, causing the search_api_data plugin to break.

Here are a few possible solutions that could be implemented in the search_api module:

1. If search_api_data relies on the rest module, then search_api should declare rest as a dependency and enable this module.
2. Create a new search_api_rest submodule that depends on the rest and contains the search_api_data plugin.
3. Refactor the search_api_data plugin to extend RowPluginBase instead of DataEntityRow.

Among the three, I believe the third option is preferable, as it would have the least impact on websites currently using the search_api_data plugin.

I'm not sure this needs more work, even though it could likely be solved differently.

The plugin is not directly tied to Rest module. If you create a view display of stream / feed / RSS (can't remember the name now), you will also use the plugin, but without Rest module.

I believe the change that happened in 11.2 is when these plugins are discovered, and that there are some optimalisations in place to lazy load / load on demand plugins, that was not there before 11.2.

If you do a dump of the plugin in d10 you will see that it exists already at /admin/structure/views (screenshot), but if you do the same in d11 you will see that it is null. The alter code is adding a ['base'] to the defined plugin, which is fine, but when the plugin is not defined it will rather create a broken plugin definition, with only the ['base'] info, which is what breaks the UI.

The MR simply checks if it exist before it alters it, so it should be very safe. It could be tested further if there are any problems creating displays that uses search_api_data in 11.2, like the bases are not added, but in my limited testing everything seemed fine.

Setting back status, but please just change it again if there is something I have not grasped completely here :)

@vegardjo I'm not opposed to the current fix, as it makes sense to check if the plugin exists before accessing its attributes. However, this solution doesn't address the root cause of the issue. The problem lies in the search_api_data plugin failing to be instantiated - not due to lazy loading, but due to an architectural oversight.

This plugin extends Drupal\rest\Plugin\views\row\DataEntityRow which is defined in the rest module. Relying on a module without declaring it as a dependency is problematic. In fact, simply enabling the rest module resolves the issue without applying the patch.

In Drupal 11.2, this may have been addressed through improved plugin discovery that respects enabled modules.

From what I’ve gathered, the Entity (Search API) plugin is intended for use specifically with REST export displays. If that’s confirmed to be the case, then one of the earlier options I suggested - either declaring a dependency or moving the plugin to a dedicated submodule - might be a more appropriate and sustainable fix.

Thanks for the thorough explanation, @hfernandes, I see now that I was indeed wrong in my assessment that the class / plugin is not directly tied to the Rest module.

Given that I agree that your options 2 or 3 seems best way forward. I assume most SAPI use cases does not involve Rest exports, so having Rest as a dependency on SAPI itself seems overkill.

Untill this is done the solution to the original problem is then either:

• Apply the MR as it is now, as it will atleast allow you to create normal SAPI views again
• Enable Rest module

I agree with the @hfernandes solution. The easiest solution would be to simply set the rest module as required.

I've decided to move this implementation to a submodule, as enabling the rest module may not be appropriate for all websites.

The tests are still failing because we need to migrate the PHPUnit test that validates the views_rest test case to the new submodule.

Good idea @hfernandes, thank you! If I managed to find some time today, I would like to try the MR

I've fixed the unit tests.
However, there is one unit test still failing that I don't think is related to this change - Drupal\Tests\search_api_db_defaults\Functional\IntegrationTest - perhaps related to 🐛 Replace deprecated REQUIREMENT_ERROR constant in search_api_db_defaults_requirements() for Drupal 11+ compatibility Active

I'm moving this to Needs review.

I ran into this exact issue using Drupal 11.2.2. I applied the patch from merge request 247 and can confirm that fixed the issue for me.

can confirm patching working on 11.2.2.

thank you @hfernandes

Seems okay to me too, thanks.