Undefined array key "base" in Drupal\views\Plugin\views\query\QueryPluginBase

I could reproduce this.

mkdir deleteme
cd deleteme/
ddev config --project-type=drupal11 --docroot=web
ddev start
ddev composer create drupal/recommended-project:^11
ddev composer require drush/drush
ddev composer require drupal/experience_builder:0.2.1-alpha1
ddev drush site:install --account-name=admin --account-pass=admin -y
ddev launch $(ddev drush uli)
// Delete "article" content type and related config on the UI
vim web/sites/default/settings.php
// Write $settings['extension_discovery_scan_tests'] = TRUE;
ddev drush en experience_builder xb_dev_mode xb_test_config_node_article --yes
// Go to /xb/node/2/editor
// Click on Dynamic components. It will show an error instead of the available blocks.

After debugging, the issue is with the standard profile "Recent comments" view.
There must be some incompatibilty with the XB Test Node Article config. Deleting/disabling that view fixes the issue.

@lauriii Do we want to fix it, or just document it for early evaluators?

Preemptively setting the Documentation component.

After deleting the view, now the components display and can be placed, but each time a component is placed I get a list of warnings.

I'm very curious what the call stack is that ends up triggering this warning 🤪

For the original error:

Warning: Undefined array key "base" in Drupal\views\Plugin\views\query\QueryPluginBase->getEntityTableInfo() (line 302 of core/modules/views/src/Plugin/views/query/QueryPluginBase.php).
Drupal\views\Plugin\views\query\QueryPluginBase->getEntityTableInfo() (Line: 1391)
Drupal\views\Plugin\views\query\Sql->query() (Line: 1493)
Drupal\views\Plugin\views\query\Sql->build() (Line: 1381)
Drupal\views\ViewExecutable->build() (Line: 1451)
Drupal\views\ViewExecutable->execute() (Line: 1514)
Drupal\views\ViewExecutable->render() (Line: 133)
Drupal\views\Plugin\views\display\Block->execute() (Line: 1690)
Drupal\views\ViewExecutable->executeDisplay() (Line: 81)
Drupal\views\Element\View::preRenderViewElement() (Line: 61)
Drupal\views\Plugin\Block\ViewsBlock->build() (Line: 173)
Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\BlockComponent->renderComponent() (Line: 306)
Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\BlockComponent->getClientSideInfo() (Line: 220)
Drupal\experience_builder\Entity\Component->normalizeForClientSide() (Line: 214)
Drupal\experience_builder\Controller\ApiConfigControllers->Drupal\experience_builder\Controller\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 212)
Drupal\experience_builder\Controller\ApiConfigControllers->Drupal\experience_builder\Controller\{closure}() (Line: 224)

For the other error

ViewsData.php:127, Drupal\views|ViewsData->get()
QueryPluginBase.php:302, Drupal\views\Plugin|views|query|QueryPluginBase->getEntityTableInfo()
Sql.php:1391, Drupal|views\Plugin|views|query|Sql->query()
Sql.php:1493, Drupal\views\Plugin|views|query|Sql->build()
ViewExecutable.php:1381, Drupal\views|ViewExecutable->build()
ViewExecutable.php:1451, Drupal|views|ViewExecutable->execute()
ViewExecutable.php:1514, Drupal\views| ViewExecutable->render()
Block.php:133, Drupal\views\Plugin|views|display|Block->execute()
ViewExecutable.php:1690, Drupal\views\ViewExecutable->executeDisplay()
View.php:81, Drupal\ views|Element| View :: preRenderViewElement()
ViewsBlock.php:61, Drupal\views|Plugin|Block|ViewsBlock->build()
BlockComponent.php:173, Drupal\experience_builder\Plugin\ExperienceBuilder|ComponentSource\BlockComponent->renderComponent()
BlockComponent.php:306, Drupal\experience_builder\Plugin\ExperienceBuilder|ComponentSource\BlockComponent->getClientSideInfo()
Component.php:220, Drupal\experience_builder|Entity|Component->normalizeForClientSide()

For the preprocess warnings:

