Home › Forums › Bug Reports › Options sub-page overwriting field values on other option sub-pages
I have multiple ACF options sub-pages. A couple of these options pages are making use of the same Flexible Content field that I use for displaying different rows of content.
Saving data in the flexible content field on one options sub-page, overwrites those values on the other sub-pages using that same field.
field names on options pages must all be unique, which basically means that you can’t use the same field group on more than one options page.
With the clone field you could use clone the field group and use the field name prefix option to make the fields unique on each options page.
Yea I thought about using the clone field prefixes to work around this, but thought I should report it here since it seemed like a bug to me.
I guess whether or not this is a bug is open to interpretation and Elliot will have to decide.
Personally I feel that an individual subpage should be treated uniquely from other sub pages. This might require that values from that subpage be retrieved a bit differently, like perhaps: the_field( ‘field_name’, ‘subpage-slug’ ), instead of the_field( ‘field_name’, ‘options’ ). Or maybe the_field( ‘field_name’, array( ‘options’, ‘subpage-slug’ ) ).
In the meantime I will work around this and leave it to Elliot and team to decide if this is a bug or a feature 😉
Options page values are stored in the _options table, there is only one place to save them in this case and creating two fields with the same name means they have the same option_name. ACF does not have any way to determine that a field belongs to a specific options page, either when saving it or when calling one of the front end functions with ‘options’ as the ID. Contrary to what a lot of people think, ACF does not actually track what field value belongs where, it simply save values to the database and then retrieves them when you supply the right information. The “Location Rules” have no effect on the fields, they just tell ACF that a group should be displayed. Saving values to an options page is like a “default”, if ACF can’t figure out where a value should be saved it ends up there. ACF basically works as a big wrapper for existing functions in WP. ACF has always worked this way and there is very little chance that this will change in the future.
If you want to submit this as a bug you should open a new ticket https://support.advancedcustomfields.com/new-ticket/, but I suspect you will get a response similar, but maybe a little less verbose, as the one I just gave.
There are choices. I’ve already mentioned a couple of them.
Another option, if you’re using ACF 5 (Pro), is to specify a post_id to save the options to when creating the options page https://www.advancedcustomfields.com/resources/acf_add_options_page/.
Another option is to customize the field group based on the options page that’s being loaded to add your own prefixes or suffixes to all the field names and then use these modified field names when getting the values in templates. This option would require a lot more explanation than is possible on this forum, but if you investigate this I suspect you’ll learn a lot more about why ACF works the way it works.
You must be logged in to reply to this topic.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
We’re reaching out to our multilingual users to ask for help in translating ACF 6.1. Help make sure the latest features are available in your language here: https://t.co/TkEc2Exd6U— Advanced Custom Fields (@wp_acf) May 22, 2023
© 2023 Advanced Custom Fields.