Support

Account

Register Login

Home › Forums › ACF PRO › Different values for same field groups on different options pages?

Solving

Different values for same field groups on different options pages?

  • So I have created 2 options pages. One I added under posts, and one under pages using acf_add_options_sub_page()

    I then created one field group, that it’s displayed on both options pages. This works, but the field values are stored as an option, so modifying one modifies the other. I thought that giving different slug names to each page would prevent that from happening, but it doesn’t.

    Is there a way to show the same field group on different options pages? But have different values for each page? Or do would I have to duplicate the field group and use different slugs for the fields?

  • After taking a look at the code. I only see this being possible if I added the current page options slug to the option_name. That way each field would have a unique name according to it’s option page. However, that would also require me to update the get_options and get_field functions to look at the correct option values.

    Does anyone see any other issues with changing the option_name value?

  • Fields added via options pages are all saved and loaded in via ‘option’ as opposed to page id. As such, the only way to have two options pages with unique data is to make them each have unique slugs.

    https://www.advancedcustomfields.com/resources/register-multiple-options-pages/

    Once you’ve changed the slugs for the pages, you won’t be able to see the data any longer – so do keep it open in a tab or just c&p somewhere if it’s important to keep a record of it before changing.

    As to referencing this data, outside of having an if statement to check the post type and output the relevant options depending on the outcome, if you put the relevant post type at the beginning / end of the field name, you could reference this using the WordPress get_post_type function.

    get_field( get_post_type($post) . '_description', 'options' );

  • This is weird, because I tried that. I gave all options pages unique slugs, but when the data is saved, it doesn’t create any relationship (that I can tell) between the option page and the field data. So the data shows up on every page. My initial thought was that the page slug would have been added to option_name. But option_name, in the options table, only contains options_name_of_the_field.

  • The slug of the options page itself doesn’t affect any of the content within, it just determines what the URL of the options page is in the backend.

    All of the actual fields are just saved into the wp_options table in the database using the field name from ACF. This means if you use the same field with the same field name on multiple options pages (irrespective of the actual page slug) this will be overwritten.

    <?php the_field('title', 'options'); ?>

    This is why I said, make two separate forms in ACF with the same fields in, but with different slugs. This would be something like:

    
Options page (Posts)
    - title_post
    - description_post

