Drupal 10.1 + Rejecting paths not conforming to standard URL's set by Drupal

Sorry, this was supposed to be a pplied to 10.1.x version

See https://www.drupal.org/about/core/blog/new-drupal-core-branching-scheme-... →

Can we get some detail about what the issue is here?

@Iarowlan -
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.

This is to try and figure out a solution to fix the issue https://www.drupal.org/project/block_exclude_pages/issues/3372696 🐛 D10 Warning when enabling path with exclusion Needs review

What is the core issue that introduced the behavior change?

@cilefen -
in /core/modules/system/src/Plugin/Condition/RequestPath.php

if (empty($path) || $path === '<front>' || str_starts_with($path, '/')) {

If there is a better way to overwrite the URL limitation via the contributed module rather than patching the Drupal core please advise. Thank you.

Using git blame, it is this issue. So what you are saying is that module Block Exclude Pages was using some nonstandard syntax for visibility and Block Exclude Pages is now broken by the validation. Correct?

"Non-standard" isn't the right word. It is better to say that Block Exclude Pages invented a syntax that relies on the field not being validated. Is that more correct?

Block Exclude pages is been used on a little over 6000 sites, from drupal 7 to now. I came up with that a few years back because there was nothing to meet the need of excluding/negate specific pages. And yes I guess we can say I "invented" that syntax as it was allowed before in the validation making it more flexible and it worked just fine, but now I have no way to fix it other than doing this.

Understood.

Something that would help spot changes like this in the future would be to have automated tests in the module to run against development versions of Drupal Core.

Can you override the validator method in the RequestPath plugin instead?

I am still kinda new to OOP and overwriting methods. I'll see if I can figure it out.

I have been trying to overwrite the "validateForm()" method on class Drupal\block\BlockForm in my .module file...
I tried creating an instance of "BlockForm" but I get an error:
ArgumentCountError: Too few arguments to function Drupal\block\BlockForm::__construct()
All variables to pass are protected and I can't figure out how to initiate this method..

Any help on how I would go about rewriting all these validations?

It would be exceedingly difficult to help, not seeing your code. Anyway, coding guidance is not often provided in the Core issue queue, although it sometimes happens. The place to get timely answers is in #contribute in Drupal Slack and also in https://drupal.stackexchange.com, provided this hasn't been asked in the past—you should search thoroughly.

Based on everything I have seen I am changing this issue to a support request.

You can override the condition plugins using hook_condition_info_alter .

I made a fork here before realizing the fix was better suited in the contrib module, not in core.

I added an MR to 🐛 D10 Warning when enabling path with exclusion Needs review that uses a hook to change the Condition plugin to a custom one in the module that allows for exclamation points.

Little bit unusual perhaps, but I notice that there is another module that does almost exactly the same as this one, altho exposes functionality slightly differently in the UI - https://www.drupal.org/project/condition_path →

I also notice that this module is using conditional plugins, so perhaps you could modify this module to work in the same way as that one, whilst keeping the (IMO, slightly better) position in the UI the same?

This is a support request, which @cilefen has pointed out are better handled outside of the core queue. And a fix has been applied to the contrib module that was reported in use in the issue summary. @SamLerner, thanks for reporting here on that.

I think this is resolved now.