Yes, that's the follow-up. @smustgrave quoted @berdir from #17 in 📌 Don't delete view due to config dependencies being deleted Active . I'm setting this back to Fixed.
I improved the test. I think it's probably good to go now.
Since one of the other library split issues got committed this one needed a rebase with updated performance metrics. I also updated the deprecation version, but I'm not going to roll back the RTBC status for that, especially since @alexpott allowed self-RTBCing in the other issue for the same minor update.
This issue can be added to the CR I made yesterday for the 11.3.0 splits: [#3530832].
I addressed the feedback.
I created a new CR for libraries moved in 11.3.0 and made the requested changes. I'm restoring the RTBC status per #24.
And now you can see that multiple content translation UI tests are failing. Thank you @godotislate!
I asked in the core-development Slack if the test-only job passes because the new assertions are in an abstract base class. Per @godotislate that is the case. The test-only runner looks for changes in *Test.php files. I was advised to create a test-only MR, which I did in MR 12393.
I'll argue that a module isn't "good to go" if its automated tests aren't running, which was the case here because a .gitlab-ci.yml hadn't been added yet. I added one and am setting the status back to Needs Review. A maintainer needs to review the testing configuration and enable/disable options that they want to support.
I also removed Drupal 9 from all of the info.yml Core compatibility strings. GitLab CI can't test against it, so you can't guarantee compatibility. A breaking change may be introduced and you wouldn't know until someone filed a bug report unless you're running the tests yourself. I've done this in the modules I maintain and encourage others to do the same. I typically release a new minor version when doing this. It isn't necessary to release a new major version.
As for everyone else asking for this to be committed: I checked the most recently-active maintainer's user profile page. He mentions that he's been serving in the Ukrainian National Guard. So I wouldn't expect a fast response. My own plan is to copy the module and this compatibility fix to a private GitHub mirror until an update is made. I'm not interested in maintaining the module because I know nothing about it or the Mailgun service yet. This is my first day of using it.
Follow-up created at 📌 [PP-1] Remove phpcs:ignore in TaxonomyHooks Postponed .
I'm able to reproduce the issue. You don't need to use views_embed_view(). It happens with a regular, old Page display.
It can only be seen in the raw HTML, which is also what a validator looks at. When the FullCalendar JS is executed it replaces the offending DIVs.
I tried to figure out how to solve it too, but didn't get anywhere. Since the problem doesn't exist after the JS runs, then one could argue there's no problem. But I empathize with anyone who doesn't want to have to deal with validation errors on their pages, especially if they have to explain them to supervisors.
I completely missed seeing that this was implemented under the Calendar Appearance/Sizing settings.
Since the schema issue was merged I decided to make an MR. It only took a few minutes of work.
If it's decided to move this forward then I'll make a change record. And the lifecycle_link in the info file will have to be updated. Just set the issue back to NW with a note.
I wasn't certain if it's better to make an update function to uninstall fullcalendar_legend or let site builders do it themselves. I decided to err on the side of not uninstalling something that custom projects might depend on. What are your thoughts?
I left the issue version as 3.0.x to get the latest code changes, but per the semver rules this will force the release of 3.1.0.
Sorry, I'm unable to review this because I can't reproduce the issue. I set up a new content type, added a single-valued datetime field, generated content, and created a few that uses AJAX. I don't get an AJAX error and nothing appears in my logs.
Am I missing a step?
All linting tests are green now.
Glad you caught that. Thank you for doing a thorough review of it.
I'm willing to do the work if it's decided that the issue should move forward.
For the record, this updated hook is working for me with the implementation I'd already set up to give end times to events that only had start dates - after updating the implementation of course.
This ended up being more complicated than I expected. The inherent problem is that the hook which came from D7 passed \DateTime objects. But the modern code mostly deals with datetime strings. It wouldn't be quite as much of a problem if it weren't for the all-day handling. In the end, the simplest thing to do was to change the hook's definition to have the date strings passed instead of objects. We could try to convert everything to use objects instead, but it would force a major refactoring of the code, I think. It makes me wonder if this is how the hook got lost in the first place.
In case you're curious, I think the reason I left the dates in their array was due to a strict reading of the ModuleHandler::alter() docs. It only allows three parameters to be passed to implementations: $data, $context1, and $context2. I'm a very literal person, so I thought "Oh, I should put both dates in the $data variable. And that works out because the entity and fields can be the context variables." But I don't think it really matters.
I'll release version 4.2.2 shortly.
Yep. That's a problem. Thank you for reporting it. I'll work on it.
dcam → changed the visibility of the branch 3511172-missing-schema-error to hidden.
This issue is a duplicate of 🐛 Single date field shows as long event. Active .
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module.
If there's still interest in integrating this functionality into the primary module, then feel free to re-open it and update the version number.
Closing as a duplicate of #2833300: Customize fields title, url don't works → . I suggest updating existing issues rather than opening new ones if you have changes to contribute.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module.
If there's still interest in adding this functionality to the module, then feel free to re-open it and update the version number.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module.
If there's still interest in integrating this functionality into the primary module, then feel free to re-open it and update the version number.
fullcalendar_field_is_date() has undergone extensive modifications during the intervening years. But I read through the function real quick and it looks like the proposed changes were implemented, albeit in a slightly different way. If I'm wrong, then feel free to re-open the issue and update the version number.
castNestedValues() no longer exists. If this issue is still relevant for version 3, then feel free to re-open it and change the version number.
The all_day code has been modified extensively since this issue was introduced. If the problem still exists in version 3, then feel free to re-open the issue and update the version number.
This needs to be triaged by a current maintainer to see if it's something they still want to do. It seems like a reasonable request, so I'm not closing it as part of my outdated issues audit. I also checked the FullCalendar JS docs and it appears that themeSystem is still supported. I'm setting the issue back to Active status because I assume that the patch will no longer apply. Also, it was mentioned in #5 that the setting's value isn't saved. It's easy to see why: the setting isn't added to the plugin configuration. So more work needs to be done.
This needs to be triaged by a current maintainer to see if it's something they still want to do. But it sounds reasonable, so I decided to not close it as part of my outdated issue audit. I'm setting the status back to active since I'm assuming that the existing patch will not apply.
The code altered by this patch has changed. If the inherent issue still exists, then feel free to re-open the issue and update the version number.
Closing this as outdated because apparently the ESLint objects to including "use strict" in contrib. See 📌 Remove "use strict" statements from JS files Active .
I have this problem in the calendar I set up too. Those events only have start dates because they represent a single moment in time, not a duration.
To solve the problem I used the fix from
🐛
Hook not firing
Active
to add hook_fullcalendar_process_dates_alter() in a custom module and give all dates a duration of 1hr.
Closing this as outdated since hook_fullcalendar_classes() and hook_fullcalendar_classes_alter() exist.
fullcalendar_event was removed from hook_theme() and I don't see a fullcalendar theme function in the history at all.
According to the issue priority descriptions this qualifies as Major at the most.
This is still relevant. There's no config schema in the fullcalendar_legend submodule.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
This was fixed and then later removed entirely.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
Integration was added and also @mandclu took over maintenance of this module. =P
fullcalendar_legend.module no longer exists. The functionality has been moved into a Views area plugin.
From the stack trace it looks like this was triggered by hook_requirements(), which has been removed along with the rest of the .install file.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
#7 makes it sound like this was possibly caused by an issue in Drupal Core. If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
The .install file and the hook_requirements() were removed.
I closed the other two issues because I doubt their patches are relevant anymore. This issue can start the effort to fix the problem with a clean slate.
Wrong status.
I'm closing this issue in favor of #3256797: Fullcalendar is incompatible with Date Recur 3.x → only because FullCalendar has changed so much that these patches are likely to be irrelevant.
I'm closing this issue in favor of #3256797: Fullcalendar is incompatible with Date Recur 3.x → only because FullCalendar has changed so much that these patches are likely to be irrelevant.
The configuration page was removed, which I suspect was the cause of this issue.
fullcalendar_legend.module no longer exists. The functionality was moved into a Views area plugin.
I rebased it to see if that might fix the PhpStan errors, but it didn't. No need to grant credit to me for that. I'd recommend committing the change and backporting to 3.0.x despite the failure. There's an open issue for fixing PhpStan failures.
🐛 Module configure link in .info.yml file. Active was marked a duplicate of this issue. Identical work was done on an MR in that issue. It's recommended to grant credit to those contributors here.
I verified the bug and tested the fix. The settings form was eliminated a while ago. This bit of leftover YAML needs to get cleaned up. RTBC+1.
Marking as a duplicate of 🐛 Warning message on installation because settings form does not exist Active . I'll recommend that credit be granted to contributors in this issue.
The jquery-ui dependencies were dropped.
v3 no longer requires this kind of manual Composer configuration.
README.txt was removed.
Development has restarted on this module and version 3 was released.
This configuration no longer exists.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
The Composer-based workflow was recently improved by the fullcalendar_io dependency.
This text was removed.
This issue was fixed by some other commit.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.
This issue was fixed by some other commit.
I've volunteered to help clean up the FullCalendar issue queue. As part of that effort I'm closing issues open for unsupported versions of the module as "Closed (outdated)".
If this issue is still relevant for version 3.x of FullCalendar, then feel free to re-open it and update the issue version number.