When a "Paragraphs (stable)" widget is used, which uses a long list of dropdowns, those items are only "hidden" with CSS, which means they are still present and causing a very long gap of whitespace at the end of the page.
Create a component which uses the "Paragraphs (stable)" widget display type. Create or edit an item. See large white space gap.
Or with only core:
core/profiles/demo_umami/modules/demo_umami_content/demo_umami_content.module:<?php
/**
* Implements hook_entity_operation().
*/
function demo_umami_content_entity_operation(\Drupal\Core\Entity\EntityInterface $entity) {
$operations = [];
for ($i = 0; $i < 50; $i++) {
$operations['dummy_' . $i] = [
'title' => t('Dummy ' . $i),
'url' => \Drupal\Core\Url::fromRoute('<front>'),
'weight' => 50,
];
}
return $operations;
}
Update the Claro theme CSS `dropbutton.css` file for `.dropbutton-wrapper:not(.open) .dropbutton__item:first-of-type ~ .dropbutton__item` items to have a height of 1px, see #12
Review
Before
After
N/A
N/A
N/A
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | after.png | 578.9 KB | utkarsh_33 |
| #18 | before.png | 371.76 KB | utkarsh_33 |
| #9 | 3374464-9_admin_content_AFTER.png | 48.36 KB | luenemann |
| #8 | 3374464-8_admin_content_BEFORE.PNG | 29.72 KB | luenemann |
| #2 | 3374464-1.patch | 402 bytes | vpa24 |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes, plain diff MR !4382
Comments
Comment #2
vpa24 commentedThanks, @jennypanighetti, I created a new patch to address the issue.
Comment #3
jennypanighetti commentedThat works great, thank you so much!
Comment #4
vpa24 commentedComment #5
luenemannThis isn't fixed / committed.
Setting to needs review to run tests.
Comment #6
luenemannComment #7
smustgrave commentedIs this replicated in core without a contrib module?
MR should be updated for 11.x as it will have to land there first to be backported.
Comment #8
luenemannIS update for Steps to reproduce.
Comment #9
luenemannAfter screenshot:
But the proposed solution reverts a change in #3168326: Dropbuttons in table cells are potentially unusable if it includes options with long text length..
Comment #10
luenemannI'm unsure if this is a won't fix or a regression on #3168326: Dropbuttons in table cells are potentially unusable if it includes options with long text length..
Maybe #1899236: Add new Splitbutton render element to eventually replace Dropbutton can solve this.
Comment #11
smustgrave commentedCan confirm the issue with the hook suggested in IS.
The MR 4382 did solve the issue.
Think it would be good to get this in now as the other may take a bit longer as it's a bigger fix.
Comment #12
bnjmnmThis reverts a UI fixm in #3168326: Dropbuttons in table cells are potentially unusable if it includes options with long text length. that prevented dropbutton items from being available to users.
It might be possible to get it working with setting
.dropbutton-wrapper:not(.open) .dropbutton__item:first-of-type ~ .dropbutton__itemto a very tiny height. This means they would still occupy the width needed to keep the fix intact, but it won't consume that vertical space when the button is closed.Comment #13
vpa24 commentedHello @bnjmnm, I think we can't use both
visibility: hidden;anddisplay: none;together, and it doesn't make sense, as they serve similar purposes of hiding elements but in different ways.When you use
visibility: hidden;the element becomes invisible, but it still occupies space on the page. On the other hand, when you usedisplay: none;the element is completely removed from the layout.Comment #14
bnjmnmRe #13
I see you mentioning my name as if you're responding to my suggestion in #12, the content of your response has nothing to do with my recommendation.
To reiterate, I'm saying don't change the visibility rules at all. Instead, set the height of collapsed splitbutton items to a very small height. That way they consume the horizontal space needed to retain the fix from #3168326: Dropbuttons in table cells are potentially unusable if it includes options with long text length. but occupy a very small amount of vertical space thus fixing the problem reported.
Comment #15
vpa24 commentedComment #16
bnjmnm@vpa24, do not switch this to 10.1.x - 11.x is the dev branch for Drupal. 10.x releases are tagged from it. It's a little confusing but when in doubt just keep it at 11.x
******************
Reminder the solution I suggested in #12 & #14 should work, for those interested in seeing this addressed.
Comment #18
utkarsh_33 commentedHi Ben I added the height to the required element and it seems to work fine.Attaching the screenshots for the same
Before:-
After:-
Comment #19
utkarsh_33 commentedComment #20
smustgrave commentedCleaned up the issue summary some using the screenshots posted by @Utkarsh_33.
Solution seems good and matches the recommendation by @bnjmnm in #12
Comment #21
nod_can we add a comment as to why we need to have the height changed in the CSS? I'm sure i'll wonder why it's there in a few months.
Comment #22
utkarsh_33 commentedComment #23
smustgrave commentedComment added.
Comment #29
nod_Committed and pushed bc18f36525 to 11.x and f0fefd6153 to 11.0.x and 7ca75f443f to 10.4.x and c86c46871a to 10.3.x. Thanks!