🇺🇸United States @erutan

Explicitly adding dependencies makes it less likely the module will break in the future, at the cost of having to explicitly declare them once. Unless a dependency name changes while it's functions don't or something kind of bizarre like that there doesn't seem to be much of a downside unless I'm missing something obvious.

It's also a bit self-documenting which is nice.

1) yup that's much nicer now.

2) user error on my part, I missed that when setting this up locally (I hadn't set that shortcut before, idk what everyone has on their machine for shortcuts that is editing the site). :)

Outside of the scope of this issue, but it is a little odd it's tucked at the bottom of "Toolbar sticky behavior", since it's only tangentially related to that. Either the header should be something like "Toolbar visibility" or it should be in it's own section. It also wouldn't be terrible if the keyboard shortcuts were just in their own section instead of below what they're related to.

3) Agreed, just seemed worth pointing out since it was related.

Running through changes, the bug occurs due to a change on unique_field_ajax.module from the commit https://git.drupalcode.org/project/unique_field_ajax/-/commit/3376dc740c...

Tested this on macOS 15.5 on latest Arc (chrome), Safari, and Firefox Dev. Same behaviour in all browsers:

1) With this patch opt-a does now bring up focus on the admin toolbar search, but it also inputs "å" into the search. That isn't ideal because you then have to delete that character before typing your search.

2) opt+p has no effect.

3) More advanced mac users will know that alt = option / ⌥, but ideally it'd show "⌥ + a" instead of "alt + a". If this would be trivial to change based on parsing user agent strings that'd be useful. More of a minor/optional QoL issue.

While technically not the smoothness jank in the video, it falls under improving the show/hide transition. If you scroll down slightly and then stop there's a blank gap at the top of the screen. Thiscould happen if someone just needs to read something barely below the fold.

Having the hide event only fire after 79px down or w/e would solve this.

I've been using (abusing?) the ajax API on a project to load form modes and whatnot into a model and having a ?destination= redirect back to the page the view on for doing larger content edits on the fly. I have it in views rewrites as well as templates. :)

<a href="/storage/{{ id }}/edit/?display=FOO&destination=/BAR" class="use-ajax" data-dialog-type="dialog">✍️</a>

This could simply be documented somewhere.

fullcalendar_view iirc has an option where you check a box and then the last field in the view will get loaded in a modal. With rewrites and custom text fields this is a nice workable option.

Thanks for coming back to module mandclu, and taking a deeper look into this issue!

#70 works on my end, though I did not test multi-value ranges.

More explicit steps to reproduce:

1) create another content/storage/etc bundle with a taxonomy field (B)
2) have an entity reference field from the original (A) that references that type (B)
3) Add that entity reference field as a relationship in a fullcalendar view for entity type A
4) Add the taxo field on entity B and confirm that it shows up correctly
5) Under view settings select the taxo field and vocab etc
6) Change colors on the terms that populate
7) Notice that colors are not passed to the calendar

Used a taxo field on entity A works fine and colors are passed, but using a taxo field on entity B on a view for entity A does not work.

This seems to be a duplicate of https://www.drupal.org/project/fullcalendar/issues/3514977 ✨ FullCalendar Event Hover with title, body, event date and URL Active , the other issue has a lot of discussion / momentum on it.

There's built in functionality in fullcalendar that does this already that might be worth looking at vs recreating with a third party solution:

https://fullcalendar.io/docs/event-popover

https://www.drupal.org/project/fullcalendar/issues/3491161 ✨ Allow opening of events in a modal dialog Active appears to be a dupe of this issue.

As indicated in comments #11 and #12, MR 152 only address the issue when using the "Disabled, show on scroll-up" setting. The problem persists if you're using "Enabled" or "Disabled"

I wonder what the difference was between me & @dydave #16 vs @justcaldwell since he was also apparently using 10.4.7 back then. @ressa being on D11 makes the change in behaviour more understandable if there's been an underlying structural issue that has changed as @tirupati_singh is also working off of 10.4.x

FWIW Comment 12 had nothing to do with the MR, it was talking about a CSS only solution presented in comment 10. Comment 11 also never specified the issue was still present in disabled and enabled.

Splitting off the jankyness when the toolbar hides and shows repeatedly as shown in the video in #19 makes sense to me vs blocking this issue with it.

Tested with the latest diff and things are unchanged on my end (so no regressions in my environment at least) in 10.4.8 and 3.6.1. :)

Still present on 3.0.3.

Step to reproduce:

1) Choose an entity/bundle with two or more core date fields.
2) Create a view with fullcalendar as a view display
3) Add date fields to the view

All entries are duplicated.

4) Optionally select two date fields for the view to use.

All entries are duplicated.

