Improve description of Excluded paths

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

Update the Description Based on the Suggestion
Please review.

spuky → credited joakland → .

wow that was quick ;-) thanks for your work!

I think this solution puts too much of the onus on the user. In my experience, most of the folks making configuration changes via the UI are not familiar with escaping characters and do not know how to use regular expressions. For people who do understand regex, it's not clear what constitutes "simple" regex. The only way they would know if their regex is insufficiently simple is if the path exclusion doesn't work.

There are other places in Drupal where a user may enter paths (such as the visibility section of block configurations) that address the same problem without relying on regular expressions, or requiring users to make a judgement about complexity. Adopting such an approach would be a more user-centered solution.

on the one hand I understand your point... on the other hand it is an "Advanced" Setting...
So reading the description of how to use it could be expected.. the added Text + an example of how to escape slashes was added.

It was taking me several tries to come up with the Idea to not escape the string here to get the warning and stack trace

This was an easy fix to Improve the usability for users by providing inline documentation.

New feature requests or even merge request for Improvements like:

- verification of entered stings on save with an error message (maybe best solution when thinking about updates of existing config..)
- spliting the config in two fields one for regex one for simple paths
- having an "regex!" prefix like the custom breadcrumb field

are welcome

but somebody has to write that code, make sure it does not break the stuff for people already having a regex in there...
to provide a sane update... to whatever the situation is changed to...

and till then a field that gives someone the power to do what they need with the risk of some "foot shooting" is better than a less powerfull alternative ;-)

That all makes sense. And you make a good point that someone using the advanced settings is more likely to be able to write those strings correctly. The inline documentation you added does a good job of explaining how to do this.

That said, I do think programmatically escaping slashes that are not already escaped is a low bar to clear. I'm going to do this in a different issue/push request, which you of course are free to accept, edit, or reject.

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