🇵🇹Portugal @jrochate

Found it. The module userprotect → was causing this behaviour only on image fields, go figure.

All fine here. Closing.

jrochate → created an issue.

Totally agree.

Hi @daniel_j. It would be cool if you could credit people that you think have helped in solving this issue.

There is a change in Drupal 11.2 on the namespace of the Form.

I'm sending a patch that make is work again on Drupal 11.2.

I'm not sending a MR because the maintainers need to make a decision on how to make it available.

@batigolix what about not having a default country selected, even if we have one or more countries in priority?

There should be a default country selected only if we choose the default value on field config.

Do you agree?

Thanks. That solved the problem.

I was also using this Navigation Extra Tools → module.

Can you add that to your test bed?

Same here.

jrochate → created an issue.

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

Well, I do not intent to keep discussing this, because I can see you are a long term Drupal developer (much more than I), so I will just detail a little more my first reply, and I hope I can contribute to anything. If not, we're ok anyway :)

Rabbit Hole is primarily about controlling what happens if a user visits the canonical entity route. It is not true access control: entities remain accessible to code and APIs unless you add custom restrictions.
- Typical technical use: Override EntityViewController, subscribe to route events.

Private Content modifies the Drupal access system at the entity level, including Views, APIs, and entity queries.
- Typical technical use: Implements hook_node_access() or custom AccessCheck classes for robust access control.

That's what I referred to when I said about "an access module".

Rabbit Hole Primary API Usage
- Entity API, Route Subscriber, Entity View Controller, Event Subscribers

Private Content Primary API Usage
- Entity Access API, Permissions API, Node Grants API, Route Access Subscribers

On my point of view, Rabbit Hole:
- Purpose: Controls what happens when someone tries to access an entity (like a node, user, or taxonomy term) directly by URL.
- Common Uses: Prevents direct viewing, redirects users, or returns 404/403 responses for certain content types or entities. It’s often used for content that’s not meant to be viewed as a standalone page (e.g., referenced content, system content).
- Visibility Control: Indirect. It doesn’t manage content privacy but rather controls how entities are displayed (or not displayed) at their URLs.

And Private Content
- Purpose: Restricts access to specific content for certain users or roles.
- Common Uses: Hides content from anonymous or unauthorized users, allowing only specified users/roles to view it. Useful for members-only content, confidential documents, etc.
- Visibility Control: Direct. It manages who can or cannot view the content based on permissions.

Cheers.

jrochate → created an issue.

I also think the widget approach works better.

I would like to add a request:

- respect the default value defined on the field

I mean, when there is no default value and the field is not mandatory, the fact that we use the widget to get priority countries shouldn't make the selection list pre-select the first priority country.
This is happening now, and it looks like a bug.

For me, the expected behaviour is only auto-fill the select box when the field has a pre-defined country selected, no mater has priority countries or not.

I'm afraid you have misunderstood one or both modules:

Rabbit Hole is not an access module as Private Content.

For that reason they could never be similar or even merged.

Drupal 11.2.2, just after installing term_merge got this PHP error.

Installed the MR!29 and now doesn't crash and merged terms successfully.

Thanks @Scott_euser

Sure, no prob. I think is make a lot of sense, because it's normal to have a "most used" countries, but you don't want to loose the opportunity to know the rest of them.

For example: select all european countries first, and then the rest of the world if your use case is primarily targeted to Europe.
Or your own country first, because it will be 90% of the income users.

Thank you for your efforts on this.

Thanks. Looks good now.

Works as expected, but when is on first use, there are some warnings about undefined variables.

- Edit a country field just after installing the patch:

Warning: Undefined array key "priority_countries" in Drupal\country\Plugin\Field\FieldType\CountryItem->fieldSettingsForm() (line 142 of modules/contrib/country/src/Plugin/Field/FieldType/CountryItem.php) 

