Forum Replies Created

Viewing 15 replies - 1 through 15 (of 29 total)
  • Thread Starter Paul

    (@headwall)

    Interesting. If I get some time later this week, I’ll do a deep dive into our caching and your plugin to see where the problem is. It might be that our caching system is very similar to WP Engine’s caching system and they share a bug? If I find anything interesting, I will post it here.

    Thread Starter Paul

    (@headwall)

    Understood.

    Do you get the same error when the hosting uses a Redis object cache?

    Thread Starter Paul

    (@headwall)

    No. We’re not on WP Engine. The client is on my hosting (Headwall Hosting). We’re running a memcached object cache.

    Disabling the object caching in your plugin sidesteps the problem, but that doesn’t feel very robust. The problem is that get_atum_order_model() can return false|WP_Error|Object. If you had a check at the end of get_atum_order_model() like this…

    if( !is_object( $atum_order ) ) {
    $atum_order = new WP_Error(........);
    }

    …that would keep things clean. Although the underlying problem seems to be that the plugin doesn’t work well with memcached? We don’t have problems using memcached on any other sites.

    Anyway, for now we’ve just disabled the object cache option. The servers are fast enough that it works fine.

    I hope this helps

    Paul

    Thread Starter Paul

    (@headwall)

    Thanks for taking the time to dig into this. Appreciated.

    I’ll have a think about whether we’ll continue to patch, or if we just add exceptions to our PHP file scanner.

    Cheers!
    Paul

    I’m seeing exactly the same behaviour on a client site. Elementor, Elementor Pro and ElementsKit are all up-to-date,

    The front-end CSS for the mega menu and header element are not being enqueued.

    Interestingly, if we edit the site in the Customiser, the styles work. So I suspect there’s a test for is_admin() (or similar) that;s behaving slightly differently in WP 6.9.

    Thread Starter Paul

    (@headwall)

    Will do

    Thread Starter Paul

    (@headwall)

    I’ve posted the support request through your website contact form. I don’t have their order details because I just host the site (managed hosting). I’ve put some extra info in the email request for you, that might help.

    Hi

    I agree with Shakoor’s observations about Jetpack. Looking through the WooCommerce code there are now so many references to things like the Jetpack connection manager, I wonder if I need to go to each of my clients and ask them to modify their sites’ privacy policy to make reference to sending customer data to third-party servers in the USA? It feels like there’s “stuff” going on behind the scenes regarding customer data that we’re not aware of. Some clients have customer lists that are sensitive (medical), and we 100% cannot have those data flowing through servers that we’re unaware of (for legal and ethical reasons).

    In addition to potential data privacy issues, I worry about site performance with all this Jetpack bloat being built-in to WooCommerce now. If we could define a constant in wp-config.php that said something like…

    const WC_JETPACK_DISABLED = true;

    …the autoloader could skip over all the Jetpack files and avoid making outgoing API calls (and potentially slowing down site access).

    Paul

    Thread Starter Paul

    (@headwall)

    Great, thanks for confirming.

    Paul

    Paul

    (@headwall)

    Hi

    Can you please re-open this ticket. Version 5.23.0 has just installed on our site and it crashes the cron jobs when running from WP CLI. The issue is as the OP described. We’ve patched src/Tickets/Commerce/Order_Modifiers/API/Coupons.php for now, but can you please address the problem for the next release?

    Paul

    I get exactly the same here. I woke up this morning to find out website was down because of line 58 in file “woocommerce-paypal-payments/modules/woocommerce-logging/src/Logger/WooCommerceLogger.php”

    PHP Fatal error:  Declaration of WooCommerce\WooCommerce\Logging\Logger\WooCommerceLogger::log($level, $message, array $context = []) must be compatible with Psr\Log\LoggerTrait::log($level, Stringable|string $message, array $context = []): void in /web/wp-content/plugins/woocommerce-paypal-payments/modules/woocommerce-logging/src/Logger/WooCommerceLogger.php on line 58

    For now, we’ve rolled back to version 2.9.4 and that’s sidestepped the problem.

    As a note, the website runs about 50 plugins, and woocommerce-paypal-payments is the only plugin where updates crash the site at least twice a year. Can you please look into improving your pre-launch testing.

    • This reply was modified 1 year, 4 months ago by Paul.
    Thread Starter Paul

    (@headwall)

    Hi Michel

    Thanks for your prompt response. We have patched it at our end for now and look forward to the next release.

    Have a great day

    Paul

    Thread Starter Paul

    (@headwall)

    Sorry for the delay – it’s been a busy couple of days.

    By “redacted”, I just mean I removed some IP addresses and filesystem paths from the log.

    When I investigate further with this patch in “ect-class-vc.php” (around line 26)…

    if( is_array( $term ) && !array_key_exists( 'name', $term ) ) {
    error_log( 'FAIL: ' . json_encode( $term ) ); // << Added diagnostic info
    } else {
    $ect_categories[$term->name] = $term->slug;
    }

    …I get this in the error logs…

    PHP message: FAIL: {"invalid_taxonomy":["Invalid taxonomy."]}; PHP message: FAIL: []

    So that’s two iterations of the foreach() loop where $term->name and $term->slug do not exist, which is causing an error in PHP8.3. One iteration returns some invalid taxonomy error, and the other iteration seems to have $term as an empty array? Weird.

    Can you please just add some protection in the loop to check that $term contains valid data before you access the name and slug?

    Thanks

    Paul

    Thread Starter Paul

    (@headwall)

    Hi

    This is a redacted version of what we were seeing in the logs this morning. The logs were full of it :

    [Mon Dec 02 06:14:31.223317 2024] [proxy_fcgi:error] [pid XXX:tid XXX] [remote XX.XX.XX.XX]
    AH01071: Got error '
    PHP message: PHP Warning: Attempt to read property "name" on array in /XXX/XXX/wp-content/plugins/template-events-calendar/admin/visual-composer/ect-class-vc.php on line 26;
    PHP message: PHP Warning: Attempt to read property "slug" on array in /XXX/XXX/wp-content/plugins/template-events-calendar/admin/visual-composer/ect-class-vc.php on line 26;
    PHP message: PHP Warning: Attempt to read property "name" on array in /XXX/XXX/wp-content/plugins/template-events-calendar/admin/visual-composer/ect-class-vc.php on line 26;
    PHP message: PHP Warning: Attempt to read property "slug" on array in /XXX/XXX/wp-content/plugins/template-events-calendar/admin/visual-composer/ect-class-vc.php on line 26
    ', referer: https://XXX.XXX.XXX/wp-admin/index.php

    I suspect it’s actually caused by another plugin that filtering the event taxonomy terms, but I don’t have time to chase that down.

    Does that help?

    Thread Starter Paul

    (@headwall)

    I just tried the new beta version on one of my dev sites and I can confirm the Doing it Wrong warnings have been resolved 👍

    I deactivated and reactivated the beta plugin and there is a Doing it Wrong warning in your activation action handlers somewhere, but the plugin looks OK for general usage now.

    I’m happy to help with additional testing if needs be.

Viewing 15 replies - 1 through 15 (of 29 total)