Before 5.3.8.1 the value of the name property for a sub field object, as returned from get_sub_field_object() matched the Field Name as entered when creating a field in the entry screen. Documentation for get_sub_field_object() confirms this behavior as well.
Post upgrade to 5.3.8.1, for subfields in flexible layouts and repeaters, the name property has been changed to <layoutname>_<index>_<actual_name>. For example, if I have Flexible Content with a name of myflexcontent and it has a layer that contains a field with a name of myselectfield, and i’m in the first loop through have_rows, get_row the name returned from get_sub_field_object is now myflexcontent_0_myselectfield where expected return ismyselectfield.
Is this a permanent change, or a bug?
5.3.8 had a bug, was this a radio field? It was reported here https://support.advancedcustomfields.com/forums/topic/choice-field-other-repeater-issue/
5.3.8.1 was supposed to have fixed it. At a guess, the renaming happened after updating to 5.3.8 and then the field was left with the wrong name when you updated to 5.3.8.1.
If this is not the case, please post more details about the types of field that’s being effected and how it can be recreated.
This is happening to every field included in a flexible layout, not just radios/selects.
I did hear back from James in support who indicated this is a permanent, known change. While disappointing, I’m pretty sure I can regex my way around it and pull out the original key/name. I don’t like doing that as it seems way too brittle… I guess maybe I could switch to using get_field_object instead of get_sub_field_object(), as it appears that get_field_object still returns the real name value instead of the adjusted name value.
Ah, I see, sorry I misread the op. What version of ACF did you upgrade from? Just curious because I can’t remember when this changed but I have noticed that the “name” attribute of sub fields does act the way you indicate for a while now.
There is another field attribute with the index of "_name" that contains the actual name of the field, this has also been there for a while. Like I said, I don’t recall when this was changed.
ah. We were on 5.3.7 and skipped over 5.3.8 and went straight to 5.3.8.1. That must be why we didnt see the change until now.
There is another field attribute with the index of “_name” that contains the actual name of the field, this has also been there for a while
PERFECT! Way better than regex’ing the key back out and keeps from having to retrieve and store more than what I want. Thank you!
Well, then it is a recent change, 5.3.8.1 came out the same day as 5.3.8 due to bugs that needed fixing. To be honest, I gave up on using field names for sub fields a long time ago so it may be another reason I haven’t notices, I almost always use the field key. The field names you’ve mentioned have always been there (or been there long enough that I can’t remember them being different) when using filters like load_field and load_value. It could be that the way they are now was something that’s been overlooked and may have been causing other issues, honestly, I don’t know, just guessing 🙂 I do know that the “_name” index has been there as long as I can remember though.