I'm not sure how long this will be up, but admin:admin on https://master-tb3wj0kram2h8gdhhswittxkcve9fq07.tugboatqa.com/admin/stru...

A quick skim shows the second module only provides full calendar 3 (not 6) and also includes v1 of the shedular, and doesn't involve packagist.org/composer but focuses on internal drupal libraries with CDN fallback.

Similar in what they want to achieve, but they're not the same.

It's been a while since I looked at this, but to reproduce this simply use non smartdate (core) date fields for the beginning and end dates for a multiday event. The ones I were using were date only, not date+time. I can spin up a new install and document it better if you'd have time to dig into this soon.

The CSS in #10 didn't fix the issue in either my admin or default/site theme. Tested in Safari & Chrome.

The patch from the MR by @tirupati_singh works for me, thanks! It doesn't seem like it'd cause any other issues, the existing disabled and enabled for admin toolbar sticky still work as expected.

Waiting for a 3.7 minor release doesn't make sense as this is a pretty obvious/annoying visual bug IMO. :)

I'm noticing something similar with views tables that have 'sticky headers' enabled. Inspecting it shows it seems to have the correct offset in and of itself:

table.sticky-header thead {
    position: sticky;
    z-index: 500;
    top: var(--drupal-displace-offset-top, 0);
}

It appears properly aligned below the menu bar when it exists, but doesn't pop back up to the top when the admin menu hides itself, which is a bit odd as it just floats in the middle of the table. It reseats itself to the top of the table properly when scrolling up. I can create a new issue, but this sounds like it has the same root cause.

Manually pinning the module at 2.2.1 fixes the issue for me.

erutan → created an issue.

Both of the related issues have been fixed, this should probably be closed as well.

What is there to review? If there's no need for styling then it's working normally?

This has been changed in 2.x dev: https://git.drupalcode.org/project/unique_field_ajax/-/commit/5e6bb43bb1...

Both warning and error are saved for me without this patch on 10.4.7 on 2.2.2.

Not a maintainer, but I think this has been fixed since 2.1.2.

This happens for me both clicking out of the field and using tab.

Drupal 10.4.7, Unique Field AJAX 2.2.2.

I'm just using all day events on my calendar, but in theory this should be loaded after the libraries CSS (the first line will still be present). Might need an !important if things don't cascade as intended.

erutan → changed the visibility of the branch 3.1.x to hidden.

Sorry for the flubs on issue forks, was using a new tool and multitasking :)

erutan → changed the visibility of the branch 3.1.x to hidden.

erutan → changed the visibility of the branch 3.0.x to hidden.

The first step would be to see if fullcalender supports this by finding it in their documentation: https://fullcalendar.io/docs

It seems like you might be able to have a link that fires some js based on https://fullcalendar.io/docs/Calendar-gotoDate

erutan → changed the visibility of the branch 3.1.x to active.

erutan → changed the visibility of the branch 3.0.x to active.

erutan → changed the visibility of the branch 3.0.x to hidden.

erutan → changed the visibility of the branch 3.1.x to hidden.

Wouldn't this and https://www.drupal.org/project/fullcalendar/issues/3520837 🐛 Times being cut off on multiday events Active get added to the bottom of:

https://git.drupalcode.org/project/fullcalendar/-/blob/3.1.x/assets/css/...

This isn't happening for me, 3.0.2 on 10.4.7.

This doesn't apply cleanly to beta4. It applied to beta3, but applying https://www.drupal.org/project/cer/issues/2846318#comment-14841353 📌 Complete Synchronization functionality for existing reference values Needs work beforehand would also have it fail to apply.

Patch no longer applies cleanly to beta4. I tested it against beta3 and it did apply cleanly.

While this isn't really worthy of a major version, in theory this could get bumped to 5.1 with a warning in the release notes to toggle bi-directional back on for all existing CERs. Not elegant or ideal.

I've been using this on 10.4.6 and it's critical for a use case moving forward.

Thanks for documenting the workaround.

Hopefully mandclu has some time to look at the issue queue at some point, but supporting open source on top of a dayjob is a rough task. :)

I'm not a maintainer, unsure if there's a slack channel but I don't think so, nothing showed up in a quick search on drupal slack.

The more information page should send you to the docs for fullcalendar (the actual javascript library), basically the values input into settings just get sent to that. If those two options aren't doing what they should be doing, you could check to see if they're wired up correctly in the module and/or create new issues. Mandclu who created the most recent version of this module seems to be busy at the moment.

You're welcome. :)

My guess is that going off how it used to be implemented might be more work. You may very well be able to just do a copy and then replace variable names etc for an existing setting in this branch - all the module is doing afaik is passing a value input in the drupal settings to the fullcalendar js library that generates the calendar.

Not sure what accordion it'd fall under in terms of organization. Date & Time settings I guess? It'd be useful as a public patch if you get it working as that seems like a not so unusual use case. :)

