@michael.garrido

@debrup Ah that makes sense. Unfortunately I can't make the media field non required. Instructing our editors to always create the media before collapsing is the most probable work around we will use.

However, I'm wondering if its possible to automatically save the media entity when collapsing/previewing (or more accurately, before doing so). Does something like that sound feasible? Might not be useful in many cases but in our case it would do.

Has there been any updates on this? I would love to have this functionality, but the patches here don't work for me. I even made a patch myself based on the MR and that also didn't work.

@deprup No worries, no rush on my end as the issue isn't breaking or blocking for our editors. Thank you for taking a look at the issue!

Hey @debrub, no you shouldn't click the create new media button.

Hey @debrup, apologies, I definitely miswrote the instructions as I was writing them. I went through again, and the updated instructions in the OP should now work.

I was just able to reproduce the issue using Drupal 10.2.9, EIF 3.0.0, and paragraphs 1.17, but I believe the issue is still present up to at least Drupal 10.3.7 (the latest version we are using in production, where the issue still appears).

for your convenience, I will also copy paste the updated instructions here:

I was able to replicate the issue using the following https://simplytest.me/ configuration:

• Drupal 10.2.9 Project
• IEF module
• Paragraphs

After Installation, log in and then:

1. Enable Media module
2. Create new paragraph type with a entity reference to a media item (choose image)
3. Make this media item required in field settings
4. set the media type to image under the reference type section of field settings.
5. Go to form display settings for paragraph type. Set The widget of the image field to Inline Entity Form - Complex.
6. Configure the IEF to have create new revision,. collapsible, and allow users to add new media items set to true
7. Create new content type and add a field of type paragraphs Choose cardinality of unlimited
8. Make sure to set the type under reference type to the new paragraph you just created
9. Set the form display widget of the image paragraphs field to Paragraphs (stable). The default configuration for the widget should be fine.
10. Create new node of that content type you just created
11. Upload an image and add alternative text. All required fields for the image should be filled in by doing this.
12. Click collapse button. The "This value should not be null" error will appear
13. Clicking the Preview button should also cause this error to happen.

@debrup Hey, thanks for checking this out! Apologies, that screenshot is from our production set up, and I only included it to show the "Should not by null" error appearing on all the fields. Please follow the reproduction steps in the original post.

If you still can't reproduce let me know, I will try to reproduce again and create better instructions.

michael.garrido → created an issue.

I can also confirm this issue happens with Flood Control and Drupal Shield module enabled, using Drupal 10.2.6. Doesn't seem to occur in Drupal 10.1.8.

This seems to be due to the isIpWhitelisted function trying to call the flood_control_get_whitelist_ips function that is defined in the flood_control.module file:

<?php
...
protected function isIpWhitelisted(string $ipAddress = ''): bool {
    $request = $this->requestStack->getCurrentRequest();

    if ($request && !$ipAddress) {
      $ipAddress = $request->getClientIp() ?? '';
    }

    // Gets the values from the config.
    $ipsWhiteList = flood_control_get_whitelist_ips();
.....
?>

it seems to be failing to resolve that particular function when called from that location. Oddly enough, in Form/FloodControlSettingsForm.php, the code does a similar call:

<?php
...
 public function validateForm(array &$form, FormStateInterface $form_state) {
    // Validating whitelisted ip addresses.
    $whitelistIps = flood_control_get_whitelist_ips($form_state->getValue('ip_white_list'));
    // Checking single ip addresses.
    if (!empty($whitelistIps['addresses'])) {
      foreach ($whitelistIps['addresses'] as $ipAddress) {
        if (!filter_var($ipAddress, FILTER_VALIDATE_IP, FILTER_FLAG_NO_RES_RANGE)) {
          $form_state->setErrorByName('ip_white_list', $this->t('IP address %ip_address is not valid.', ['%ip_address' => $ipAddress]));
        }
      }
    }
.....
?>

But that one does NOT cause an error.

The error seems to partly stem from the namespace causing PHP to look in the wrong spot, IE its looking for Drupal\flood_control\flood_control_get_whitelist_ips(), but since that function isn't in the Drupal/flood_control namespace, it fails. However, I did try doing something like:

<?php
...
protected function isIpWhitelisted(string $ipAddress = ''): bool {
....
$ipsWhiteList = \flood_control_get_whitelist_ips();
....
?>

But it results in essentially the same error (and I'm not sure if that is even that way to go about that anyways).

I'm not sure whether this is an issue with the flood control module itself, or some issue introduced by core that is causing this issue with resolving the function.

michael.garrido → created an issue.

michael.garrido → created an issue.