block_theme_suggestions_block()
call_user_func_array() (Line: 355)
Drupal\Core\Extension\ModuleHandler->Drupal\Core\Extension\{closure}() (Line: 307)
Drupal\Core\Extension\ModuleHandler->invokeAllWith() (Line: 354)
Drupal\Core\Extension\ModuleHandler->invokeAll() (Line: 379)
Drupal\Core\Theme\ThemeManager->buildThemeHookSuggestions() (Line: 220)
Drupal\Core\Theme\ThemeManager->render() (Line: 446)
Drupal\Core\Render\Renderer->doRender() (Line: 203)
Drupal\Core\Render\Renderer->render() (Line: 120)
Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 119)
Drupal\Core\Render\Renderer->renderInIsolation() (Line: 52)
Drupal\experience_builder\ClientSideRepresentation->renderPreviewIfAny() (Line: 214)
Drupal\experience_builder\Controller\ApiConfigControllers->Drupal\experience_builder\Controller\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 212)
Drupal\experience_builder\Controller\ApiConfigControllers->Drupal\experience_builder\Controller\{closure}() (Line: 224)
Drupal\experience_builder\Controller\ApiConfigControllers->normalize() (Line: 89)

@penyaskito Thanks for all that detail in #7!

But how is this possible if XB only allows block plugins that are fully validatable? Because the Views block one is not:

views_block:
  type: block_settings
  label: 'View block'
  mapping:
    views_label:
      type: label
      label: 'Title'
    items_per_page:
      type: string
      label: 'Items per block'

block.settings.views_block:*:
  type: views_block

… another reason we really need 📌 Introduce unit test coverage for both ComponentSource plugins (Block + SDC) Active 😅

Unassigning @lauriii because per #8, this really smells like a bug 😷

function experience_builder_config_schema_info_alter(array &$definitions): void {
  // This allows these blocks to be placed for now, but really the schema
  // should actually be FullyValidatable.
  // @todo Fix this in core or solve this another way in https://www.drupal.org/project/experience_builder/issues/3484666
  $types = ['block.settings.system_menu_block:*', 'block.settings.views_block:*'];
  foreach ($types as $type) {
    if (isset($definitions[$type])) {
      $definitions[$type]['constraints']['FullyValidatable'] = NULL;
    }
  }
}

📌 Define `props` in the context of Block components Active was fixed, but we never did anything with this @todo. Is it time to remove this alter?

This doesn't looks like the right solution but avoids all the preprocess warnings:

diff --git a/src/ClientSideRepresentation.php b/src/ClientSideRepresentation.php
index 4637364..2f0d636 100644
--- a/src/ClientSideRepresentation.php
+++ b/src/ClientSideRepresentation.php
@@ -49,6 +49,11 @@ final class ClientSideRepresentation implements RefinableCacheableDependencyInte
     }

     $build = $this->preview;
+    // If it's a block, the preprocess won't have the necessary info and will
+    // throw lots of warnings.
+    if (isset($build['#theme']) && $build['#theme'] === 'block') {
+      $build['#configuration'] += $build['#configuration']['default_settings'];
+    }
     $default_markup = $renderer->renderInIsolation($build);
     $assets = AttachedAssets::createFromRenderArray($build);
     $import_map = ImportMapResponseAttachmentsProcessor::buildHtmlTagForAttachedImportMaps(BubbleableMetadata::createFromRenderArray($build)) ?? [];

Is it time to remove this alter?

IMHO yes 😅

But that doesn't help sites already using these, of course.

I suspect that:

1. SystemMenuBlock will take a very long time to become fully validatable in Drupal core … but maybe 🌱 Plan how to evolve code component overrides Active can offer a default rendering with more sane ?
2. ViewsBlock will quite possibly never become fully validatable in Drupal core 😬 But here, maybe ✨ Dynamic List Component Active will make that less important?

@lauriii We took massive shortcuts (aka accepted big technical debt) in 📌 Add support for Blocks as Components Active by allowing menu and views blocks to be placed. We need to stop allowing that before 🌱 Milestone 1.0.0-beta1: Start creating non-throwaway sites Active .

Choices:

1. Remove the "temporary" allowlisting @penyaskito cites in #12
   existing sites won't be able to place these blocks anymore (their Component config entities will become disabled) and new sites won't be able to use either at all.
2. Explicitly make menu blocks fully validatable, by racing ahead of Drupal core, which is not without risk. AFAICT a viable solution would be to alter the config schema to add per-menu validation constraints to each of the 3 settings, i.e. generate type: block.settings.system_menu_block:admin_menu etc.
   menu blocks continue to work as they do today in XB. Existing sites won't be able to place views blocks anymore (their Component config entities will become disabled) and new sites won't be able to use them at all.

