I should have been more specific. Here’s the explanation:
This is how I used to register options pages:
acf_add_options_page([
'page_title' => __('Options page', 'textdomain'),
'menu_title' => __('Options page', 'textdomain'),
'menu_slug' => 'options-page-slug'
]);
This is what I refer to in the previous post:
acf_add_options_page([
'page_title' => __('Options page', 'textdomain'),
'menu_title' => __('Options page', 'textdomain'),
'menu_slug' => 'options-page-slug',
'post_id' => 'custom-id-as-a-string' // A custom string
]);
Thanks to this feature I don’t need to prefix custom fields names with a unique prefix, in order to avoid conflicts. I can simply register multiple options pages with a different post_id
parameter.
Then I’m able to get custom fields like this:
get_field('field_name', 'custom-id-as-a-string');
Direct answer to your question:
Fields are saved in the wp_options
table, but their names are prefixed with a value of the post_id
attribute. So if the field name is field_name
and the options page post_id
attribute value is custom-id-as-a-string
then the database entry is custom-id-as-a-string_field_name
.
I think it should be clearly explained in the documentation. It is said in the documentation that the post_id
could be an integer or a string, but it doesn’t explain that it can be any string. Users might think that the string should be a post slug or something… This is exactly what I thought before i started to play with custom strings.