patroba

Hi @mikemeinz,

That’s absolutely perfect! Wrapping those functions in the acf/init hook exactly like that is the best way to keep your code running smoothly and warning-free.

Thank you so much for sharing your final working snippet with the community! If you ever need a hand with anything else, please don’t hesitate to reach out. Have a great day!

Best regards,
Patroba

Hi @mikemeinz,

Thanks for reaching out and providing that detailed Query Monitor stack trace! I know database errors can look quite alarming when they suddenly pop up on your dashboard.

That specific unserialize() error indicates that a serialized string in your WordPress database has been corrupted. Based on your stack trace, it looks like the configuration or saved data for a Repeater field inside your ACF widget has malformed byte counts. This almost always happens immediately following a site migration or a database search-and-replace operation that didn’t properly handle serialized PHP arrays, such as updating a URL where the string length changes but the serialized count does not.

To fix this, the corrupted data or the field group itself needs to be re-saved to regenerate the correct serialized string. Since fixing database serialization can get a bit technical, please feel free to open a direct support ticket so our team can help you safely analyze and troubleshoot your specific widget and field setup!

Best regards,
Patroba

Hi @masselyn,

Thank you so much for following up and sharing your solution with the community! I’m glad you were able to track down the culprit so quickly, and I completely agree, that is definitely a weird bug to encounter out of the blue.

You hit the nail on the head with your diagnosis. WooCommerce stores its native product prices using specific meta keys in the WordPress database, such as _sale_price. When an ACF custom field is created with a highly generic name that matches or closely resembles a native WooCommerce key, the database gets confused during the saving process and can overwrite the product’s actual price with unexpected or corrupted data. Prefixing your custom fields with something unique to your project, like tour_sale_price, is the absolute best practice to prevent these types of data collisions.

If you ever run into another strange conflict or roadblock like this in the future, please remember that you can always create a direct support ticket with us so our team can jump in and help you debug it right away.

Best regards,
Patroba

Hi @louie02,

Thanks for reaching out, and welcome to the ACF community! That’s actually a fantastic question, and it’s a structural detail that every developer runs into when first setting up their content architecture.

When naming your fields, we highly recommend going with more detailed, specific names rather than keeping them too simple. Using very generic field names like “title”, “date”, or “image” can sometimes cause unexpected conflicts with native WordPress database columns or other plugins. A great best practice is to prefix your field names based on the context of where they are being used, such as “event_start_date” or “hero_background_image”.

Taking a little extra time to use descriptive names not only prevents technical conflicts but also makes your PHP templates significantly easier to read and maintain six months down the line when you need to update your code.

What kind of content setup are you currently building for your project? If you ever need to share more details privately as your build progresses, you are always welcome to open a direct support ticket with us!

Best regards,
Patroba

Hi @24jobs,

I sincerely apologize for the long delay in getting back to you on this. I’m very sorry you were left waiting so long for some guidance on your tech stack!

To answer your main question: yes, absolutely! ACF, Custom Post Types, and FacetWP are fully compatible with Twenty Twenty-Four. Because TT4 is a modern Full Site Editing (FSE) block theme, it doesn’t use traditional PHP template files or classic “Widget Areas”. Instead, you will use the visual WordPress Site Editor to build your layout. You can display your ACF custom fields anywhere within these templates, like in a custom sidebar or hero section, using the ACF shortcode inside a Shortcode Block, by building custom ACF Blocks, or by utilizing the native WordPress Block Bindings API if you are running WordPress 6.5 or higher.

Regarding the Post Loops, the native WordPress Query Loop block is indeed the perfect place to integrate this. The core Query Loop block fully supports selecting and displaying Custom Post Types right out of the box. FacetWP also plays very nicely here; they offer built-in integration to hook their filtering directly into the core Query Loop block, or you can use FacetWP’s own blocks to completely replace the loop if you need more advanced sorting features.

You can read more about how ACF interacts with modern block themes and the Site Editor in our documentation here: ACF and Full Site Editing

If you start building out your TT4 templates and run into any specific roadblocks getting your fields to display, please feel free to open a direct support ticket with us so we can investigate your specific setup further!

Best regards,
Patroba

Hi @herve72,

I sincerely apologize for the massive delay in getting back to you on this. I’m very sorry you were left waiting so long for an answer!

It looks like you might have accidentally posted this in the wrong place! Your detailed bug report specifically mentions a conflict between the Admin Menu Editor plugin and Divi 5, but you have reached out in the Advanced Custom Fields (ACF) support forum.

Because our team does not develop or maintain the Admin Menu Editor plugin, we unfortunately cannot investigate or patch this specific TinyMCE initialization conflict. I highly recommend posting this excellent bug report directly to the official Admin Menu Editor support forum or reaching out to Elegant Themes (Divi) support so their respective development teams can properly address it for you.

Best regards,
Patroba

Hi @alcegraphics,

I sincerely apologize for the delay in getting back to you here.

To achieve this, the first step is to create a standard Text field in ACF and set the Location Rule to “Post Type is equal to Product”. This will successfully add the shelf locator input to all your backend product pages.

The second part requires a little bit of custom code, as ACF does not automatically inject field data into the WooCommerce order dashboard. To display that field next to the sold product on the order screen, you will need to use a WooCommerce hook (like woocommerce_after_order_itemmeta) inside your theme’s functions.php file. Within that hook, you can grab the product ID from the order item, and then use the ACF get_field('field_name', $product_id) function to output your shelf locator text directly to the shop manager.

You can read more about how to pull field values from specific post IDs in our documentation here: https://www.advancedcustomfields.com/resources/how-to-get-values-from-another-post/

If you try setting up that hook and are still having trouble getting your text to appear, please feel free to open a direct support ticket with us so we can investigate your specific setup further!

Best regards,
Patroba

Hi @hunterfox3,

Thanks for reaching out! Yes, there is a very straightforward way to do this. If you’re editing your PHP post template files directly, you can use the built-in the_field('field_name') function to output the value right onto the page. Alternatively, if you’re using the WordPress block editor or a specific page builder, you can display the value using the ACF shortcode [acf field="yfield_name"].

You can read more about the different functions and methods available in our official documentation here: https://www.advancedcustomfields.com/resources/displaying-custom-field-values-in-your-theme/

If you try those out and are still having trouble getting your text to appear, please feel free to open a direct support ticket with us so we can investigate your specific setup further!

Best regards,
Patroba