You could try switching between BEF & default exposed filters https://www.drupal.org/project/better_exposed_filters → and see if there's any change.

This is duplicate of https://www.drupal.org/project/fullcalendar/issues/3497050 🐛 Warning message on installation because settings form does not exist Active , but more focused.

The other issue also edits some labels.

Not a dev, but looking at fullcalendar's docs what you want is to pass a value to https://fullcalendar.io/docs/defaultTimedEventDuration

You could look at the structure of the rest of the settings, pick one to modify to pass values to this value in the event model.

Marking this as a duplicate issue. See:

https://www.drupal.org/project/field_group/issues/3333953 🐛 Nested field groups improperly display as "Disable" in the admin UI Active has a manual workaround

https://www.drupal.org/project/field_group/issues/3085858 🐛 Drag and drop acts weird, sometimes not resetting the parent, or even clearing the region value Needs review has a patch

people mentioned this patch worked for them https://www.drupal.org/project/drupal/issues/3089151 🐛 TableDrag JS :first-of-type issues Needs work

As a workaround for this, you can disable drag and drop and then manually select a tab to go from disabled to content when in the sort by weights mode, save the form, and then go back to drag and drop.

It's a little annoying, but it works.

The workaround patch has been working for me for a while now, but it hasn't been tested by anyone else. I wouldn't say it is fixed, or RBTC, but neither is it active or needs work. Needs review seemed the best status as it indicates that the functionality is considered to be complete but has not been verified by a second party.

I considered putting the patch in issue 3490590, but any discussion about it would seem off topic to a proper solution. 3490590 was linked as a related issue to this one.

I tend to not use Ajax unless I have a good reason to - it's odd in this case as the module is loading the javascript library for fullcalendar anyway.

On a local or dev server try disabling all other contrib modules and then try with/without Ajax? There's often some weird ajax errors when there's a lot of views centric contrib enabled. If that solves the problem, start enabling them until you find the problem one.

erutan → created an issue.

erutan → created an issue.

erutan → created an issue.

If anyone else has this issue, try mvonfrie's patch. If that works, let us know here, if not also let us know then try installing the module a few times, possibly opening the view display the settings in a new tab. :)

Updated the issue summary and added an extra paragraph at the bottom for context.

I don't think it's appropriate to make a MR at this time.

The current release is a different branch entirely.

It'd probably make sense to add a feature request for the 3.x branch.

@dlfaison the ajax/scrolling thing would be a separate issue - it has nothing to do with what you originally posted. If you keep on tagging unrelated issues onto an existing issue then there's no way to set the status of issues correctly - I'd edit the new issue out of this one and create a new issue. There shouldn't be exposed filters if you don't have them set up in the view. Do you have some other contrib installed that interacts with filters?

It sounds like reinstalling the module fixed your original issue? If not I'd recommend trying to apply mvonfrie's patch https://git.drupalcode.org/project/fullcalendar/-/merge_requests/55.diff

I'm able to scroll through a year or so worth of months with AJAX disabled.

The ratio values are just being passed into fullcalendar via it's API... that's how the JS works under the hood.

https://fullcalendar.io/docs/sizing

If you haven't figured this out yet, looking a bit wider the issue in fullcalendar itself (vs this drupal bridge / contrib) could be useful. Perhaps loading contentHeight as well as height would work via custom JS, or make a patch to include contentHeight in the UI?

$('#calendar').fullCalendar({
    height: 'auto',
    contentHeight: 'auto'
});

I just created a new fullcalendar view and can go into settings, make a change, and save the view fine. Existing views work as well.

What other views plugins do you have? I swear that sometimes VERF going bad on one view will impact another, and there's sometimes odd AJAX errors when you're running a lot of contrib.

Drupal 10.4.1
PHP 8.2.27
No smartdate

I'd recommend:

1) Try upgrading to Drupal 10.4.1
2) Look at the actual error in the dev console. This varies by browser but will be googleable.

Ah yeah, good catch.

Also interesting the account has existed for over 9 years but apparently hasn't been active for long.

As per the discussion at https://www.drupal.org/project/site_moderators/issues/3500259 💬 TATA Consultancy Services is bulk posting requests to gain maintainer access to modules Active this person should likely be removed as co-maintainer.

As per https://www.drupal.org/project/site_moderators/issues/3500259#comment-15... 💬 TATA Consultancy Services is bulk posting requests to gain maintainer access to modules Active I'm closing this.

I remembered this from a previous issue on Tablefield (which I felt had a great response):

https://www.drupal.org/project/tablefield/issues/3488566 💬 Offering to co-maintainer TableField Active

Looking at their profile, they were granted maintainership of blocktabs @

