jinvil

Hi,

Thanks again for the clarification and for the fixes included in 1.2.0.

While continuing to test the new version, I noticed what looks like a couple of remaining admin-side save paths that may still be using the previous hardcoded limits.

In admin/class-pvr-admin.php:

1. In ajax_save_review(), the admin Review editor still appears to apply hardcoded limits to:

• Author Name: 200 characters
• Review content: 5,000 characters
• Store Owner Reply: 2,000 characters

The relevant code currently still uses:

$author_name = mb_substr( $author_name, 0, 200 );
$content = mb_substr( $content, 0, 5000 );
$store_reply = mb_substr( $store_reply, 0, 2000 );

So if a review or store reply is edited from the PVR admin Review editor, it looks like the configured Review Max / Reply Max values may still be bypassed, including when those settings are set to 0.

I also noticed that Author Name is still capped at 200 characters here, whereas you previously mentioned that WordPress itself allows up to 250 characters for the author field.

2. In ajax_save_reply(), the admin Comments editor also still appears to trim reply content to 2,000 characters:

$content = mb_substr( $content, 0, 2000 );

So editing a reply through:

PV Reviews → Comments → Edit Comment

may still ignore the configured Reply Max setting and truncate content beyond 2,000 characters.

The intentional 200-character Title limit is understood and is not an issue.

It looks like the front-end save paths were updated in 1.2.0, but these admin-side handlers may simply have been missed.

Would it make sense for the admin editors to use the same Review Max / Reply Max validation logic as the front-end paths, so that:

• 0 continues to mean no plugin-level limit,
• non-zero values follow the configured setting,
• and content is not silently shortened during admin saves?

Just wanted to flag this in case it is an overlooked path from the previous implementation.

Thanks.

Thank you again for the work you have been putting into PVR.
After testing it more deeply over the last few versions, PVR has honestly exceeded our expectations by quite a large margin.
We originally approached it as a relatively focused way to add photo/media support to native WooCommerce reviews, but we have continued to find thoughtful details throughout the plugin.
For example, having the main visual system — accent, stars, cards, surfaces, text, borders and corner radius — exposed directly in the admin Design settings is extremely useful. It allows a brand to establish much of the basic visual language without immediately adding another layer of custom CSS.
The standalone review-form work has also been particularly valuable to us. When we explained why we wanted to collect reviews first on a separate “Share Your Experience” page, you added the official [pvr_review_form] capability very quickly. That allowed us to retire a custom PHP / JavaScript prototype we had already started building around PVR.
We also noticed several details that we had not even asked for. A good example is preserving the customer’s existing review text, rating and other entered information when the selected product changes. That is a small interaction detail, but exactly the kind of thing that makes a form feel considered rather than merely functional.
We are still mostly testing the main architecture at this stage, so there are many newer parts of PVR that we have not explored in detail yet. So far, however, the overall implementation has been a very pleasant surprise.
There is one small Product Picker UX point we would like to get your opinion on before we customize anything ourselves.
At the moment, the standalone picker is primarily search-first:
click the field → type part of the product name → results appear → select a product
We wonder whether, when the customer first clicks or focuses the product field, the existing product-result list could simply be shown immediately — without requiring the customer to type something first.
The reason is quite simple: a customer can own a product without necessarily remembering its exact product name. In our case, we deliberately use distinctive model names such as “Aura Petite”, so this is relatively easy. Other WooCommerce stores may use less memorable model names or product identifiers.
From the customer’s perspective, recognising the product they own from a visible list can therefore be easier than recalling its name before the interface shows any choices.
We are not suggesting that PVR needs another large picker system or additional catalogue/search features. In fact, we appreciate that PVR remains focused, and we would prefer not to encourage unnecessary feature growth.
What we have in mind is much smaller:
Select a product → click/focus → show the existing available product results → choose one
If the current picker architecture already makes something like this straightforward, we think it could slightly improve the review-submission experience.
If you prefer to keep the current search-first behaviour as PVR’s default, that is completely understandable. We also have the ability to adapt the presentation for VELARA ourselves using PVR’s existing customization layer.
Before doing that, we simply wanted to hear your view on whether this small interaction change makes sense at the plugin level, or whether you would recommend that we treat it as a VELARA-specific customization.
Thank you again.

Thank you again for the updates. We have now updated to PVR Media Reviews 1.1.6 and continued testing the new standalone Review Form shortcode.

The database-schema issue from our previous report is now resolved.

We first tested a completely new review through PVR’s native WooCommerce product-page form after updating to 1.1.6.

The complete workflow now works correctly:

