🇧🇪Belgium @dieterholvoet

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)

Source

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.

We have been encountering the same bug on a bunch of sites since tonight. In our case the current MR doesn't seem to solve the issue. Our problem is that ini_get('apc.shm_segments') returns FALSE, making $shm_size === 0 which still causes a DivisionByZeroError.

dieterholvoet → created an issue.

dieterholvoet → created an issue.

dieterholvoet → created an issue.

As discussed in the call:

• calls are stored in the civicrm_api_call table
• calls can be scheduled to be executed at a later time
• calls can be retried N times after failing

This abstract functionality is provided by the cmrf_abstract_core package. Let's try to keep using Drupal queues, but use the civicrm_api_call table as storage backend. If that turns out to be too difficult we can still consider dropping Drupal queues completely, or to use the current implementation that uses the Drupal queue storage.

An advantage of using Drupal's queue backend is that you can e.g. use Redis → instead of a database table. We're not currently using that though, so not super important.

An advantage of using CMRF's queue backend is that it integrates with the /admin/reports/cmrfcalls overview, which is a useful interface for the client.

I'll have another look at this MR soon.

I realised this is basically the inverse of the EntityExists validator, so I renamed it to EntityUnique and was able to copy most of the code.

dieterholvoet → created an issue.

Just tested on a Drupal 10.5.1 site, works as well. Do you have any errors logged after changing the field settings? Did you run database updates after updating the module?

I'm sorry, but I can't reproduce. I just tested on a fresh Drupal 11.2.3 installation with required_api 3.0.0 and required_by_role 2.0.0 and everything is working as it should.

It seems that when I select "Required by role" in the "Choose a required strategy" section the "default required" field is selected automatically? Hard to tell. My problems persist.

The default 'Required' checkbox shouldn't be visible when you have selected the 'Required by role' strategy. It should look like this:

Are you sure the default 'Required' checkbox is visible while the 'Required by role' strategy is selected?

The changes in 🐛 Only show red asterisk when the field is actually required Active should remove this limitation. Could you test them and let me know if it works for you?

dieterholvoet → created an issue.

I just tested this module again and it does seem to work. What can be confusing is that the red asterisk is always present, but when saving no validation error will show if the user doesn't have one of the configured roles. Could you test again and actually try to save the entity?

My bad, I still had to submit the review. Done now!

Thanks for your contribution! I left some comments in the MR.

I added some documentation to the README file. The examples use application/x-www-form-urlencoded, but multipart/form-data should work as well. Let me know if this is sufficient, so I can merge this and update the project description as well.

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

Maybe it could be an idea to not drop the old tables just yet, just in case there are still issues with the migration? The dropping of the tables could be added once a stable release of the module is made.

@gillesv fixed!

@rodrigoaguilera could you check the boxes next to our names in the 'Credit & committing' section below? This way the right credit is assigned.

@rodrigoaguilera could you check the boxes next to our names in the 'Credit & committing' section below? This way the right credit is assigned.

dieterholvoet → created an issue.

I have been using this for a while in production and it works quite well, I would say even well enough for our use case. Couldn't we consider adding this as an (experimental) submodule? Having to manually break locks is a big barrier for editors and blocks issues like ✨ The same user shouldn't be allowed to open the same edit form multiple times Active .

dieterholvoet → changed the visibility of the branch 3.x to hidden.

Sure, we could do that. I would still mark the module as obsolete though. MR's are welcome.

dieterholvoet → created an issue.

dieterholvoet → created an issue.

What exactly is being changed here? Didn't the OPT_IN_TEST_PREVIOUS_MAJOR variable indicate that tests were being run on both Drupal 10 and 11?

I recommend creating an issue in the Kint → issue queue to add the ksm() functionality.

trackleft2 → credited dieterholvoet → .

dieterholvoet → created an issue.

dieterholvoet → created an issue.

This isn't enough. Would also need to override the WebformSubmissionHandler, DefaultDataHandler, ValidationHandler, CalculationHandler classes.

dieterholvoet → created an issue.

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

dieterholvoet → created an issue.

It allows other (custom) modules using services provided by this module to be autowired. It's not required for this module to use autowiring, that would only be possible if the module only supports Drupal 9.3.0 or higher.