Fatal error on installing the Navigation module: `PropShape::resolveSchemaReferences(): Argument #1 ($schema) must be of type array, string given`

Does the error occur if you uninstall the custom/experience_builder module that is throwing an exception? Can you provide a stack trace?

I am marking this as needing more steps to reproduce because additional modules are needed for the setup that are not mentioned on the steps.

Moving to the Experience Builder queue since this seems like a problem most likely related to it.

This seems related to #3467870: Support `{type: array, …}` prop shapes. I wonder if we should add a new requirement for components; i.e. to not have type: array properties?

This is also pointing another problem; we need a way for components to indicate if the component should be available for Experience Builder. I would not expect anyone to ever want to use the "Toolbar button" component in Experience Builder.

This is also pointing another problem; we need a way for components to indicate if the component should be available for Experience Builder. I would not expect anyone to ever want to use the "Toolbar button" component in Experience Builder.

Emphasis mine.

This is a contradiction with earlier statements you made? 😅

You specifically said that SDCs should not in any way have to be changed. But you did quality that with "changed for use in XB, which specifically is NOT the case here.

So: this is possible. What do you envision the DX for that to be like from a Product POV?

This seems related to #3467870: Support `{type: array, …}` prop shapes. I wonder if we should add a new requirement for components; i.e. to not have type: array properties?

No; that can't shouldn't 😅 be the reason: XB literally won't try creating an XB Component config entity when it encounters a prop shape it doesn't know how to support.

The stack trace (THANK YOU, @kunalkursija! 🤩) points to ::resolveSchemaReferences(). I bet this is simply a bug in there, which is a necessary processing step before the decision is made to create an XB Component config entity or not!

I actually ran into this ~2 months ago while working with the folks who were developing https://www.drupal.org/project/demo_design_system for #3454094: Milestone 0.1.0: Experience Builder Demo. Then they moved away from type: array altogether and hence the problem disappeared. Many urgent things happened, and I failed to create a new issue 🙈

MR created with what I think fixes it, @kunalkursija, can you test again? 😊

A simple hardening for a few LoC IMHO should not have to wait >24 hours. It's already been five days since #9, and >36 hours since #11.

@lauriii Back to you because #7 still needs to be answered by you, and merits an explicit issue 🙏

@tedbow's comment on the MR is a correct interpretation of what the bugfix is that landed here 👍🤓

It's not a fix specific to the Navigation module's SDCs, it's a generic bugfix, that https://www.drupal.org/project/demo_design_system also ran into!

I don't know if this is of any more use or just noise, but I had the same error on enabling XB 0.1.0-alpha1 on Drupal CMS. That Drupal CMS build was based on https://git.drupalcode.org/api/v4/projects/157093/jobs/3432366/artifacts... and I hadn't installed anything else or made any other config changes.

Stack trace slightly different.

The website encountered an unexpected error. Try again later.

TypeError: Drupal\experience_builder\PropShape\PropShape::resolveSchemaReferences(): Argument #1 ($schema) must be of type array, string given in Drupal\experience_builder\PropShape\PropShape::resolveSchemaReferences() (line 49 of modules/contrib/experience_builder/src/PropShape/PropShape.php).
array_map() (Line: 61)
Drupal\experience_builder\PropShape\PropShape::resolveSchemaReferences() (Line: 36)
Drupal\experience_builder\PropShape\PropShape->__construct() (Line: 40)
Drupal\experience_builder\PropShape\PropShape::normalize() (Line: 101)
Drupal\experience_builder\PropShape\PropShape::getComponentPropsForMetadata() (Line: 167)
Drupal\experience_builder\Plugin\ComponentPluginManager->propHasStorablePropShape() (Line: 156)
Drupal\experience_builder\Plugin\ComponentPluginManager->componentMeetsRequirements() (Line: 97)
Drupal\experience_builder\Plugin\ComponentPluginManager->setCachedDefinitions() (Line: 214)
Drupal\Core\Plugin\DefaultPluginManager->getDefinitions() (Line: 588)
experience_builder_rebuild()
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: 446)
drupal_flush_all_caches() (Line: 34)
experience_builder_install() (Line: 748)
Drupal\Core\Extension\ModuleInstaller->invoke() (Line: 368)
Drupal\Core\Extension\ModuleInstaller->install() (Line: 83)
Drupal\Core\ProxyClass\Extension\ModuleInstaller->install() (Line: 504)
Drupal\system\Form\ModulesListForm->submitForm()
call_user_func_array() (Line: 105)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers() (Line: 43)
Drupal\Core\Form\FormSubmitter->doSubmitForm() (Line: 589)
Drupal\Core\Form\FormBuilder->processForm() (Line: 144)
Drupal\autosave_form\Form\AutosaveFormBuilder->processForm() (Line: 321)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 97)
Drupal\autosave_form\Form\AutosaveFormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 183)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)

Site is now dead. Can't drush pmu as getting experience_builder: The <em class="placeholder">Experience Builder</em> field type is used in the following field: node.field_xb_demo. I'll reload from scratch.

@dunx in #16: 0.1.0-alpha1 was just a snapshot in time. It gets zero updates. This bug was fixed in the 0.x branch and will ship only in 0.2.0-alpha1 in a few months — no other releases will happen.

If you want to test XB in its current shape, you must install 0.x-dev 😊

Hmm... just got this but I'm using 0.x. I'll see if I can figure it out.

UPDATE: Ignore... for some reason, head was detached, just like mine, so all sorted.

I had the same issue as @dunx - I followed the composer instructions on the project page:

composer require 'drupal/experience_builder:^0.1@alpha'

Having the same issue with a broken install that I can't revert from.

I know it's in the works but it would be great if this 0.2@alpha could get released soon so others don't have this gotcha.

https://www.drupal.org/project/experience_builder/releases/0.2.0-alpha1 is out. You still need to follow the instructions in CONTRIBUTING.md though. #3510892: Allow XB to be gradually adopted: make XB's viewing (formatter) and editing (`ApiLayoutController::get()`) work with an empty XB field will ease that 👍

I haven't gotten a response to #7 from @lauriii in almost 4 months. I don't want to keep this issue open any longer. I'll ping him one more time and he can then remove the tags when he answers it. 👍

Sorry for dropping the ball here. What I was thinking in #6 was providing a new property for SDCs to opt-out from XB, e.g., hideFromUi: true. This would allow indicating that a specific component never makes sense to be displayed in XB. Because this is opt-out, this doesn't go against the original principle in my mind.

Created #3513078: Provide an opt-out for hiding a SDC component from XB for following-up on Lauri's proposal.