Troubleshoot Your ACF Use via the WordPress Database

Most everything you do on a WordPress website impacts your database in some way and utilizing ACF is no different. While you can do severe damage to your site via the database if you start dropping tables or taking more consequential actions, it’s valuable to understand the insight harmless browsing of the database can offer to any troubleshooting efforts. Whether you’re having difficulty figuring out how to work with the ACF data you want or unclear on how the data is stored, knowing where to look is the first step.

Locating ACF fields in the WordPress database

The following is a helpful guide on where you can find ACF data in your WordPress site database. If your database prefix isn’t the default “wp_”, then adjust the location by replacing the prefix with the one more applicable to your situation.

• ACF Blocks (wp_posts): ACF block data is stored within the post_content field of a record in the wp_posts table.
• Post/Page/CPT Custom ACF Fields (wp_postmeta): If you attached a traditional ACF field to a post, custom post type, or page, that meta key/value pair will be found in the wp_postmeta table.
• Attachment ACF Fields (wp_postmeta): If you attach a traditional ACF field to any type of attachment that meta key/value pair will also be found in the wp_postmeta table because attachments are just a post type.
• Menu Item ACF Fields (wp_postmeta): If you attach an ACF field to a menu item that meta key/value pair will also be found in the wp_postmeta table because menu items are also a post type.
• Category/Tag/Taxonomy ACF Fields (wp_termmeta): Attaching an ACF field to a taxonomy will place the ACF field’s data in the wp_termmeta table.
• Menu ACF Fields (wp_termmeta): Attaching an ACF field to a menu will also place the ACF field’s data in the wp_termmeta table
• ACF Options (wp_options): If you’re an ACF Pro user and you’re leveraging an options panel, any ACF field assigned to that area will be found in the wp_options table. If you are using get_option to return an ACF options page value, the field name should be prepended with “options_”. If you have an ACF options field with the name custom_option_field, you’d use options_custom_option_field if calling it with get_option.
• User ACF Field (wp_usermeta): If you assign an ACF field to a user, that field’s data can be found in the wp_usermeta table.

How to access your WordPress site database

Most hosts provide a tool for browsing databases, the most common of which is PHPMyAdmin. Some hosts have their own database manager, such as Flywheel. If you use a tool for local development, like Local or DevKinsta, you’ll see capabilities to browse the database via Adminer.

Useful insights the WordPress database can provide

Browsing ACF data directly in the database can offer insights as to:

• How various field types store data: Whether you’re seeing how ACF repeaters store their values in the format repeater_name_X_subfield, with X being an incrementing row number or ACF groups append the group name to the field name before storing data, it can help you leverage that information for meta queries.
• Why get_post_meta can return a different value than get_field: For ACF fields where you’re choosing between multiple return values, the ACF field’s value stored in the database does not change regardless of what you select. For example, whether you choose to return an image field as an image array, ID, or URL, the ID is what is getting stored in the meta key named by your field. If you’re using get_post_meta, what you choose as the return value won’t impact it, which you can see when browsing the database. That choice only is impacted in what get_field or the_field returns.
• Native WordPress function alternatives to access the same data: You can remove dependency on ACF by falling back to native WordPress functions to pull data out of various tables. Whether that’s get_post_meta, get_term_meta, get_option, or get_user_meta, there’s usually another route to the same information ACF functions return. By knowing where the data you’re looking for exists in the database, you have options in how to grab that data.
• Identifying mistakes in field names or where you’re looking for them: There are a lot of ACF support instances where people are struggling to get the right items or data returned because they’re looking for it in the wrong place. By browsing the database and confirming how the data is stored and where it is stored, you can quickly troubleshoot these kinds of instances.

Overall, understand your WordPress database is nothing to be afraid of and a potentially valuable troubleshooting route when needed. Beyond even use of it with ACF, being willing to poke around in the database to find where various bits of data are landing is super useful when working with other plugins and themes. Once you realize that odds are anything is in your database somewhere, a lot of doors open in terms of how you can access and leverage any of that data.