Forum Replies Created

Viewing 11 replies - 1 through 11 (of 11 total)
  • Thread Starter jswoolf01

    (@jswoolf01)

    Excellent advice, threadi. I read through the comments in firewall.php and found where it came from: the plugin “Really Simple Security”. That plugin’s settings page included the way to update it.

    Thanks.

    Thread Starter jswoolf01

    (@jswoolf01)

    Thanks for the pointers. They let us find and fix the issue: a bug in an update to our payments gateway. Payment saving appears to be working correctly again.

    Thread Starter jswoolf01

    (@jswoolf01)

    I’ve communicated with the plugin author and we believe we’ve fixed it.

    Thanks for the help.

    Thanks, LovingBro. This information is very useful. After some further experimenting, the custom pricing appears to be working properly, even after a billing address is entered. Getting my function attached to the right action hook seems to have done the trick.

    Can you at least tell me where, in this insane maze of code, is the action that triggers cart price recalculation after the billing address is entered?

    By a stroke of luck, I’ve managed to make some progress on this.

    I have been triggering my changes on action ‘woocommerce_before_calculate_totals’, and that gives me the original price on the line item and mixed results in the order summary — until I enter a zip code in Billing Address. When I enter a zip code, one of the things that happens is that the cart calculate_totals() method gets fired (to recalculate things like shipping fees and taxes), which recalculates everything and overwrites my changes. If I change my function to fire on ‘woocommerce_after_calculate_totals’, I get the right price in the line item details, but the wrong prices in the order summary. If I use action ‘woocommerce_calculate_totals’, I get nothing – my changes never show up.

    Still looking for how to fix this, though. Any suggestions?

    My apologies for leaving this for so long, but I have been busy with other things and had almost forgotten I posted this here.

    I’m back to working on this issue, and it’s as inexplicable as ever. I’ve looked around repeatedly for anything that might be causing the inconsistencies and have come up empty. I don’t see how this can be a Javascript issue, because the price adjusting is definitely being done in PHP, using a WooCommerce action hook. I’ve tried several different action hooks for the updates without any improvement. At the moment I’m updating the cart prices using an add_action function which fires on the action “woocommerce_before_calculate_totals”. What really confuses me is that this should be a straightforward bit of code: see if the customer is a member (which involves a third-party API call); see if any item in the cart is one of the target products (that is, a locker subscription); if both conditions apply, update the price to reflect member discounting. Why would this run differently on different computers? And why would it result in a different price showing in the “Order Total” box of the Checkout screen than shows next to the shopping-cart icon at screen upper right?

    Thread Starter jswoolf01

    (@jswoolf01)

    Thanks for the reply, Mahfuzur. Are there any specific pitfalls I need to watch out for, if I try to integrate a second subscriptions-tracking plug-in with Woo Subscriptions?

    Thanks again,

    — Jon W.

    Thread Starter jswoolf01

    (@jswoolf01)

    I’m reviving this topic, rather than start a new one, in hopes that someone else might know a way to do this. What I need to do is migrate the payment information for our memberships, which are sold through WooCommerce as subscriptions, from our old payment gateway to a new one that supports ACH. We’re very reluctant to go with ‘ask users to update their payment information’ because we’re pretty sure it would result in a lot of cancellations. We’ve been able to copy the customer information, but not (yet) the tokens that allow WooCommerce to use that data. Is there any way to transfer the WooCommerce pay-method tokens from the old gateway to the new one?

    Thread Starter jswoolf01

    (@jswoolf01)

    Thanks for the response. I’ve done some more studying of this, and I believe now that it’s not a plug-in error, but rather a configuration problem. I didn’t notice this before, but Console is also showing a series of errors of the form “Refused to execute script from ‘[url]’ because its MIME type (‘text/html’) is not executable, and strict MIME type checking is enabled.” All of the affected files are Javascript. I believe if these scripts were running, the other errors, including the ‘Cookie not defined’ error, would disappear.

    Thread Starter jswoolf01

    (@jswoolf01)

    Thanks, Ollie.
    One more question: about how long can I expect the reindexing to take?

    — Jon W.

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