I fixed this in context of ✨ Add support for updating submissions Active , could you try out the latest dev release and see if it fixes your issue?
Maybe there is an issue also with the format of the min and max values. In formkit and html the time input format seems to be hh:mm while it's returned hh:mm:ss.
That shouldn't be an issue according to the MDN docs:
The value is always a 24-hour HH:mm or HH:mm:ss formatted time, with leading zeros, regardless of the UI's input format.
This seems to have been working for more than a month in one of our projects so I'm going to go ahead and merge this. Any bugs or improvements can go in new tickets.
This module still supports Drupal 9.2. The PHPUnit attributes were only added in PHPUnit 10, which has only been supported since Drupal 11.2.0. Won't this cause issues?
That's a possibility, or ideally we would add a change record summarizing what was said/decided in the issue.
It should also be the time in seconds the Drush command should spend working on this specific queue in one run, but this is not enforced in this module.
Just realised this is not true. That's what the time-limit option is for, the lease-time only determines how long queue items are held.
dieterholvoet → made their first commit to this issue’s fork.
dieterholvoet → created an issue.
Thanks!
I think so, but not sure. It's been a while.
Pipeline is passing now, but still some phpstan & cspell warnings.
dieterholvoet → made their first commit to this issue’s fork.
Moving to the Drupal.org project ownership issue queue.
Setting to Needs work because more changes might be necessary, don't have time to do a deep dive right now.
dieterholvoet → created an issue.
I already tried a couple times but the new contribution record system has been acting up. I tried again.
I'm going to use this patch in a project for a week or two and if all is good, I'll merge.
Changes to this contribution record don't seem to be saving for me, once I refresh the page everything is unchecked again. I am noticing a lot of console errors in the likes of Uncaught TypeError: $(...).once is not a function
Tests are finally passing again. Thanks for the work everyone!
Maybe filter by only entries that were created by Tagify? Not sure if it could hurt to delete everything.
dieterholvoet → created an issue.
This fixes the error on the settings form for me.
dieterholvoet → created an issue.
Never mind, seems like more changes were necessary.
Seems like this is already possible if you just leave those two settings empty. I created a MR to leave those settings empty by default and to document the auto detection in the field descriptions.
dieterholvoet → made their first commit to this issue’s fork.
dieterholvoet → created an issue.
dieterholvoet → created an issue.
I checked it myself using the test form, seems like it has to look like this:
travel_options[one]: "one"
travel_options[two]: "two"
travel_options[three]: "three"
I created a separate issue for the remaining CSpell issue: 📌 Clean up config keys Active . I'm going to apply a patch of these changes to a website that uses the module a lot and keep it running for a couple weeks. If all is good afterwards, I'll merge this.
dieterholvoet → created an issue.
Test is fixed.
dieterholvoet → created an issue.
@benstallings sorry, but can't reproduce this with the patch from 🐛 Only show red asterisk when the field is actually required Active applied. required is also set to true in my case, but that shouldn't matter.
third_party_settings:
required_api:
required_plugin: required_by_role
required_plugin_options:
- editor
required: true
Thanks for the quick response! I sent the same message to @eme through their contact form.
I sent the following message to @mandclu, the only maintainer who has been working on the module in the last 4 years:
Hi,
Could you post a comment on my offer to co-maintain Form Mode Control ( https://www.drupal.org/project/form_mode_control/issues/3542611 💬 Offering to co-maintain Form Mode Control Active )? I would like to become a co-maintainer of the module to help resolve any pending and future issues.
Thanks in advance,
Dieter Holvoet
dieterholvoet → created an issue.
I tested the MR and apart from a small issue I fixed in the MR, nothing broke. I didn't encounter the issue as described here though, so I can't really say anything about that.
I did some profiling. I loaded the /admin/structure/menu/manage/admin page under different conditions:
- no patches: 49.3s
- patches from 🐛 Outbound path processors miss the route name Needs work & 📌 Domain Config loading is resource intensive Needs work : 19.6s
- patch from 🐛 DomainSource Outbound Path Processor endless Loop Closed: cannot reproduce : 26.8s
Conclusion: good improvement, but not as good as the solution with the core patch, so I would leave this issue open for the time being. The new solution introduces a lot of custom code, but if you're willing to maintain all that I'd say go for it!
dieterholvoet → made their first commit to this issue’s fork.
dieterholvoet → created an issue.
dieterholvoet → created an issue.
If you're unsure on how exactly to submit certain types of values, you should submit the Webform test form with the Network tab of your browser developer tools open and inspect the outgoing request.
The fix here is to use replaceWith instead of replace as AJAX method (
change record →
).
dieterholvoet → made their first commit to this issue’s fork.
dieterholvoet → created an issue.
I added a new 'Only use merge variables' option as described in the issue description. Ideally this new feature would get some tests.
dieterholvoet → made their first commit to this issue’s fork.
dieterholvoet → created an issue.
The current MR fixes the issue for me! The disabled state is now propagated from the address element to its country element.
@benstallings what's the field type you tested with?
dieterholvoet → created an issue.
Okay, I was able to reproduce the issue, but only on simple fields that have HTML5 required validation through the required attribute. Before I was testing on more complex fields like entity reference and paragraphs fields. The good news is that the patch from
🐛
Only show red asterisk when the field is actually required
Active
seems to fix the issue. Please test this and let me know if it works for you, so I can merge the fix and make a release. Don't forget to clear caches after applying the patch.
You're misunderstanding the intention of the issue. This is about making sure that the 'Break lock' link does not appear in the dropdown of the sticky actions next to the title on the edit form, and instead it displays as an actual button. You're talking about the entity operations on the content overview.
Rebased!
Good news, we're going to be working on a more complete JSON Forms schema integration for a client soon.
dieterholvoet → changed the visibility of the branch 8.x-1.x to hidden.
Already done!
Found the culprit. The issue was triggered by security updates last night. There's an associated core issue: 🐛 APCu requirement for 32MB always displays since APCu 5.1.25 Active .
The apc.shm_segments ini option has been removed. Multiple SHM segments are no longer supported. (They were already not supported when using mmap, which is the default mode of operation)
I suggest we add a fallback to 1 if the ini directive is missing.
dieterholvoet → created an issue.
Not sure if the other check is actually necessary, I'll leave that to @primsi to determine.
Well I checked phpinfo() and the directive is missing. Haven't figured out how yet, I'm checking with our hosting partner, but it couldn't hurt checking for this situation. It's interesting that we're not the only one encountering this issue in the span of a couple days.