PHPCBF automatically fixed all but one sniff it found, that and what was caught by phpstan have been uploaded.
All the unit tests from this pass, all the existing kernel tests are failing with the exit 2 that I was getting, but that's just a warning somehow.
I just removed the kernel tests and kept the unit tests, since the unit tests cover all the core sorting functionality.
Test pass locally for me. Unsure why they're failing on the d.o pipeline.
You mean update hooks (8005, 8006, 8007, 10001)? Are they post_update hooks or standard hook_update_xxxx? It looks like they just process go view by view and don't run in batches.
It disables existing functionality that was approved and implemented for the module, so it doesn't seem proper to put in a MR on the main issue.
This issue could be renamed to be a discussion on whether that functionality is worth the drawbacks (for me it isn't, for others it might be) since it doesn't seem like a proper fix is coming anytime soon, if there's a positive consensus for this approach then a MR seems appropriate.
https://www.drupal.org/project/tablefield/issues/3385030 💬 After upgrade to D10, empty tablefield output is displaying in paragraph on node Active just visually hides the issue but there's still the db bloat which isn't ideal.
The maintainer will not merge this patch unless something has changed.
Looked things over, and the most likely explanation was that I goofed on copying over the right charts folder. Did it again and it worked. Assuming the rest of the libraries work as you've gone over them I'll mark it as RBTC. Once it's in dev I can pull an issue fork and make a stab at updating documentation at some point.
The old root package.json had:
"workspaces": [
"web/modules/**/*"
]
I have a very basic functional understanding of NPM but never have had the need to dig deep into it. On a more meta level going forward in order to keep dependencies clean one would just keep adding new workspaces to package.json per project that uses this approach?
"workspaces": [
"web/modules/contrib/charts/**/*",
"web/modules/contrib/FOO/**/*",
"web/modules/contrib/BAR/**/*"
]
I might just be doing something wrong here, but I think the workspace limitation might have borked the install?
Copied this fork over, deleted my package-lock.json, and removed the highcharts libraries from web/libraries.
Running npm install from both root and from the contrib folder just outputs the following and no highcharts libraries are downloaded.
npm install
> postinstall
> npm run libraries:copy --workspaces --if-present
up to date, audited 1042 packages in 2s
[...]Yeah I just ran `npm install` at the base level of the site - interesting side effect there. If things are properly scoped it'd be nice to just be able to update all the modules in a project with it at once, I have to imagine it's capable of running different tasks with their own dependencies.
I've bumped into (and noticed others having) this issue of not being able to update someone else's issue branch, sorry for not being able to just fix some of the little things. :)
Current behaviour persisted before I made any configuration changes on my side.
Ran a standard composer upgrade on top of it out of curiousity and it pulled highcharts/solid-gauge. Looking at the package.json in charts_highcharts it's missing that package.
So this runs, and is really cool. Once things settle down I think it'd be really neat to have some kind of post-install script in composer that just runs `npm install` after a `composer upgrade` run. :)
There's a LOT of deprecated packages in here that should be modernized (redundant console output removed). I had a package-lock.json but it basically just had the project name in it. Along with updating the readme.md I'd put it as needs work, but this runs as is (I'll keep the changes in my composer.json heh).
npm install
npm warn deprecated @npmcli/move-file@1.1.2: This functionality has been moved to @npmcli/fs
npm warn deprecated inflight@1.0.6: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.
npm warn deprecated stable@0.1.8: Modern JS already guarantees Array#sort() is a stable sort, so this library is deprecated. See the compatibility table on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global...
npm warn deprecated rimraf@3.0.2: Rimraf versions prior to v4 are no longer supported
npm warn deprecated glob@8.1.0: Glob versions prior to v9 are no longer supported
npm warn deprecated glob@7.2.3: Glob versions prior to v9 are no longer supported
npm warn deprecated @stylelint/postcss-markdown@0.36.2: Use the original unforked package instead: postcss-markdown
npm warn deprecated @stylelint/postcss-css-in-js@0.37.3: Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.
npm warn deprecated @humanwhocodes/object-schema@2.0.3: Use @eslint/object-schema instead
npm warn deprecated @humanwhocodes/config-array@0.13.0: Use @eslint/config-array instead
npm warn deprecated @ckeditor/ckeditor5-dev-webpack-plugin@30.5.0: This package is no longer maintained. Please, read the migration path: https://github.com/ckeditor/ckeditor5-dev/releases/tag/v32.0.0.
npm warn deprecated eslint@8.57.1: This version is no longer supported. Please see https://eslint.org/version-support for other options.
Having trouble pushing, in the base readme.md I'd make the following changes to lines 1 & 2 to make them actionable vs vague "ensure":
1. Run `composer require wikimedia/composer-merge-plugin` to ensure that you have
the `wikimedia/composer-merge-plugin` package installed.
2. Run `composer require oomphinc/composer-installers-extender` to ensure that you
have the `oomphinc/composer-installers-extender` package installed.
Should these be pinned to a major version or something?
Also the following should refer to creating/modifying package.json, not running `composer require`
7. Run the `composer require` specified in the submodule’s README.md file
It still applies cleanly to 7.1.x as per the MR, my understanding is the branch is unable to merge with 7.0.x because of drift since. What additional rebasing needs to happen?
What is needed for an upgrade path? It's not removing or altering any existing settings.
No test coverage at the moment.
erutan → changed the visibility of the branch better_exposed_filters-3437511-7.1.x to hidden.
erutan → changed the visibility of the branch 3437511-toggle-contents-of to active.
Patch for 7.0 that works for me to change ascending and descending for non entity references. MR failed as I forgot things had been switched over to 7.1 branch for the issue.
erutan → changed the visibility of the branch 3437511-toggle-contents-of to hidden.
Thanks for researching what the problem was @irinaten!
I've contributed a module patch that works on Drupal 10.5.3 so people don't need to code in hooks to load it. :)
Only one blocker keeping me from using this module now.
Seems like it should work for non entity reference fields (taxo, user, custom, etc). I'll take a stab at it soonish.
Thanks for the quick follow up bhogue. To clarify, they worked with my patch, but did not work without it?
If so can you mark it as RBTC? Thanks! :)
rename highcharts/solidgauge:12.1.1 to highcharts/solid-gauge:12.1.1, composer runs without errors and downloads the library.
Sharing your specific patch might help abstract things out as a starting point.
I took stab at LLMing this and didn't get anything that fixed it, but Claude came up with the following areas that may or may not be worth focusing on:
$entity->hasField() check that was preventing relationship fields from being processed. $this->view->style_plugin->getField() handles relationships automatically and could be a good way to replace it. The getField() method returns the processed field output for the current row, which includes values from related entities.
In reference to #41 I can confirm the patch applies cleanly and there are no errors on my drupal site. given @dqd's code review still stands I'd say this qualifies as RBTC :)
Can confirm that #7 works on 10.5.
Here's a quick patch that includes the labels as well if someone wants to take a look and possibly clean it up.
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.
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.
Sorry for the flubs on issue forks, was using a new tool and multitasking :)
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
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.