Hi @hamid,
You’re welcome, and I’m glad we managed to find a solution that works for you in the end.
I’m sure others in the community will find it useful in time, too.
Regarding your enhanced approach, yes, that’s possible, and it’s probably a better approach than hardcoding listing IDs.
Two steps:
- Create the attribute
- Go to Listings → Attributes → Add Attribute:
- Title it something like “Hidden” and check the slug is hidden. The slug becomes the meta key with an hp_ prefix (dashes become underscores), so hidden → hp_hidden. If you use a different slug, adjust the snippet below to match.
- In the Editing section, set the field type to Checkbox.
- If only site admins should control this, leave “Editable” unticked, and the checkbox will appear only on the back-end listing edit screen. Tick “Editable” if listing owners should be able to hide their own listings.
- Leave the Search section options unticked.
- Replace the second snippet from my previous reply with this one:
add_action(
'pre_get_posts',
function ( $query ) {
if ( is_admin() || ( ! $query->is_main_query() && ! $query->get( 'hp_main' ) ) ) {
return;
}
// Skip singular requests so direct listing URLs keep working.
if ( $query->is_singular() ) {
return;
}
// Only target browsing contexts (archives, search, and the Listings page).
if ( ! $query->is_main_query() && ! $query->get( 'hp_archive' ) ) {
return;
}
// Keep any existing meta clauses (e.g. attribute filters).
$meta_query = (array) $query->get( 'meta_query' );
// Exclude listings with the checkbox ticked.
$meta_query[] = [
'relation' => 'OR',
[
'key' => 'hp_hidden',
'compare' => 'NOT EXISTS',
],
[
'key' => 'hp_hidden',
'value' => '1',
'compare' => '!=',
],
];
$query->set( 'meta_query', $meta_query );
},
1000
);
Ticking the checkbox now removes that listing from the Listings page, search results, and category archives, while its direct URL keeps working. Untick it to make the listing visible again. The NOT EXISTS clause is needed because HivePress deletes the meta entirely when a checkbox is unticked, rather than saving a “no” value.
And, to clarify; no – I’m not HivePress staff. I’m just a regular community member who enjoys helping out where I can. Helping solve other people’s problems has helped me learn about HivePress in much more detail, provide inspiration for my own site, and helps me increase my knowledge about HivePress should I run into similar issues down the line.
I also aim to inspire the community to be more involved and hopefully take some of the pressure off the HivePress team, so they can focus on implementing bug fixes and new features, etc.
I believe what Kseniia meant was that the help the HivePress staff provide falls under their support policy:
If you require further assistance in regard to developer guidance, custom implementation advice, and small code snippets, you should consider renewing your premium support, which you can do here:
For things outside either of these scopes, like custom themes, extensions or large logic changes, you can also consider hiring a HivePress-vetted expert here:
I hope this helps!
Cheers,
Chris 