Warning: Undefined array key "show_priority_separator" in Drupal\country\Plugin\Field\FieldType\CountryItem->fieldSettingsForm() (line 152 of modules/contrib/country/src/Plugin/Field/FieldType/CountryItem.php) 

Warning: Undefined array key "priority_separator_text" in Drupal\country\Plugin\Field\FieldType\CountryItem->fieldSettingsForm() (line 159 of modules/contrib/country/src/Plugin/Field/FieldType/CountryItem.php) 

Warning: Undefined array key "priority_countries" in Drupal\country\Plugin\Field\FieldType\CountryItem->fieldSettingsForm() (line 142 of modules/contrib/country/src/Plugin/Field/FieldType/CountryItem.php) 

Warning: Undefined array key "show_priority_separator" in Drupal\country\Plugin\Field\FieldType\CountryItem->fieldSettingsForm() (line 152 of modules/contrib/country/src/Plugin/Field/FieldType/CountryItem.php) 

Warning: Undefined array key "priority_separator_text" in Drupal\country\Plugin\Field\FieldType\CountryItem->fieldSettingsForm() (line 159 of modules/contrib/country/src/Plugin/Field/FieldType/CountryItem.php) 

- After saving that specific country field definitions, the variables are set, so no more warnings.

Hi @xjm.

Like reported above, I had this error appearing and needed to patch with #49.

But now I have removed the patch and applied the MR!12440 and it works as expected.
I'm not having the error on the operations I was having before.

Thanks you @all for the effort is solving this.

Yep, there is a a path component missing.

jrochate → created an issue.

+1 RTBC. It solved this problem using Drupal 11 and the the module as the OP referenced.

I'm having the same problem on Drupal 11.2 and #49 solved it.

Anyway, the solution doesn't look definitive.

jrochate → created an issue.

#8 is still a great way to solve this.

Thanks.

Awesome. Please don't forget to credit who you think might have contributed to this issue.

This patch solved the problem when the image field has max dimensions set.
Drupal 10.4 and stable exif_orientation 1.5 and also using imagick 1.12

Sorry, @adamps but your combo fix didn't solved the problem, so setting this as RTBC

On my case this patch didn't solve the problem.

The patch applies OK, but the error still persist. The only way to clear the error was to install the stable version 2.0.8 instead of dev version.

I'm testing against 3-beta3 and so far so good. no errors. marking RTBC

It looks good to me.

I have patched, enabled the module on the same installation that the error occurred before, and cache can be cleaned without any warning nor error.

Thanks.

Check! I have also ECA enabled.

Thanks. That solved the error I was having, even after uninstalling the module

Thanks.

I was getting this fatal error, and the #5 solved it.

jrochate → created an issue.

jrochate → created an issue.

This MR is setting charts requirements to 5.1.6 but the module is still on 5.1.3

diff --git a/composer.json b/composer.json
index e4d087cf381d9ccac41fb7a9d9a1632b179f02a4..6017dd455582b55385463a5502a857abb7cdf7a5 100644
--- a/composer.json
+++ b/composer.json
@@ -18,6 +18,6 @@
   },
   "license": "GPL-2.0-or-later",
   "require": {
-      "drupal/charts": "^5.0.3"
+      "drupal/charts": "^5.1.6"
   }
 }

Solved on the related issue

There are no more PHP warnings when editing ECA model, and the select box with Entities still show the flat list with all of them.

Thanks!

Awesome. I'm ready to test that MR when it's available .

I have edited the Plugin EntityFinder, on line 386 and invalidated the PHP with an implode() function on getLabel.

With that, the warning about Array to String on editing ECA models, disappeared.

I think you should improve that issue and try to explain a little more why you think an ECA error message is related to tamper :)

I think the problem is near,. because if I invalidate the getLabel with a forced PHP error, por exemple using implode(), then the warnings go away.

To get more deep on this, I will join my colleague on Monday to trace the code and be sure about it.

In my case, the $entity_type->getLabel() does return a string.

Maybe there something else on the structure. I will take a look on Monday.

