ablears

I had a look on the server, searching for other instances of Psr\Log\LoggerInterface::log and found that WooCommerce was logging errors on one domain only on this network, and that is the one showing the error. It backtraces to woocommerce/includes/class-woocommerce.php.

3:2024-09-09T20:22:02+00:00 CRITICAL Declaration of Psr\Log\NullLogger::log($level, $message, array $context = []) must be compatible with Psr\Log\LoggerInterface::log($level, Stringable|string $message, array $context = []): void CONTEXT: {“error”:{“type”:64,”file”:”/var/www/z/wp-content/plugins/mpdf-addon-for-pdf-invoices/vendor/psr/log/Psr/Log/NullLogger.php”,”line”:26},”backtrace”:[{“file”:”/var/www/z/wp-content/plugins/woocommerce/includes/class-woocommerce.php”,”line”:359,”function”:”critical”,”class”:”WC_Logger”,”type”:”->”},{“function”:”log_errors”,”class”:”WooCommerce”,”type”:”->”}]}

Running ack 'LoggerInterface' . showed a number of themes and plugins using it, but mpdf is the only one that generates a fatal error.

• This reply was modified 2 months, 1 week ago by ablears. Reason: more detail

I had to make the code change to your plugin to prevent the fatal errors. I’m not sure what else I can do, considering this is the only plug-in that generates this error on our WordPress network.

No worries, I found the changelog and can see it was removed.

I have exactly the same issue, but on PHP 8.1.13. It manifests on both my staging and production servers, and both our WordPress networks, and started happening yesterday when we updated all plugins. We test on staging first, but did not notice this issue.

Support info:
https://pastebin.mozilla.org/uegLK4rd

When viewing the variations tab, an AJAX POST is triggered, and that responds with a 500 error. I can see most of the variations markup is returned in the response, but is truncated due to a fatal error. In our case, it is due to the following

add_action( 'woocommerce_product_after_variable_attributes', 'variation_settings_fields', 10, 3 );

function variation_settings_fields( $loop, $variation_data, $variation ) {
	echo '<h3>Automation options</h3>';
	
	woocommerce_wp_select( 
		array( 
			'id'          => 'product_automation_type[' . $variation->ID . ']', 
			'label'       => __( 'Automation type', 'woocommerce' ), 
			'description' => __( 'Select type of automation.', 'woocommerce' ),
			'value'       => $variation->get_meta('product_automation_type', true) <-- PHP Fatal error:  Uncaught Error: Call to undefined method WP_Post::get_meta() 

	

In this case, I solved the issue by changing calls from $variation->get_meta to get_post_meta( $variation->ID, 'product_automation_type', true )

• This reply was modified 8 months ago by ablears. Reason: added debug
• This reply was modified 8 months ago by ablears. Reason: added fix

Ah, I noticed we’re on the premium version which is on 5.2.1. I’ll check the Visser site for more info about that.

Blank admin pages after a core update is very likely related to cached JS files. This has become an issue as WordPress has moved to JS-based functionality (the blocks editor). So, clear any caching you may have (I need to purge Cloudflare and Varnish), and try in an incognito/private tab.

Normally if this is JS/cache related you can also check by looking at the dev console. You’ll see a whole bunch of JS errors there.

It’s very annoying. I have over 200 sites on a network and cannot purge all the domains after a core update as the server would get hammered.

Thanks for the reply.

Can your plugin return templated HTML content when given raw email body text? Our system handles order delivery through additional emails, using Postmark’s PHP library for sending. Since we aren’t using wp_mail(), these emails aren’t processed by your plugin. What I’m after is a way to pass email content to WP HTML Mail and get back the templated HTML, which we can then send through Postmark.

Yes, agreed @dbemowsk. My error logs are being polluted by thousands of entries strstr(): Passing null to parameter #1 ($haystack) of type string is deprecated in woocommerce/includes/wc-page-functions.php on line 139

Ahhh. That is why after running composer update I found autocomplete-woocommerce-orders had disappeared from WP Admin. In the plugins folder I found autocomplete-woocommerce-orders contained WooCommerce Checkout Manager instead. Specifying 3.1.0 fixed it.

Hi, this appears solved in the latest version, thank you!

Hey, could you email me at [email protected] please.

I have fixed the pro version so it’s compatible with PHP 8.1, not sure if it’s the same fixes for the free version. Our support license has run out and no way to contact @visser these days. Consider moving to another plugin.

If you’re having performance issues try focusing on improving that through caching. I manage a WP network with hundreds of ecommerce sites and they all zip along, getting 90+ in Core Web Vitals. The key is caching at every layer – my setup is Cloudflare (so most requests don’t even make it to the web server), Varnish, WP Rocket and Redis (object caching). Without having proper caching in place you will always have awful performance. 2000 job listings is absolutely trivial if you serve them cached.

I fixed my missing conditional field by updating checks for mwb_upsell_bump_checkbox_container to wps_upsell_bump_checkbox_container.

Sadly, upgrading to 2.1.0 stopped a conditional field at checkout from showing when the order bump was selected. So I downgraded to 2.0.2 and my order bumps don’t show in admin any more.

Looking into it I see your option changed from mwb_ubo_bump_list to wps_ubo_bump_list which explains why downgrading lost the data.

• This reply was modified 2 years, 7 months ago by ablears. Reason: added detail