This is because the field's form element is not in fact at $form[field name] because we're on a profile2 entity inside a user entity.
This is because the field's form element is not in fact at $form[field name] because we're on a profile2 entity inside a user entity.
Comments
Comment #1
joachim commentedWIP patch; nearly there but there seems to be something wrong with the AJAX not getting loaded back in. No time to dig further right now, but posting this for later (or in case someone else feels like picking this up).
Comment #2
flocondetoileHi Joachim,
Thanks for you nice module.
I need to use reference option limit on taxonomy term field inside a profile2 entity.
I port your patch on the latest dev version (7.x-1.4+2-dev) and made some modifications to make it working with the ajax trigger.
This patch need some work yet to be more robust. It's a first attempt.
With this patch, reference option limit works fine now inside a profile2 entity, but i have yet some issues I don't understand.
If i select only one value in the field matching, then all is OK. But if i select more than one value (so in case of a multiple select), then I have a fatal error because it seems that the multiple values (returned by the callback ajax) of the field matching are returned in only one array with the tid separated by comma.
In fact, the form_state['values']['prodile_bundle'] contain this elements
Whereas it should be
And the form_state['triggering_element']['#value'] contain
Whereas it should be
I'm trying to debugging but for now seems that I'am blocked.
Any idea ?
Comment #3
flocondetoilethe patch.
Comment #4
joachim commentedThanks for looking into this!
> . But if i select more than one value (so in case of a multiple select), then I have a fatal error because it seems that the multiple values (returned by the callback ajax) of the field matching are returned in only one array with the tid separated by comma.
I've just tested this behaviour with nodes, and I get the same problem. So it's an unrelated bug -- file a new issue for that :)
This module was originally built with the controlling field as a single-valued field. I've never tried it with a multi-valued field there, so I imagine there will be work to be done.
I'd suggest you change your fields on profiles to be the baseline configuration -- a single-valued select controlling radios. If you can get that working, then I think we can say we've fixed Profile2 support.
Comment #5
flocondetoileThanks for the prompt feedback.
Hu !? I've just tested latest dev version with nodes, and it's work fine with a select multiple field for the matching element (test with a "Reference to a term" field type).
Options of the field limited are relevant according to the values selected in the field matching.
I've just tested too the patch #3 on a simple node and this works fine too. Need some test with some entity reference field.
What I do not understand is why, and how, on hell, the form is updated with values concatened of the matching field whereas only the limited field is returned with the ajax callback !? This issue seems occur only on profile2 entity.
Comment #6
joachim commented> Hu !? I've just tested latest dev version with nodes, and it's work fine with a select multiple field for the matching element (test with a "Reference to a term" field type).
Huh. It's working for me now! It wasn't earlier on!
Comment #7
flocondetoileLol :-)
Look good that we have same behavior !
Have you got an idea of the reason why tids aret passed to form in a single array, separated by comma, instead of an array of array ?
Do you process these data somewhere ?
EDIT : after read all the code, it seems that reference_option_limit don't process these data anyway.
Comment #8
flocondetoileWell,
I test the patch on a clean install and on a fresh installed profile2 entity.
It's works very fine, even for multipe select field.
So i must have a conflict with another module on the site i'm working on :-(
Comment #9
flocondetoileHi Joachim,
I Just realize that you succeed to reproduce this bug. Can you tell more about the context you've got same errors ?
Comment #10
joachim commentedI can actually still reproduce it on another test site! What's even weirder is that both this and the one that's working are running identical code for this module -- it's symlinked in!
I can't work out what's different between the two. taxonomy_field_validate() is receiving a badly formed $items, but I don't see how ROL can be responsible for that!
Comment #11
flocondetoileI succeed to reproduce the bug on the site where it's work fine.
If you have in the form (profile2 or node) a file (or image) field widget (and soo with some ajax), then the error occurs.
Comment #12
joachim commented> If you have in the form (profile2 or node) a file (or image) field widget (and soo with some ajax), then the error occurs.
Same here!
Thanks for figuring this out! IIRC there's an issue for that already.
Comment #13
flocondetoileIf you refer to this issue https://drupal.org/node/2006798
It's not the same use case. And the dev version have already your patch published in this issue.
Comment #14
joachim commentedYou're right. Cleaned that up, filed #2183127: error with multiple select for controller & file field.
Comment #15
Rdnala commentedPatch #3 works well with Profile2, but it doesn't support miltiple (chain) referencing fields. Patch #21 from Support one field changing 2+ fields works with chain referencing fields, bit doesn't work with Profile2.
Can anybody join these patches together to get completely working solution?
Comment #16
joachim commentedThe patch here applies, but it's got lots of whitespace errors and unrelated changes.
If someone can take care of that, I can commit it. Then the patch at the other issue can get rerolled.
@Rdnala: You shouldn't be working off patches anyway. The purpose of patches is to get committed, not be a shopping list for people to fix their code with.
Comment #17
joachim commentedNot sure why this patch isn't testing. Let's set it back to need review and see if that triggers the testbot.
Comment #19
joachim commentedComment #20
flocondetoileI join the patch #3 cleaned (no more dsm fucntion). Let's the bot test it.
Comment #21
Rdnala commented@joachim: I need a module to fill 3 chain referencing fields (A->B, B->C) in Profile2, and Reference field option limit is the only (and great!) module I found. Unfortunately, nor stable version, nor current dev doesn't work as expected, so I'm trying to work with dev and patches. I don't see another way right now :(
Comment #22
dariogcode commented#20 works very good. I'm using profile2, and after applied patch errors gone and everything is working ok. Thanks @flocondetoile.
Comment #23
dariogcode commentedI tested with other modules and reference option limit have problem in general with modules that attach fields or forms to an entity form. Also there are multiples patch and not well stablished way to implement each one. Do you have some like a roadmap?
Comment #24
joachim commentedIf you mean multiple patches on this one issue, then generally the latest patch is the one to consider, unless the comments say otherwise.
> not well stablished way to implement each one
Not sure what you mean by this.
> Do you have some like a roadmap?
Nope. I have very little free time at the moment. So it's a case of whichever issues get pushed forward by contributors get my attention. If you feel this project needs a roadmap, feel free to start a new issue for one, and invite people to discuss what they feel their priorities are.
I'm in the process of making a test module for use with Profile2, so I'll be in a position to test the patch myself soon.
Comment #25
joachim commentedPatch works, but needs a clean-up. There are loads of unrelated changes in it.
Comment #26
dariogcode commentedthanks for answer my comments.
About multiples patchs I mean some patch that need to be inlcude in dev if was tested properly, for example
#2035157: Limiting options in views exposed filters with ajax: https://www.drupal.org/files/issues/reference_option_limit-2035157_10.patch
#1814316: This one, in this thread: https://www.drupal.org/files/issues/reference_option_limit-support-profi...
#2239831: Replace form_alter with form_attach: https://www.drupal.org/files/issues/reference_option_limit-replace-form-...
I know that need to be tested properly, but my concern is that we can be overwriting something with patch that is neccesary or cover other issue.
And specfically about this patch, I have problem in two scenarios:
1. When implementing a limited field option in the profile
2. When using other ajax elements, for example in a form with two entities (node + profile). The special case of image field I tested, where doesn't allow me to upload images, when disabled one of the form, it works.
As mentioned early, this module appear not handle well when attaching forms to an entity, I see in some cases it is because the field parent isn't recognized, the module doesn't identify the corrent "tree" in form when doing ajax request/responses.
I really appreciate your time and I want to collaborate, so anything I can do to make this work, please let me know
Comment #27
joachim commented> I know that need to be tested properly, but my concern is that we can be overwriting something with patch that is neccesary or cover other issue.
That's a fair point. This issue and #2239831: Use hook_field_attach_form() instead of hook_form_alter(). overlap. Whichever one gets in first will cause the other one to need a reroll, and a very careful one at that.
Regarding causing regressions, this is why we have tests :)
> 2. When using other ajax elements, for example in a form with two entities (node + profile). The special case of image field I tested, where doesn't allow me to upload images, when disabled one of the form, it works.
How are you making your multiple entity form? Do we need to consider writing tests that use https://drupal.org/project/multiple_entity_form ?
Does the patch fix the problem for you in both scenarios, just one, or neither?
Comment #28
joachim commentedHere's a patch with just the tests. This will fail tests :)
Comment #29
joachim commentedOops, need to change the status so the testbot sees it.
Comment #31
dariogcode commentedThanks for share this https://drupal.org/project/multiple_entity_form, It is new for me.
I don't know well about test, so I'm a bit lost there, but I can try different patch to find the better combination. I will try to setup a fresh install with different settings and try to combine my forms.
I'm using https://www.drupal.org/project/inline_registration and https://www.drupal.org/project/profile2, or combinations. My main goal is to have a node form with user registration. Thinking better I guess I had 3 forms, the node forms, the user register form, and the attached profile2 form, a worse combination.
Inline registration add the user form in the node tree $form['register']['form'] and the profile add in $form['profile_profile_name']. And the errors becomes when you use reference_option_limit in those other form (profile entity or even user fields).
I'm not sure multiple entity forms will work with user registration, because the username and pass aren't part of the user entity form, probably doesn't apply for me.
Comment #32
joachim commentedHere's the patch at #20 cleaned up with all the unrelated changes removed, plus the tests.
BTW this patch and the patch at #2239831: Use hook_field_attach_form() instead of hook_form_alter(). merge fine, though it does look like the other issue's patch breaks the fix for profiles somehow!
Comment #34
Anonymous (not verified) commentedIt would be great to get this functionality working. Let me know if I can help.
Comment #35
joachim commentedPlease review the patch. Try the tests locally -- I suspect the failure is because we're adding a test module and the testbot doesn't like that.
Comment #36
joachim commentedLet's get this committed and a new release out :)
Comment #39
murfi commentedthank you for your work
i still have two issues:
1. i'm using the module in commerce checkout; i have a form with billing address and shipping address and both have fields with similar names; i have rebuilt the tree in $form_state['reference_option_limit'] and i have extended the wrapper name with the parents names to keep them distinct
2. there's also a checkbox which makes shipping address the same with the billing address; to keep the functionality, the function reference_option_limit_field_widget_form_alter must not bailout too early even if the ajax call does not concern it
i only tested the patch in this particular case