I don't think there are any field widgets in core that set the #maxlength property on a Textarea form element object.
There aren't, unless something changed recently. I checked before writing #23.
This module might become obsolete by that reasoning.
I think that's a very real possibility.
Thanks the check looks right but we should inject ModuleHandler here now.
I didn't do it initially because IIRC it's on the roadmap to split up these bulk Hook classes and wasn't sure if it mattered. Also, the procedural call is used throughout the other hooks. So I decided to err on the side of following the example of what was doing elsewhere in the class.
I took @berdir's suggestion of checking for the node_type definition so there's no new dependency.
I addressed the feedback and made code changes.
Tweaked the Option 2 text.
If there are 2 MRs to choose from usually helps to still update the issue summary but in the proposed solution mention there are 2 solutions
Fair enough. It's done.
I addressed the feedback with no edits. Restoring RTBC.
Since I originally authored the CR I took responsibility for updating it with the before/after examples. But I'm going to leave the issue metadata the same so @quietone can review my changes and address #148 if necessary.
I added the change record. I haven't addressed other feedback yet.
Ok, so I wasn't entirely stupid. The failing test that @xjm referenced is for the machine name element description. But there is a different assertion further down that checks for an error message. The description and error message have nearly identical text, resulting in the confusion we both had. @xjm was correct to request that an additional assertion be added. However...
So I just think we need to add one more assertion above this one about the entity being unchanged.
There's no entity being changed here. It's an attempt to create a new shortcut set with underscores in the ID. It should be sufficient to check that an attempt to load the set returns NULL, which is what I added.
Sorry, I'm clueless. I missed something important there.
That's good, but should we also be asserting that the shortcut set was not saved? Generally asserting error messages by itself isn't robust enough.
@xjm that assertion isn't testing for an error message. It's checking for the unique machine name element description. Since the focus of this issue is specifically about that description being incorrect I wrote the assertion to check for the corrected version. But since you asked, I also included assertions to check for whether a hyphenated machine name and another attempt to save an underscored machine were correctly saved. This was because a misunderstanding starting at #37 revealed that there was no test coverage for the hyphenated naming scheme.
I addressed all feedback. Since the only changes were to code comments, one of which was written and suggested by a release manager, I'm going to be bad and self-RTBC this.
MR 56 fixed the issue on my dev site. Messages were sent successfully after applying it.
I have this same issue with a site that I'm in the process of upgrading to Drupal 11.2.2 this morning. I'm going to test the change.
Just in case anyone else arrives here looking for answers:
This update broke the Anchor Link module too. See
🐛
Missing icon (pencil) is breaking CKEDitor5
Active
.
Rebased. Restoring RTBC.
For the record I'm not working on this issue. I don't know why it thought I made a commit to a fork. I only checked the issue because I had the same errors when updating sites to 11.2.0 over the last couple of days.
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.