Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.The condition plugin system is useful on its own, but a user interface to allow for groupings of conditions to be made for generic reuse purposes helps promote the basic needs of both a page management style solution as well as a Rules style paradigm. This UI is incomplete but is basically working at this point and allows condition plugins to be configured and that configuration to be saved into a Condition Group config entity. The entities themselves cannot yet execute the configured conditions within them, but the UI is working if you inspect the entity as it is generated. This issue depends upon 4 other patches right now.
#1896076: Contextual Plugins and supporting code
#1743686: Condition Plugin System
#1886616: Multistep Form Wizard
#1909144: Allow #ajax['dialog'] to contain options other than 'modal'
Next steps:
The modal is saving the condition configuration into the entity appropriately. There is a blank div on the form that needs to be populated with condition summaries (there's a method on conditions to do this for you).
A user interface for TypedData probably needs to be build to tell the condition group what sorts of contexts will be required in order to fulfill this grouping of conditions. This is incredibly non-trivial and I will be filing a follow up for it shortly.
Configuration of the conditions will need to inspect what typed data is available and allow the configurer of the condition to select which (relevant and available) context to use in order to fulfill the condition.
Once the entity type is saving what TypedData conditions it requires to operate, it will need methods exposed on it to satisfy these contexts and pass them to the conditions appropriately for execution.
Eclipse
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | condition-ui.patch | 21.16 KB | EclipseGc |
| #3 | condition-ui-interdiff-do-not-test.patch | 8.22 KB | EclipseGc |
| #2 | 1912452-2-condition-ui.patch | 17.69 KB | boztek |
| #2 | interdiff.txt | 2.79 KB | boztek |
| condition-ui.patch | 16.6 KB | EclipseGc | |
Comments
Comment #2
boztek CreditAttribution: boztek commentedStarted an initial review of conditions and used this UI as a way to try to get up to speed.
Simple condition listing attached with interdiff on this patch - as mentioned requires four patches applied first to work.
Comment #3
EclipseGc CreditAttribution: EclipseGc commentedBased on Boztek's great work, I went ahead and added operations to the list of conditions in the UI. This is all administratable from the modal, and seems to work quite nicely. Entities are updating as expected.
Eclipse
Comment #4
Bojhan CreditAttribution: Bojhan commentedI'd be tempted to mark this as 9.x, is there any benefit to doing this so late in the cycle with no usecases defined, and no page management? The risk of this becoming triggers but then less usable is abundant.
Comment #5
EclipseGc CreditAttribution: EclipseGc commentedI've broken apart a bunch of this patch into other pieces and gotten a lot of them into core at this point. The full UI isn't there yet, but I intend on reusing some of it for block visibility. Whether the full condition group UI gets in or not I think is up for debate still, but once block visibility is converted over we would at least have a use case for it beyond page management. I see this as a really big nice to have, and if the cycle permits then perhaps we can do it, and if not... well perhaps that's just how the cookie crumbles here. Still I'd prefer to give it a little more time before we just postpone it.
Eclipse
Comment #6
kenorb CreditAttribution: kenorb commentedComment #7
kenorb CreditAttribution: kenorb commented