Problem/Motivation
When an inline entity form is used to create content, the conditional_field.js
is not loaded and the conditional field rules do not run.
Steps to reproduce
- Download Drupal 8.9.0, Inline Entity Form 8.x-1.0-rc6; and clone Conditional Fields branch 8.x-1.x (when I wrote this, the latest commit was
9c9930e
) - Install Drupal using the Standard install profile. When that is done, install Conditional Fields and Inline Entity Form
- Go to
/admin/structure/types/manage/article/fields
, add a Boolean field named "Has image" (machine namefield_has_image
) - Go to
/admin/structure/types/manage/article/conditionals
and add a condition/dependency as follows:- Target field =
field_image
- Controlled by =
field_has_image
- The target field =
visible
- when the control field
is Checked
- Click
Add dependency
- Target field =
- Go to
/node/add/article
. Observe that when "Has image" is unchecked, the "Image" field is hidden; and when "Has image" is checked, the "Image" field is shown. - Go to
/admin/structure/types/manage/page/fields
, add a field of type [Entity]Reference
to entities of typeContent
named "Related article" (machine namefield_related_article
). Use the default configuration. - Go to
/admin/structure/types/manage/page/form-display
and change the widget from the default toInline entity form - Simple
. ClickSave
- Go to
/node/add/page
:- Actual behavior: Observe that the "Image" field is always shown regardless of the state of the "Has image" field.
- Expected behavior: When "Has image" is unchecked, the "Image" field is hidden; and when "Has image" is checked, the "Image" field is shown
Analysis
As originally mentioned in #1, the conditional_fields.js
file is missing, and the drupalSettings JSON which controls it is missing (the drupalSettings JSON for the working article form is...
"conditionalFields": {
"effects": {
"#edit-field-image-wrapper": []
}
},
)
The missing library and drupalSettings is because conditional_fields_form_after_build()
doesn't attach the libraries. It doesn't attach the libraries because it doesn't detect any conditional fields. Notably, though, it only runs for the outer form (i.e.: the basic page form in the steps to reproduce). It doesn't detect any conditional fields because $this->form['#conditional_fields']
does not exist in the outer form. $this->form['#conditional_fields']
is not added to the outer form because conditional_fields_element_after_build()
doesn't detect that the outer form is associated with the inner form's entity/bundle. conditional_fields_element_after_build()
detects whether a form is associated with an entity/bundle by calling $form_state->getBuildInfo()['callback_object']->getEntity()
.
Proposed resolution
Inject information about the inner form's entity so that it can be detected when conditional_fields_element_after_build()
runs for the outer form.
Remaining tasks
Figure out how to inject information about the inner form's entity.(done as of #27)Update the issue summary to better explain what the problem(s) are, how we could go about fixing them, and identify any remaining issues- Update the patch from #27 to identify the correct element to attach conditional field actions to.
- Statically cache DependencyHelper for different entity types / bundles: #1161314-235: Add basic Field Group support for ANDing conditions
- Review and feedback
- RTBC and maintainer feedback
- Commit and release
User interface changes
None.
API changes
None.
Data model changes
None.
Release notes snippet
To be determined.
Comment | File | Size | Author |
---|---|---|---|
#95 | 2856720-support-for-inline-entity-form-95.patch | 23.35 KB | ramil g |
#89 | interdiff.txt | 1.13 KB | ramil g |
#89 | 2856720-support-for-inline-entity-form-89.patch | 23.26 KB | ramil g |
#87 | interdiff.txt | 712 bytes | ramil g |
#87 | 2856720-support-for-inline-entity-form-87.patch | 23.13 KB | ramil g |
Issue fork conditional_fields-2856720
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
Topplestack CreditAttribution: Topplestack commentedSo far all I can tell is that it is related to the $form['#attached']['js'] method of attaching JS to a module where in Drupal 7 the same problem existed, but the drupal_add_js() function could be used instead. Since drupal_add_js() has been deprecated in D8, it's not an option. So it looks like the $form['#attached']['js'] is actually at fault.
Comment #3
niko- CreditAttribution: niko- at Adyax commentedMy investigation shows that we need pass embeded entity for example via form state storage and make special handle method in conditional_fields_element_after_build for inline entities
Comment #4
niko- CreditAttribution: niko- at Adyax commentedComment #5
pavithra.raman CreditAttribution: pavithra.raman at Acquia commentedTried this patch, but while calling the inline entity form I get this error
Comment #6
xavier.massonI've the same problem, when you check the Drupal 7 implementation, it's really different the use the field to retrieve $entity_type and $bundle (it's the right way after several tests). Using the $build_info = $form_state->getBuildInfo(); return the root parent form entity_type and bundle, not the inline entity.
Code below is the Drupal 7 implementation, and returning right values in Drupal 8.
The second issue i've seen, it's the inline entity form fields do not exists in this form :
Comment #7
Topplestack CreditAttribution: Topplestack commentedComment #8
xavier.massonUp, no one to work on this major issue ?
Comment #9
tisteegz CreditAttribution: tisteegz commentedIs this just talking about conditional fields within an inline entity form or also about the inline entity form field being a conditional field itself?
I have fields which I only want to display if my entity reference (using inline entity form) has a value but nothing seems to be happening?
Comment #10
Topplestack CreditAttribution: Topplestack commentedThis is specific to conditional fields on an entity being displayed via an inline entity form.
Comment #11
colan#5 looks a lot like #2950955: Type Error generated in conditional_fields_evaluate_dependencies(). Are you sure it's related to IEF?
Comment #12
Topplestack CreditAttribution: Topplestack commentedI'll update conditional fields and test as soon as I can. Likely early next week.
Comment #13
achapcolan, I tried applying the patch that you linked in #11 but it didn't appear to load the conditional field's js. I guess they are separate issues then.
Comment #14
achapah... completely missed that you were talking to the commenter from #5. My bad.
Comment #15
scott.whittaker CreditAttribution: scott.whittaker as a volunteer commentedJust noting that the patch in #4 gives me a 500 error creating IEF content:
Comment #16
vbory CreditAttribution: vbory commentedDoes anyone have any updates regarding this issue?
Comment #17
scott.whittaker CreditAttribution: scott.whittaker as a volunteer commentedNot from me unfortunately, I ended up re-implementing conditional fields with custom javascript.
If you want to do the same, you'll be able to catch IEF Ajax callbacks using Drupal.behaviours. Here's an example:
Comment #18
cweldon CreditAttribution: cweldon as a volunteer commentedAny updates on this issue? Anything I can do to help?
Comment #19
yuseferi CreditAttribution: yuseferi commentedI have the same issue with 8.x-1.x-alfa4.
doesn't work with inline form complex form.
Comment #20
peter.thorndycraft CreditAttribution: peter.thorndycraft commentedWe have the same issue as above, inline complex forms are not adhering to the conditional fields settings
Comment #21
colan#8, #16, and #18: Comments like these (e.g. "Are there any updates?" and "Why isn't anyone working on this?") are simply noise. Please stop posting them as they don't move anything further along. If there were any updates, they'd be posted here. And nobody's working on it because nobody else is paying them. That's how open-source software development works.
#18: Your offer to help is appreciated. What we need it an updated patch the fixes the problem above. Are you either (1) able to provide one yourself, or (2) pay someone else to do it?
Comment #22
mebel192 CreditAttribution: mebel192 commentedMhh Inline entity form and conditionnal fields not working i disable conditionnal field inline entity form work.
setup:
1- Add content type member
2- Add 2 fields entity ref with taxonomy
3- in form use widget inline entity form complexe for two field with permission only select taxo no creation.
create new member
in the entity field enter noting and clic add... after that clic cancel.
the fields just clone the last fields entity
very wierd, help
Comment #23
chriscalip CreditAttribution: chriscalip commentedI am trying to move this issue forward.
Here are my initial findings.
The inline_entity_form provides field widgets (inline_entity_form_simple & inline_entity_form_complex) for field types, entity_reference & entity_reference_revisions. Both field widgets then provide Render Element Type, inline_entity_form, ie. Drupal\inline_entity_form\Element\InlineEntityForm. The render element type, inline_entity_form, then presents an entity form based on either Drupal\inline_entity_form\Form\EntityInlineForm or Drupal\inline_entity_form\Form\NodeInlineForm.
The conditional_fields module is currently geared towards Drupal\node\NodeForm. Fortunately, inline_entity_form, provides a hook for integration. Other modules have integrated with inline_entity_form via implementation of hook_inline_entity_form_entity_form_alter.
For example: auto_entitylabel_inline_entity_form_entity_form_alter, geocoder_field_inline_entity_form_entity_form_alter, and field_group_inline_entity_form_entity_form_alter.
At this point in time, I believe a similar hook might do the trick. Initially I thought an updated https://www.drupal.org/files/issues/2856720-4-IEF-support.patch per deprecation of `conditional_fields.api.inc` in favor of `src/ConditionalFieldsFormHelper.php` would be enough. I don't believe an update on `src/ConditionalFieldsFormHelper.php` would be necessary .. hopefully integration through hook would be enough.
Comment #24
colanThe work happening in #1161314: Add basic Field Group support for ANDing conditions may be helpful as there's a fair amount of refactoring to allow for nested fields. Would it make sense to postpone this on that one?
Comment #25
chriscalip CreditAttribution: chriscalip commented#24 @colan
The work needed is an abstracted utility that adds/processes conditional-fields given an entity-form.
The situation is that a form can have field/fields with each field can have multiple values (entity-references) and each of those
entity-reference value is an entity-form.
EG. node has entity-reference fields field_a, field_b which have multiple values thus multiple entity-forms.
each entity-form is then passed to
conditional_fields_attach_fields($entity_form, $context);
So then:
Comment #26
colanAdded missing link to IEF in IS.
Comment #27
nuezI've been doing some work on this.
Currently, conditional fields heavily relies on the assumption that all field dependencies are available in the root the form array. See for example:
$form['#conditional_fields'][$dependee['#parents'][0]]['parents'] = $dependee['#array_parents'];
$dependee['#parents'][0]
hook_inline_entity_form_entity_form_alter
hook to add them.I've looked into that one but it looks like the issues are not so much related.
I have seen that there is a change in the
conditional_fields_load_dependencies
function that won't work with this patch because it creates a staticDependencyHelper
that doesn't take into account the possibility of needing this helper with different entity types and bundles in one request. I'll leave a comment on the other issue.Comment #28
nuezIt looks like the same tests are failing as on https://www.drupal.org/project/conditional_fields/issues/1161314#comment..., so possibly unrelated.
Comment #29
nuezComment #30
mparker17Updated issue summary and some issue metadata.
The patch in #27 does inject information about the inner form's entity so that it can be detected when
conditional_fields_element_after_build()
runs for the outer form, by attaching the entity type ID, bundle ID and field name insideconditional_fields_field_widget_form_alter()
; as well as making sure that theconditional_fields_element_after_build()
function is attached to the element, not the form.The result is that both
conditional_fields.js
and the drupalSettings snippet are added to the outer form. However, the patch in #27 doesn't work using the steps to reproduce in the issue summary, because the drupalSettings snippet specifies an HTML ID that would be valid for the inner form, but is not valid once that inner form is injected into the outer form by IEF. That is to say, using the steps to reproduce, the drupalSettings snippet is...... but the image field wrapper inside the inline entity form has the HTML ID...
#edit-field-related-article-0-inline-entity-form-field-image-wrapper
, so the code inconditional_fields.js
does not run.The patch in #27 also appears to contain some media-entity-specific code...
... which we should re-evaluate for 8.9.0 and/or make more universal.
So I'm setting the issue to "needs work".
Comment #31
alegacy99 CreditAttribution: alegacy99 commentedIs there any patch that works for 8.9.2 available? Tried #30 but fails.
Comment #32
NightArComment #33
NightArI had made some changes in the patch, actuality I got the bundle and entity_type data from the "Inline Entity Field" module.
Also, when we got the states of the fields, I got the components from the EntityFormDisplay object, which I got from the entity object stored by the "Inline Entity Field" module.
Comment #34
djdevinI tested #33 and visually it worked! But on form submit (the form containing the IEF) I got an error. I can't investigate it right now so here it is. Basic conditionals were set up (checkbox on a text field).
Comment #35
NightArI had update the patch.
Comment #36
djdevinI tested this, the fields now show/hide and save correctly.
Unfortunately it does not seem to work with conditionally required/optional fields, but I believe that may be an existing issue with conditional fields outside of this patch. A required field is still required if it is hidden conditionally.
Comment #37
NightArAs I see, the issue with the required field in the hidden state already exists - https://www.drupal.org/project/conditional_fields/issues/2845855.
I guess it should be updated.
Comment #38
darrenwh CreditAttribution: darrenwh as a volunteer and commentedI've just done a clean install of D9 and the issue is no longer replicable.
Screen recording
I wonder if a change in this core resolves this issue?
Will retest with latest version of 8.9
Comment #39
darrenwh CreditAttribution: darrenwh as a volunteer and commentedI have installed a boilerplate version of Drupal 8.9.7 on docksal.
Installed and enabled both of the above modules.
Have same result as above, so cant replicate issue.
I have not tested the scenario mentioned in #36
Can anyone replicate this in the current version of Drupal?
Comment #40
darrenwh CreditAttribution: darrenwh as a volunteer and commentedReading the replication steps, step 8 says to go to node/add/page this is what I have done, but reading more of the issue it seems to be more related to embedded entities that have the same fields where the issue is, my bad. Will look at the final task...
Comment #41
darrenwh CreditAttribution: darrenwh as a volunteer and commented@djdevin I have tested the latest patch in the scenario mentioned, discounting my comments in 38 ad 39, and I still see the issue with the conditional action not working inside of the inline entity on a CT. on your comment on 36 you say you have tested and it works?
Comment #42
hedge89 CreditAttribution: hedge89 commented[@nightar] your patch works for me, but only for the first layer of IEF. We have IEF within IEF and it doesn't work below the first level.
My company are looking to pay for someone to complete this work and get the fix committed, is anyone who is familiar with the issue available?
Comment #43
vselivanovPatch #35 doesn't work for multiple entity reference field with IEF (both Simple and Complex widget types).
You can create/edit the 1st node with IEF, but will get the error with the 2nd one.
Comment #44
ChrisDarke CreditAttribution: ChrisDarke as a volunteer commentedWould be great if this patch supported other EntityForm types, and as such if instead of enforcing instanceof NodeForm in getFieldFormDisplay, it instead checked against ContentEntityForm. I am currently testing this approach as my use case is not with a NodeForm, but if anyone knows of other issues this may bring up, do give me a shout... also going to be looking into the other issues around the multiple IEF.
Comment #45
colanAs #1161314: Add basic Field Group support for ANDing conditions is now in, this may need to be re-rolled.
Someone mentioned over there that it will be necessary to statically cache DependencyHelper for different entity types / bundles. The details are at #1161314-235: Add basic Field Group support for ANDing conditions, and I added this to the remaining tasks in the IS here. Please remove it if that's now out-of-date, or something.
Comment #46
ChrisDarke CreditAttribution: ChrisDarke as a volunteer commentedRerolled that patch with a couple of tweaks in this fork:
https://git.drupalcode.org/issue/conditional_fields-2856720/-/tree/28567...
Comment #47
Dave Kopecek#46 Works for me when patched against 48b240345
Comment #48
nonom CreditAttribution: nonom commentedThis project is no longer maintained?
Comment #49
lmingarro CreditAttribution: lmingarro at easytechgreen commentedI reproduce the error using
And changed the widget from the default to Inline entity form - Complex not simple as the description saids.
Then I fetched the issue fork conditional_fields-2856720 and the error was fixed. I'm not sure which patch was applied to the fork but now the bug is fixed.
I'm not sure if this is enough but I changed the status of the issue
Comment #50
lmingarro CreditAttribution: lmingarro at easytechgreen commentedComment #51
nevergone CreditAttribution: nevergone commentedComposer-compatible patch from https://git.drupalcode.org/issue/conditional_fields-2856720 repository.
Comment #52
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedIf I use a non-default form mode t display IEF, would this issue help, https://www.drupal.org/project/conditional_fields/issues/3063330
Comment #53
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedalso this does not apply for me anymore
Comment #54
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedComment #55
lmingarro CreditAttribution: lmingarro at easytechgreen commentedComment #56
lexsoft CreditAttribution: lexsoft commentedDrupal Version
8.9.13
51 patch applies for me on "drupal/conditional_fields": "1.x-dev#5ae3db4b5497d5ea487a0d6cc9ee1f5ddf9c931f"
But the required condition does not work on inline entity form. Visible and invisible for fields works.
Comment #57
lexsoft CreditAttribution: lexsoft commentedComment #58
lexsoft CreditAttribution: lexsoft commentedIt would be really useful if we can get this in 4.x .
Comment #59
Anilu@Intalling patch #51 with composer did not work
Drupal core 9.3.9
Composer.json
"drupal/conditional_fields": {
"Support for Inline Entity Form": "https://www.drupal.org/files/issues/2020-05-15/2856720-51.patch"
}
❯ composer install
Gathering patches for root package.
Removing package drupal/conditional_fields so that it can be re-installed and re-patched.
- Removing drupal/conditional_fields (4.0.0-alpha1)
Deleting web/modules/composer/conditional_fields - deleted
Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform.
Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. It is recommended that you run `composer update` or `composer update
`.
Package operations: 1 install, 0 updates, 0 removals
Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.
- Installing drupal/conditional_fields (4.0.0-alpha1): Extracting archive
- Applying patches for drupal/conditional_fields
https://www.drupal.org/files/issues/2020-05-15/2856720-51.patch (Support for Inline Entity Form)
Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2020-05-15/2856720-51.patch
In Patches.php line 326:
Cannot apply patch Support for Inline Entity Form (https://www.drupal.org/files/issues/2020-05-15/2856720-27.patch)!
Comment #60
Anilu@I tried #52 related issue solution and did not work with Drupal core 9.3.9
Comment #62
MurzI've re-rolled patch from #51 on last 4.x-dev version in a new branch: https://git.drupalcode.org/issue/conditional_fields-2856720/-/compare/4....
but it doesn't work properly, seems too many changes were happened in the module.
So I've started from scratch in this branch: https://git.drupalcode.org/issue/conditional_fields-2856720/-/tree/28567...
Comment #64
MurzI've created a new implementation of the functional for adding support of inline_entity_form to the Conditional Fields module in the https://git.drupalcode.org/project/conditional_fields/-/merge_requests/16#note_92767 - can anybody please review and test it?
In this implementation I'm checking all parents of the element, and if found parent with id
inline_entity_form
- I'm extracting this subform as separate form, getting$entity_type
and$bundle
from it, and removing all parents upper than inline entity form.After that I'm passing the data to further processing without changes.
Also I've got a problem with
case ConditionalFieldsInterface::CONDITIONAL_FIELDS_DEPENDENCY_VALUES_WIDGET
- it works wrong for me in all cases, so I've changed the logic to fix it. Hope this fix doesn't broke any other widget types.Please test and review my implementation and leave comments if anything needs rework, or something goes broken.
Comment #65
jwilson3latest MR doesn't apply to 4.0.0@alpha but works fine for my use case:
composer require drupal/conditional_fields:dev-4.x
Haven't had a chance to review the code changes in detail, so I apologize that cannot really give any feedback at the moment.
Comment #66
lexsoft CreditAttribution: lexsoft commentedThis patch is the merge work done by @Murz plus 1 commit from myself.
Should apply to latest dev:
"drupal/conditional_fields": "4.x-dev@dev"
Comment #68
lexsoft CreditAttribution: lexsoft commentedShould apply to latest dev:
"drupal/conditional_fields": "4.x-dev@dev"
Comment #69
lexsoft CreditAttribution: lexsoft commentedComment #70
Selphie CreditAttribution: Selphie commentedI tried the patch from #68 with Drupal 9.5 and conditional fields 4.x-dev and it is not working in my case.
If I edit Entity A directly, it is working. If I edit Entity B having an entity reference on Entity A via Inline Entity Form, it throws wsod.
I got the following error report:
I tried to debug and there indeed seems to be no "#field_parents" in the dumped data (DANGER: serialized!):
a:30:{s:5:"#type";s:5:"radio";s:6:"#title";O:37:"Drupal\Core\Field\FieldFilteredMarkup":1:{s:9:"*string";s:5:"Video";}s:13:"#return_value";s:5:"Video";s:14:"#default_value";b:0;s:11:"#attributes";a:1:{s:20:"data-drupal-selector";s:95:"edit-f827b9aabd816f689787eae1e49679f6-form-0-fd9217b12dea6e4c8e294f0c312b541a-video-d82wdgyd4fa";}s:8:"#parents";a:4:{i:0;s:32:"f827b9aabd816f689787eae1e49679f6";i:1;s:4:"form";i:2;i:0;i:3;s:32:"fd9217b12dea6e4c8e294f0c312b541a";}s:3:"#id";s:96:"edit-f827b9aabd816f689787eae1e49679f6-form-0-fd9217b12dea6e4c8e294f0c312b541a-video--D82wdgYd4FA";s:5:"#ajax";N;s:17:"#error_no_message";b:1;s:7:"#weight";d:0.001;s:6:"#input";b:1;s:8:"#process";a:1:{i:0;a:2:{i:0;s:32:"Drupal\Core\Render\Element\Radio";i:1;s:15:"processAjaxForm";}}s:11:"#pre_render";a:1:{i:0;a:2:{i:0;s:32:"Drupal\Core\Render\Element\Radio";i:1;s:14:"preRenderRadio";}}s:6:"#theme";s:12:"input__radio";s:15:"#theme_wrappers";a:1:{i:0;s:12:"form_element";}s:14:"#title_display";s:5:"after";s:15:"#value_callback";a:2:{i:0;s:32:"Drupal\Core\Render\Element\Radio";i:1;s:13:"valueCallback";}s:12:"#after_build";a:1:{i:0;s:38:"conditional_fields_element_after_build";}s:16:"#defaults_loaded";b:1;s:5:"#tree";b:1;s:14:"#array_parents";a:7:{i:0;s:32:"f827b9aabd816f689787eae1e49679f6";i:1;s:6:"widget";i:2;s:4:"form";i:3;s:18:"inline_entity_form";i:4;s:32:"fd9217b12dea6e4c8e294f0c312b541a";i:5;s:6:"widget";i:6;s:5:"Video";}s:10:"#processed";b:1;s:9:"#required";b:0;s:20:"#description_display";s:5:"after";s:7:"#errors";N;s:5:"#name";s:75:"f827b9aabd816f689787eae1e49679f6[form][0][fd9217b12dea6e4c8e294f0c312b541a]";s:6:"#value";b:0;s:15:"#ajax_processed";b:0;s:7:"#sorted";b:1;s:17:"#after_build_done";b:1;}
Thank you for your help!
Comment #71
B1 CreditAttribution: B1 as a volunteer commentedDrupal 9.4
PHP 8.1.7
Conditional fields: 4.x-dev@dev
Inline entity form:1.0@RC
Add a conditional field to an inline entity form.
Condition is ignored.
Apply Patch by lexsoft (comment #69)
Condition successful.
Unsure why Selphie (comment #70) got WSOD, perhaps a version of Video Module might cause conflict?
If someone else tests
support-for-inline-entity-form-2856720-67.patch , then perhaps we can move forward.
Comment #72
Vladimir Tanovic CreditAttribution: Vladimir Tanovic commentedAdded a patch for notice @Selphie got, I had the same issue.
One big notice, this patch does not work with the latest alpha version.
Comment #73
Vladimir Tanovic CreditAttribution: Vladimir Tanovic commentedHm, patch failed to apply but it did applied successfully on my side
Comment #74
nevergone CreditAttribution: nevergone commentedRe-rolled #2856720-73: Support for Inline Entity Form patch, base commit: b7dd4872a61c06f040b7a0997e044b9ad50136d0
Please check the re-rolling, manual fixing this patch.
Comment #75
Vladimir Tanovic CreditAttribution: Vladimir Tanovic commentedYep, thanks @nevergone, this should resolve the warning and notice on patch #68 for dev version.
There still needs to be created a patch for alpha version though.
Comment #76
nevergone CreditAttribution: nevergone commented@Vladimir Tanovic:
Why? Why is there no new (alpha, beta) release?
Comment #77
riazsaid15 CreditAttribution: riazsaid15 as a volunteer commentedWhen I apply the #74 patch then the below error comes in when I create a new node.
InvalidArgumentException: Missing required properties for an EntityDisplay entity. in Drupal\Core\Entity\EntityDisplayBase->__construct().
When I change the inline form entity from simple to complex then this error removes and conditional field logic is not working. Any idea why this error is coming?
Comment #78
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot for Vardot commentedOn editing IEF
I'm facing the same issue
"Missing required properties for an EntityDisplay entity."
Comment #79
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot for Vardot commentedFound 2 issues in the patch
Using PHP 8.0 and PHP 8.1
1st one
$widget_id
will not have a value. As it's in conditions .. needed$widget_id = '';
2nd one
$dependee_form_field['#entity_type']
it's empty .. I'm using paragraphs in my case$dependee_form_field['#bundle']
it is empty too. I'm using adoc
bundle for paragraphsThe following change over the
getState
method, will have it work in both simple and complex IEFNot sure in which hook it should pass the
#entity_type
and#bundle
Maybe the entity reference field should pass them in the other hook options.
This is a static fix ( using it as a local patch fix) , which should not be used as a general fix .. it's only for
paragraphs
and a paragraph type calleddoc
More generic fix should be changed in the MR or patch
Maybe a further checks over if the IEF module was enabled and used in the entity reference field widget
Comment #80
saurabh-2k17 CreditAttribution: saurabh-2k17 at Consensus Enterprises for Consensus Enterprises commentedHi, I have updated the patch with the changes from #74 and #79 including few other changes to make it work.
Please find patch and interdiff attached, Thanks
Comment #82
saurabh-2k17 CreditAttribution: saurabh-2k17 at Consensus Enterprises for Consensus Enterprises commentedComment #83
saurabh-2k17 CreditAttribution: saurabh-2k17 at Consensus Enterprises for Consensus Enterprises commentedHi, I updated the patch with some changes.
Comment #84
welly CreditAttribution: welly at manifesto commentedI don't know if it's related to the patch but I'm getting the following error when I applied it.
Comment #85
welly CreditAttribution: welly at manifesto commentedComment #86
ramil g CreditAttribution: ramil g at The University of British Columbia commentedHere's a re-roll of patch #83 for the latest 4.0.0-alpha5 release.
Comment #87
ramil g CreditAttribution: ramil g at The University of British Columbia commentedJust uploading another patch that fixes a part in afterbuild where it wasn't getting the right entity bundle.
Does this patch work for anybody out there? It's currently not working for us, and we're working on getting it to work. Just curious if there's anyone out there that this patch is working for.
Comment #88
joelpittetJust for context on the above interdiff in #87.
Our
$form['#bundle']
was null and thus FALSE. This is for a custom entity type. Grabbing it from the$form["#entity"]
gave it the right value (as is similar but not the same to the current code outside of IEF).We are playing with the idea of simplifying the code paths be removing:
And letting the $form variable be unchanged.
and
Looks to be unneeded since the reroll in #86.
Comment #89
ramil g CreditAttribution: ramil g at The University of British Columbia commentedThis patch gets it working for us.
Inside the getState method of ConditionalFieldsFormHelper, when you use $form_state to grab the entity , it gives you the entity from the main form, rather than the entity inside the inline entity form (the entity being referenced). This patch fixes that.
Comment #90
ramil g CreditAttribution: ramil g at The University of British Columbia commentedComment #91
Megha_kundar CreditAttribution: Megha_kundar at Srijan | A Material+ Company for Drupal Association commentedWorking as expected
Thank you very much for patch !!
Hence moving to RTBC.
Comment #92
very_random_man CreditAttribution: very_random_man as a volunteer commentedThis patch in #89 causes the following error when trying to use Config Split to edit a config split setting.
Removing the patch allows it to work.
Comment #93
joelpittet@very_random_man maybe you can provide more info? We use config_split also. What version and what config was being split? Maybe we can reproduce the error and fix it. Thabks
Comment #94
very_random_man CreditAttribution: very_random_man as a volunteer commentedApologies for the terse response. :-)
I'm not sure it's specific to the config. I get the error when just trying to edit the config split entity at /admin/config/development/configuration/config-split/[ id ]/edit
I'm using Config Split 1.9.0 on Drupal 10.2.1.
This is the complete backtrace:
Having now had a look in the code, it looks like the `findInlineEntityFormParentsForElement` method is getting confused and incorrectly identifying a checkbox element instead of an inline_entity_form on the basis that it is called 'inline_entity_form'. I would assume that this is because the config split form has a checkboxes for each module.
I think the solution would be to check to see if the parent IEF form is actually a form and not a form element as part of `findInlineEntityFormParentsForElement`, rather than just assuming that is only IEF forms are called 'inline_entity_form'.
Comment #95
ramil g CreditAttribution: ramil g at The University of British Columbia commentedThanks for reporting this @very_random_man and thanks for that info. I think you're right, it does need a check to make sure it's an inline entity form. We've implemented this in this new patch.
Comment #96
very_random_man CreditAttribution: very_random_man as a volunteer commentedNice one, thanks! That definitely does the job. :-)
Comment #97
dqdWhat a long issue and patch history! +1 for all the hard work in here.
Review/Testing now for commit ...
Comment #98
dqdBut we need some polish of the issue before commiting:
If the support of IEF has been assumed before in the project but needed fixes to work properly then this is a bug, yes, but if this hasn't been a documented feature yet in there before, it should be changed to Feature request for better tracking regarding change record details for a next release. Especially because this patch involves a lot of changes and additions.
IMHO, I rather consider this here Feature request, but, if this keeps being a bug for reasons, then the title is too random.
The summary part:
.. seems still valid in a certain way but the patch history kindof changed/increased the radius of the scope a little, so we need to change the title accordingly before commiting this change, since the original title is too random to track down possible follow ups. Thoughts for a better title from the latest patch authors?
We have
+ * Implements hook_inline_entity_form_entity_form_alter().
and
+ // Detect if this element is located inside inline_entity_form.
and namespace additions like
Again, to summarize: If this keeps being a "Bug" then we need a title better reflecting the fixes implemented. If we turn it into a "Feature request" - what I would recommend TBH - then the title is OK, because it is the issue where the final implementation of IEF support has been done.
Comment #99
dqdHm ... to speed things up here (this issue has run long enough) I take my own consideration into account. Especially because
clearly states that IEF hasn't been supported yet before. And I do not see any documented support for IEF in this project before mentioned. I will set this issue to FR now.
But I see a lot of issues with the same scope not linked here yet, like:
Some of them I will surely close in favour of this one here.
Comment #101
dqdComment #103
dqdAddendum: Removed patch file accidently left in file root from latest commit. Too many terminals open today to clean up the issue queue...