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.

Works for me after applying the patch.

Thank you for sorting this one out! This also fixes the AI Search module (sub-module of AI core) where tests had to be disabled temporarily as a result: 📌 Reinstate MySQL tests Active

Can confirm the patch from MR 247 works!

Following is my version stack:
Search API Solr - 4.3.10
Search API - 8.x-1.38
Drupal - 11.2.2

Thanks for the MR, we can have a search_api version bump!

khaleghian → changed the visibility of the branch 3531256-cannot-create-search to hidden.

khaleghian → changed the visibility of the branch 3531256-cannot-create-search to active.

The patch from MR247 also works from me on core 11.2.2

Thanks a lot for reporting this problem and already providing fixes!
However, I’m not sure I fully understand why the new module is needed? It seemed vegardjo’s initial fix was already working fine.

Are there any actual problems when just applying the small fix to search_api_views_plugins_row_alter() and the REST module is not installed? Could I have steps to reproduce for those?

Hi @drunken monkey,

Please take a look at comments #12 and #14 for an explanation of why this submodule is needed.
Let me know if it makes sense or if you'd like me to provide more details.

Rereading the comments and checking the code change, moving to submodule does seem to be the right way to fix it rather than just masking the problem like initial commit. If we extend a core module we should make sure it is enabled. The approach of auto-enabling the sub-module when in use is a pattern we used before when splitting out providers from the AI Core module.

That said it could be split into a seperate follow-up issue if it means getting it fixed sooner with just the initial commit workaround. At least for me this is slowing progress on AI Search since it's harder to keep up with issue queue there with tests failing and both options would unblock that.

Ah and tests now pass after updating fork now that 🐛 Fix failing pipelines Active is resolved (thank you!)

@hfernandes: I did read those comments, but they don’t answer my question: Are there any actual problems for users? You just state that “this is problematic” without explaining why.
This module provides a bunch of classes integrating with specific modules we do not depend upon. I do not want to create a new submodule for each of them, and haven’t so far. (To be fair, not sure if any of the others actually extend a class that would be unavailable.) In the case of the taxonomy-related Views plugins, there were actual problems so we had to work around them, see search_api_views_plugins_argument_alter() and search_api_views_plugins_filter_alter(). Maybe we could do something like this for the REST data row style, too, if necessary. However, it currently seems like we really need to just add that single check (which does make immediate and perfect sense, of course) and we’re fine, so I am loathe to add an entire new submodule just on the basis of “this is problematic”.

@scott_euser: Yes, if you want to get this resolved quickly then a new MR with just this one change seems like the better option.
I’ve created a new MR with just your initial commit. Please ping me on Slack if you’re happy with that (it seems people were happy with it originally, too, so no further tests/reviews should be necessary) and I’ll merge it right away.
We can then leave this issue open to complete the discussion regarding a submodule or other additional measures.

Yep perfectly happy with the new MR "3531256-views-row-alter-checks" you created with just the initial commit from @vegardjo and your explanation for not wanting an extra sub-module fair enough - perhaps if the use statement somehow causes a fatal error not existing for some scenario we haven't come across then a follow-up can be raised with lower priority. Thank you!!

I tried to generate a patch from the MR

@scott_euser: Thanks for the feedback, good to hear! And yes, sorry, it was @vegardjo who made that first fix, not you. Thanks for pointing it out.
Merged my new MR.
If someone still wants to argue for the sub-module, please open a new issue with additional information as explained.

Great solution, it worked for me as well! thanks @drunken monkey