Generic Entity Field Value Plugin

Hi Pavel,

I tested the module :

• It seems to work ok with Layout Builder + Layout Library modules
• It breaks entity_field_condition on Block Layout and Page Manager. Message error: context "entity" is missing. displays

Scrrenshots of the issue :

Hello,

I'm using patch #5, but faced with error
RuntimeException: The subform and parent form must contain the #parents property, which must be an array. Try calling this method from a #process callback instead. in Drupal\Core\Form\SubformState->getParents() (line 76 of /docroot/core/lib/Drupal/Core/Form/SubformState.php).
Probably something was changed since patch.

I've fixed this issue, but form doesn't work for me as multistep currently.
I have to open condition for edit and then I'm able to specify value of the field.
@pavel-ruban do you have any idea what I have to change?

Updated patch for 8.x-1.1 release, previous one works on dev version only.

Previous patch broken condition for layout library itself (not for the block inside), corrected this.

1. Not working with Page Manager, I got "error: context "entity" is missing." adding a field value page access condition:

2. An update hook should be implemented to update config with the new plugin ID in existing installations, or leave the current node based field condition and mark it as deprecated

@manueladan, you're right, in some cases, we don't have the required context like we have on layout builder.
I returned back the Field node plugin but modified that a bit to have correctly work with the Extra field module (when subform attached not as `visibility` component) + I faced issues with negating condition and absence check on empty value (not NULL), made corrections for that.
Plugin Entity field will be advance for the cases when we have entity context (layout builder and etc).

Modified NodeField plugin to don't set default value with entity_type_id, because it works only with node, but this setting forces Extra field module thinks that condition configured when in fact it wasn't.

Added fix of the notice when $form['#parents'] absent.

Corrected return of result in case of the Negated condition, it should be outside condition plugin evaluate.

Updated patch for the latest dev version.

Fixed notice.

Corrected context_definitions for FieldValue to work correctly on D9.

Attaching an alternative patch on top of #3225480: Separate condition plugin for entity reference fields. It also requires #3230847: AJAX is broken on the add condition form for Ctools-based UIs. It should be backward-compatible with #19, but with a different implementation of the config form without continue/back buttons. The evaluation logic is the same with #19.

It still needs some cleanup and it may be better to spending time on porting some improvements to 2.0.x, that's why I change status on the issue.

Added check that selected entity has the defined field.

Trying to get block visibility in LB based off field value. The set of 3 patches in #20 is the only solution i have found so far. Thanks @Dmitriy.trt

EDIT:
i thought those 3 patches were working but doesn't seem to now. :(

also, any of these i think requires: "2916876 = block visibility control for LB": "https://www.drupal.org/files/issues/2021-11-03/2916876-144.patch" to get this to work with LB

I get:
- Control Visibility option with contextual links for blocks in LB (2916876)
- under vis options i have 2 field options: Field value and Node Field (without preview) - not sure which is from this module (but will track it down)
- Field Value when i click Add condition does nothing.
- Node Field adds condition but when i pick bundle, it says loading fields but loads nothing.

Is it possible these solutions only work when doing the layout of a specific node - as opposed to what i am doing which is defining the layout for all nodes of a specific bundle?

Wondering if this work is still on going and if someone can comment on status.

My guess is this is trying to make a generic/universal field conditional plugin. Is this correct? A bit confused by a few things though:

- it sounds like it is focused on LB although i see mention of patches for Layout Library (which doesn't make a lot of sense as that isnt a LB requirement) and no mention of the core patch #2916876: Add visibility control conditions to blocks within Layout Builder which i think is needed just to get visibility setting in LB at all.
- i havent been able to get any of the combinations mentioned here to work in LB (without trying LL patch which doesnt apply)

My 2 uses cases at the moment are:
1. pathauto (with a patch) allows conditional patterns
2. layout builder (with a core patch and a ctools patch) allows controlling block visibility

For which i think would require 3 patches:
- the core one i mentioned (for LB only)
- this ctools one: #3230847: AJAX is broken on the add condition form to allow ajax loading field list once the bundle has been selected
- a patch for this module to allow it to work in these applications

Mostly just curious if the work here (not including whatever LL discussion is about) is heading down that road or if i misjudged what the title of this issue is about.

Just as a reference, this is what i get currently:

core 9.2.11
patches:
- https://www.drupal.org/files/issues/2021-11-03/2916876-144.patch (core)
- https://www.drupal.org/files/issues/2021-09-15/ctools-condition-form-aja... (ctools)
- https://www.drupal.org/files/issues/2021-07-28/entity_field_condition-ge... (efc)

The patch from here changes the Node field condition to now 2 conditions:
- Field value (does nothing)
- Node field (without preview)

Field Value
- in pathauto condition just states "error: context "entity" is missing. "
- in LB (for a content type, not a specific node): WORKS!!, odd, tried this multiple times and didnt seem to work but does now. required to re-edit after saving condition to set the field value - but working. Yay

Node field (without preview)
- in pathauto: when selecting bundle, node field selector disappears.
- in LB: when bundle selected, it shows loading fields, but returns an empty list.

Seems like a solution here for LB but not generically. I did seem comments above about this requiring node context which would explain the error when trying to use this with pathauto. Perhaps this is the difference between field value and node field. Node field adds its own context by allowing user to pick bundle (but isnt loading fields correctly) and field value relies on figuring out bundle.

Although nice not to pick bundle; this doesn't seem like it will be a very generic solution as many places to use a condition won't provide this context (and shouldnt need to).

The patch in #20/21 breaks dev/8.x-1.3

Drupal core 9.3.12

If you edit a block before the patch is applied, everything works. But after the patch is applied, clear the cache and you get:

Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "entity_field_condition.subform.helper_factory". in Drupal\Component\DependencyInjection\Container->get() (line 156 of /core/lib/Drupal/Component/DependencyInjection/Container.php).

Will try to track the issue down if I get a chance and re-roll

Edit: ironically #19 seems to work for LB, but seems to break the block "Field Value" tab: error: context "entity" is missing.

hi
thanks for this feature
However i would like know if we can also have possibility to test empty field

From #25 changed status

Rerolled existing patch targeting the latest dev (and supporting Drupal 10).

The patch from #31 still has the same issue I reported in #25 unfortunately.

Here is the full stack trace:

Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "entity_field_condition.subform.helper_factory". in Drupal\Component\DependencyInjection\Container->get() (line 157 of core/lib/Drupal/Component/DependencyInjection/Container.php).

Drupal\entity_field_condition\Plugin\Condition\FieldValue::create() (Line: 21)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance() (Line: 59)
Drupal\Core\Condition\ConditionManager->createInstance() (Line: 72)
Drupal\layout_builder\EventSubscriber\SectionComponentVisibility->onBuildRender()
call_user_func() (Line: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch() (Line: 117)
Drupal\layout_builder\SectionComponent->toRenderArray() (Line: 88)
Drupal\layout_builder\Section->toRenderArray() (Line: 316)
Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay->buildSections() (Line: 275)
Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay->buildMultiple() (Line: 340)
Drupal\Core\Entity\EntityViewBuilder->buildComponents() (Line: 24)
Drupal\node\NodeViewBuilder->buildComponents() (Line: 282)
Drupal\Core\Entity\EntityViewBuilder->buildMultiple() (Line: 239)
Drupal\Core\Entity\EntityViewBuilder->build()
call_user_func_array() (Line: 101)
Drupal\Core\Render\Renderer->doTrustedCallback() (Line: 788)
Drupal\Core\Render\Renderer->doCallback() (Line: 374)
Drupal\Core\Render\Renderer->doRender() (Line: 204)
Drupal\Core\Render\Renderer->render() (Line: 242)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 243)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare() (Line: 132)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse() (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray()
call_user_func() (Line: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch() (Line: 174)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 58)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 50)
Drupal\ban\BanMiddleware->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 23)
Stack\StackedHttpKernel->handle() (Line: 718)
Drupal\Core\DrupalKernel->handle() (Line: 19)

Now using Drupal 9.5.9 and the EFC 8.1.4

I didn't need to do anything to get this error this time except view a page on the site.

We are using this in conjunction with the Layout Builder to show various views/fields based on field conditions (e.g. a taxonomy value).

This is for D9.5 and php 8.1

Compatible for 9.5 and php 8.1

Patch #35 kicks out an error:

ParseError: syntax error, unexpected identifier "parent", expecting ";" in Composer\Autoload\includeFile() (line 443 of modules/contrib/entity_field_condition/src/Plugin/Condition/FieldValue.php).

