Closed (fixed)
Project:
Experience Builder
Component:
Config management
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
27 Aug 2024 at 17:22 UTC
Updated:
23 Sep 2024 at 07:14 UTC
Jump to comment: Most recent, Most recent file

Comments
Comment #2
kristen polNote there are a number of errors in the logs like:
Comment #3
kristen polTested the other components and many have the same problem (all the "shoe" ones). The heading and and hero components let me change their title text. When I upload an image for the image component, I'm redirected which is a different bug obviously but won't add another issue for that for now.
Comment #4
wim leersI predicted this problem, which is why I opened #3469461: New component requirement: each SDC prop must have StorablePropShape, which is almost done and will fix this. Crediting you on that issue for reporting this 👍
Comment #5
kristen polReopening this one.
#3469461: New component requirement: each SDC prop must have StorablePropShape
is marked fixed but I just tried the latest code with a fresh install using these instructions and am getting the same behavior again.
I don't see "Shoe Button" listed anymore, but I tried "Shoe Badge" with similar behavior.
Logs:
Comment #6
wim leersNeeds investigating.
Comment #7
kristen polThis isn't just "shoe badge"... also happens with:
Comment #8
wim leersComment #9
wim leersThis is happening even for the
experience_builder:my-heroSDC.The root cause for the symptom took me 10 seconds to find.
\Drupal\experience_builder\Form\ComponentPropsForm::buildForm()calls$component->get('defaults')['props'][$sdc_prop_name]['field_type'], but not all prop names have an entry in theComponentconfig entity:Full list of props:
headingsubheadingcta1cta1hrefcta2attributesInvestigating why this is happening.
Comment #10
wim leersAnother 10 seconds later, and it's clear
\Drupal\experience_builder\Entity\Component::getDefaultsForComponentPlugin()is the culprit: it's only generating defaults forrequiredprops, instead of all props.So we caused this regression in #3463999: Auto-create/update Component config entities for all discovered SDCs that meet XB's minimum criteria without noticing. How is that possible?
It's possible because the validation of
Componentconfig entities is incomplete, and we know it:experience_builder.schema.ymlcontains this since #3452397: Allow specifying default props values when opting an SDC in for XB:👆 Implementing that will cause
\Drupal\Tests\experience_builder\Kernel\ComponentTest::testComponentAutoCreate()to fail. No need for additional test coverage beyond that.Comment #12
wim leersComment #13
wim leersYay,
There were 57 errors:in https://git.drupalcode.org/project/experience_builder/-/jobs/2602729 🥳Comment #14
wim leersFirst pass at fixing the bug brought the failures down to 40: https://git.drupalcode.org/project/experience_builder/-/jobs/2602877.
But many tests are now failing because some plugins cannot be found: in kernel tests, all module dependencies must be explicitly installed. This is now necessary because the validator is verifying the config entity is consistent with the SDC plugin.
So: installing missing modules next.
Comment #15
wim leersDown to 24 test failures.
Most test failures are now like this:
— https://git.drupalcode.org/project/experience_builder/-/jobs/2603045
Root cause:
\Drupal\experience_builder\Plugin\ComponentPluginManagercreatesComponentconfig entities in\Drupal\experience_builder\Plugin\ComponentPluginManager::setCachedDefinitions().But in this MR, the
Component::save()call happens inside that method, which will trigger validation, which in turn also callsComponentPluginManager. Which then causes these config entities to be created too!Comment #16
wim leersDown to 22 test failures.
The remaining violations look like this:
and
That second one is caused by #3464036: Component config entity should validate that the SDC actually (still) exists not yet being fixed. Let's fix that first. Or fix it here. Whichever is handier.
I think @f.mazeikis and @tedbow can carry this over the finish line!
Comment #18
wim leersComment #19
wim leersClosed #3464036: Component config entity should validate that the SDC actually (still) exists as outdated — @f.mazeikis implemented that as part of this issue.
This is ready for final sign-off by @f.mazeikis. We both worked on this, but he's the owner of 👍😊
Comment #20
wim leersForgot to re-assign to Felix :)
Comment #21
kristen polFor testing, I needed to get the fix from this issue in there:
#3471083: Prop select lists don't affect the component
Comment #22
kristen polThe shoe components are still causing errors.
Try dragging shoe icon or shoe tab panel and you'll see the error popup.
Or drag shoe badge, shoe tab, or shoe tab group and try changing something.
Comment #23
lauriiiI added the shoe icon component and got the following error:
Drupal\Core\Render\Component\Exception\InvalidComponentException: [name] The property name is required in Drupal\Core\Theme\Component\ComponentValidator->validateProps() (line 203 of /var/www/html/drupal/core/lib/Drupal/Core/Theme/Component/ComponentValidator.php).I changed a value for the shoe tab component using the right sidebar and got the following error:
I changed a value for the shoe badge using the right sidebar and got the following error:
I changed a value for the shoe tab group using the right sidebar and got the following error:
I'll let @wim leers and/or @f.mazeikis to decide if this is something that should be fixed here or in a follow-up issue.
Comment #24
lauriiiIt seems that #23 might be related to #3471511: `enum` data shapes: error when choosing "- None -" in `<select>` but maybe there's an aspect related to booleans that isn't being tracked there currently?
Comment #25
wim leersThe boolean shenanigans reported in #23 are indeed unrelated.
The goal of this issue is to be able to render the
ComponentPropsFormwithout triggering the PHP warnings reported in #3. That it does 👍If I interact with the boolean field widget, I can also reproduce
This is being worked on in #3462310: Component props form: map textarea, bool, and select elements to React components. The root cause is the request to update the preview after interacting with the boolean field widget, which sends this data from the client to the server that indeed violates the JSON schema, because both
pillandpulsemust be booleans, not strings nor integers:Comment #26
kristen polSo if both this and that issue are fixed then there will no more fatal errors when using the prop forms for ALL XB example components? If so, ETA on both?
Comment #27
wim leersYes, for all XB components. With the exception of the special
all-propsSDC, which we're using to be able to test/develop missing pieces. But that's not an SDC that is installed by default.Utkarsh is testing the combination of this issue's MR with that one 👍 — @bnjmnm pushed that other MR forward last night, so IDK the latest state. Based on his findings, an ETA should become possible to provide.
Comment #29
wim leersComment #30
wim leersNext up: #3469684: Surface the REASON for an SDC not being made available in XB (i.e. not meeting criteria) 🥳
Comment #31
kristen polThanks. I tested and found the following:
1. Shoe button is missing... not sure why and didn't debug but maybe due to the variant info?
2. Shoe badge and shoe tab are "working" (other than the boolean true/false issue that I reported).
#3472179: [PP-1] Can't toggle boolean prop back to true after changing to false
3. Shoe icon and shoe tab panel have known fatal error:
#3467954: META: Evolve XB UI's data model to allow non-SDC components' inputs, DynamicPropSource support, etc.
4. Sidenote that there are a lot of these:
as well for some reason.
Comment #32
wim leersnameis de facto an unsupported prop name right now, and that must be fixed, too