Controlling Visibility and Request Detection

BreadcrumbsPress uses request conditions to select a page-type visibility setting and a builder. You can adjust the initial visibility decision or, for integrations that need it, the plugin’s detection of a request. First check Settings for the relevant visibility option.

Add examples to a site-specific plugin or child theme’s functions.php, and register them before the relevant check. Test representative pages and clear any page cache after changes.

Hide a current trail

The visibility filter receives an initial boolean. Return false to stop the normal current-trail visibility check from allowing display. For example, substitute your own page slug:

add_filter( 'breadcrumbspress_visibility', function( $visible ) {
    if ( is_page( 'private-area' ) ) {
        return false;
    }

    return $visible;
} );

Returning true still leaves the page-type settings in control. Forced display bypasses this check, including

. This filter is not a general visibility control for every specific-post or term trail. See Single Breadcrumbs Shortcodes for shortcode behavior.

Adjust request detection

Filters such as search, single post type, taxonomy archive, and 404 change BreadcrumbsPress’s internal boolean classification. Integration-specific examples include WooCommerce shop, bbPress view, and BuddyPress group.

Use these only when an integration needs a different classification. They can affect both the visibility setting and builder selected; they do not change WordPress’s own query. Preserve the incoming result for requests your integration does not handle, and return a boolean. Register the filter before BreadcrumbsPress evaluates the condition. Multiple conditions can overlap, so check the resulting trail and visibility for both the special case and ordinary pages.

If the classification is correct and only the trail contents need changing, use a builder or generator filter instead.