D10 Warning when enabling path with exclusion

I have run into the same issue. This module version worked ok in my Drupal 10.0x sandbox, but once I updated to 10,1x I started getting this error when saving. I'm not a programmer, but maybe this will help someone diagnose further?

I would have to guess this is a core issue not allowing urls without a starting "/" to be saved... I would have to track it down and maybe create a patch for core.

As I suspected it has to do with Drupal core. I created a patch for now till I can figure out a cleaner way to fix this.

Apply Drupal core patch and please let me know if that works for you:

https://www.drupal.org/project/drupal/issues/3375092#comment-15153306 💬 Drupal 10.1 + Rejecting paths not conforming to standard URL's set by Drupal Postponed: needs info

I applied the patch and ran multiple tests. I can save the url with ! at the beginning, BUT the block does not appear on any page when that is saved. I honestly don't know if this was working before 10.1 as I only installed it briefly before I upgraded to 10.1, and I never fully tested it.

I don't see any errors being reported in Watchdog. Not sure how much more I can help as I'm not a developer, but I will play around with it more when I have time to see if I can get something working.

@tyler-durden - I have tested and I can confirm that my block is showing on the right pages and not showing where it's not supposed to.
have you updated the module to the latest of this issue "2.1.0-beta2"?

As the change was a bug fix to core I don't see special cases going in to support this module. Can you override the validator method in the RequestPath plugin instead?

Automated tests prevent these surprises. I recommend implementing some.

Ok, I'll try and figure out overwrite the method via the module. In the main time, I'll keep this patch active on the link above for those that need it on Drupal 10. I'll close it when I have the validation overwritten on my part and the new version of this module loaded. Thank you.

I am using 2.1.0-beta2, and I think I found a pattern but I've been pulled away and won't be able to test further for a week or two.

The block I added for this testing of the patch, I added to a page that is numbered only, example /23. It should have excluded from /23 only, but excluded from /24, etc. I did not use a wildcard.

I found the original blocks I had created with these, and they are working but they are on pages with text as urls and used wildcards in the filter.

I will try to do more testing in a week or two, but I think this is a separate issue than this one.

Reading through the upstream issue, 💬 Drupal 10.1 + Rejecting paths not conforming to standard URL's set by Drupal Postponed: needs info several ideas come to mind for approaches to fix this in the module/patches here:

Starting Drupal 10.1 there are some constraints added to pages settings in blocks, that only allow strings "" and anything beginning with a forward slash "/", there for limiting the use of this settings section. Block Exclude Pages module uses a "!" at the beginning of URLs on pages settings to exclude some pages when a wild card is used.

• Change the module's syntax so that the negation flag "!" is last, and thereby passes validations.
• Change the module's syntax to be something that looks more like a URL eg `/not/somepath` instead of `!/somepath/`
• Create a completely separate block visibility plugin that completely overrides and replaces the core functionality, and doesn't suffer from the validation limitations.

I made a PR that adds a new custom Condition plugin to handle the leading exclamation point, and used hook_condition_info_alter to use it as the validation class. This works for me locally after clearing cache!

Just a note: one can just override the buildConfigurationForm method and tweak the #description a bit instead of using the form alter & helper function in the module file.

What's going on with this issue? I'm not familiar with the "Patch" status. There's an MR available, what do we need to get it into the module?

Patches added on 2.1.0-beta3

I guess you want fixed instead of Needs review as the patch/MR has been committed.

Automatically closed - issue fixed for 2 weeks with no activity.