Konstatninos

I am leaving this note here for possible future discoverers of the post that the issue appears to have been resolved.

As it turned out, although Facebook’s Codeless Events were configured to not fire, they had been created prior to installing and using PYS, and somehow they were finding their way into the source code. I explicitly deleted all duplicate events from Fb’s configuration, allowed some time, and re-tested. This time no duplicate events were present.

The code I had pasted above was also disabled during all of the testing. It may have played its role while the issue remained, but it seems to be of no use as of this time.

Hi,

Thank you for the insight. It was not what I was hoping to read, but that made me try things I would have otherwise skipped. The “what not” part that I posted yesterday included the cleaning up of the Events created with Facebook’s Events without code (I just did not mention it explicitly).

Anyway, I have now managed to make sure no more than one Purchase events fire on my order-received page.

What worked in my case – and I really hope this is the correct approach, because I don’t know what else to try at this point – was removing the noscript tags with the following two actions. After that and only then would I place an order and not get a second Purchase event. All other attempts have failed.

add_action( 'wp_head', function() {
    remove_action( 'wp_head', 'pys_fb_noscript', 10 );
}, 999 );

add_action( 'wp_footer', function() {
    remove_action( 'wp_footer', 'pys_fb_noscript', 10 );
}, 999 );

Please review and comment.

Thank you,
Konstantinos.

Hi Oleg,

Thanks for assisting me with this.

The reviews are present as data in that product. Every product has its own reviews. When I use the built-in “Reviews (%d)” from your plugin in that particular product, I get no reviews displayed; only the title “Reviews (15)” and the correct count (15) of reviews for that product.

When I replace the default “Reviews (%d)” tab with a newly created one, and I use a shortcode from a plugin that handles reviews in that new tab, that plugin is able to read the reviews data and display them.

i.e. I did not disable your plugin. I just ditched the default “Reviews (%d)” that did not display the reviews, and used a shortcode in conjunction with your plugin, and in that case the reviews were visible.

Regards,
Konstantinos.

• This reply was modified 8 months, 3 weeks ago by Konstatninos.

Update: After an extensive and thorough troubleshooting session I discovered that the location order was set to 0 for all locations. When I changed the one location’s order to 99 and refreshed the product in question a dozen times, the module loaded zero times. When I later changed the order for that location to -10 and refreshed another dozen times, the module loaded every time.

I’m leaving this note here if it is of any value to any third party, or for the plugin developers.
—

Environment:

• WordPress version: 6.8.2
• WooCommerce version: 10.1.2
• BeRocket Product Tabs plugin version: 1.2.1.1
• Theme: Avada 7.13.2 (issue also reproduced on Twenty Twenty-Five)

Issue:
When creating tabs that are restricted to specific product IDs, the extra tabs appear inconsistently:

• Sometimes only the default description and reviews tabs render.
• Sometimes the custom BeRocket tabs are present.
• This happens even with only WooCommerce + BeRocket Tabs active and a default WordPress theme.
• No related PHP errors are logged.

Investigation:

• Added logging to woocommerce_product_tabs confirmed that in “failed” cases, BeRocket’s custom tabs are never added to the $tabs array.
• Other products with different tab rules load correctly every time.
• The problem only occurs with product-specific rules.

Workaround discovered:

• In the plugin’s Location rules → Order column:
  • Default value (0) → tabs load randomly (sometimes missing).
  • Setting rule priority to 99 → tabs never load.
  • Setting rule priority to -10 → tabs load reliably every time.

This strongly suggests that the plugin is evaluating product-specific conditions at the wrong time in the filter chain, depending on when $product or $post is available.

Expected behavior:

• Product-specific tab rules should evaluate consistently without needing to adjust rule order manually.

Workaround used:
Set the rule order to -10, which ensures the tabs always display.

Update:

• I have disabled anti-spam for CF7 integration
• I have run the validation for all forms, and I have received the “Configuration validation completed. No invalid contact form was found.” message.
• I have placed an order with WooCommerce, and that goes through, and I get the successful order placement email properly.
• I checked from incognito.
• I checked with WP Rocket disabled (by using ?nowprocket on the URL)
• I checked from a different browser.
• I checked with TOR from a different IP (to rule out my IP was not blacklisted).
• I checked Flamingo (that I had already installed) and it does not record submissions in the Inbound Messages.
• I created an all new form without editing the default fields, which I then placed in a test page, and I was not able to submit that either.

Still I am unable to submit a CF7 form.

• This reply was modified 11 months ago by Konstatninos.
• This reply was modified 11 months ago by Konstatninos.
• This reply was modified 11 months ago by Konstatninos.
• This reply was modified 11 months ago by Konstatninos.

Hi plugin author,

I noticed you mentioned here that the issue has been resolved. I checked and installed the update to my site (v 5.8012) but it has not resolved it in my case. Could you please help further?

Thank you in advance.

• This reply was modified 11 months, 2 weeks ago by Konstatninos.

I have managed to discover the issue at hand. You would never guess what the problem is.

In my registration form, I have two drop-down elements. Under each I have a different registration form. When the user submits one of the forms, it is very probable there is an error. Then the page will reload, and the drop-downs now are collapsed. The errors are hidden. Therefore the user has the impression of a successful submission, but that is far from the case.

When I realized that and expanded the appropriate drop-down, I was able to review the errors, and fix them. Then the user gets submitted correctly, and is set to be reviewed by the admin. The emails also get sent like expected.

Therefore I reckon it is not a problem of UM’s, but rather one of poor design that I have to focus on next.

Thank you for assisting me with this.

• This reply was modified 1 year, 4 months ago by Konstatninos.