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

Created on 9 April 2025, 3 months ago

Testing 0.2.1-alpha1

On a fresh Drupal 11.1.6 install

After enabling modules:
Experience Builder, Experience Builder dev mode, Experience Builder Test Node Article and xb_dev_standard, building UI.

When editing an article in XB, the components fail to load. And getting this 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).

🐛 Bug report
Status

Active

Version

0.0

Component

Page builder

Created by

🇺🇸United States galactus86

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @galactus86
  • 🇪🇸Spain penyaskito Seville 💃, Spain 🇪🇸, UTC+2 🇪🇺

    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.

  • 🇪🇸Spain penyaskito Seville 💃, Spain 🇪🇸, UTC+2 🇪🇺

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

  • 🇪🇸Spain penyaskito Seville 💃, Spain 🇪🇸, UTC+2 🇪🇺

    Preemptively setting the Documentation component.

  • 🇺🇸United States galactus86

    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.

  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

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

  • 🇪🇸Spain penyaskito Seville 💃, Spain 🇪🇸, UTC+2 🇪🇺

    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)
    
  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

    @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 😅

  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

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

  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
  • 🇪🇸Spain penyaskito Seville 💃, Spain 🇪🇸, UTC+2 🇪🇺
    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?

  • 🇪🇸Spain penyaskito Seville 💃, Spain 🇪🇸, UTC+2 🇪🇺

    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)) ?? [];
    
  • 🇪🇸Spain penyaskito Seville 💃, Spain 🇪🇸, UTC+2 🇪🇺
  • Pipeline finished with Failed
    3 months ago
    Total: 1748s
    #478368
  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

    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.
  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
  • 🇫🇮Finland lauriii Finland

    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?

  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

    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
  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

    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?

  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

    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
  • 🇪🇸Spain penyaskito Seville 💃, Spain 🇪🇸, UTC+2 🇪🇺

    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."
    
  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

    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.

  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

    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… 🤞

  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

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

    This is now just blocked on XB requiring Drupal 11.2.

  • Status changed to Postponed 19 days ago
  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

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

  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

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

  • Pipeline finished with Skipped
    about 23 hours ago
    #541092
    • wim leers committed 4f86e0d0 on 0.x
      Issue #3518325 by penyaskito, wim leers, galactus86, lauriii: [11.2-only...
  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
Production build 0.71.5 2024