Options page (Pages)
    - title_page
    - description_page

    This effectively allows you to keep the slug the same per options page, whilst incorporating the post-type of the page that this options page will appear in, to keep them unique.

    Then when you call in this information, you can use the block I added earlier to specify which fields to look at:

    get_field( 'description_' . get_post_type($post), 'options' );

    On a posts page this will give you

    get_field('description_post', 'options);

    and on a page:

    get_field('description_page', 'options);

  • Thanks Edd. I misunderstood what you said previously. I thought you meant giving the pages different slugs. Duplicating the fields using different slugs was my initial approach.

    As a test, I modified the ACF code to include the page slug as part of the option_name, but that causes other issues down the road.

    Thanks for taking a look.

  • I would be curious to see a solution where duplicating the fields isn’t required. Sometimes post archive templates look the same, but they are custom and each require unique fields/settings. I may have 20 CPT Archives that all look the same and would be neat if the option storage could be connected with page it’s on. So for a field called “_description”, the slug of the page could be stored with it like “_staff_settings_description”.

    I’ve tried modifying the field names to just post values under different fields, but ACF must be looking up the “option_name” value with the field ID and always store it under that name. I’m looking for this code to see if I can modify it as well.

  • Ok, I think I came up with a working solution. Here’s the code:

    https://gist.github.com/solepixel/e8f09b9ba781502f893274ff8bf6dcf1

    Basically, each settings page needs a menu_slug and that menu_slug should have somewhat of a consistent naming convention to identify settings pages with common field groups.

    Then, the settings page also needs a way of identifying the unique values, in my case they’re associated with Post Type Archives, so I’m using the Post Type.

    I make sure the screen matches one of the desired settings pages, then I prefix the field with the Post Type, so I can grab the specific field setting in my theme. Hope that helps someone.

  • @briandichiara How would I implement that workaround for the case I describe at https://support.advancedcustomfields.com/forums/topic/same-relationship-field-for-multiple-post-options-sub-pages/ ?

    (ie. I want an Options sub-page or similar to store different sets of featured-post Relationships for two different custom post types).

  • Actually, having different options pages that use the same field groups can be done. The key is using the “post_id” setting when adding the options page. This defaults to options and ACF constructs the option name "options_{$field_name}". If you use the post ID of “options2” for example then acf will use the option name of "options2_{$field_name}". I don’t think that this is documented or well known.

  • @hube2 Thanks…
    But I am currently using acf_add_options_sub_page without acf_add_options_page().

    The following code…

    // Support showcase Features for this post type, via ACF

if( function_exists('acf_add_options_page') ) {

	// add sub page
	acf_add_options_sub_page(array(
		'page_title' 	=> 'Articles Features',
		'menu_title' 	=> 'Articles Features',
    'menu_slug'   => 'articles-features',
    'capability'  => 'edit_posts',
		'parent_slug' 	=> 'edit.php?post_type=article',
    'position'    => false,
    'icon_url'    => false
	));

}

    … makes a sub-page underneath the “Articles” post type menu entry.

    The post_id parameter seems to pertain to acf_add_options_page() and not acf_add_options_sub_page.

    Is there another way, eg. to use acf_add_options_page() for what I want?

    I intended to integrate the options page in to the post type menu folder since, rather than break it out elsewhere in the nav, since it pertains to the corresponding post type.

  • That does not matter. Options sub pages take the same arguments as options pages. This may not be clear from the documentation. The only thing that’s different is the parent slug. I use the slug of the options page as the post ID regularly now.

  • Hmm,

    Okay, adding 'post_id' => 'options2_featured_posts' successfully separates things in the backend…

    // Support showcase Features for this post type, via ACF

if( function_exists('acf_add_options_page') ) {

	// add sub page
	acf_add_options_sub_page(array(
		'page_title' 	=> 'Articles Features',
		'menu_title' 	=> 'Articles Features',
    'menu_slug'   => 'articles-features',
    'capability'  => 'edit_posts',
		'parent_slug' 	=> 'edit.php?post_type=article',
    'position'    => false,
    'icon_url'    => false,
	'post_id' 		=> 'options2_featured_posts'
	));

}

    But what does this mean for how I should call/display the resulting data?

    So far, I have used a common template part, “showcase”, to serve up the features in a consistent layout, including…

            // Must get IDs from ACF options page...
        $featured_posts = get_field('featured_posts', 'option');

    … as seen in the docs.

    How should that change to reflect options2_featured_posts?

    Do I perhaps have an issue using an underscore in the original field name?

    Thanks.

  • I experimented and think I figured it out…

    If I use 'post_id' => 'options2' in acf_add_options_sub_page per your suggestion, then where corresponding options2 needs to appear on display is…

    $featured_posts = get_field('featured_posts', 'options2');

    This suggests I can use…

    $featured_posts = get_field('featured_posts', 'article');

    $featured_posts = get_field('featured_posts', 'report');

    To display through my singular template fragment, showcase.php, I’m going to need to write a little piece to determine whether to call “article” or “report”.

    You’re right, this is not at all clear from docs. You should write ACF: The Missing Manual.

    BTW, I get a weird white screen when I save these options for the first time.

  • Sorry, I should have mentioned that you just need to use the same ID when showing the fields get_field('field name', 'any_post_id_value_here;);

  • If anyone is interested, my plugin actually has this feature built in and there are functions that allow you to get the “post_id” value for any options page based on the options page “slug” value. But I’m going to be honest, I don’t actually use my own plugin on production sites because it means additional database calls to register options pages. Some day I should build an “export to php” tool.

Viewing 16 posts - 1 through 16 (of 16 total)

The topic ‘Different values for same field groups on different options pages?’ is closed to new replies.