• Resolved lencw

    (@lencw)


    Hi, This is looking good and essentially solves a big issue for us. But confused with the settings screen. I want the code to be visible on the admin order pages, the order receipt and invoice, but not on the front end product catalog, individual product screen, basket/cart or order received screen. For now I have used CSS to hide on the product and basket screen, but not on the order receipt screen.

    Can you please explain exactly what each of the following are intended to do, and how they interact:

    Display product code on user side on the products posts, checkout, cart, and receipts.

    Hide product code on user-side product posts only.

     Hide product codes for customers on the front end of your store.

    Thanks.

Viewing 8 replies - 1 through 8 (of 8 total)
  • Plugin Author Steven Ray

    (@steveneray)

    Greetings, @lencw,

    I just uploaded a revised interface with some text changes… it might make better sense now.

    Check both check boxes to the right of “Show Product Code” and “Hide Product Code”. The first enables display on cart, checkout, and receipts. The second hides it on product pages only.

    Thanks!

    • This reply was modified 3 months ago by Steven Ray.
    Thread Starter lencw

    (@lencw)

    Hi Steven, what I am wanting to do is have the code visible on the order invoice and placking slip, also on the order details screen in admin, but not on the user facing pages: product pages, basket, checkout / order received confirmation page.

    The settings you suggest still have the code visible on the basket and checkout pages. With specific CSS I have removed it from the basket page where the selectors are specific. When the order is placed, the order checkout receipt page displays the code using a CSS selector “wc-item-meta” , is this specific to your plugin, if so I can remove it from there. If not is there a way to remove it?

    I appreciate that the plugin has numerous uses, as a product code the settings make sense, the “bin” usage is a little different.

    Plugin Author Steven Ray

    (@steveneray)

    Hi @lencw,

    I’ve added a new setting specifically for your use case. Update to the latest 1.5.9 version (will be loaded up soon), and you’ll find “Hide from Customer Orders” in the Primary Product Code section.

    Check this option to hide the bin number from:

    • Cart
    • Checkout
    • Order received/confirmation page

    The code will still be:

    • Saved to order data
    • Visible in admin order screens
    • Available for invoices and packing slips

    This should give you exactly what you need – internal bin numbers visible for fulfillment but hidden from customers.

    Thanks for leaving positive feedback!

    Thread Starter lencw

    (@lencw)

    Hi, thanks, really appreciated.

    The bin number is still appearing to the customer on the “Checkout – Thank you. Your order has been received screen.” (order received/confirmation page), this is displayed after the order is committed and when confirmed. Code snippet from the page is:

    – Natural</a> <strong class=”product-quantity”>&times;&nbsp;1</strong><ul class=”wc-item-meta”><li><strong class=”wc-item-meta-label”>Bin:</strong> <p>BIN997</p></li></ul>

    Can you check this please. Thanks again.

    Plugin Author Steven Ray

    (@steveneray)

    Thanks @lencw, for catching this bug and providing the HTML snippet – that helped pinpoint the issue.

    The problem was in how the woocommerce_order_item_get_formatted_meta_data filter was implemented. When WooCommerce displays order item meta on the confirmation page, it passes an already-populated $formatted_meta array through this filter. The original code simply returned that array unchanged when the hide option was enabled, but the product code entries were already present in the array.

    The fix now iterates through $formatted_meta and unsets entries matching either the internal field names (_product_code, _product_code_second) or your custom Field Title label (“Bin”). The meta is stored using the label as the key, which is why matching on the internal field name alone wasn’t catching it.

    This is included in the 1.5.10 update just uploaded.

    Thread Starter lencw

    (@lencw)

    Hi thanks, its now fixed, thanks for the great support.

    However, I thought I would look at the Secondary Product Code, as we might want to use this for other reasons. I setup secondary code in each of the variations, of the same product I am testing the bin numbers, then in the settings “Display second code to customers.” set on. The “Hide from single product pages only” is unchecked.

    The secondary code does not appear on the product page or customer facing pages. It does show on the order, invoice and packing slip. It looks like the Display second code to customers flag isn’t working as it should.

    Plugin Author Steven Ray

    (@steveneray)

    Thanks @lencw,

    This is a separate bug from the order confirmation issue – thanks for the thorough testing.

    For variable products, the plugin stores product codes on each variation, not the parent product. The template was checking !empty($value_second) before creating the HTML container, but it was reading the parent product’s value, which was empty. So the container never existed for the JavaScript to update when you select a variation.

    The fix allows variable products to create the container regardless of whether the parent has a value. The JavaScript then populates it via AJAX when a variation is selected. The fix is available in version 1.5.11.

    We apologize for the incomplete testing on this release – the assistant developer rushed these features out without properly verifying all option combinations. We wish WordPress offered a support sandbox for consensual beta testing with willing users who are eager to help. It would catch issues like this before public release, to avoid several updates in a row.

    We appreciate you taking the time to test thoroughly and report back. Please leave feedback on the plugin!

    @steveneray

    Thread Starter lencw

    (@lencw)

    Thanks for the quick response, now working as expected.

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

You must be logged in to reply to this topic.