Back a few months the following issue was reported (and closed).
"Can you please clarify how this is substantially different from the inbuilt Drupal block visibility by page functionality?"

After working a bit with this module, I'd like to suggest the other side of the coin for discussion. The wildcard and wildcard exclusion capabilities really should be considered for core. It may be a stretch, but these capabilities could really substitute for "multi-site light". My "use-case" (to use a Drupalism) is that I've put my wife's old web site as a kind of sub-site of my site. But she doesn't want to see my menus or, more important, have any users to her "site" see the overall site menus. Block exclude provides a perfect solution.

But, the site admin really needs to bear these capabilities in mind when adding content, setting up menus etc. For instance, my wife's name is "Gay". So by creating the urls for all her content prefixed with "gay" I can easily use the wild cards have her menus show on her pages and exclude my main navigation menus from her "area". For instance, in her area we have a menu that links to 20 content items that contain juicebox galleries. By setting the urls for each of these items with a url prefixed with "gay" we can just put "show for the listed pages" and a link of /gay* and voila, it's done.

I'll nose around the core issue queues and see if there is a diplomatic way I can suggest this for some future version. I know they'll be concerned about regressions, backward compatibility and the like, justifiably. But it really is a great contribution.

Comments

fkelly created an issue.

RaisinBranCrunch’s picture

RaisinBranCrunch commented

Yes, Jesus, I don't know how this isn't a core functionality already. Thank you so much for creating this module.

jcontreras’s picture

jcontreras commented

Thank you to both of you to take the time to drop a line. I'm glad you are finding the module useful. I'm sure at some point they will push it in, or at least I hope as it is something so simple but so useful. on the main time, I would appreciate it if you can add "star" to make more noise about this module to make it more visible to the Drupal engineers.

amaisano’s picture

amaisano commented

+1, it's quite ridiculous that in D8 you cannot both hide and exclude by path -- you HAVE to pick one logic mode or the other. Case in point, not being able to show a block only on the view mode (user/*) but not on the edit mode (user/*/edit).

In Drupal 7, the matching was EXPLICIT: user/* would literally only match if there were two path arguments. If you wanted a block on deeper wildcards, you'd have to write user/*/*. This was FAR more flexible than what is in D8 core. It's really embarrassing.

Is there any work in core to fix this?

weseze’s picture

weseze commented

This is included in core already...
You can just use: (following the example on the homepage of this module)

~/user/jc
~/user/jc/*
/user/*

I really don't understand what this module does that core cannot? Please help me understand...

weseze’s picture

weseze commented

Update to my previous comment. Seems that solution does not work...

Also consider the example below which would give a weird result:

/node/*
/node/*/edit
!/node/*/*

I would expect the block to show up at for example node/5/revisions, but not at node/5/edit. But it doesn't show up at either.

This all got me very confused at what exactly core does and what exactly this module does differently...

It seems te boil down to:
1/ core checks all your conditions and passes if there is 1 match.
2/ This module only checks the conditions with an ! and stops checking on the first match.

Am I correct?

kclarkson’s picture

kclarkson commented

How do we get this considered for core?

fkelly12054@gmail.com’s picture

fkelly12054@gmail.com commented

The core developers rarely look in these Forums for ideas. You could go over to the issue queue side of Drupal.org. Search carefully for similar issues or maybe submit one of your own. Put a reference to this thread as well as the Module Home page. Or post something in the module home page and see if you can motivate the authors to put a core request in.

I use this module. It's essential to my site and let's me run two separate "domains" side by side. BUT, it really helps to have a local system to test on because the syntax is a bit wonky. It's almost like trying to make changes to .htaccess ... you better have a backup and be prepared to test thoroughly under a variety of conditions. "Wonky" is not a very analytic term I know. It's a bit like messing with regular expressions ... a powerful and compact tool but one that can bite you.

OOPS. I just noticed that this discussion is already in the issue queue for block exclude pages. Not in Forums. My bad. I also noticed that I initiated the discussion quite some time ago. This still begs the question about how to get the core developers to focus on this. I'm pretty sure that it requires a level of expertise that I don't have to advance an idea like this.

chris matthews’s picture

chris matthews commented

Helpful info here: https://www.drupal.org/project/ideas

fernly’s picture

fernly commented

The Condition Path module does the same thing but leverages the condition plugin system which makes it more generic and usable in more places than just "blocks".