Custom Post Type Does Not Appear In Query Parameter

All the creds are in the “Private Information” below, including the link.

In the list view of the page, to get to the query loop click down through the named containers as shown:

Placements Section
  Placements Loop
    Query loop
      Grid
        Post Template
          Top Half
            Headshot Missing
            Headshot Present

The conditions are in the last two containers in the stack (Headshot Missing, Headshot Present).

The post type I am trying to query is “placement”.

Thank you for the Post Type direction. I flipped it, and it worked.

Do we have a target date for a release of the fix? I need to know if we should wait or if it is too long I’ll need to look for another 3rd party plug-in that facilitates this conditional formatting.

That worked! I added it via the Code Snippets plug-in with the description to remove or suspend it when GB Pro 2.4.1 is released.

I was a little nervous about altering the behavior of ACF, thinking there might be a reason for it to be the way it is. To check to make sure the code posted from YING earlier is safe, I triangulated her approach with AI. Fascinating result. It not only validates what she posted, but also seems to know that the proper fix would be in the query. I’m posting it here for grins:

# # #
The Prompt:
Background: The context is WordPress internals. A post type and field groups were created by ACF. One of the fields are optional. If the user does not populate it when creating the post, the key/value for that post/field is created in the database without a value. Would deleting that key/value with the delete_post_meta function create problems? It seems like if the post/key was created without a value, it should be that way for a reason.

Claude answers:
You’re right to be cautious! In the context of ACF (Advanced Custom Fields), here’s what’s happening and whether it’s safe to delete:

What ACF is doing:
When ACF creates a field entry in wp_postmeta without a value, it’s typically storing an empty string (”) as the value. ACF does this to indicate that:

The field exists and has been “touched” or saved at least once
The field is intentionally empty (user left it blank)
It helps ACF distinguish between “field was saved as empty” vs “field has never been saved”

Is it safe to delete?
Generally yes, but with caveats:

Deleting won’t break ACF – ACF will continue to work fine
The field will reappear as empty – If the post is edited again and saved, ACF will recreate the empty meta entry
You might lose the “has been set” state – ACF may treat it as “never saved” rather than “intentionally left blank”

When you might want to delete:
Database cleanup – Removing unnecessary empty entries to reduce database bloat
Conditional logic – You want to check if a field exists vs. is empty
Performance – On sites with many posts and fields, empty meta can add up

When you should NOT delete:
If ACF conditional logic depends on it – Some ACF setups check for field existence
If custom code checks for the meta key – Your theme/plugins might use metadata_exists() or similar checks
If you’re using ACF field groups with location rules – ACF uses these entries to track which fields belong to which posts

Better approach:
Instead of deleting, consider querying to exclude posts where the field is empty:

php
$args = array(
    'post_type' => 'your_post_type',
    'meta_query' => array(
        array(
            'key' => 'your_field_name',
            'value' => '',
            'compare' => '!='
        )
    )
);

# # #

You gave me the solution, Ying. I just validated it with Claude.ai. Thank you!