Drupal 9.5.11
PHP 8.1.23

Just an FYI, regarding #25, the reason Layout Builder context integration broke in D10 is referenced in #2916876-192: Add visibility control conditions to blocks within Layout Builder

Anyone know the status of this?

We had it working on D9.5 but it does not work for D10. I see the patch has code which references: \Drupal\entity_field_condition\Subform\SubformHelperFactoryInterface but this doesnt exist in the 1.x or 2.x branches.

Not sure what #35 patch is as it refers to code which doesn't exist. To get this working for D10 i took the version i was using in D9 (1.3) and the patch i was using from here (#19) and simply made it D10 compatible by removing the composer.json file and setting core_version_requirement.

Not quite the proper path forward i suspect but unclear the direction here.

Ok I scrapped my own merge request.

Try this patch instead

patch 43 now removes the garbage .orig file and I did a better job dealing with conflicts than patch #35

With that said, I am still reviewing the patch
***EDIT** This patch works.

Patch 43 is a re-roll of patch #19. I resolved the conflicts manually.

Testing of patch #43 shows that it resolves the issues that we noticed with patch #35

Tested with Drupal 10.0.11 and the latest dev 8.x-1.x of entity_field_condition

Please review

Thanks to @liquidcms for reporting the success with patch #19 on Drupal 10 using a modified version of release 1.3.

I took this as proof that patch #19 works well with Drupal 10.

So I re-rolled patch #19 on top of 8.x-1.x head of dev to create #43. The conflicts were carefully resolved and I believe the re-roll is a path forward here.

I have only done very minimal testing with #43, so it does require additional review.

EDIT #2: patch 43 above and #192 (Drupal core patch) from the link below work for me.

#43 (and #19) no longer seem to work for me on Drupal 10 sites (10.1.5 or 10.1.6). I can't edit an existing field condition for visibility controls nor add a new one.

In both cases, I get "error: context "entity" is missing." with an "Update" button that does nothing and a "Back" link.

Steps to reproduce on an existing block with an existing rule:

1. Click the context menu and select "control visibility"
2. Click Edit
3. "error: context "entity" is missing."

On a new block or one without a visibility condition:

1. Add the block to the layout builder
2. Context menu > control visibility
3. Select Field Value and click Add condition
4. "error: context "entity" is missing."

The field in question is a list (text) field.

EDIT: I should have mentioned I'm using the patch here (#167): https://www.drupal.org/project/drupal/issues/2916876

Perhaps that is the issue causing problems, but I'd be curious to know what patch combination people are using on D10.

Updated the default "Node Field (without preview)" condition so it's a bit more robust - such that the AJAX callbacks now works regardless of where it's used from e.g. Layout Builder and Blocks.

Also added a new equals and regex operation, making the contains operation now more of a str_contains() check instead of a regex.

@codebymikey does the patch in #48 fix the issue here as well?

https://www.drupal.org/project/entity_field_condition/issues/3278442#com...

I tested MR5 in the following forms and it works. Thanks very much for getting this far with this!

Layout Builder (my original need for this patch along with the block visibility patches in https://www.drupal.org/project/drupal/issues/2916876).
Works as expected, but throws an AJAX error after choosing the node type. In spite of the console error, it does load the fields and allows saving of the condition, which then works as expected.

Core Block Layout
Works as expected.

Menu Position
This module used to ship with a field value option in D7, which no longer exists in D10.
Works as expected.

It also works with Context module

The fix in https://www.drupal.org/project/entity_field_condition/issues/3506895 needs to be applied for this patch, I believe.

Undefined array key "value" in:

$value_to_compare = $value_item[$main_property_name];

Could be fixed with:

$value_to_compare = !empty($value_item[$main_property_name]) ?? NULL;

No longer applies:
drupal/entity_field_condition (1.4.0 => 1.5.0)

Attached a copy of the MR 5 applied on top of #3225480: Separate condition plugin for entity reference fields

I want to add a Selection Criteria to my Page Manager page based on a field in the current user's profile. I am able to add a Context to my page config for "current user" and then this work gives me a Selection Criteria of "Field Value". But selecting it fails as there is no context called "entity". Looking through code it seems it needs any context to be defined as "entity", which of course would not work as soon as one doesnt declare itself as that or there are more than 2.

This patch lets me select which context (out of the ones added in Contexts) to use for the field value.