https://www.drupal.org/project/blocktabs/issues/3488855 💬 Offering to co-maintain blocktabs Active

Not from TATA, but a similar one credit on an automated security issue and then applying for co-maintainership.

I'll reopen that ticket on blocktabs and link back here. :)

FWIW I've been noticing a lot of offers to co-maintain large projects by new accounts with little contribution or history recently. The usual response is to participate in the projects issue queue, review some patches, fix some active issues, etc.

I've never seen anyone of the accounts in this pattern follow through. I assume it's for clout in terms of getting contracts, though it could become a security issue as well.

Thanks for sharing what you found out - while I know you were looking into taxo and don't expect you to develop outside of that itch does it seem this would also be the case for non reference fields?

I'll close this as a duplicate.

erutan → created an issue.

This still applies cleanly to dev, but ticking those fields and clearing caches do not hide existing tables with dummy "spacer" content.

As per: https://www.drupal.org/project/tablefield/issues/3385030#comment-15228612 💬 After upgrade to D10, empty tablefield output is displaying in paragraph on node Active I rolled back /src/Element/TableField.php from the commit before https://git.drupalcode.org/project/tablefield/-/commit/26d63be6aa25d34d1... and "empty" tables stopped being saved. The interface still spawns an empty table below one with content in it, but as there are no spacers inserted into it it doesn't get saved as content.

This is a pretty brute force approach (and I'm sure there's been updates to that file after this that need to pulled in) but I personally have no need to drag tables but would prefer them not being created every time an entity is saved.

It seems like it'd be simpler to just not save any tables/cells that only have the spacer in them, but there could also just be a patch that rips out the drag and drop stuff and keeps up to date with current changes to the file.

@thetwentyseven not seeing that on my side. Do you have steps to reproduce?

erutan → made their first commit to this issue’s fork.

From a functional perspective this works on 10.3.10 when applied with the related fix in https://www.drupal.org/project/fullcalendar/issues/3241489 🐛 Fix fullcalendar_field_is_date() re: non-entity Views fields (e.g. 'Custom text') Needs review and there are no phpstan errors introduced. A custom field consisting of box text and a token of another field in the view was used and rendered properly.

Can't vouch if there's a tighter way to do it.

Airplane WiFi sucks but composer was finally able to patch the module. :p

erutan → created an issue.

Tested the issue branch with mandclu's commit and custom fields can be added to the view without errors and the view renders fine in Drupal 10.3.

That does look like a better approach to scope it. :)

erutan → created an issue.

Sorry about missing that - I have phpstan running in my dev environment again though that should have been obvious.

It seems the typo from ten years ago was putting [rebuild] on a new line (as well as duplicating it), rebuild seems to just be there to help restructure the data and then isn't needed after.

elseif (!empty($values['tablefield'])) {
      $values['rebuild'] = $values['tablefield']['rebuild'];
      $values['value'] = $values['tablefield']['table'];
      unset($values['tablefield']['rebuild']);
    }

The elseif statement below it only unsets rebuild.

elseif (!empty($values['value']['tablefield'])) {
      $values['rebuild'] = $values['value']['tablefield']['rebuild'];
      $values['value'] = $values['value']['tablefield']['table'];
      unset($values['value']['tablefield']['rebuild']);
    }

Does that seem right?

@lolandese any thoughts on this?

Sorry for taking a while to get to this. :)

It still applies cleanly to dev.

Tablefields still keeps adding empty tables every time I save an entity with a tablefield field with this patch. This happens with existing entities, new entities, entities with empty tablefields or ones with data.

This does clean up the following phpstan error:

------ -------------------------------------------------------------------------- 
  Line   modules/contrib/tablefield/src/Plugin/Field/FieldType/TablefieldItem.php  
 ------ -------------------------------------------------------------------------- 
  164    Cannot unset offset 'tablefield' on array<mixed, mixed>.                  
 ------ --------------------------------------------------------------------------

Makes sense to me. :)

This has been committed to the module already, should this just be closed along with https://www.drupal.org/project/fullcalendar/issues/3472260 📌 Cleanup PHPCS test Needs review ?

For native (non google calendar) events we'd need to target another field for the contents of the modal as well.

Thanks, this is a good thing to catch!

I got a white screen when adding a custom field without this patch when going to a view where a custom text field had been added, so it's more than an AJAX error.

While this does allow for a custom field to be added to a FullCalendar view without erroring out, the field cannot be used for the title. I'm not sure what other use case there is for one. Contents of a modal popup?

This technically solves the issue, but either a child issue should be created to address using a custom text field as the title or this should be changed to needs work. I haven't looked at the code at all.

FYI - it's not up to community norms to list your own work as RBTC, the idea behind it is that someone else confirms it works (hence the by the community part). :)

This works great, thanks!