isarisar

One more unrelated warning:

PHP Warning: Trying to access array offset on value of type int in /srv/wp-content/plugins/dhl-for-woocommerce/includes/abstract-pr-dhl-wc-order.php on line 1338

Is there no way to at least print which taxonomy is causing this issue?

It seems highly advisable to add a check to at least the first occurrence that prints info about such problematic $this->source, rather than leave the user to guess.

Getting similar errors with the free version since the most recent(?) update. It’s always these four lines on repeat:

PHP Warning:  Undefined property: WP_Error::$taxonomy in /srv/wp-content/plugins/wordpress-seo/src/presentations/indexable-term-archive-presentation.php on line 151
PHP Warning:  Undefined property: WP_Error::$taxonomy in /srv/wp-content/plugins/wordpress-seo/src/presentations/indexable-term-archive-presentation.php on line 176
PHP Warning:  Undefined property: WP_Error::$taxonomy in /srv/wp-content/plugins/wordpress-seo/src/presentations/indexable-term-archive-presentation.php on line 182
PHP Warning:  Undefined property: WP_Error::$taxonomy in /srv/wp-content/plugins/wordpress-seo/src/presentations/indexable-term-archive-presentation.php on line 210

Hi, sorry for the delay. I haven’t seen the warning since I clicked update on the plugin’s settings page, and so also can’t try & find anymore how it occurred.

Maybe the setting isn’t being written into the db during the update?

Some settings:

Tracking Note: Unchecked
Tracking Email: Unchecked
Tracking URL Language: “German” (“English” also listed)
Create Label on Status: None

I added an error_log for cases of $post being string.

The warning is thrown for $post being customer_invoice. IOW, it’s indeed caused by the standard woocommerce_before_resend_order_emails WooCommerce action linked in my prior comment.

If the plugin is meant to do nothing in these cases – as is the current flow – why not just prepend that part of the if condition with !is_string($post)?

Replacing $thing [0] with (is_string($thing[0]) ? $thing[0] : get_class($thing[0])), the diagnostic runs fine.

The troublesome string is Woocommerce_Invoice_Pdf, added by the German Market plugin in their woocommerce-invoice-pdf.php @ 238:
add_filter( 'wp_mail', array( __CLASS__, 'phpmailer_validation' ) );

If that’s a wrong way to register for that filter, should I write them about it?

Hi,

sorry for the delay.

Yes, other parts we’re actually relying on are working fine. Only the diagnostics seem affected.

Also seeing it with PHP 8.1.6.

Hi @shevasa,

we just got this same warning again with 2.8.15, same line# & all. Maybe you forgot to push that commit?

Anyway, thanks for your support, I’ll certainly write a review until the end of the week!

Hi Ilya,

nobody has reported anything, so I assume it does not.

Hi Jon,

thank you for taking the time to write a detailed explanation.

I’ll have to locate the problem in Divi (or some other plugin involved) then, there’s indeed no point in adding a hack around it into CPT as the issue is likely just going to blow up elsewhere eventually.

Hi Ilya,

thanks for the update!

Another path to the same error:

PHP Fatal error:  Uncaught TypeError: method_exists(): Argument #1 ($object_or_class) must be of type object|string, null given in /srv/wp-content/plugins/yikes-inc-easy-custom-woocommerce-product-tabs/public/class.yikes-woo-tabs-display.php:41
Stack trace:
#0 /srv/wp-content/plugins/yikes-inc-easy-custom-woocommerce-product-tabs/public/class.yikes-woo-tabs-display.php(41): method_exists()
#1 /srv/wp-includes/class-wp-hook.php(307): YIKES_Custom_Product_Tabs_Display->add_custom_product_tabs()
#2 /srv/wp-includes/plugin.php(189): WP_Hook->apply_filters()
#3 /srv/wp-content/themes/Divi/includes/builder/module/woocommerce/Tabs.php(359): apply_filters()
#4 /srv/wp-content/themes/Divi/includes/builder/feature/woocommerce-modules.php(2148): ET_Builder_Module_Woocommerce_Tabs::get_tabs()
#5 /srv/wp-includes/class-wp-hook.php(307): et_builder_get_woocommerce_tabs()
#6 /srv/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters()
#7 /srv/wp-includes/plugin.php(474): WP_Hook->do_action()
#8 /srv/wp-admin/admin-ajax.php(187): do_action()
#9 {main}
  thrown in /srv/wp-content/plugins/yikes-inc-easy-custom-woocommerce-product-tabs/public/class.yikes-woo-tabs-display.php on line 41

Suffices to do
1. Products → Add New
2. click “Use The Divi Builder” to launch it

For the same error & resolution, see click here. Seems to be: First check with isset for $product & if it doesn’t exist return $tabs unaltered.

Just opening (a page with) an empty list is enough for them to appear.

[Eg, “Search orders” for some nonsense string, use one of the “tabs” if they’ve got a “(0)”, or delete all orders.]

I think the changes to the manual page haven’t yet been pushed.

Though more importantly, I’ve come to notice that the spam filter doesn’t actually work anymore despite reCaptcha properly being enabled. Maybe it’s that bots don’t care for CSS.

Dunno if that issue is caused by Complianz or WPForms, though.