Get option values from specific options page?

• shshaw

• October 21, 2014 at 7:01 am

Using ACF Pro v5.0.9

If I have multiple options pages with the same fields, how do I retrieve option values from specific options pages?

For example: I have options pages for several custom post types to control some aspects of the archive display. If I use the same Custom Field Groups on those options pages, how do I get the values for those specific options pages?

I would expect to be able to use the_field('field_name','options_page_slug');, but that doesn’t seem to work.

• John Huebner

• October 21, 2014 at 7:45 am

You don’t. All options field names must be unique because they are saved in the “wp_options” table. The field name becomes the “option_name” value.

Basically you need to duplicate the field group and then manually modify the field names of all the fields for each options page

I have created an options page adder that includes a field group duplicator to do this automatically that I’d like input on if you care to try it.

• shshaw

• October 21, 2014 at 7:49 am

Hm. That’s unfortunate. Where are they stored under the wp_options table? I don’t see the one I’ve currently entered. Never mind, I was looking in the wrong database.

Like I said in the original post, I’d expect to be able to access the option by using the_field('field_name','option_page_slug');. For storing under the WP_Options table, it could be prefixed with that slug to keep options unique to specific pages.

• John Huebner

• October 21, 2014 at 8:57 am

The problem with adding a potentially long prefix (the options page slug) to an option_name value is that by default option_name in WP is limited to 64 characters.

This might not be a problem in a lot of cases, but when added to the way that repeater fields, or nested repeaters are stored it can become a problem that I’ve actually run into when building custom plugins and themes using ACF, and that’s without including a prefix for the options page name.

• Michelle

• November 5, 2014 at 5:28 am

No answer here, and I understand the limitations of the db/code right now, just another +1 for the idea of being able to retrieve values from specific options pages. This would be super-useful for specific custom-post-type options pages where the fields are similar/same across all CPTs.

• shshaw

• November 5, 2014 at 5:31 am

Agreed, Michelle.

To get around the 64 character limit, perhaps a sort of hashing could be done to give unique option slugs that meet that limit and ensure that option values can be unique to option pages?

• John Huebner

• November 5, 2014 at 6:10 am

I’m not the developer and can’t speak for him, not sure what will happen. I just see several problems with altering the way options values are stored.

The biggest problem for me would be backward compatibility. What happens with all the sites that are using the current method if you change all the options names. And this is not just for ACF. I build plugins that use ACF and it becomes necessary for me to use the standard WP get_option() function to get the values. I know what the “option_name” will be because I’ve spent a lot of time digging into the database to figure it out. I also build custom themes so that they will keep running even if someone deactivates ACF. ACF is needed for adding data, but not for retrieving it. By using get_option() and get_metadata() instead of get_field(), I ensure the theme keeps going no matter what. Changing the option_name value, from my point of view, would mean long hours of updating code to use the new storage names. It would also make it extremely difficult for anyone to know what’s going on when they look at the names in the database if hash values were used.

This is why I built my options page adder and field group duplicator plugin I mentioned above… but failed to include a link for it (https://github.com/Hube2/acf-options-page-adder)

• shshaw

• November 5, 2014 at 6:23 am

The need for backwards compatibility is certainly vital.

An alternative could be making the value become an object or array, with the options page identifier as the key, allowing you to retrieve the values for specific options pages, even without using ACF. This would get around the 64 character limit of option names and allow for unique values to be stored per options page.

Would that be any better in terms of backwards compatibility, Hube2?

• Gerben van Dijk

• October 14, 2016 at 12:19 am

I’d just like to give this a thumbs up; imho essential functionality that’s missing atm. Perhaps it’s better to move away from using the wp_options table for this?

Common use case for me: make a custom post type archive template editable. We’d have an options page nested under the post type in the CMS where the user can change certain variables. Now we have to create and maintain seperate field groups with the same fields in there to be able under each post type. Would be awesome if we could just have the one field group applied to multiple options pages; without them inheriting eachothers content there.

• John Huebner

• October 14, 2016 at 1:15 am

Just want to reiterate, that I’m not the developer and don’t make the decisions, so these are just thoughts of someone that’s spent a lot of time digging around in ACF and figuring out how it works.

There aren’t many choices in WP to store values. You have posts, post_meta, terms, term_meta, users and user_meta, comments, comment_meta and options.

There is the possibility of having ACF store values for particular options pages to a “Post ID”. In other words, when you set up the options page you tell it what post id to use and it will save the values there. This would allow for multiple options pages to use the same field groups without needing to modify field names.

From other comments and requests I think that it is commonly believed that ACF knows what custom field value belongs to a post or and options page. Really, it does not. It only knows what values belong to what fields and it loads the values associated with either the current post that’s being displayed or the post ID that is supplied when using the $post_id parameter in one of it’s functions. Without this 3rd bit of information that must either be assumed or supplied, ACF would be unable to find any data.

By the way, in my options page adder add on for ACF, one of the options lets you select saving values for an options page to a post. You can even select the options page post that you’re creating as the place to save your values to after you publish the options page, it is really the perfect place to save them since it’s not being used for anything and is already holding the information the options pages. You just need to be careful that you don’t use one of the field names that is used in the group for creating the options page, which should be pretty easy since they all start with “_acfop_”… https://github.com/Hube2/acf-options-page-adder

• shshaw

• October 14, 2016 at 1:30 am

Now that the clone field is available, one potential solution could be to use ‘Prefix Field Names’ to easily differentiate between multiple options pages with the same options.