The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
Panopoly Magic adds the ability to configure display type and view modes for views blocks when placed in a layout. When the view is built on a Search API index, there's a fatal PHP error.
Steps to reproduce
- Install the latest 3.0.x-dev of Panopoly with its demo content.
- Add a new display to the Panopoly Search (Database) view by cloning the existing Block display.
- In the Block Settings section, edit the Allow Settings and check the box for Display type.
- Save the view.
- Create a new landing page.
- Edit the layout of the page. Add your new Views block to the page.
- Note the block is not added successfully.
- Check the Recent Log Messages for PHP errors and note the error, see example below.
Error: Call to a member function id() on bool in Drupal\panopoly_magic\Plugin\views\display\MagicBlock->buildBlockFormDisplayType() (line 318 of /panopoly_magic/src/Plugin/views/display/MagicBlock.php).
The error is happening because Search API views don't have a base entity type, so they return FALSE for $this->view->getBaseEntityType().
Proposed resolution
It may be possible to use a different function to find out which types of entities are being indexed for the Search API index that's used as the base of the view. (As far as I know, you can't include more than one entity type in an index.) A stopgap would be to say that if there's no base entity type, we assume that it's nodes and go from there.
Remaining tasks
Determine best approach; patch and test.
User interface changes
None.
API changes
None.
Data model changes
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | panopoly_magic-search_api-views-3454052-6.patch | 524 bytes | cboyden |
Comments
Comment #2
cboyden commentedHere's a patch with a proof of concept that is working on a Panopoly child distribution
Comment #3
cboyden commentedAs it turns out Search API can have multiple types of entities as data sources in the same index, so it's not feasible to just assume that everything is a node. And if there are multiple data sources, they won't necessarily all have the same view modes configured. Maybe there's a way to query the search index to see if there are multiple data sources (in which case, switching view modes maybe shouldn't be allowed) or only one (in which case we need the entity type just as if it were a regular view).
Comment #4
cboyden commentedThis new patch is a total kludge but it does manage to get the correct view modes for a Search API view that uses a single datasource.
Comment #5
dsnopekI've spent a little time thinking about this, and I don't think we should try to make the
MagicBlocktry to work as if the View was using the underlying entity type, given that Search API indexes can hold multiple entities types. I think thatMagicBlockshould only be able to work on Views of a single particular entity type.So, I think we should focus on fixing the fatal error:
If that function returns
FALSE, thenMagicBlockshouldn't allow changing the display type.Ideally, it'd be great if we could remove the "Display Type" option when configuring a view that isn't on an entity type, so that site builders can't even enable this option for a View that it wouldn't work on.
Comment #6
cboyden commentedHere's a minimal patch that should keep Views blocks without an entity base table from being able to change display type. I wasn't able to figure out a way to hide the option in the Views UI, so Views can still be configured to allow changing display type, but the options won't be available on the block config if there's no base table.
Comment #7
dsnopekThanks! It works great in my testing :-)
Comment #8
dsnopekComment #10
dsnopek