Ok, will do so. I will get back here with more info.

thanks.

jrochate → created an issue.

jrochate → created an issue.

Drupal 10.4 + pathauto 1.13 + upgrade to rh 2, and the patch was still needed.

The error was the same as post title:

[error] The "" plugin does not exist. Valid plugin IDs for Drupal\rabbit_hole\Plugin\RabbitHoleBehaviorPluginManager are: access_denied, page_not_found, display_page, page_redirect

Thanks manish.upadhyay

hi @megachriz

Yep, that nails it. Thanks.

Same as #112, using Drupal 10.4 and PHP 8.4.

When editing Media, the image it's no there, but it can be seen on files and on the related node.

We're almost there... With ver 2.1 custom_tag module, we can achieve rel=alternate and href=link. It just misses the type tag.

Thanks. #5 tip solved the lagging version.

We are on Drupal 11.0.5 and yet this message still marks the Drupal 10.3 as Outdated

If we have 4.0.3 that is still supported, on Drupal 10.3, the installation should not be marked as outdated.

Oh, now I can add that secondary axis, but in very specific conditions.

It would be good if:

1. I could had several columns, and just the last one into the secondary.
At the moment it's mandatory to have just two columns, where the first goes to axis1 and the second goes to axis2

2. I cloud have a distinct chart type for the secondary axis, e.g., bars for the axis1 and line for the axis2
At the moment, it's the same chart type for both axis

Anyway, thank you very much for your kind reply.

Do you think it will be possible to achieve the previous 1. or 2. good-to-have stuff?

thanks.

After some digging we found out that it was a very specific use case in token_or → that was not having consequences until we used ECA.

So it's has nothing to do with ECA, but it has to be improved in token_or side when using a specific duplicated token that we had.

Thanks anyway.

jrochate → created an issue.

I have this problem also.

When rejecting cookies, or not saving cookies, the SESSIONID is non existent. The SQL tries to save a new line using null value on the Sid column, and if there is already another non-cookie saved, the primary key error occurs.

Does not work on current dev.

Patch works great on dev. Thanks.

Doesn't work on latest 1.13

I got the same situation using BEF 6.0.6, and I have reroll the patch for BEF 6.x version.

It really make difference when using chosen search input. Please review.

This is getting a little messy.

The #12 works fine on module's 1.5 and 1.6 version.

Thanks @jan! For me it doesn't break now, when listing users and in other places where I was having memcache's WSOD.

I'm sending a simple patch just to keep speed up people who would like to test it also.

Same here, for example when listing users.

Same here with #11. It works with ECA2, and also the problem of not being able to use a locally defined token with an e-mail as value.

For now I can hardcode the e-mail address, but it would be great to use a local token instead of hardcode of an entity token.

Same here. Version 1.6 has the problem with special chars. Patch in #15 for the 1.5 version works fine.

I was having this same problem.

Even forcing to update records on every run, this error always poped-up.

I found out that when a referenced entity did not exists, instead of feeds reporting that (as usual) it would break.

I solved it by guarantying that the referenced entity always exists before running the feed that was rising the error.

Maybe this can be helpful to anyone who comes here with the same problem: be sure that referenced entities (nodes) already exists.

Does not work with current DEV branch.

I'm also having this problem:

webform 6.2.x
drupal 10.3

    data_evento_inicio:
      '#type': datetime
      '#title': 'Data do Evento'
      '#title_display': inline
      '#required': true
      '#format': simple_datetime_alt
      '#date_year_range': ''
    data_evento_fim:
      '#type': datetime
      '#title': Fim
      '#title_display': inline
      '#required': true
      '#date_min': '[webform_submission:values:data_evento_inicio:raw]'
      '#format': simple_datetime_alt
      '#date_year_range': ''

I think the best is to use raw as should result in an UNIXTIMESTAMP.

But I'm getting the error:

Unable to render elements, please view the below message(s) and the error log.

