Include a way to exclude certain admin paths from config_warning

Hi all, I’ll start working on this.

rduterte → changed the visibility of the branch 3531838-include-a-way to hidden.

Implemented path include/exclude logic using the request_path condition plugin.

Supports wildcard paths (e.g. /admin/structure/*)

Includes a toggle to switch between exclude/include behavior.

Changes are available in the issue fork.

Ready for review.

This is a great piece of work! I’m beginning to worry I’ve pitched some training I have organised for you a bit low! :-D

I’ve added a couple of comments that I think will make it more maintainable.

I like the direction, though.

Hi,

I have refactor the work for this task and also resolved some phpcs warnings.

Moving this to needs review.

Thank you! :)

I've tried this out locally and it works great! Adding paths to the list hides the message on those pages. Unticking the 'negate' checkbox only shows the message on the paths listed. The wildcard also works for all subpages of that path, multiple levels deep.

Thanks for all the work on this, we're already planning to use it on a lot of websites.

Having a closer look at this, while the functionality works well, I think the wording could be changed on the Paths box, for clarity.

It currently mentions adding one path per line to exclude from the warning message, but that's not what the field does. That behaviour depends on the Exclude checkbox below it. Even though that checkbox is ticked by default, the Paths description should probably say:

"Specify pages to show the warning on by using their paths. Enter one path per line. You may use wildcards, such as /admin/structure/block/* to match all subpaths."

This wording would also bring it more in line with the Block layout configuration.

Added the wording suggested above - it does help!

Thanks everyone! I took a look at the code and I think we can work more closely with existing core logic. The request path condition implements \Drupal\Core\Plugin\PluginFormInterface so we can use ::buildConfigurationForm, ::validateConfigurationForm, etc. You can see an example in BlockForm. Also the request path's schema is already defined as condition.plugin.request_path (without negate).

This would also make it easier if we wanted to expand to other conditions, eg roles.

wanna have a go at it?

I'm happy to try and take a look Thursday or Friday, but can't promise :)

@rduterte I notice this is still assigned to you and don't want to step on any toes... are you or would you like to be working on it?

Hi Andy, I appreciate your insights!

Yes, I'd still work on this, especially as I see it as a good learning opportunity.
I’ll go ahead and start exploring the approach you suggested and aim to post an update soon. :)

Thanks!

Hi!

Thanks again for all of the input.

I’ve updated the implementation to follow the core pattern using `PluginFormInterface`, so conditions like `request_path` now manage their own form fields. It’s also now set up to easily support other plugins.

I've also updated the README file if incase other devs want to add other plugin if necessary.

Happy to get any feedback or suggestions. Let me know if anything seems off or could be improved.

Cheers! :)

I'll be moving issue to 'Needs Review'.

Just updating the assignment. In general, we tend to just have people write a comment saying they are working on something and for how long. That way, it avoids it getting left assigned (and I used to be massively guilty of this!)

feels like needs work...

I'll start working on the suggestions and will post an update this week.

Thank you!!

Also did test this and all working as expected.

1. If unchecked, the warning will be shown only on matching paths. ✅

Matching path showing config warning.✅

This also work on path with url parameters.✅

Matching path via wildcard showing config warning.✅

Non-matching path NOT showing config warning.✅

2. If checked, the warning will be hidden on matching paths. ✅

Matching path NOT showing config warning. ✅

Matching path via wildcards NOT showing config warning. ✅

Non-matching path showing config warning. ✅

3. Validation. ✅
Error message when adding invalid path.

4. Coding Standard. ✅
New code changes is using Drupal and Drupal Practice coding standard.

Awesome work, everyone!