We cannot remove the allow list for now. We need to make sure that the absolute must have blocks continue working one way or another. That would be Menu, Breadcrumbs, Title, Branding, and Views. It doesn't seem that there's any option that would keep Views Blocks working in Experience Builder. Does that mean that regardless of what we do in XB, it will not be possible to place Views Blocks using it?

We cannot remove the allow list for now.

This implies there will be a time when this would be okay. When would that be?

That would be Menu, Breadcrumbs, Title, Branding, and Views

1. ❌ block.settings.system_menu_block:* not fully validatable, core issue: 📌 Make menu blocks (block.settings.system_menu_block:*) fully validatable Active , only block.settings.block_content:*: and block.settings.search_form_block were made fully validatable.
2. ✅ Breadcrumb block has no settings ⇒ block.settings.system_breadcrumb_block does not exist ⇒ falls back to block.settings.* which is fully validatable
3. ✅ Title block has no settings ⇒ block.settings.page_title_block does not exist ⇒ falls back to block.settings.* which is fully validatable
4. ✅ Branding block has settings ⇒ block.settings.system_branding_block is fully validatable
5. ❌ Views block has settings (depending on the View) ⇒ block.settings.views_block:* exists and reuses views_block which is not fully validatable … but is surprisingly achieveable: 📌 Make View blocks (block.settings.view_block:*) fully validatable Active

Related: 📌 BlockComponent::checkRequirements() should disallow any block plugins whose definition declares it requires certain contexts Active will disallow Views blocks that are powered by Views that consume "view arguments".

@penyaskito: can you please apply that MR and check if it fixes #2?

For now, assuming that this is hard-blocked on these 2 upstream core issues:

1. 📌 Make menu blocks (block.settings.system_menu_block:*) fully validatable Active
2. 📌 Make View blocks (block.settings.view_block:*) fully validatable Active

Deleted comments field from articles, have recent_comments view enabled, applied 📌 BlockComponent::checkRequirements() should disallow any block plugins whose definition declares it requires certain contexts Active , I still see:

Warning: Undefined array key "base" in Drupal\views\Plugin\views\query\QueryPluginBase->getEntityTableInfo() (line 302 of core/modules/views/src/Plugin/views/query/QueryPluginBase.php).

and components don't load with an error on xb/api/config/component:

"A valid cache entry key is required. Use getAll() to get all table data."

Too bad. 🤔 I'm wondering if some Views things have not yet been installed? I don't see how that's possible though. I have been developing XB on the standard install profile all along. Interesting that I haven't seen this.

Can you put a breakpoint on the line in \Drupal\views\ViewsData::get() that throws that exception and then debug using the callstack? That should make it fairly easy to pinpoint the exact root cause — AFAICT this issue so far has only been talking about symptoms (other than narrowing it down to the recent_comments view).

I wonder … if this is somehow related to 📌 Test coverage to prove that BlockPluginInterface cacheability + BigPipe support work when rendered via XB Active or 🐛 Placeholders/#lazy_builder is not supported for block component rendering Active , aka the way XB's block ComponentSource plugin renders things.

📌 Make menu blocks (block.settings.system_menu_block:*) fully validatable Active is in!

See #3520946-24: Make View blocks (block.settings.view_block:*) fully validatable → and -25, I got this to an (IMHO) RTBC-worthy state, which hopefully means we'll be able to fix this soon… 🤞

📌 Make View blocks (block.settings.view_block:*) fully validatable Active also landed!

This is now just blocked on XB requiring Drupal 11.2.

🐛 PHPUnit Next Major tests failing Active is in, so this is unblocked! Got an MR going…

• is obsolete — added in #16, responded to by @lauriii in #18, upstream bugfixes identified in #19 👍
• is accurate, but has been solved upstream: both 📌 Make menu blocks (block.settings.system_menu_block:*) fully validatable Active and 📌 Make View blocks (block.settings.view_block:*) fully validatable Active have been fixed upstream, shipped as part of 11.2, and XB requires 11.2 since 🐛 PHPUnit Next Major tests failing Active 👍
• is obsolete — because 📌 Make View blocks (block.settings.view_block:*) fully validatable Active has in fact been fixed :)

So this is now a minor task, which is trivial: it just requires deleting a few lines! 🥳

wim leers → closed merge request !923