Regarding the experience I had with https://www.drupal.org/project/eca_entity_share →
And regarding the approach we do in
https://www.drupal.org/project/ui_suite: →
- one module and sub-modules for Core integrations
- when integrating with another contrib modules we do a separated project.
I think it will be better to have an eca_file_extractor dedicated project so it can live at its on speed.
POC working.
Need to clean up:
- removing useless code
- removing code duplication
- rename classes to remove DisplayBuilder prefix
Click o this link to edit the display
Typo on "on"
Thanks @jurgenhaas for the review!
@das-peter Can you update the MR regarding the review points please?
Then I will finish code quality stuff.
Thanks @riyas_nr for the MR.
Looks good!
I put a review comment and pipeline needs to pass.
Currently in https://git.drupalcode.org/project/svg_image/-/blob/3.x/modules/svg_imag...
For an SVG, it is just rendered as SVG markup. If wanting an img, if render an image (and not a responsive image) using the fallback image style.
If this is the kind of examples you wanted. Not the best.
Maybe it is just an unsolvable feature.
About PHP attribute conversion of the last code review, in 📌 [meta] Convert test metadata from annotation to attribites Active it is stated:
we can't mix PHPUnit attributes and annotations [in a single file], we will have to convert them all at once unfortunately
So updating the code changed in the MR would require changing code out-of-the-scope of this issue.
If a code conversion in the Contextual module happens before the merge of this issue then I will update it, otherwise I prefer to keep it aligned with the module current codebase.
Hi,
Thanks for your interest in the module and for the MR.
I will ping on ECA slack channel, to ask for a review from people more accustomed to ECA code to ask if the implementation is correct. even if it looks great!
Then I will handle the code quality parts. As it has been a long time since the pipeline has been executed, PHPStan and Coder rules had evolved since then.
Hi,
Try this in your settings.php:
$settings['container_yamls'][] = $app_root . '/sites/development.services.yml';
$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null';
$settings['cache']['bins']['page'] = 'cache.backend.null';
$settings['cache']['bins']['render'] = 'cache.backend.null';
The problem is that preventing the usage of cache and having that re-computed at each page refresh is a performance killer.
In this case an opt-in should be provided to allow to explicitly choose that you want to disable the render cache for this field.
g4mbini → credited grimreaper → .
Thanks for the link, I will give a look.
It would be better to avoid the need a contrib module for that, and Core to be able to handle it by itself.
MR now targeting 11.x.
Rebased.
And changes updated to handle dev version of packages.
Still not 100% the scenario why you would comment out the actions
It is just to provide simple steps to reproduce.
There is a theme key "top_bar_page_actions", so potentially plugins (contrib or custom) could also use the same theme key without needing "#page_actions".
Put TODO in issue summary
TODO:
- Add dependency on Navigation module
-
✨
Change MockEntity into real content entity
Active
to work with test display builders
- Fix JS to work with toolbar elements outside of .display-builder
- Fix/limit side effects of Navigation CSS revert all in top bar on shoelace components
grimreaper → created an issue.
Tested, ok to allow the module to install on D11.
grimreaper → created an issue.
TODO:
- Fix CSS compatibility between shoelace and Navigation global CSS revert.
- Fix left actions
- Avoid code duplication with controllers after controller refactoring
Steps to reproduce added.
Not sure about existing tests and if a test is needed for an if.
I can't find occurences of "toolbar-dropdown__list" or "toolbar-dropdown__menu", which are the CSS classes of the dropdown in the existing tests folder.
Entity references not properly handled in section library when exporting as default content.
grimreaper → created an issue.
Hi Christian,
Thanks for the new MR.
I have tested it, I confirm that it prevents fatal error when updating from 2.0.4 to 2.0.5 on existing websites.
grimreaper → created an issue.
grimreaper → created an issue.
Hi,
Thanks @finnsky.
I have tested MR https://git.drupalcode.org/project/drupal/-/merge_requests/12843, it fixes the issue.
Changing to RTBC as the test failure in the pipeline seems unrelated.
grimreaper → created an issue.
grimreaper → created an issue.
Ok for me
grimreaper → created an issue.
Maybe the confusion also comes from the default empty label "- Select -"?
Maybe let's change this default empty label to "- Choose a source -" or "- Choose a data source -"?
And for the widget source, like with "[Entity]", "[Field]", etc prefixes, why not add a "[Widget]" prefix? or in this case it is too much and just in a first time changing the empty label as a first step will be enough?
On entity save, if the entity has layout builder override available, redirect to the layout builder page.
Ok for me.
But is it a behavior of the design system done on purpose? Or is there helper or variant foreseen by the design system to prevent this behavior?
Hello,
Please create a MR.
I think you can change the schema version of those modules in key_value table to point to the hook_update_N mentioned in those modules.
Layout then edit
Need to manually set contextual-region class on content block and inside block content.
Paddings target classes intended for views blocks.
wrong tag.
And regarding definition:
It denotes an issue that prevents porting of a contributed project to the stable version of Drupal due to missing APIs, regressions, and so on.
Then not a blocker as it prevents a feature and not a stable version.
grimreaper → created an issue.
Hi,
Thanks to have pushed the MR forward! And glad to have helped!
+1 for RTBC too, I have retested on my contrib project, working fine too!
Just one comment about PHPStan and PHPMD.
TODO:
- welcome block
patch for Composer usage.
I think I found a solution while comparing with Layout Builder module.
Not sure if the same problem but looks similar to what I found in: 🐛 Impossible to save Layout when block with VBO Active
grimreaper → created an issue.
Is the long term solution will be something like in the other MR I created for POC?: https://git.drupalcode.org/project/drupal/-/merge_requests/12799/diffs?c...
I thought there was a link on the project page to https://www.youtube.com/watch?v=TLHlYQXmlMY
Maybe the demo will help understand.
TODO:
- allow to update layout of a dashboard, problem on save, it is not saved
- welcome block
- update permissions
- remove user page blocks
Patch for Composer usage.
grimreaper → created an issue.
grimreaper → created an issue.
grimreaper → created an issue.
grimreaper → created an issue.
Thanks for the quick response :)
grimreaper → created an issue.
Hi,
Should be good with 🐛 Toolbar icon is not displaying with gin theme Active
Patch for Composer usage.
Hi,
It would be nice to have a new release to get this bug fix without needing to apply a patch.
Hi,
I think it should be the same fix as in https://git.drupalcode.org/project/layout_builder_restrictions/-/commit/...
grimreaper → created an issue.
Maybe only needed to squashed commits on MR.
Here is a patch file from the other branch.
Hi,
Thanks for the MR.
I have tested it it works.
But I will create a new MR from 2.0.0 version because patch from current MR can't apply on it.
Added a few patches applied on Sobki Bootstrap and to sync in Sobki DSFR.
Hi,
Thanks for the MR and patch.
Confirm it works!
Ok I found the problem, it is when there are files uploaded in the directory from for example a previous installation.
But the new installation does not have the files registered as file content entities so it can't delete it.
grimreaper → created an issue.
grimreaper → created an issue.
grimreaper → created an issue.
grimreaper → created an issue. See original summary → .
grimreaper → created an issue.