The timestamp must be numeric.

Is it impossible to reference previous submissions fields on this validation rule?

Can't find out the limitation. TIA

same here... This message keeps the drupal installation in an outdated state.

The Linkit module had a similar problem, that we could patch it like 💬 Update module erroneously recommends conflicting update to 6.1.x for sites on Drupal 10.0.x or lower Closed: works as designed

Still the same problem using Drupal 10.3 and latest IMCE

Patches don't apply work on 10.3

Same here, but not multi-site.

Currently none of the patches above works: 1.11

Thanks for the commit. It would be nice to give credit to lolgm since he has made the MR.

jrochate → created an issue.

Hey @ThuleNB, try this one 🐛 TypeError: Illegal offset type in isset or empty Needs review , I think it will fix your error.

What about this issue 🐛 Compability issue with BEF 6.0.3 Needs review ? The patch it's similar but a few more instructions.

I have the same situation, and maybe it's related to 🐛 Changes on clone are reflected on the original node also Postponed: needs info .

I am not using site studio and I got the same problem:
- when cloning a node with Layout Paragraphs, we can see that we got a duplication of IDs

Clones node

     "x-default" => array:27 [▼
        0 => array:2 [▼
          "target_id" => "5747"
          "target_revision_id" => "111694"
        ]
        1 => array:2 [▼
          "target_id" => "5748"
          "target_revision_id" => "111695"
        ]
        2 => array:2 [▼
          "target_id" => "5749"
          "target_revision_id" => "111696"
        ]
        3 => array:2 [▼
          "target_id" => "5750"
          "target_revision_id" => "111697"
        ]
        4 => array:2 [▼
          "target_id" => "5751"
          "target_revision_id" => "111698"
        ]
        5 => array:2 [▼
          "target_id" => "5752"
          "target_revision_id" => "111699"
        ]
        6 => array:2 [▼
          "target_id" => "5765"
          "target_revision_id" => "111700"
        ]
        7 => array:2 [▼
          "target_id" => "5766"
          "target_revision_id" => "111701"
        ]
        8 => array:2 [▼
          "target_id" => "5767"
          "target_revision_id" => "111702"
        ]
        9 => array:2 [▼
          "target_id" => "5753"
          "target_revision_id" => "111703"
        ]
        10 => array:2 [▼
          "target_id" => "5754"
          "target_revision_id" => "111704"
        ]
        11 => array:2 [▼
          "target_id" => "5755"
          "target_revision_id" => "111705"
        ]
        12 => array:2 [▼
          "target_id" => "5756"
          "target_revision_id" => "111706"
        ]
        13 => array:2 [▼
          "target_id" => "5757"
          "target_revision_id" => "111707"
        ]
        14 => array:2 [▼
          "target_id" => "5758"
          "target_revision_id" => "111708"
        ]
        15 => array:2 [▼
          "target_id" => "5759"
          "target_revision_id" => "111709"
        ]
        16 => array:2 [▼
          "target_id" => "5760"
          "target_revision_id" => "111710"
        ]
        17 => array:2 [▼
          "target_id" => "5761"
          "target_revision_id" => "111711"
        ]
        18 => array:2 [▼
          "target_id" => "5762"
          "target_revision_id" => "111712"
        ]
        19 => array:2 [▼
          "target_id" => "5763"
          "target_revision_id" => "111713"
        ]
        20 => array:2 [▼
          "target_id" => "5764"
          "target_revision_id" => "111714"
        ]
        21 => array:2 [▼
          "target_id" => "5768"
          "target_revision_id" => "111715"
        ]
        22 => array:2 [▼
          "target_id" => "5769"
          "target_revision_id" => "111716"
        ]
        23 => array:2 [▼
          "target_id" => "5770"
          "target_revision_id" => "111717"
        ]
        24 => array:2 [▶]
        25 => array:2 [▶]
        26 => array:2 [▶]

Original node, now with the clone paragraphs back to it:

      "x-default" => array:42 [▼
        0 => array:2 [▼
          "target_id" => "5716"
          "target_revision_id" => "112067"
        ]
        1 => array:2 [▼
          "target_id" => "5717"
          "target_revision_id" => "112068"
        ]
        2 => array:2 [▶]
        3 => array:2 [▶]
        4 => array:2 [▶]
        5 => array:2 [▶]
        6 => array:2 [▶]
        7 => array:2 [▶]
        8 => array:2 [▶]
        9 => array:2 [▶]
        10 => array:2 [▶]
        11 => array:2 [▶]
        12 => array:2 [▶]
        13 => array:2 [▶]
        14 => array:2 [▶]
        15 => array:2 [▶]
        16 => array:2 [▶]
        17 => array:2 [▶]
        18 => array:2 [▶]
        19 => array:2 [▶]
        20 => array:2 [▼
          "target_id" => "5741"
          "target_revision_id" => "112087"
        ]
        21 => array:2 [▼
          "target_id" => "5747"
          "target_revision_id" => "112088"
        ]
        22 => array:2 [▼
          "target_id" => "5748"
          "target_revision_id" => "112089"
        ]
        23 => array:2 [▼
          "target_id" => "5749"
          "target_revision_id" => "112090"
        ]
        24 => array:2 [▼
          "target_id" => "5750"
          "target_revision_id" => "112091"
        ]
        25 => array:2 [▼
          "target_id" => "5751"
          "target_revision_id" => "112092"
        ]
        26 => array:2 [▼
          "target_id" => "5752"
          "target_revision_id" => "112093"
        ]
        27 => array:2 [▼
          "target_id" => "5753"
          "target_revision_id" => "112094"
        ]
        28 => array:2 [▼
          "target_id" => "5754"
          "target_revision_id" => "112095"
        ]
        29 => array:2 [▼
          "target_id" => "5755"
          "target_revision_id" => "112096"
        ]
        30 => array:2 [▼
          "target_id" => "5756"
          "target_revision_id" => "112097"
        ]
        31 => array:2 [▼
          "target_id" => "5757"
          "target_revision_id" => "112098"
        ]
        32 => array:2 [▼
          "target_id" => "5758"
          "target_revision_id" => "112099"
        ]
        33 => array:2 [▼
          "target_id" => "5759"
          "target_revision_id" => "112100"
        ]
        34 => array:2 [▼
          "target_id" => "5760"
          "target_revision_id" => "112101"
        ]
        35 => array:2 [▼
          "target_id" => "5761"
          "target_revision_id" => "112102"
        ]
        36 => array:2 [▼
          "target_id" => "5762"
          "target_revision_id" => "112103"
        ]
        37 => array:2 [▼
          "target_id" => "5763"
          "target_revision_id" => "112104"
        ]
        38 => array:2 [▼
          "target_id" => "5764"
          "target_revision_id" => "112105"
        ]
        39 => array:2 [▼
          "target_id" => "5765"
          "target_revision_id" => "112106"
        ]
        40 => array:2 [▼
          "target_id" => "5766"
          "target_revision_id" => "112107"
        ]
        41 => array:2 [▼
          "target_id" => "5767"
          "target_revision_id" => "112108"
        ]
      ]

At the moment, the MR!416 is working fine on 1.1.x.

I can't firmly test it on 2.0.x-dev for now.

same here, #7 solves.

I'm sorry, but I think that's not the solution.

You would have a warning about the non existing dimension of the array.

Also I don't the real implications of having the $field_target_bundles empty processed, instead of just skipping the code when empty.

I think we must wait for someone with a better knowledge about PbT. This is an access module, we shouldn't patch it to solve basic PHP errors without knowing the implications of some patch decisions.

If there is no suggestion from someone more used to PbT, I will post my own patch in a couple of days.

jrochate → created an issue.

Hi @joseph.olstad

I think @pianomansam should get credit on this fix, that would be good for him and his organization.