mrapino

Jory, I spent a lot of time working on it and found the issue. It wasn’t clear in the documentation, but I connected the dots finally… since [each] and the conditional shortcodes are only available within templates, I figured out that I needed to wrap the code block with [pods] [/pods] to create a custom “one-use” template.

I’m sure I could have also written some PHP code to loop through the post meta, but I really wanted to use the built-in Pods functionality to display multiple outputs from a repeating custom field.

Anyway, thanks for your reply. If you don’t have plans to refine your documentation, I would request that you put this on the roadmap. I’ve gone through a lot of your docs, and there are times when more explanation and usage examples would definitely help.

I’m excited for v3!

Take care.

Serge,

I need to open this topic again. I took all of your advice and kept watching, but my server’s CPU was maxed out on 100% constantly. I just disabled the Cleantalk plugin, and my CPU usage immediately got better. I need Cleantalk to prevent WooCommerce attacks, but I can’t have this one plugin constantly eating my whole server’s CPU usage 24/7.

Please advise.

There are a few of these settings that specifically say that you need them if you use caching. I don’t mean to be a pain, but these items that say there will be conflicts and/or false negatives when using caching … have you found that this is a minimal impact?

Thanks so much for your reply. I am mainly using Cleantalk to protect the WooCommerce store from attacks and a flood of fake carding activity. I use a WAF and I also have a caching plugin.

To clarify, will I still have protection where I need it if I implement all of your recommendations?

I created a filter, so we don’t have to alter the core plugin …

<?php
function modify_recaptcha_hook( $hooks ) {
    // Find the index of the original hook.
    $index = array_search( 'woocommerce_checkout_after_customer_details', $hooks );
    
    // Replace the original hook with the new hook.
    if ( $index !== false ) {
      $hooks[$index] = 'woocommerce_review_order_before_payment';
    }
  
    // Return the modified hooks list.
    return $hooks;
  }
  
  add_filter( 'advanced_google_recaptcha_filter_injection_hooks', 'modify_recaptcha_hook' );  
?>

Please let me know if there is a better way.

Thanks!

I think I figured out what is happening. It seems that the Stripe Checkout form submits first and if it doesn’t get fully submitted, the rest of the WooCommerce forms don’t get verified, including the reCaptcha.

Thank you for your reply. I have Gravity Forms 2.5.16 and was using with Extended version of WP Armour. I am also using Gravity Forms Mailchimp Add-On, but no feed is created for this particular form.

Gregory, the conflict is literally coming from your plugin. How is this not your responsibility? You say you don’t support this feature … why is it a feature in your plugin then?

I described exactly how YOUR plugin is breaking my login page. Are you suggesting I don’t use this feature in YOUR plugin?

Any news on this? I was extremely thorough and tracked down exactly what was happening for you. Are you able to replicated this issue? If so, will you be able to fix it?

Thanks!

I found the root cause of the issue. I thought it was the Cerber Custom Login URL section, but the issue was happening when I installed and used WPS Hide Login while Cerber was still activated. This led me to want to disable every single setting one-by-one in Cerber until I finally found it!

The Cookie Error issue occurs when ANY or ALL of the Anti-Spam settings in the “Cerber Anti-Spam Engine” section are enabled. It does not matter in what combination … one or all can be enabled, and this issue occurs.

• Registration form: Protect registration form with bot detection engine
• Comment form: Protect comment form with bot detection engine
• Other forms: Protect all forms on the website with bot detection engine

I happen to use all of these on every client website, which is why all of my sites are having this cookie error issue upon trying to login.

Now that I have tracked this issue down, perhaps you might have an answer as to why it is causing WordPress to think the browser’s cookies are disabled.

Please let me know if you now have enough information to create a fix.

Thanks!

Okay, I’m back with some news.

I just created a brand new install of WordPress. There were zero plugins installed/active other than Cerber. The default Twenty Twenty-One theme was active.

The Custom Login URL was used, and I received the cookie error.

Additionally, before installing Cerber, I went to /wp-admin in a completely fresh install, and the url did in fact redirect to:

/wp-login.php?redirect_to=https%3A%2F%2Fdomain.com%2Fwp-admin%2F&reauth=1

Out of the box, WordPress is adding the query string above.

Again, when I take that query string and add it to the end of my custom url, I do not get the error.

You had mentioned:

WordPress doesn’t use/add any query string during the standard login sequence.

Have you done this type of test? I made no modifications to the fresh install, and WordPress is definitely adding this query string within the login sequence.

Is no one else having this issue? I feel like if this is happening right out of the box on a new install with Cerber being the only plugin activated that everyone should be having this same error pop up.

Super strange … please advise.

First of all, try to open your Custom login URL with no query string (do not click any login link rendered somewhere on your website) and try to log in from that page. Does it work?

I always just go directly to the custom login page by typing it into the address bar of my browser. This is when I get the error.

I created a brand new test site, completely clean. I am going to only install Cerber to see if I still get the error. If so, I’ll do some debugging to see exactly why all of my client websites are getting this error.

More to come.

I think I tracked down the issue.

The following query string is automatically added to the default ‘wp-admin’ login url.

?redirect_to=https%3A%2F%2Fwww.domain.com%2Fwp-admin%2F&reauth=1

The error occurs in all configurations of the Cerber Custom Login URL in both Legacy and Standard modes.

When I use the custom login url and add the additional query string to the end of it, the error does not occur.

If a patch/update can be pushed with this addition to the custom login url functionality, we will not get this cookie error anymore.

Please let me know if you have any questions.

Thanks!

This is happening to me, as well. I have the official paid plugin from WooCommerce to implement Google reCaptcha. I am diabling the “Place Order” button until reCaptcha is clicked. I have Cerber Security real-time scanning enabled. I honestly don’t know how these fake transactions are getting through.

I’m following this post.

Any news on this?