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.
This is postpone on #1959806: Provide a generic 'entity_autocomplete' Form API element. We have to rethink and fix DER widget after the brand new 'entity_autocomplete' Form API element.
Comment | File | Size | Author |
---|---|---|---|
#24 | Screenshot 2015-02-18 19.32.24.png | 24.05 KB | larowlan |
#24 | Screenshot 2015-02-18 19.30.07.png | 44.89 KB | larowlan |
#20 | fixes_after_generic-2411981-20.patch | 22.2 KB | jibran |
#20 | interdiff.txt | 594 bytes | jibran |
Comments
Comment #1
jibranWell this is frustrating the parent issue got re-scoped and I have to change the logic again. But I think this is what you have to deal with if you are following a moving target. :/
Comment #2
jibranCan I get review/RTBC here before #2374019: Cleanup the use of custom item properties in EntityReferenceFormatterBase got fixed? Everything is green locally.
Comment #3
jibranMinor docs adjustment needed.
Comment #4
larowlanThanks jibran
Comment #5
jibranThank you for the review. Committed and pushed 2fe2783 to 8.x-1.x.
Comment #6
jibranI have changed the title and scope of the issue so that we can fix #1959806: Provide a generic 'entity_autocomplete' Form API element here.
Comment #7
jibranI pushed the fix for widget aa241d1 but we still need this issue to find a proper solution.
Comment #8
jibranThis is postpone on #2419923: Port SA-CONTRIB-2013-096 to D8
Comment #9
jibranComment #11
jibranI was expecting more test drama.
Comment #12
jibranI think I should create a bug against core for this.
Comment #13
Dave ReidI think the proper way to add this is:
There's no way for FAPI to know if you want the defaults merged in, or if you want to override them, so it's not a core bug.
Comment #14
larowlanIs this repeated on every target-type field? could we just store it in settings instead of repeating it?
We can inject this - widgets support injection right?
Where is this used? I don't see unserialize or decoding happening - or is there something in core you're using here?
Comment #15
jibranThank you @Dave Reid for the suggestion, I didn't know that. I'll fix it.
Thanks for the review @larowlan.
Comment #16
larowlan1. ta
2. sure
3. ta
Comment #17
amateescu CreditAttribution: amateescu commentedApart from #14.1, this patch looks good to me. Glad to see so much code removed :)
Comment #18
jibranHere we go. Fixed #14.1 and #13.
Comment #19
amateescu CreditAttribution: amateescu commentedDoesn't seem to be used below.
Are you sure this works? I don't see $delta used in the JS...
Comment #20
jibranThank you for the review.
It translates to select name(in this case $select[0].name) which is field_der[0][target_id], field_der[1][target_id], field_der[3][target_id] and so one. I am binding the change event on that select.
.
Comment #21
amateescu CreditAttribution: amateescu commentedHm.. okay, I'll let @larowlan mark it as RTBC then.
Comment #22
jibranDo you have some other implementation in mind?
Comment #23
amateescu CreditAttribution: amateescu commentedNope, not really.
Comment #24
larowlanWe have a UI regression here - the entity ID autocomplete now sits on the next line.
But the JavaScript elements etc all work fine, so other than the css issue/width issue - this is good to go.
Manual testing screenshot:
Comment #25
jibranI was unable to reproduce it. After increasing the text field size to 100 I was able to reproduce it but not with the default value 60.
Comment #26
jibranI tried the patch at simplytest.me and there was no UX regression. Committing this as per #21 and #24. Thank you everyone.
Comment #28
jibranOh it is an issue in firefox not in chorme
Comment #30
jibranFixed the issue in the follow up commit. Changed text field size from 60->40.