Closed (fixed)
Project:
Display Builder
Version:
1.0.x-dev
Component:
UI/UX/Islands
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
4 Jul 2025 at 15:04 UTC
Updated:
3 Mar 2026 at 15:51 UTC
Jump to comment: Most recent
Comments
Comment #2
pdureau commentedComment #3
juc1 commentedComment #5
juc1 commentedComment #6
pdureau commentedComment #7
pdureau commentedHi @juc1, thanks for the work, can you:
The prefill of group value with the SDC group is unexpected but looks like a good idea :) Maybe we can do the same with other sources ?
Then, users will be able to edit the group in admin UI anyway.
Comment #8
juc1 commentedok will update...
Comment #9
pdureau commentedComment #10
juc1 commented@Pierre is it ok now? or let me know anything else...
Comment #11
juc1 commentedComment #12
pdureau commentedHi @juc1,
Thanks for your proposal and proposing cool additional mechanisms like the prefill of the value. It is very lovely.
Review
However, I am a bit concerned this little feature became a +233 LOC addition with:
ComponentPluginManagerdependency inApiControllerComponentSourcedata structure logic inApiController::saveAsPreset()ComponentPluginManagerdependency inPresetLibraryPanelWe need to keep parts of the architecture cleanly separated.
ApiControllerandPresetLibraryPanelmust not be aware ofComponentPluginManagerandComponentPluginManager, because there must be the Source API as a proxy in-between.Proposal
What do you think about proposing to UI Patterns' team to add something like:
SourceInterface::getGroup(array $data = []): stringSourceWithChoicesInterface::getGroupedChoices(): arraySo:
PresetLibraryPanel::getComponentPresetGroup()can becomeSourceComponentSource::getGroup()PresetLibraryPanel::getBlockPresetGroup()can becomeBlockSource::getGroup()PresetLibraryPanel::getOtherSourcePresetGroup()can becomeSourcePluginBase::getGroup()That's all for the scope of this issue. After that, we can create a follow-up ticket to use the new methods to get rid of
BlockLibrarySourceHelperbecause most of the logic here will reside in Source plugins themselves.Let's discuss :)
Comment #15
juc1 commented@ Pierre yes of course you are right - display_builder should not be trying to work out group id's. Instead it should be asking ui_patterns for the group id. Shall I open an issue in ui_patterns to add the two new methods to the api so that ui_patterns can provide the group id?
Comment #16
pdureau commentedHi @juc1,
I will push an additional commit to your MR with the move of the logic.
We have a look together. If we like that, we create an UIP2 issue with the proposal.
Comment #17
pdureau commentedBack to Juc1 :)
A little tip: you can move the initialization logic from ApiController to PatternPreset entity by making
$groupnullable:and extending
::getGroup()method:Comment #18
pdureau commentedWe will also need a unit test for this
Comment #19
juc1 commentedComment #20
pdureau commentedThanks, i will have a look and add a commit with the documentation update.
Comment #21
pdureau commentedThanks for the incredible work, with a lot of clear comments and a kenrel test.
I will do 4 little changes before RTBC:
php-cs-fixer(not mandatory but some team members run this linter locally, so it will make their life easier)::getGroup()in\Drupal\display_builder\Plugin\UiPatterns\Source\ComponentSource(this class is temporary, it will be move to UI Pattenrs later, but it will already be useful to get the implementation)::getGroup()logic change.::getGroup()is used only when creating the pattern preset.Comment #22
pdureau commentedWe did it!
Comment #23
juc1 commented💪😍
Comment #25
mogtofu33 commentedAdded a better cache for presets to avoid too much cache when refreshing a Display.
Removed a lot of comments, refactor some nested code, please keep it clean and simple.
When using AI please review beforehand.
Needs to work on this source::getGroup() which needs to be removed if not used as it is now.
Comment #27
mogtofu33 commented