- Issue created by @wim leers
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
Discussed
#explicit-input-schema-change-strategies
in detail with @longwave just now. Here are the meeting notes:- @longwave came up with a really really interesting proposal in
#3501708-9: [SPIKE] Prove that it's possible to apply block settings update paths to stored XB component trees â
for allowing us to reuse all of the existing block update path logic, seemingly without the need for additional logic/burden on block plugin maintainers!
However âĻ it can't actually work because we won't know which of those post-update hooks are associated with which block plugins! In theory, we could run all those block-targeting post-update hooks, but then we'd need to track for every single block-sourced component instance which update hooks have already been executed (equivalent to how core does the system-wideUpdateRegistry
). That doesn't scale, just like it doesn't scale to update potentially millions of (revision) rows. - We agreed that different update strategies (perhaps the 3 in
ExplicitInputSchemaChangeStrategyEnum
in the current IS) will be necessary. And there may be a need for even more. It really depends on how a particular component source functions. Future ones: layout types, paragraph types, web components, external API shenanigans, etc. â it's literally anything. So we cannot lock ourselves into one corner. - âĻ but short-term, the primary challenge is block plugins. (Worst case: we disable the SDCs and code components which add new required properties and let đą [META] Robust component instance error handling Active handle it for us until that SDC/code component is edited and gets the missing props.)
- The "track different explicit input schema versions" part described in the sibling meta â needs massive rethinking because "provider version" is meaningless in a world of post-update hooks (which is the block plugin reality today!)
Conclusion: both my ideas (articulated in this issue + #3520449) and @longwave's (at #3501708-9) have been invalidated đ But we both agree that đ Calculate field and component dependencies on save and store them in an easy to retrieve format Active is an important step towards more clarity on how we might solve this.
- @longwave came up with a really really interesting proposal in
#3501708-9: [SPIKE] Prove that it's possible to apply block settings update paths to stored XB component trees â
for allowing us to reuse all of the existing block update path logic, seemingly without the need for additional logic/burden on block plugin maintainers!
- đŦđ§United Kingdom catch
Opened đ Block plugins need to be able to update their settings in multiple different storage implementations Active in relation to #22.
- đĻđēAustralia larowlan đĻđēđ.au GMT+10
I think we're missing đ [PP-1] Implement client-side validation of block settings Active in the scope here - at present we're relying on the 'jsonSchema' of SDC (and via the ephemeral SDC plugin in Code components) to show validation errors in the UI but we don't have another source component that has clientside validation so can't be sure the API is ready
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
đ Expand `::getClientSideInfo()` test to all ComponentSource plugins Active and đ Auto-saved Javascript Components CSS changes do not work with CSS aggregation Active landed đĸ
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
Replacing #3497990 with đ Handle components without HTML wrappers Active per @lauriii at #3497990-18: [later phase] Support Block's PreviewAwarePluginInterface (and similar for other component sources) â .
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
Added đ JS component slots don't appear in the preview canvas until published Active .
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
đ Previews of SDCs with default image props broken Active landed a while ago. đ ComponentMetadataRequirementsChecker::check() should validate that the example(s) actually match the JSON schema Active landed just now.
đ Make menu blocks (block.settings.system_menu_block:*) fully validatable Active landed in core.
- đŦđ§United Kingdom longwave UK
đ JS component slots don't appear in the preview canvas until published Active was fixed in đ Hovered preview for JS components in library not working Active
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
- đĻđēAustralia larowlan đĻđēđ.au GMT+10
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
- đĒđ¸Spain penyaskito Seville đ, Spain đĒđ¸, UTC+2 đĒđē
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
New category in the issue summary: . Prompted by the addition of đ Image upload breaks after optional image without an image gets published Active .
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
Also marked ⨠Consider adding "in_preview" var to components Active as less urgent.
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
#3523496 was in there twice đ
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
Moved đ SDC prop of `type: string` with empty string listed in its `enum` results in broken input UX Active to "discovery" thanks to superb feedback from somebody in the community I've not seen before â wonderful way to start the day :)
Also: đ Ensure XB works with CSS + JS aggregation, including for (auto-saved) code components Active landed!
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
Landed:
- đ Cannot delete JS components due to component depending on them Active
- đ Components sourced from JsComponent are missing source component cacheable metadata Active
- đ Only run XbTwigExtension inside XBPreviewRenderer Active
- đ Handle update and delete of Block component config entities Active
Added: đ Include compiled CSS from global asset library when displaying component library preview thumbnails Active .
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
Updated the issue summary to more clearly distinguish between:
- beta blockers (i.e. necessary for đą Milestone 1.0.0-beta1: Start creating non-throwaway sites Active )
- stable blockers (i.e. necessary for đą Milestone 1.0.0: Production Sites Postponed )
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
đ Include compiled CSS from global asset library when displaying component library preview thumbnails Active landed.
Removed đ [later phase] Support props defaults that have config dependencies Postponed , because that belongs in đą [META] Production-ready data storage Active , where it is already being tracked.
Moved đ Handle components without HTML wrappers Active and đ After deleting all the components from the canvas, "Add section" button should be visible on the canvas Active to stable blocker (but in order to understand whether that's appropriate, I actually âĻ kinda ended up completely fixing that last one đ )
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
Triaged the list of issues tagged â . Added the following missing stable blockers:
- đ ComponentSourceInterface::inputToClientModel needs to support passing an entity Active
- đŦ SDC prop "description" is not used as the form element description? Active
- đ [Needs design] Previews of pages containing (dynamically) empty blocks are malformed Active
And also one overlooked beta blocker: Assigned to: wim leers đ Leap ahead of #3493070 in core: SDC `enum` props should have human-readable labels: use `meta:enum` Active
Now that triaging is done, I realized/discovered that only 3 known beta blockers remain:
sdc,js
: Assigned to: wim leers đ Leap ahead of #3493070 in core: SDC `enum` props should have human-readable labels: use `meta:enum` Activesdc
Assigned to: partyka đ ComponentMetadataRequirementsChecker::check() should validate no prop is of type object Activesdc,js
: đ SDC prop of `type: string` with empty string listed in its `enum` results in broken input UX Active- â AFAICT fixed by a larger infra issue, being confirmed.)
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
Added đ Consider renaming the 'inputs' column on ComponentTreeItem to 'input' Active as a stable blocker.
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
đ Handle update and delete of SingleDirectoryComponent `Component`s, plus missing config dependencies Active was confirmed as a duplicate đ
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
Added đ DX & authoring experience: for SDC+code components, the example is treated as the default, may not be desirable Active to a new section.
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
Added these stable blockers:
- đĻđēAustralia larowlan đĻđēđ.au GMT+10
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
Added đ Auto-saving of blocks needs to handle string-to-bool fixing Active .
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
Added đ Preview is not accurate for the site branding block Active .
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
Added đ Disabled SDC components are re-enabled after cache rebuild Active as a new beta blocker.
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
đ Disabled SDC components are re-enabled after cache rebuild Active landed.
Down to one remaining beta blocker again: đ Leap ahead of #3493070 in core: SDC `enum` props should have human-readable labels: use `meta:enum` Active .
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
Added @phenaproxima's đ Consider renaming ComponentSource plugins to ComponentType Active .
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
The beta parts are 99% done đĨŗ â the only remaining one is đ Leap ahead of #3493070 in core: SDC `enum` props should have human-readable labels: use `meta:enum` Active , which is in the final stages, and the "land upstream support for this" part is already complete: ⨠Enum vales do not have translatable labels Active . đ
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
Moved đ Handle adding page title to content Active here from đą [META] Production-ready client-side data model + internal HTTP API Active .
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
New stable blocker: đ block__content div is omitted from preview when "Use Experience Builder for page templates in this theme." is enabled Active .
- đēđ¸United States bnjmnm Ann Arbor, MI
wim leers â credited bnjmnm â .
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
Given #3526644-9: Add xb transform to webform block storage so that it works with Experience Builder â , I think we actually need something like the
all-props
SDC but for block plugins.I suspect we actually need to expand what
\Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\BlockComponent::checkRequirements()
does, because block forms can use arbitrary render arrays, and those are definitely not guaranteed to just work in XB.So I think
BlockComponent::checkRequirements()
would at minimum need to be expanded with calling::blockForm()
and traversing it to see if only "known to be working"#type
s are present đCrediting @bnjmnm for putting #3526644 on my radar!
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
Together with @bnjmnm I articulated a proposal at #3500795-8: [PP-2] Implement client-side validation of block settings â đ
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
Added đ Follow-up for #3500386 Active as a stable blocker.
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
- đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
âšī¸ @lauriii decided to descope a stable
ComponentSource
plugin API to after 1.0. It'll still be around for contrib to experiment, but we won't have the time to actually make it a stable PHP API with a BC promise before DrupalCon Vienna. - đ§đĒBelgium wim leers Ghent đ§đĒđĒđē
- Added đ Integer BlockComponent inputs (i.e. block settings) are incorrectly saved as strings Active .
- Closed đ Define how block settings should be presented in the UI Active .
- Landed đ ComponentSourceInterface::submitConfigurationForm and validateConfigurationForm are never called Active , which allowed closing đ Auto-saving of blocks needs to handle string-to-bool fixing Active .