Created on 7 April 2023, about 2 years ago
Updated 5 May 2023, almost 2 years ago

Do I understand this right, that this runs on every form on the site except the ones I explicitly exclude? That seems like a lot.

I guess it is excluding any form on a URL under /admin/ but still.

It would be simpler, to me, to specify the forms where I do want it to run. Maybe use the same field and have an exclude/include checkbox? Or just two fields, that's simple.

Or let users prefix the form with "!" to mean "not this form" - that would give you what you have now. I would mention the /admin/ exclusion just so people knoww, but it seems unlikely to be a problem.

πŸ’¬ Support request
Status

Active

Version

3.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States brad.bulger

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @brad.bulger
  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica
  • πŸ‡ΊπŸ‡ΈUnited States brad.bulger

    Why do you think this is a support request and not a feature request? Sure seems to me like what I'm describing would be new functionality. Is there some way to do this with the existing system?

  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    Based on πŸ’¬ Excluded forms Active someone could write a radio select to invert the setting from exclude to include, like on other places in Drupal.
    Until that I think exclusion makes more sense in 95% of all cases. Happy to review MR.

  • πŸ‡ΊπŸ‡ΈUnited States brad.bulger

    I've pushed some changes to the issue fork, do you want to review it there or as a merge request? I have not written tests for it yet.

  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    MR should be used

  • Merge request !27Surface form ID patterns to validate β†’ (Open) created by Anybody
  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    @brad.bulger please see my comment in #4. I'd vote for a radio switch instead of two fields. Like Drupal does it in many other cases, e.g. block visibility conditions.

  • πŸ‡ΊπŸ‡ΈUnited States brad.bulger

    I don't see the advantage. All this is doing is surfacing what was actually being done in the code, as far as only looking at form IDs that match those patterns (sort of - it would have matched on any form ID containing "user_", I changed it to match form IDs that start with "user_").

    Being able to say "Match all of these except this one and this one" seems like a useful thing to be able to do.

  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    Okay, please then document, that it works like this, so the negative lists wins over the positive. And please add tests showing it works like this.
    With the other option, this possible conflict wouldn't exist. It''s just how Drupal solved this typically, but I also see the benefits you mentioned.

  • πŸ‡ΊπŸ‡ΈUnited States brad.bulger

    We could also copy the way that Block Exclude Pages β†’ does it:

    Basic example where a wildcard is used to display the block on pages under the user path:

    /user/* <-- this will make the block visible on all pages under the path.

    But let's say you want to exclude a specific page or another path directory under the path "/user/?":

    !/user/jc <-- now you will be able to specifically exclude the "jc" page

    or/and:

    !/user/jc/* <-- exclude on all pages under "jc/?"

    That changes what's there now, we'd have to convert any excluded form IDs.

  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    Yeah condition plugins are great for such things and another nice Drupal standard. We could also pick other condition plugins that make sense here.

    https://git.drupalcode.org/project/block_exclude_pages/-/blob/2.1.x/src/...

Production build 0.71.5 2024