• Resolved Simon Kane

    (@simonkane)


    Plugin auto-updated this morning and crashed my site.
    Reverted to v3.2.15 and am back online.

    Ah – error log is showing the issue — I have suppressed the worthless-to-client foreign gateways so that the client doesn’t have to wade through a pile of junk to do their job, but the new version is failing on some missing settings for those gateways and crashing the entire site.

    More details to come.

Viewing 6 replies - 1 through 6 (of 6 total)
  • Thread Starter Simon Kane

    (@simonkane)

    OK – the issue has to do with “registered blocks” not matching the underlying payment methods. The fault is triggered at:
    woo-stripe-payment/packages/blocks/src/Payments/AbstractStripePayment.php line 22 which is looking for a payment_method which has been suppressed by use of the long-existing ‘wc_stripe_payment_gateways’ filter.

    My filter overrides the $stripe_gateways array to only have the gateways my client wants.

    However, as of v3.3.0 (blocks support), we now have a mismatch between the registered blocks and the loaded gateways.

    Do I need to add a filter to “unregister” the unwanted stripe gateway ‘blocks’ ???
    I have not used blocks, and have no reason to do so (at least for now LOL), but happy to implement forward-looking code to keep my clients happy.

    • This reply was modified 2 years, 11 months ago by Simon Kane.
    Thread Starter Simon Kane

    (@simonkane)

    OK – more research.
    woo-stripe-payment/packages/blocks/src/Payments/PaymentsApi.php
    has hard-coded lists of blocks to register (lines 48-135).
    Triggers are:
    public function __construct ….. $this->add_payment_methods();
    and:
    add_action( ‘woocommerce_blocks_payment_method_type_registration’, array( $this, ‘register_payment_methods’ ) );

    I do not see any filters to control which of the payment methods actually get loaded, but as the lists are hard-coded, they do not respect the existing ‘wc_stripe_payment_gateways’ filter.

    If I had my way, the filter would totally prevent the actual gateway class modules (both kinds) from even being loaded (for server performance reasons), but at least for now, we can live with a way to remove the unwanted entries before they crash the site — or better yet, a filter (2 places) that supplies a list of the classes that are going to be registered, and remove unwanted entries.

    Hi @simonkane,

    You are using Stripe for WooCommerce which is a plugin I develop. You can start a support thread there and I can discuss the 3.3.0 update with you along with the points you have made.

    https://wordpress.org/plugins/woo-stripe-payment/

    Kind Regards,

    Thread Starter Simon Kane

    (@simonkane)

    Oh dang – Soooo many similar plugin names!
    Thank you much for chiming in here!

    I’ll grab the pertinent stuff here and copy it over there.

    Plugin Support AW a11n

    (@slash1andy)

    Automattic Happiness Engineer

    @simonkane as was mentioned, it looks like you’re not using the official WooCommerce Stripe plugin that we make, so you’d be best suited getting support with the folks that make the plugin you are using.

    If you are using the plugin we make, we are more than happy to help out.

    Have a great one!

    Thread Starter Simon Kane

    (@simonkane)

    Yes sir – you are correct.
    I have a copy of a few, but went the other way.

    • This reply was modified 2 years, 11 months ago by Simon Kane.
Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Site Hard Down after v3.3.0 update’ is closed to new replies.