• the upload progress is displayed;
• the success / thank-you state appears;
• the WooCommerce review is created correctly;
• the review appears under PV Reviews → Reviews;
• the uploaded photo is correctly associated with the review;
• after approval, the photo is displayed with the review on the product page.

So the database repair in 1.1.5 / 1.1.6 has resolved the original submission issue.

We have now moved on to testing the new standalone [pvr_review_form] shortcode on our “Share Your Experience” page.

Our previous custom standalone-form prototype has been disabled, so the following tests are using only PVR’s official shortcode.

We found two things that we would appreciate your guidance on.

1. Media selection does not complete when using picker="yes"

We tested:

[pvr_review_form picker=”yes”]

The product picker itself is available and we can select Aura Petite.

However, after the product has been selected:

• clicking “Click or drag files here” opens the operating-system file picker normally;
• we select a JPG image;
• after confirming the file selection, nothing happens in the PVR form;
• no image preview appears;
• no upload/progress state appears.

This is different from both:

• PVR’s native WooCommerce product-page form, where photo upload works correctly; and
• the standalone form with a fixed product, where selecting the same image does produce the expected preview.

Could you please check whether the media uploader is being correctly re-bound / initialized when the standalone form is used with the product picker?

2. Daily IP review limit on the standalone form

We also tested:

[pvr_review_form product=”393″ picker=”no”]

In this configuration:

• the product is correctly set;
• photo selection works;
• the photo preview appears correctly.

However, when submitting the review, PVR currently returns:

“Daily review limit reached for your IP address.”

We checked:

PV Reviews → Settings → Limits & Anti-spam

but we cannot find a setting for the daily review limit or IP rate limit there.

Could you please clarify:

• what the current daily IP review limit is;
• whether it is configurable;
• where that setting can be changed;
• and whether logged-in / verified-purchase customers are subject to the same IP limit?

During development we have submitted many test reviews from the same IP, so reaching a protection threshold is understandable. We mainly need to know how this limit is intended to be configured for testing and for the production store.

One additional UX question

With:

[pvr_review_form picker=”yes”]

the Aura Petite product image/name is already shown at the top of the form before the customer has explicitly selected a product from the picker.

For a store with multiple products, we would ideally prefer the initial state to remain product-neutral, and only display the selected product information after the customer chooses a product.

Is the current preselected product behaviour intentional, or is there a supported way to start the picker with no product selected?

Everything else is progressing very well.

We also tested the new 1.1.6 access controls and confirmed that setting:

Who can reply → Disabled

successfully disables customer-facing replies while the store administrator can still add an Admin Response from the PVR review editor. That is exactly the behaviour we were hoping for.

Thank you again for the very responsive development and support.

Thank you — your explanation of the customization options, especially the new template override support, is very helpful.
Before we move on to media integration, we have a more fundamental question about the PVR review form itself.

Our current use case
During the early stage of our brand, we intentionally do not want to display a review section on the product page when there are either no reviews or only a very small number of reviews.
For a new brand, we are concerned that showing a product page with “0 reviews” or only one or two reviews may reduce customer confidence rather than increase it.
For that reason, we created a separate page called “Share Your Experience”, where verified customers can submit public product reviews during this early stage.
Once we have accumulated enough genuine customer reviews, we plan to begin displaying those reviews as a complete review system on the corresponding product pages.

How we currently achieve this
At the moment, the Public Review section on our Share Your Experience page is built with an Elementor Atomic Form.
We developed our own access and purchase-verification logic, together with a custom server-side bridge. After a customer is validated, the bridge converts the Elementor form submission into a standard native WooCommerce product review for the selected product, including the rating, reviewer identity, verified-purchase status and moderation status.
This is why the reviews created through our standalone Elementor form are already visible correctly in PVR on the product page.

Our question
Instead of continuing to maintain a separate Elementor review form and bridging it into WooCommerce, we are wondering whether we could use PVR’s complete native review form directly on the standalone Share Your Experience page.
Specifically, can the full PVR review form be rendered on a normal WordPress / Elementor page that is not a WooCommerce single-product page, while assigning the submission to a specific WooCommerce product?
We are looking for something conceptually like:
Share Your Experience page → PVR Review Form → selected WooCommerce product → native WooCommerce/PVR review
We would like to use PVR’s complete review flow — rating, review text, photo/video upload and submission handling — rather than trying to embed individual PVR fields inside an Elementor form.
Does PVR currently provide a supported:

• shortcode,
• PHP function,
• widget/block,
• hook,
• or another recommended method

for rendering the full PVR review form for a specified product outside the normal WooCommerce product review tab?
If this is not currently supported, would this architecture still be technically possible using PVR’s existing template system and hooks?
Thank you.