I’m building a marketplace with HivePress where vendors can purchase a membership plan to unlock the visibility of certain listing attributes (phone, social links, website) on their listings.
The logic I need:
If the vendor has an active paid plan → show the attributes on the listing page
If the vendor has no active plan → hide those attributes completely
I’ve found that HivePress stores active memberships as hp_membership posts with post_status = publish, post_parent = plan_id and post_author = wp_user_id.
I tried using the hivepress/v1/models/listing/fields filter to unset the fields based on a DB check, but the attributes still show even without an active plan.
Is this the correct filter to use, or is there a better hook for controlling attribute visibility based on the vendor’s membership status?
Before the guidance, have you considered using the built-in “Attributes (Display)” feature in a plan, which hides custom attributes when no active plan is available?
I’m aware of the “Attributes (Display)” feature in plans, but if I understand correctly, it restricts visibility based on whether the visitor/buyer has an active plan.
In my case, the logic is reversed - I need to restrict visibility based on whether the vendor/seller has an active plan. Specifically:
Vendor purchases a plan → their listing attributes (phone, social links) become visible to all visitors
Vendor has no plan → those attributes are hidden from everyone
Is there a built-in way to achieve this vendor-side attribute visibility control, or is a custom filter the recommended approach?
From what I understand, you can use the “Attributes (Editing)” option in the Restrictions (Vendors) section. This setting hides the selected fields from vendors, so when they create their profile, they won’t have access to those fields. If they want to use them (for example, phone number, etc.), they would need an active plan.
In other words, this allows vendors with an active plan to create more detailed profiles with additional information, while vendors without a plan will have more limited profiles.
If this is not what you’re trying to achieve, please let me know, and I’ll check how this logic could be adjusted or reversed.
The “Attributes (Editing)” approach makes sense for controlling what vendors can fill in. However, I have a concern about plan expiration:
When a vendor’s plan expires, the editing fields will be hidden correctly - but what happens to the data that was already saved? Will the attribute values (phone, social links) still be visible on the listing page even after the plan expires?
Ideally the behavior should be:
Active plan → attributes visible on listing page
Expired/no plan → attributes hidden from listing page (regardless of whether data is saved)
Is there a built-in way to handle this, or would a custom filter on the display side still be needed?
It should work as you described, but it seems there is a bug. Currently, the fields are hidden, but if there’s a value, it will still be visible on the page, just not editable.
We’ll fix it in future Membership updates. In the meantime, we can look into a temporary workaround. Let us know if you’d like us to suggest one.
Thank you for confirming! Yes, please - a temporary workaround would be greatly appreciated while we wait for the fix.
To clarify the desired behavior: when a vendor’s plan expires, the attribute values should not be visible on the listing page, regardless of whether data is saved. A display-side filter would be the ideal solution.
Please try the sample code snippet below, it replaces values of restricted attributes (defined in the code snippet) with the “hidden” word (you can replace it with an empty string or other placeholder) if the listing vendor has no membership or it’s expired.
Thank you for the membership snippet - it looks like exactly what we need. We’ll test it on staging this week!
One follow-up question: we’re about to create the contact attributes (phone, Instagram, Facebook, website) that we want to hide/show based on membership. We want vendors to fill in this info once, not re-enter it for every listing.
What would you recommend:
Create them as vendor attributes - can they be displayed on the listing page (not just the vendor page)? And would the membership snippet work with vendor fields too?
Or create them as listing attributes - is there a built-in way to auto-fill values from the vendor profile so they don’t have to re-enter the same data for each listing?
I’m not HivePress staff, but here’s a quick guide for syncing attributes as you describe.
Syncing Listing Attributes with Vendor Attributes
Here’s how to pre-populate listing attributes from vendor data:
Basic Setup
Create matching attributes with the same field name in both Vendor and Listing settings
Enable sync by checking the “Sync with the vendor field” option when creating or editing a listing attribute
Ensure compatibility — the attribute types should be the same or similar (e.g., select and checkboxes work together)
How It Works
Once configured, when a vendor updates their attribute value, it will automatically sync to all their listings with the same field name. However, note that:
Syncing occurs when the vendor attribute is updated
New listings created after sync is enabled will inherit the vendor’s current values
For best results, create the attributes from scratch rather than modifying existing ones
Code-Based Syncing
For more advanced syncing (like social links), you can use a PHP snippet like this:
add_filter(
'hivepress/v1/models/listing/attributes',
function( $attributes ) {
$fields = ['field_name']; // Replace with your field
foreach ( $fields as $field ) {
if ( isset( $attributes[ $field ] ) ) {
$attributes[ $field ]['synced'] = true;
}
}
return $attributes;
},
1000
);
This feature streamlines the listing creation process by reducing duplicate data entry for vendors.
Thanks again for the membership snippet - it works perfectly for hiding the attribute.
We’ve set everything up but the Plans page is blank and the Memberships menu item is missing from the vendor account sidebar. Here’s what we did step by step:
Created a vendor attribute (premium_phone, type: Phone, Editable) and a matching listing attribute with the same field name, with “Sync with vendor field” enabled
Created a virtual WooCommerce product for the plan (published, with price)
Created a membership plan in Memberships > Plans, linked to the WC product, Expiration Period: 30 days
Added the snippet you provided earlier to hide the attribute for vendors without an active membership (using unset instead of display_template = hidden, since that was showing the word “hidden”)
Created a Plans Page and set it in HivePress > Settings > Memberships > Plans Page
Content Types is set to “Listings” in Memberships settings
The attribute hiding/showing works correctly - tested by manually assigning a membership to a vendor. But:
The Plans page is completely empty (tested as both admin and vendor)
The “Memberships” menu item doesn’t appear in the vendor’s account sidebar
We have NOT set any restrictions in the plan (Attributes Display, Pages, etc. are all empty). Could that be the reason? Do we need at least one restriction for the plan to appear?
Please add the Memberships Plans block to your Plans page. At the moment, this page is not automatically populated with content like listings or vendors. Once you add the block, the available plans should appear. Additionally, even if you don’t create a dedicated Plans page, users will be redirected to a page with available plans that includes such restrictions when they trigger a restricted action (for example, trying to reveal a phone number).
Regarding the issue with the Membership section, I wasn’t able to reproduce it on my side. I added the snippet Ihor provided, created an empty plan, and assigned it manually to a user, the Memberships section appeared in the profile. I also tested with a plan that includes restrictions, and the section still displayed correctly.
Could you please share the exact steps to reproduce the issue or record a screencast? This will help me investigate further, and if there is a bug, we’ll make sure to fix it.
Also, please let me know which versions of HivePress and the Memberships extension you’re currently using.