- Issue created by @pdureau
- Assigned to just_like_good_vibes
- First commit to issue fork.
- Status changed to Needs review
about 2 months ago 4:09pm 20 July 2024 - 🇫🇷France just_like_good_vibes PARIS
i proposed something to tackle this issue.
instead of discarding all blocks having blockSubmit (almost all blocks have it..)
i proposed to be a little more precise.
we whitelist some blocks based on their id (system_menu_block...) or their provider (views, layout_builder, ui_patterns_blocks..)
and then we remove the other ones which have implementation of blockSubmit.still not perfect but allows to use the source with a set of blocks, which are supposed to work.
let's review and test please
- Status changed to Needs work
about 2 months ago 4:24pm 20 July 2024 - 🇫🇷France pdureau Paris
interesting. So, we do like Layout Builder is doing?
// @todo Add a way to alter this list properly (hook, event, etc).
indeed :)
$whitelisted_blocks = [ "id" => ["search_form_block", "system_menu_block"], "provider" => ["layout_builder", "ui_patterns", "ui_patterns_blocks", "views"], ];
do we whitelist
ui_patterns
&ui_patterns_blocks
's blocks now we have ComponentSource? - 🇫🇷France just_like_good_vibes PARIS
to answer your questions,
i think layout_builder blocks are not shown here... so we can remove it safely from the whitelist.about "ui_patterns", "ui_patterns_blocks" blocks, maybe you are right, we could remove them.
the only reason i see now to desire a block VS a component, would be to have the "title" of the block or a specific template associated to it..
- 🇫🇷France pdureau Paris
i think layout_builder blocks are not shown here... so we can remove it safely from the whitelist.
I was not talking about layout_builder blocks. I was just telling this whitelist idea seems to look like what LAyout Builder is doing.
about "ui_patterns", "ui_patterns_blocks" blocks, maybe you are right, we could remove them.
the only reason i see now to desire a block VS a component, would be to have the "title" of the block or a specific template associated to it..
We don't care about specific block template. One of the long term goal of UI Suite is to get rid of
node.html.twig
,user.html.twig
,field.html.twig
,block.html.twig
,views.html.twig
...So, let's remove them from the whitelist.
- Status changed to Needs review
about 2 months ago 7:54pm 20 July 2024 - 🇫🇷France just_like_good_vibes PARIS
yes i agree with you, i was just raising questions :)
the code is not perfect yet, but we have now more confidence in the fact it will work,
but not with all possible blocks.
what about custom blocks which would have a blockSubmit but without breaking the config structure VS blockForm structure.
do we introduce a mechanism to allow blocks to be whitelisted?
or an advanced option where the user has access to the full list without our recent filtering? - Status changed to Needs work
about 2 months ago 8:00pm 20 July 2024 - 🇫🇷France pdureau Paris
what about custom blocks which would have a blockSubmit but without breaking the config structure VS blockForm structure.
Custom blocks as content entity ? We are not supporting them because embedding such a block in a config entity will create a dependency from config to content, which is something to avoid in Drupal.
Maybe we can add a comment in the code to tell about this decision? And also why we are not supporting BlockSource?
Also, do you plan to do this:
// @todo Add a way to alter this list properly (hook, event, etc).
- Status changed to Needs review
about 2 months ago 12:54pm 21 July 2024 - 🇫🇷France just_like_good_vibes PARIS
ok, i found a real better way to handle the filtering.
Part of the filtering "job" was already done in. ui_patterns.module in the ui_patterns_plugin_filter_block__ui_patterns_alter function.
Indeed, we use the consumer "ui_patterns" in the BlockSource source plugin to gather the list of blocks.In ui_patterns_plugin_filter_block__ui_patterns_alter, we place a boolean marker inside each block plugin definition :
'_ui_patterns_compatible' (similar to '_block_ui_hidden' ?).
This marker is used in BlockSource plugin to filter the block definitions when the marker is false.The idea of the marker is to allow other modules to interact with the decision placed inside the marker.
If one wants a block to be blacklisted or whitelisted, it should implement the hook hook_plugin_filter_TYPE__CONSUMER_alter()
with 'block' as TYPE and 'ui_patterns' as CONSUMER and do the following thing :
- case 1 : the hook implementation is called before our hook implementation in ui_patterns.
A module can place a value '_ui_patterns_compatible' inside some block definitions (before ui_patterns place its value). It will force the value, as ui_patterns won't touch the value decided. It will force the blacklist of the whilelist of those marked blocks.- case 2 : the hook implementation is called after our hook implementation in ui_patterns.
The module simply override the value '_ui_patterns_compatible' on the desired blocks. I will therefore blacklist or whilelist those blocks based on the value written.please review :)
- 🇫🇷France just_like_good_vibes PARIS
i rebased the MR and i removed the "required" plugin_id to ease removal (allow to fix https://www.drupal.org/project/ui_patterns/issues/3462502 🐛 [2.0.0-beta1] No way to remove Content Active )
-
pdureau →
committed 737cc6c1 on 2.0.x authored by
just_like_good_vibes →
Issue #3460784 by just_like_good_vibes, pdureau: Add a whitelist...
-
pdureau →
committed 737cc6c1 on 2.0.x authored by
just_like_good_vibes →
- Issue was unassigned.
- Status changed to Fixed
about 2 months ago 5:18pm 22 July 2024 Automatically closed - issue fixed for 2 weeks with no activity.