The CSS for the durations overlay seems to be using position:absolute, which means that the overlay appears in a fixed location tied to the bottom of the page. If the page is really tall, the overlay won't be visible until you scroll down.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | smd-after.PNG | 12.17 KB | angel_devoeted |
| #12 | smd-before.PNG | 11.95 KB | angel_devoeted |
| #4 | Screenshot_2024-11-04 12.18.11_g5Hbuo.png | 120.72 KB | gribnif |
| #4 | Screenshot_2024-11-04 12.11.49_V7HSe7.png | 121.4 KB | gribnif |
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
Comments
Comment #2
mandclu commentedWhat admin theme are you using?
Comment #3
mandclu commentedI have tested this in both Gin and Claro, and it works as expected. Unless I get detailed steps to reproduce on a fresh install or Drupal, I don't have a path forward.
Comment #4
gribnif commented1. Set up a test site using the evaluator guide: https://www.drupal.org/node/2997977
2. Install smart_date:
composer require 'drupal/smart_date:^4.2@beta'3. Create a new content type with a Smart Date Range.
4. Change the form display mode to Smart Date|Classic and move the date field to the top of the page. These are the options I used, to match my original site:
5. Add a new node using this content type. The default theme is Claro. This is what I see:
Comment #5
mandclu commentedAh OK, so the issue is specific to the Classic widget. That shouldn't be an overly difficult fix.
TBH I have been thinking of deprecating the Classic widget. Can I ask why you decided to use that one?
Comment #6
mandclu commentedComment #7
gribnif commentedI'm not entirely sure. I think it's simply because we've been using Smart Date since this was the only option. I just tried using Inline Range instead and, after some minor changes to the form_alter() hook we're using to set custom default values, I think it will work just fine--and it avoids the problem described above.
Comment #8
nicholassWe also ran into this bug, long time Smart Date users, and didn't even know new form display options existed. Seems like you could also fix the classic with a "position: relative" on the end date. We don't mind updating away from Classic, but probably lots of long term users of the module need notified to update their settings.
Comment #9
richarddavies commentedSame as previous comment, we're also long time Smart Date users who are having this issue with our Classic widgets (and were unaware there were newer options now.)
Can I ask why this 1+ year old issue hasn't been fixed yet if it's an easy fix? Presumably, you still support the Classic widget since it's still an option, right?
This seems to fix it for us, but there may be a better solution:
Comment #11
mandclu commentedThanks for the code suggestion! I rolled it into an MR. I would appreciate feedback from others who have experienced this issue
Comment #12
angel_devoeted commentedThe fix works as expected, but the selector
.smartdate--widget .time-end div.form-item:nth-child(2)has unnecessarily high specificity (0,4,1). Wouldn't a simpler selector like.smartdate--widget .time-endbe enough and more maintainable?