Dan Olson

I can also confirm this. We spent several days trying to figure out why one of our sites was not showing any updates and the problem was solved when we deleted the DCL plugin. Re-adding DCL v11.0.1 seemed to fix the problem and updates are now showing. We were VERY behind on updates as a result.

I can confirm that this is happening on our site as well and I can recreate it using the steps mentioned above. We’ve had to disable the plugin. When we follow the steps mentioned above the error we get is “Invalid key.”

If it helps, we are using WooCommerce for login/lost password and WP-rocket for caching and Mandrill for email. I’ve tried disabling Mandrill and WP-rocket and this does not solve the problem.

As far as I can tell this problem is limited to the Lost Password page and has not affected our checkout pages.

Oh, duh. I just noticed that when using the multi-select in ACF you can change the display order simply by dragging and dropping them into the order you want. I can’t confirm whether this would work in a front-end form, but I can confirm that I just moved the order around in my CPT in the wp-admin and when I refresh the display page the order is changed. Easy peasy.

Kenny,

Just curious if you found a solution to this. We have a similar need. We are using the post object field to pull in a list of courses (set up as a separate post type) that make up a “track.” But we’d like the user (in this case the teacher) to be able to sort the list within the multi-select so it reflects the order in which the student shoudl take the courses.

The only other way I can think to do this would be to create a repeater field and to add an “order number” as another field in the repeater. Not as clean, but may work.

Thanks,
Dan

We did test this using a version of the test mentioned above and everything worked fine. So we currently have the plugin fix installed and it is helping.

I also heard back from WooCommerce Subscriptions and they said this fix will no longer be required as of Subscriptions v2.1.

Hi Frank… sorry for the delay — I just realized that all my WordPress emails are going to spam :/

I now see my question was not clear as written. What I should have asked is: “Is there a better way for ME to handle the logged in vs. logged out css situation?”

But I’ll answer my own question. If Autoptimize displays the correct CSS based on the logic I set up in my enqueues, then no, there really isn’t a better way to handle it. It’s working just as expected.

As for the error I am seeing with Safari browsers, I did find some old bug report about it here.

On a related note — we load a different set of CSS and JS for logged in vs. logged out users. Logged out users basically just see a marketing page while logged in users see more of a ‘dashboard.’ We handle this through a simple logged-in check in our functions.php to enqueue the right styles and scripts (3 total for each).

In our tests everything seems to work fine with Autoptimize and W3 Total Cache (minifying turned off), with the exception of Safari browsers which tend to hang on to the logged out CSS after logging in for some reason.

I am wondering what’s going on in the background. My read on the above is that Autoptimize will create two cached css and js files and load the right one based on the logic mentioned above. Is that right? Is there a better way to handle it?

Now that I think about it I think the Safari issue might have more to do with W3 Total Cache than Autoptimize, but thought I would bring it up in case there are any insights. Perhaps the best approach is to exclude all of our theme enqueues and simply use Autoptimize to roll up all the CSS and JS from plugins.

I have not heard anything from WooCommerce Subscriptions. We are still having the issue as well. We tried the code as mentioned by @heliocles and it certainly worked to stop the problem (which also proves there is a problem). However, our next two recurring billings failed. I am unsure whether the code had anything to do with it. We are working on a way to test it now. But I wish they would just fix it.

If you hear anything @ inovacrea I would love to know.

We are still running W3 Total Cache, @mystyleplatform, and all is well.

Steve,

Just wondering if you heard anything from WooThemes on this issue. We are experiencing the same thing. I ran a P3 profiler and Subscriptions is definitely hogging most of the resources.

I did try installing their plugin fix that @heliocles pointed out and that did reduce the issue for us. (WooCommerce itself is now creating most of the slowdown is there another issue there I’m not aware of?)

@mystyleplatform We are using W3 Total Cache and so far have not experienced any problems with subscription billing. But I will let you know if that changes.

Dan

Shamim,

I think there’s a way to do this to give admins more control. There’s a hook called ‘woocommerce_register_form’ that appears on the registration page, but not on the checkout page. I *think* this would allow for a third option to your list:

1) Checkout page with registration
2) Checkout page without registration
3) Registration page (only)

This way I could choose to show the captcha on the registration-only page but not on my checkout page.

If I disable all the choices in your plugin and add @acn’s code above, using the hook ‘woocommerce_register_form’ the captcha only appears on my register form but not on my checkout page.

Unfortunately it doesn’t validate the captcha, so I must be missing something in the code.

Hi Shamim, sorry for the delay, I’ve been out for a couple of days. Thanks for working on the fix. Our situation may be somewhat unique, not sure.

We use WooCommerce for site registration and Lost Passwords, and the noCaptcha works just fine on those pages.

We use WooCommerce to sell a subscription, so we bypass the cart page and go right to the checkout page. We also force users to create an account on the checkout page. Because the only way to complete the checkout is by entering a valid credit card, we would prefer to NOT use the Captcha on the checkout page.

The problem before your update was that the captcha did not appear on the checkout page, but it still threw an error that the captcha was not validated.

I just tested your latest release and now the problem is different. The captcha now appears on the checkout page regardless whether I have the “WooCommerce Checkout” option checked or not. I *think* the reason is because (as you stated) we force registration on that page as well.

The good news is I can complete an order. But our preference would be to be able to actually eliminate the captcha from the checkout page altogether, if possible. (Also note it appears in a strange place, below the order button, not above it.)

Does that help? Let me know if you have more questions.

Thanks — I had the same problem and this snippet worked for me. In fact, I tried several other recaptcha plugins and they had the same problem with not displaying the recaptcha. So this might have something to do with the way WooCommerce is now displaying the checkout page, not sure.

BTW, I just discovered that with this plugin enabled and the recaptcha turned on for registration I can no longer take an order with WooCommerce (v2.5.5 and v2.6). For me, anyway, this plugin basically breaks everything to do with WooCommerce so I am uninstalling it.

I have the same problem. Took me forever to figure out this plugin was the source, unfortunately.

Unchecking the check-box in the settings enables the password reset to work, but of course disables the captcha for that page.

Hi Danny… I just implemented this on our WooCommerce checkout page and it works great. Thanks for the tip. I actually set the group fields to “hidden” so it just automatically adds the groups on purchase. We just wanted to make sure that those who purchase get added to the appropriate interest group on purchase to customize the email they receive.

This does make me wonder, however, why are there options on the WooCommerce integrations panel pertaining to Groups (“Update existing subscribers?” and “Replace interest groups?”) if this doesn’t actually happen without this custom code? Do those options actually do anything? Am I missing something?