Since we are now past that timeframe, could you confirm if this update has been released or if there has been any delay? If the feature is available, could you provide guidance on how to enable it?
One it is reached a certain limit, the button is hidden :
jQuery(document).ready(function($) {
$(".hp-field--repeater .hp-field--button").click(function (e){//.hp-field--repeater .fa-times
//limit portfolio entries to 4 (hide button)
if ($("i.fa-bars").length>3){
$(this).hide();
}
});
However here is it a little more complicated, as you can select multiple elements at once. But you can prevent the form from being validated “on submit” based on the number of images.
Please note that we are still planning to add this update for Memberships this quarter. However, if you need this functionality specifically for Paid Listings, we can provide general guidance if you are familiar with coding or have a developer.
I understand that the update is still planned for Memberships this quarter. However, I specifically need this functionality for Paid Listings. Since I am a developer, I would appreciate any guidance or technical details you can provide on how to implement this feature manually while waiting for the official update.
In my case, the image upload limitation will be tied to a paid package and a specific listing category. HivePress was supposed to implement this feature, but it hasn’t been developed yet.
Your workaround with jQuery is interesting, but since the limitation depends on the selected package and category, I would need a more dynamic and integrated approach. Hopefully, HivePress will provide an official solution soon!
Hello! I have the same interest as the author of the post, but in my case is limiting in the free level. I tried some approaches with snippets, but I was unsuccessful, because in my process the advertiser creates the registration, then the ad and finally chooses the plan. Then the limitation is unfeasible before.
I tried the approach to exclude extra images after choosing the free plane, but I couldn’t get a suitable result of what I wanted. I even managed to limit the sending of images, but was valid for all plans and is not my goal. I’ll be following!
Thanks for the excellent work!
To add this functionality to Paid Listings, please try using this code snippet as a starting point Allow restricting listing attribute fields by package It allows restricting specific attributes to packages. To add the Images field to the attribute drop-down, you can try changing this line:
I would like to add a toggle field associated with the image upload field. This toggle would allow users to add more photos (e.g., by default, 3 images are allowed, but if the toggle is switched on, the user can upload up to 10 images for an additional price).
Then, when selecting a package (e.g., “Featured”), the extra cost for the additional images would be added to the total price of the selected package.
Another approach I am considering is that if the user selects the “More Photos” option, I could pre-select a package that includes this option (for example, using JavaScript) before the listing submission.
For example:
Featured package with extra photos → X$
Featured package (Classic) → Y$
Would you recommend a specific way to implement this within HivePress? Or is there an existing method to dynamically adjust the package price based on selected options?
As far as I know, that’s now the way it works. You can’t choose the package before the listing. Unless ihor or andrii can point you to the right direction and come up with an awesome solution.
If you want to assign a default package to user, here’s a possible solution, and you may start building from here.
Basically, you already have a valid “premium” package, then your listing will be able to have the extra features that come with it.
Maybe you can edit the feature afterwards, once you selected the package, with the exception of the categories, which are set once and for all.
Since packages are shared across all listings, I assume that I cannot limit the number of images only through the packages themselves, correct?
If this is correct, the solution would be to have an attribute directly at the listing level, similar to the “featured” option provided by the “Paid Listings” extension. This way, the image limit would apply only to the listing the user is currently submitting.
Questions that arise:
What is the best method to add a listing attribute similar to the “featured” option from the “Paid Listings” extension?
How can I integrate the cost of the “More Photos” option into the selected package price before the listing submission?
For this second point, my approach would be:
If the “More Photos” option is checked, allow more image uploads.
When selecting a package, either:
Add the additional cost to the package price dynamically.
Only display packages that already include the price of this option.
For example, let’s say I offer:
A free package (limited to 3 images).
A featured package (limited to 3 images).
If the “More Photos” option is NOT checked, I display both of these packages as options.
If the “More Photos” option IS checked, I only display:
A 10-photo package
A featured package with 10 photos
To do this properly, I should also allow users to select the free package, but this means that if they choose it, I would need to remove any extra uploaded images beyond the limit. Is this technically feasible?
I hope my explanation is clear. Let me know if you need further details!
This code fetches an array of the listing packages assigned to the current user. It would be also good to check if the user is not admin to prevent applying limits to the admins.
The remaining issue is adding the first listing, because the package selection appears after the listings form, so it’s not possible to increase the limit without filling the listing form first. A possible solution is adding a separate page and redirecting users there, so they would buy a package before the Add Listing process.
It is not working. I mean it’s always possible to allow multiple images even if the user does not have any credit left in the pro package, or is in a different package.
However :
I confirm it is possible to retrieve the current package name.
I also confirm the gist alone (limiting to three pix for instance) would work.
But the combination of both don’t, for some reasons. Is my code at fault ?
Anyway, I don’t think it can work in each and every case, as you select the package after the listing is already submitted (while in auto-draft state), in case there is no credit left.
Thanks for your reply. However, the suggested solution doesn’t really match what I’m trying to implement.
My idea is to have an attribute directly attached to the listing, which I believe would be the most flexible and scalable solution.
Here’s the logic I would like to apply:
During the listing creation, if the user checks the “Extra Images” checkbox, I will only display the packages that include this option (with the cost of extra images already included in the package price).
If the checkbox is not checked, I’ll display only the packages without the “extra images” option.
This raises two technical questions:
How can I add this “Extra Images” attribute to the listing, similar to how the “Featured” attribute is handled?
I was thinking about using ACF (Advanced Custom Fields) for this — would you recommend that approach, or is there a native HivePress way to add a custom attribute like this?
How can I filter the available packages based on whether the “Extra Images” option is checked or not?
Ideally, I’d like to check the value of this checkbox and dynamically show only the matching packages and hide the others.
Once the user selects a package and submits the listing, the value of the “Extra Images” field should be saved along with the listing data.
Is there a hook or another recommended approach to achieve this?
Sorry, implementing this logic would require advanced customizations. I can provide general guidance, but the implementation itself requires further research and testing.
You can add custom attributes via the UI in WordPress/Listings/Attributes or using code via the hivepress/v1/models/listing/attributes hook.
It’s possible to query packages this way:
\HivePress\Models\User_Listing_Package::query()->filter([
// query filters here
])->get();
Please note that adding a new checkbox to the packages to filter them by restriction (e.g. “Extra Images”) requires further code changes, e.g. using hivepress/v1/models/user_listing_package hook.
Thanks for sharing the code. You can try to debug this further, maybe the packages are not fetched correctly. But indeed, without changing the Select Package page order the code wouldn’t work for the first listing in any case.
After thinking about it further, I’m wondering if it would make more sense to treat the “Extra Images” option as a setting, similar to how it’s done for “featured” or “verified”, rather than as a standard listing attribute.
This option is not really a property of the listing itself (like the number of rooms or a product brand), but more of a promotion or enhancement tied to the listing process. That’s why I was considering using ACF (Advanced Custom Fields) to add a toggle field at the listing level, with the logic handled separately from standard attributes.
As for the package selection logic, I could then build upon your recommendation, and use a hook (like hivepress/v1/models/user_listing_package) to check whether the selected package includes the “Extra Images” option, and show or hide the relevant packages accordingly.
Does this seem like a reasonable approach in line with how HivePress is structured?
If using Paid Listings over Memberships is a requirement, then the easiest way is to move the Select Package page before Add Details. This way, by choosing the package (without extra images, or with extra images for a bigger price) it’s possible to detect on the next step (in the listing form) whether to show extra options/fields or allow extra images. This way you don’t have to store an extra field like Extra Images because the package selected by user already indicates this.
I recommend using the upcoming Memberships version if possible, because adding field limitation support to Paid Listings would require advanced customizations.
Thanks for your suggestion, I really appreciate it.
While moving the Select Package step before the Add Details step may be technically convenient, I have some concerns regarding the user experience (UX). Asking users to choose a package before knowing what they will need to fill out might feel confusing or premature, and could send the wrong message by making them feel like they’re committing too early in the process.
Also, this approach doesn’t seem very scalable. For instance, I may later want to limit certain packages to specific listing categories, and handling this logic cleanly would become more difficult in that flow.
I’m a developer, so coding is not a blocker for me — I’m comfortable implementing a custom solution if needed. That’s why I’m still leaning toward the idea of managing this logic at the listing level, for example with a toggle (like “Extra Images”) that would influence which packages are available in the next step. This would provide more flexibility and make the process more intuitive for the end user.
If you think it’s better, I’d be happy to continue this conversation privately (by email or messaging) so we don’t overload the forum with technical discussions.
Sure, you can choose the Extra Images toggle approach, or simply allowing users to upload images and hide these extra images if they choose the basic package later (this would be easier). You can add this toggle via the hivepress/v1/models/listing/attributes hook (it would be the same as using ACF, but without the plugin) and check this toggle when the image upload occurs, and also show specific packages on the next step, but this requires advanced customizations.
