Title: jinvil's Replies | WordPress.org

---

# jinvil

  [  ](https://wordpress.org/support/users/jinvil/)

 *   [Profile](https://wordpress.org/support/users/jinvil/)
 *   [Topics Started](https://wordpress.org/support/users/jinvil/topics/)
 *   [Replies Created](https://wordpress.org/support/users/jinvil/replies/)
 *   [Reviews Written](https://wordpress.org/support/users/jinvil/reviews/)
 *   [Topics Replied To](https://wordpress.org/support/users/jinvil/replied-to/)
 *   [Engagements](https://wordpress.org/support/users/jinvil/engagements/)
 *   [Favorites](https://wordpress.org/support/users/jinvil/favorites/)

 Search replies:

## Forum Replies Created

Viewing 8 replies - 1 through 8 (of 8 total)

 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Photo & Video Reviews for WooCommerce — PVR Media Reviews] Advice on Adding Optional Review Titles](https://wordpress.org/support/topic/advice-on-adding-optional-review-titles/)
 *  Thread Starter [jinvil](https://wordpress.org/support/users/jinvil/)
 * (@jinvil)
 * [1 day, 4 hours ago](https://wordpress.org/support/topic/advice-on-adding-optional-review-titles/#post-19041436)
 * Hi,
 * Thank you for the quick response and for implementing this natively in 1.2.1!
 * This is even better than we had hoped for, especially with review titles supported
   consistently across the product pages, My Reviews, the all-reviews hub and the
   review details modal.
 * We were aware that implementing this ourselves would require some custom JavaScript.
   Since we’re using Elementor Pro Custom Code and PHP code snippets alongside our
   Child Theme, we could have handled the customisation on our side.
 * However, having the functionality built directly into PVR is definitely the better
   solution for us. It keeps our setup simpler, reduces the amount of custom code
   we need to maintain, and makes future plugin updates much easier to manage.
 * We also appreciate the clarification about the Product Picker’s `title` setting
   and the reminder to synchronise our overridden templates. We’ll take care of 
   that when updating to 1.2.1.
 * Thanks again for your responsiveness and for continuing to improve the plugin.
   This kind of native support makes a real difference for us as we plan to use 
   PVR long-term.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Photo & Video Reviews for WooCommerce — PVR Media Reviews] Character limits set to 0 still truncate review at 5,000 characters](https://wordpress.org/support/topic/character-limits-set-to-0-still-truncate-review-at-5000-characters/)
 *  Thread Starter [jinvil](https://wordpress.org/support/users/jinvil/)
 * (@jinvil)
 * [1 day, 11 hours ago](https://wordpress.org/support/topic/character-limits-set-to-0-still-truncate-review-at-5000-characters/#post-19041343)
 * 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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Photo & Video Reviews for WooCommerce — PVR Media Reviews] Only Customers (bought product) rejects a verified purchaser](https://wordpress.org/support/topic/only-customers-bought-product-rejects-a-verified-purchaser/)
 *  Thread Starter [jinvil](https://wordpress.org/support/users/jinvil/)
 * (@jinvil)
 * [3 days, 1 hour ago](https://wordpress.org/support/topic/only-customers-bought-product-rejects-a-verified-purchaser/#post-19039720)
 * Hi, I did some additional debugging after posting this topic, and I think I may
   have found the likely cause.
 * I first narrowed it down through the control test described above:
    - same logged-in customer account
    - same product
    - same completed WooCommerce order
    - `Registered users` → review submits successfully
    - `Only Customers (bought product)` → form opens, but submission returns “You
      do not have permission to leave a review.”
 * Since the form itself could open successfully, I then traced the permission checks
   used when the form is loaded versus when the review is actually submitted.
 * In `PVREV_Hooks::handle_get_review_form()`, the product ID is passed explicitly:
 *     ```wp-block-code
       self::check_permission( 'review', $product_id )
       ```
   
 * However, in `PVREV_Review::submit()`, $product_id has already been obtained from`
   $_POST`, but the permission check is called without it:
 *     ```wp-block-code
       PVREV_Hooks::check_permission( 'review' )
       ```
   
 * I can see this happens twice in the submit flow.
 * In `PVREV_Hooks::check_permission()`, when the permission mode is `buyers` and
   no product ID is supplied, it falls back to the global $product or `get_the_ID()`.
 * My understanding is that during the `admin-ajax.php` submission request there
   may be no normal WooCommerce product-page context, so the fallback product ID
   can resolve to `0`. In that case the method returns `false` before the purchase
   check can succeed.
 * That would also explain why the review form itself can open successfully — because`
   handle_get_review_form()` does pass the product ID — while the final submission
   is rejected.
 * Would the submit-side permission checks perhaps need to pass the already available
   product ID as well?
 *     ```wp-block-code
       PVREV_Hooks::check_permission( 'review', $product_id )
       ```
   
 * I have not modified the plugin files; this is only based on reproducing the issue
   and then tracing the current source, but it seems to match the behaviour very
   closely.
 * Hope this helps narrow it down.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Photo & Video Reviews for WooCommerce — PVR Media Reviews] Front-end customization of PVR Media Reviews](https://wordpress.org/support/topic/front-end-customization-of-pvr-media-reviews/)
 *  Thread Starter [jinvil](https://wordpress.org/support/users/jinvil/)
 * (@jinvil)
 * [4 days, 2 hours ago](https://wordpress.org/support/topic/front-end-customization-of-pvr-media-reviews/#post-19038629)
 * 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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Photo & Video Reviews for WooCommerce — PVR Media Reviews] PVR returns HTTP 500 “Failed to save review” although WooCommerce review is crea](https://wordpress.org/support/topic/pvr-returns-http-500-failed-to-save-review-although-woocommerce-review-is-crea/)
 *  Thread Starter [jinvil](https://wordpress.org/support/users/jinvil/)
 * (@jinvil)
 * [4 days, 18 hours ago](https://wordpress.org/support/topic/pvr-returns-http-500-failed-to-save-review-although-woocommerce-review-is-crea/#post-19038047)
 * Hello,
 * Thank you for investigating this and for explaining the root cause so clearly.
 * We have now updated PVR Media Reviews to version 1.1.6 and completed a fresh 
   control test using PVR’s native review form directly on the WooCommerce product
   page.
 * The issue is resolved.
 * After the update, the complete workflow now works correctly:
    - the upload progress is displayed normally;
    - the review submission completes successfully;
    - the normal thank-you / moderation state appears;
    - the review is created under WooCommerce → Products → Reviews;
    - the review also appears correctly under PV Reviews → Reviews;
    - the uploaded photo is associated with the review;
    - the photo is visible in the PVR review editor;
    - after approval, the photo is displayed correctly with the review on the product
      page;
    - the Verified Purchase status is also shown correctly.
 * This confirms that the missing PVR database tables were the cause of the HTTP
   500 / “Failed to save review” behaviour we originally reported.
 * The runtime database-schema repair introduced in 1.1.5 has therefore resolved
   the issue on our site.
 * The reviews created during the affected period also became visible again in the
   PVR review administration after the database structure was restored, which matches
   your explanation. We understand that media from those historical failed submissions
   cannot be recovered automatically because the media-processing step never completed.
 * Thank you again for the fast diagnosis and fix.
 * We are now continuing our standalone “Share Your Experience” implementation using
   PVR’s new official review-form shortcode. Any questions specific to that implementation
   will remain in our original customization topic so that this bug report can stay
   focused.
 * I’m marking this topic as resolved.
 * Thank you.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Photo & Video Reviews for WooCommerce — PVR Media Reviews] Front-end customization of PVR Media Reviews](https://wordpress.org/support/topic/front-end-customization-of-pvr-media-reviews/)
 *  Thread Starter [jinvil](https://wordpress.org/support/users/jinvil/)
 * (@jinvil)
 * [4 days, 18 hours ago](https://wordpress.org/support/topic/front-end-customization-of-pvr-media-reviews/#post-19038043)
 * 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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Photo & Video Reviews for WooCommerce — PVR Media Reviews] Front-end customization of PVR Media Reviews](https://wordpress.org/support/topic/front-end-customization-of-pvr-media-reviews/)
 *  Thread Starter [jinvil](https://wordpress.org/support/users/jinvil/)
 * (@jinvil)
 * [5 days, 17 hours ago](https://wordpress.org/support/topic/front-end-customization-of-pvr-media-reviews/#post-19037113)
 * Thank you very much for the detailed explanation.
 * This is very helpful and answers the main architectural question we had.
 * We had originally been building a fully custom review workflow around Elementor,
   WooCommerce native reviews and our own server-side integration. Based on your
   explanation, we are going to pause further development of that fully custom review
   form for now and instead build a small prototype with **PVR as the core review
   engine**.
 * Our plan is to keep our own brand-specific logic around it — such as account 
   access, product selection and purchase eligibility — while allowing PVR to handle
   the actual review form, rating, media upload, validation, moderation and WooCommerce
   review submission.
 * This should allow us to evaluate PVR in a much more realistic way than simply
   testing it inside the default WooCommerce product review tab.
 * One of the things we appreciate about PVR so far is that it appears to be focused
   specifically on the customer-review problem rather than trying to become a much
   larger marketing suite. That is important for our website architecture, because
   we try to keep each plugin focused on a clear responsibility and avoid introducing
   large overlapping feature sets.
 * Tomorrow we will start building and testing a minimal **PVR-based Review Form/
   Review System** on our standalone Share Your Experience page.
 * If the integration remains lightweight and the testing continues to go as well
   as it has so far, PVR could become the long-term review plugin for our brand 
   website.
 * If we do adopt it successfully, we would also be very happy to leave an honest
   positive review on WordPress.org and share our experience, especially since PVR
   is still a relatively new plugin and real implementation feedback may help other
   store owners evaluate it with more confidence.
 * Thank you again for being so responsive and for explaining the architecture so
   clearly.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Photo & Video Reviews for WooCommerce — PVR Media Reviews] Front-end customization of PVR Media Reviews](https://wordpress.org/support/topic/front-end-customization-of-pvr-media-reviews/)
 *  Thread Starter [jinvil](https://wordpress.org/support/users/jinvil/)
 * (@jinvil)
 * [5 days, 18 hours ago](https://wordpress.org/support/topic/front-end-customization-of-pvr-media-reviews/#post-19037035)
 * 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 reviewWe 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.

Viewing 8 replies - 1 through 8 (of 8 total)