More information on the source of the issue: The delete and reinstall really just resets the options to the defaults. I did more testing and this is the exact option that causes the issue:
BeRocket > Min/Max > Addons > Input Limitation
If you disable this checkbox all works as expected with v1.3.8.3
If you enable it, products with a blank MIN field are set to qty of 1 when you go to the checkout.
Starting Setup: Min Max 1.3.8.3 WC 10.4.0 WC Stripe Gateway 10.2.0 HAS ISSUE
Update to Min Max 1.3.8.3 WC 10.5.2 WC Stripe Gateway 10.2.0 STILL HAS ISSUE
Roll back to Min Max 1.3.8.2 WC 10.5.2 WC Stripe Gateway 10.2.0 STILL HAS ISSUE
Roll back to Min Max 1.3.8.1 WC 10.5.2 WC Stripe Gateway 10.2.0 FIXED / WORKS!
Giving an explicit minimum on a product means the issue won’t show. So setting the min to 1 on a product or variation means it works fine… We only saw the issue on products with a blank MIN field. In those cases it goes back to 1 between Cart and Checkout screens no matter what the qty is set to.
We did find a way to get the most recent version working:
Update all plugins to most recent: Min Max 1.3.8.3 / WC 10.5.2 / WC Stripe Gateway 10.2.0
Deactivate and totally delete the Min Max plugin.
Reinstall the plugin.
Overall – I’m not sure what option/config setting in the database is causing this, but it seem like something that gets set when you install a fresh copy of v1.3.8.3 needs to be changed or updated when upgrading from older versions as well.
Here’s a GIF of the issue happening … just to prove we’re not crazy:
Here’s the stripe / apple pay settings we were using:
While we have found 2 solutions that work: deleting the plugin and reinstalling; or downgrading to 1.3.8.1 – it still seems like this is not an isolated edge case since several people have reported it. Would be great if it worked properly on a standard update and not just on reinstall.
Ok, thank you. I do think it’s a reasonable expectation that a user with manage_woocommerce permissions be able to access these settings. That’s the structure that’s used for WooCommerce core’s marketing/coupons settings.
I’m guessing that the Pro version of the plugin uses the same permissions structure (only allowing Administrator users). Is that correct?
Without getting into a whole conversation on gender in general – just the fixed options of Man/Woman/Not Specified and also asking for gender when it’s not required, even on the back end are not ideal for many of our clients. I get that it can be kind of a core demographic datapoint you always want to track if you’re doing a shoe or fashion website, but for our users it’s not needed at all, and the fixed set of options can be a turn off.
I just want to leave the value as “not specified” for every single record and hide the options from the admin UI. We can’t currently do that easily because there are no classes to target things in the HTML.
I supposed I could do things like .tnp-users-edit table.form-table tr:nth-child(4) { display: none; } but that feels a little risky to break if any new lines or options get added in the future.
I’m also just curious why gender is hard coded into everything since custom fields of type “list” also exist… maybe it’s just for backwards compatibility?
Thanks for getting back to me and taking the time to look into this.
I recommend creating a separate IAM user with limited permissions specifically for FluentSMTP
Yes, that’s exactly what we already did. See the original post above. Properly limiting the permissions with a single IAM user per site is what is causing the issue.
FluentSMTP requires permission to list all SES Identities on the account in order to establish a connection
We already have “Action”: “ses:*” set which includes listing identities. But we also have restricted the “Resource”: to the specific site identities we want to allow for this client site, so that will block the “list all” action. If I make one IAM user for each client but give them all permission to access all SES Identities, then that still gives every site permission to see our complete client site list and to send emails from any of their domains at any time. There’s no point in making one IAM user per site if they can all access every authorized domain. For us that means if one site is compromised, a spammer could send emails out to their choice of 50+ authorized client domain names.
I realize that probably many of your users are more casual and need easy setup and also they will just be starting a new AWS account for only one company. The existing setup will work fine for those users. But for agency users, it would be great to have some kind of “advanced” mode or override to be able to set things up in this way where we truly can restrict the IAM user to sending from only specific authorized domains.
Thanks for the quick reply and for the awesome plugin. It’s very odd that the official Cloudflare WP plugin is so limited and actually causes more problems than it solves. Thanks for filling a need in the community with this great plugin!
I’ve done some additional testing and found a bit more about what’s going on:
If you check the “Remove Cache Buster Query Parameter” this successfully marks the option as true in the options table. This basic test looks good and works:
$test1 = new SW_CLOUDFLARE_PAGECACHE();
$test2 = new SWCFPC_Cache_Controller( 'demo', $test1 );
echo $test2->remove_cache_buster(); // returns 1;
What it does do is successfully removes the inline JS code that modifies the links on the page. This take care of some but not all of the instances where the cachebuster appears. So the following things are now good:
existing links on the page don’t have cachebusters added
visiting pages like example.com/shop/ directly don’t add a cachebuster
But a few circumstances cause it to reappear:
Anything that triggers a redirect causes it to be added. This could be as simple as leaving off the trailing slash – so example.com/shop/ is fine but example.com/shop causes a redirect to the version with the trailing slash and adds ?swcfpc=1
Anytime you submit a form instead of following a link, the cachebuster is also added. For example visiting example.com/cart/ directly it’s fine… but if you go to a product page and add a product to the cart – then ?swcfpc=1 is tacked on to the end when you get to the cart page after the form submission.
Following… we just setup a new site with this and have set things up successfully using Cache Rules. It’s a pretty sweet setup actually!!! But we set them up manually, the plugin didn’t do it via the API.
Ok, yes I can confirm that 6.2.8 RC1 works fine without any code changes needed to ACF:FA for me as well. So maybe not worth trying to shoehorn a special fix and just wait for 6.2.8 to come out instead.
