The selection list of conditions to add to a rule includes a section named 'Other' and these conditions do not work when selected. They often produce a blank form with no more selections or text entry. On further investigation these conditions are provided by Core and probably should not be included in this Rules selection list.
Here is an example - the items in the red block will vary depending on which other modules are enabled, as they do not come from Rules code.
The source of some of these items is as follows:
Node Bundle = core/modules/node/src/Plugin/Condition/NodeType.php
Current Theme = core/modules/system/src/Plugin/Condition/CurrentThemeCondition.php
Request Path = core/modules/system/src/Plugin/Condition/RequestPath.php
User Role = core/modules/user/src/Plugin/Condition/UserRole.php
They fall into the "Other" section as they have no category defined. The conditons are annotated with @Condition
which is the same for the Rules conditions. However, for actions, the Rules ones are annotated with @RulesAction
presumably to distinguish them from Core actions. So maybe we should use @RulesCondition
for the conditions which are OK for this selction list.
Comment | File | Size | Author |
---|
Comments
Comment #2
dasjoWe had to fork the actions api, but as far as i know we didn't have to fork the conditions api for rules yet. Ideally we should try to stay compatible which is why they show up.
Is there something missing for the core conditions that they don't work with rules?
Comment #3
tedbow@dasjo just a quick look at the differences between:
\Drupal\node\Plugin\Condition\NodeType
(core) and\Drupal\rules\Plugin\Condition\EntityIsOfType
(rules)Here is what I think is happening
You can use NodeType in Rules but...
\Drupal\node\Plugin\Condition\NodeType::evaluate()
does get called but because the configuration for the condition was never set it always returnstrue
.So obviously Rules conditions are more flexible and don't rely on hardcoded forms. So I am not sure if Rules ever calls
\Drupal\Core\Plugin\PluginFormInterface::buildConfigurationForm
for the conditions or uses the form logic at all. If it does not one way to make Rules with core conditions would be:\Drupal\rules\Core\RulesConditionBase
override all the methods from\Drupal\Core\Plugin\PluginFormInterface
with empty implementations.PluginFormInterface
. This is would have no effect for conditions that extendRulesConditionBase
This is my first look at Rule 8.x so I could be totally off 😉
Comment #4
tedbowHere is patch that simply gets the configuration form for core conditions to show up. The configuration doesn't save.
Just a note, most(all?) of the conditions are duplicated with conditions that Rules provides. So you might just want to remove the known ones.
Comment #5
fagoYeah I agree we should just hide the conditions which we replace with better alternatives.
For the others, just adding in the form + making sure it saves correctly should be the way go. Of course we need to figure out a common code path somehow here. Maybe we could just have the Rules' generated form be loaded in the same methods as core uses?
Setting to needs work as this is not finished.
Comment #6
TR CreditAttribution: TR commentedComment #7
Nchase CreditAttribution: Nchase as a volunteer commentedI guess it would be the best for now to just hide those conditions, otherwise there will be continuous support requests and bug reports with error messages that result form trying to use Core conditions.
Comment #8
TR CreditAttribution: TR commentedThis patch hides the non-working core conditions from the Rules UI.
Comment #9
firfin CreditAttribution: firfin commentedThis indeed hides the 'other' category and the conditions in it. Applied cleanly.
When or how the to-do in the patch will be resolved is a question I still have though.
Comment #11
TR CreditAttribution: TR commentedI committed this patch, primarily for the reason stated in #7.
But I'll keep this issue open to address the larger problem of using core Conditions in Rules.
Comment #12
dinazaur CreditAttribution: dinazaur as a volunteer and at DevBranch commentedThe last committed patch also all default Block visibility conditions. Also, Rules conditions always are in the Block visibility conditions selection.
This patch just remove applied changes.
Comment #13
andypostComment #14
TR CreditAttribution: TR commentedIt looks like this check should be made in the ConditionForm rather than in the ConditionManager, that way it will affect only Rules. I will post a new patch later. This issue is still "Needs work" for all the other things that need to be done - there is no new patch to review.
The problem of Rules conditions showing on the Block settings page is the subject of #2675698: Ensure compatibility with core block UI
You don't need to post a new patch, the changes can be reversed by applying the old patch with patch -R.
Comment #15
TR CreditAttribution: TR commented@dinazaur: Try this - this should not remove the default conditions from block visibility, but should hide the core conditions from the Rules UI.
Comment #17
TR CreditAttribution: TR commentedI reverted the commit made in #10 to fix the Block visibility problem, and added the changes in #15 to restrict the core Conditions using the ConditionForm rather than the ConditionManager. This patch was reviewed and tested by several people in #3160347: Option of block page visibility is missing.
Back to NW for the rest of it...
Comment #19
Mike.Brawley CreditAttribution: Mike.Brawley commented#15 worked for me on drupal 8.8.8 and rules 8.x-3.0-alpha6
Comment #20
slowflyer CreditAttribution: slowflyer commentedone more
#15 worked for me on drupal 8.8.8 and rules 8.x-3.0-alpha6
Comment #21
hristos CreditAttribution: hristos commentedThank's very very match. #15 work but I wasted all day wondering what it was, and I didn't know how to ask google. Thank you again!!!!
Comment #22
ab2211 CreditAttribution: ab2211 commented#15 helped (Drupal 8.9.2 / Rules 8.x-3.0-alpha6).
Comment #23
ddhuri CreditAttribution: ddhuri as a volunteer commentedThanks #15 works for me with Drupal 8.9.6 and Rules 8.x-3.0-alpha6
Comment #24
ThoreauinSF CreditAttribution: ThoreauinSF commented#15 worked - thank you
Comment #25
nchristensen CreditAttribution: nchristensen commented#15 worked (Drupal 8.9.10 and Rules 8.x-3.0-alpha6)
Comment #26
Mike.Brawley CreditAttribution: Mike.Brawley commented#15 worked on 8.9.12 Rules 8.x-3.0-alpha6
Comment #27
Mike.Brawley CreditAttribution: Mike.Brawley commentedChanging this to reviewed and tested as the past 7 people have tested.
Comment #28
TR CreditAttribution: TR commentedRead the issue - the patch was committed 6 months ago . .
Comment #29
aiphesI can't apply the patch on the D8914 + rules 8.x-3.0-alpha6
what is missing ?
Comment #30
jonathan1055 CreditAttribution: jonathan1055 as a volunteer commentedHi aiphes,
Take a look at the command you pasted. You are trying to apply a comment link, you need the patch file.
Comment #31
aiphesExact. The right command is:
/sited8/modules/contrib/rules$ wget -q -O - https://www.drupal.org/files/issues/2020-07-23/2927132-15- remove-other-conditions-from-ui.patch | git apply
Thanks