Support

Account

Register Login

Home › Forums › Gutenberg › get_option() called dozens of times on option names that don't exist in the DB

Solved

get_option() called dozens of times on option names that don't exist in the DB

  • Using Query Monitor plugin I’ve spotted recently that ACF performs hundreds of get_option() queries. The queries seem to be related to my field groups registered for my ACF blocks.

    According to QM, the queries are like:

    SELECT option_value
FROM wp_options
WHERE option_name = 'block_5c18f2af95ec7_my-block-field'
LIMIT 1

    However, no such options exist in the database, so it seems to be something created by ACF virtually.

    Is this valid behavior? Why it is done this way? I’m little afraid seeing 50, 100 or more such queries reported by QM…

  • I have made some test and it seems that ACF calls get_option() when the block inserted into the content does not actually contain the field keys predicted during registration via acf_add_local_field_group().
    It happens when I save an empty block or a block with hidden fields.

    So when I add an empty block which looks within the code like:

    <!-- wp:acf/header {"id":"block_5c8ac410e890e","name":"acf/header","align":"","mode":"edit"} /-->

    the plugin looks for the missing fields in wp_options table, for example:

    SELECT option_value
FROM wp_options
WHERE option_name = 'block_5c8ac410e890e_my-header-content'
LIMIT 1

    where my-header-content is the name of a field type group in this case.

    It’s quite surprising for me – why ACF thinks that I store any block data in wp_options?

    Then, when I add some content into the subfield of my-header-content field, the plugin no longer queries wp_options for my-header-content and the block structure grows into:

    <!– wp:acf/header {“id”:”block_5c8ac410e890e”,”data”:{“field_my-header-content”:{“field_my-header-content-lead”:”This is our lead”,”field_my-header-content-text”:””},”field_my-header-aside”:{“field_my-header-aside-settings”:””},”field_my-header-background”:{“field_my-header-background-image”:””,”field_my-header-background-video”:””,”field_my-header-background-color”:”white”,”field_my-header-background-has-pattern”:”0″}},”name”:”acf/header”,”align”:””,”mode”:”edit”} /–>

    Well, after all I think I’ll report it on Github…

  • When the function get_field() is called, or any ACF function for that matter, ACF tries to determine the correct post ID. It goes through a series of test to try to figure out if the field is for a post, term or user. If it does these test and does not come up with a post, term or user then it defaults to options. Basically this is happening because ACF cannot figure out where to get the value from.

  • Thank you for the explanation.

    This is going to be solved: https://github.com/AdvancedCustomFields/acf/issues/150

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

You must be logged in to reply to this topic.