isarisar

Unfortunately I don’t know, my colleagues didn’t report the occurrences. I just saw them later in the log.

(We don’t have anything DHL-related in our functions.php, that much I know.)

Seems like somewhere a string isn’t parsed into a number, which used to be accepted implicitly with but a warning up to & including PHP7.

I’m sorry, but are you actually reading my replies? The true cause is a faulty floor() call in your code that turns into a full bug in PHP8. I posted the fix!

Another unrelated, but this time critical error I’ve found in the log:

CRITICAL Uncaught Error: Call to a member function get_category_ids() on bool in /srv/wp-content/plugins/product-add-ons-woocommerce/includes/Model/Group.php:344
Stack trace:
#0 /srv/wp-content/plugins/product-add-ons-woocommerce/includes/Frontend/Product.php(521): ZAddons\Model\Group::getByProduct()
#1 /srv/wp-includes/class-wp-hook.php(309): ZAddons\Frontend\Product->add_to_cart_validation()
#2 /srv/wp-includes/plugin.php(189): WP_Hook->apply_filters()
#3 /srv/wp-content/plugins/woocommerce/includes/class-wc-form-handler.php(904): apply_filters()
#4 /srv/wp-content/plugins/woocommerce/includes/class-wc-form-handler.php(790): WC_Form_Handler::add_to_cart_handler_variable()
#5 /srv/wp-includes/class-wp-hook.php(307): WC_Form_Handler::add_to_cart_action()
#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-settings.php(609): do_action()
#9 /srv/wp-config.php(128): require_once('...')
#10 /srv/wp-load.php(50): require_once('...')
#11 /srv/wp-blog-header.php(13): require_once('...')
#12 /srv/index.php(17): require('...')
#13 {main}
  thrown in /srv/wp-content/plugins/product-add-ons-woocommerce/includes/Model/Group.php in line 344

Hi @ihereira,

thank you for the reply.

Unfortunately I don’t know what causes the error, so far I just see it being in the log repeatedly.

The report contains a bit too much info to share openly, is there some private way I can share it with you?

Version info:
PAOfWC: 2.1.38
WC 6.3.1
WP 5.9.2
PHP 8.0.17

Maybe relevant: Occurrence & fix in another plugin (Parsi Date/wp-parsidate)

Sorry, forgot about that version info. Yes.

TP PIFfW: 1.0.5
WC: 6.3.1
WP: 5.9.2
PHP: 8.0.17

That’s reading the stack trace the wrong way. The issue is floor() calls now being invalid with eg. implicitly convertible empty strings in PHP8. If you read relevant the PHP manual parts, you will see that its parameter was restricted:

• Standard: “The math functions abs(), ceil(), floor() and round() now properly heed the strict_types directive. Previously, they coerced the first argument even in strict type mode.”
• floor(): “num no longer accepts internal objects which support numeric conversion.”

Said empty string is exactly what get_post_meta() may well return:

• “An empty string if a valid but non-existing post ID is passed.”

(edit: It could, ofc, be that rather than setting 0 for such case, the proper way would be to gracefully show a notice. For that matter, another thread suggest that clearing transients sometimes helps.)

Our limit is already 512M.

BTW, aren’t you incidentally already using essentially the same checked way for $max near the same line? You only call ceil() on it after an !empty() check.

• This reply was modified 2 years, 12 months ago by isarisar.
• This reply was modified 2 years, 12 months ago by isarisar.

Indeed, without me knowing the internals of the code, change in class-wpf-form.php at line 407…

$min = floor(get_post_meta(get_the_ID(), '_price', true));
if (empty($min)) {
    $min = 0;
}

to sth. like

$min = get_post_meta(get_the_ID(), '_price', true);
$min = empty($min) ? 0 : floor($min);

… and it’ll work again.

To remove the warning (originally) on line 1381, just adopt the empty() check already found two lines above…
<img class="preview-image-wraper" src="<?php echo $module['image_bg_' . $cat->term_id] ?>" alt="">
… to sth. like:
<?php if (!empty($module['image_bg_' . $cat->term_id])): ?><img class="preview-image-wraper" src="<?php echo $module['image_bg_' . $cat->term_id] ?>" alt=""><?php endif; ?>

Hi, I figured trying to run with debug enabled, it shows a repeated warning & subsequent error that doesn’t seem related to our server:

PHP Warning:  Undefined array key "image_bg_641" in /srv/wp-content/plugins/themify-wc-product-filter/includes/class-wpf-form.php on line 1381
PHP Warning:  Undefined array key "image_bg_642" in /srv/wp-content/plugins/themify-wc-product-filter/includes/class-wpf-form.php on line 1381
PHP Warning:  Undefined array key "image_bg_646" in /srv/wp-content/plugins/themify-wc-product-filter/includes/class-wpf-form.php on line 1381
PHP Warning:  Undefined array key "image_bg_643" in /srv/wp-content/plugins/themify-wc-product-filter/includes/class-wpf-form.php on line 1381
PHP Warning:  Undefined array key "image_bg_645" in /srv/wp-content/plugins/themify-wc-product-filter/includes/class-wpf-form.php on line 1381
PHP Warning:  Undefined array key "image_bg_644" in /srv/wp-content/plugins/themify-wc-product-filter/includes/class-wpf-form.php on line 1381
PHP Fatal error:  Uncaught TypeError: floor(): Argument #1 ($num) must be of type int|float, string given in /srv/wp-content/plugins/themify-wc-product-filter/includes/class-wpf-form.php:407
Stack trace:
#0 /srv/wp-content/plugins/themify-wc-product-filter/includes/class-wpf-form.php(407): floor()
#1 /srv/wp-content/plugins/themify-wc-product-filter/includes/class-wpf-form.php(331): WPF_Form->get_main_fields()
#2 /srv/wp-content/plugins/themify-wc-product-filter/includes/class-wpf-form.php(278): WPF_Form->module()
#3 /srv/wp-content/plugins/themify-wc-product-filter/admin/partials/form.php(7): WPF_Form->form()
#4 /srv/wp-content/plugins/themify-wc-product-filter/admin/class-wpf-admin.php(343): include_once('...')
#5 /srv/wp-includes/class-wp-hook.php(307): WPF_Admin->add_template()
#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/themify-wc-product-filter/includes/class-wpf-form.php on line 407

Hi @aahulsebos,

thank you, now it works again.

Can’t add the .cmplz-placeholder-element.g-recaptcha rule without the recaptcha icon (the small one that appears bottom right) then refusing to appear, but we’re using a soft cookiewall and the double placeholder isn’t really an issue, anyway.

Hi @aahulsebos,

your test site exhibits the same bug. I’ve tried both Chrome 101-dev and Firefox 98.0.2 with new profiles, same behavior:

After accepting cookies in the banner, the “Click here to accept reCaptcha cookies before sending the form.” button correctly disappears, but no “Submit” button becomes visible/replaces it to actually trigger message delivery. (Previously such button would appear consistently.)

Only when you’ve ignored the cookie banner and click the form’s accept button does the send button become visible. (Revoking that consent for marketing via the “manage consent” form then yields inconsistent behavior: Sometimes it causes no button to be shown, sometimes it’ll redisplay the accept button, sometimes both buttons will be shown. But whatever the result, revoking consent won’t unload reCaptcha.)

Anyway:

• I don’t know what section you mean by “script center – services – reCaptcha”.
• Wizard→Consent→3rd Party Services: Yes & reCaptcha enabled & reCaptcha blocked before consent
• Integrations→Services: Google reCaptcha: On (Placeholder setting is off & cannot be enabled)
• Integrations→Script Center: unused/empty
• Settings→Disable placeholder insertion: Off

It’s the “block reCAPTCHA before consent” setting in the Wizard that seems to create the extra placeholder: But if this setting switched to off, reCaptcha will be loaded unconditionally – including if no consent was given and even if consent was explicitly denied.

[Entirely unrelated: Divi needs a yet higher z-index for the soft cookiewall to work – .cmplz-soft-cookiewall {z-index: 100001}]

• This reply was modified 3 years ago by isarisar.
• This reply was modified 3 years ago by isarisar.

Re. 1:. Ups, that was easy: Somehow “Do you want to block reCAPTCHA before consent, and when consent is revoked?” was set to No.

I don’t recall setting it to that or it even being present when I originally set the form up. I’d suggest to add checking the option as a hint to the tutorial.

Re. 2: I think it’s an CSS issue from when you (at least in the tutorial) renamed a few things. An older copy of the site still has the setup when .cmplz-recaptcha was .cmplz-status-marketing etc. With that, while the placeholder text remains on acceptance, the button at least doesn’t vanish and can trigger the form to be sent.

Maybe the tutorial is outdated? Seeing as with the option from 1. enabled, the WPForm placeholder button is now duplicated in function immediately below by another (rather unsightly) reCaptcha placeholder inserted by Complianz.

• This reply was modified 3 years ago by isarisar.
• This reply was modified 3 years ago by isarisar.
• This reply was modified 3 years ago by isarisar.

Unfortunately I haven’t. This is the only plugin of our four dozen which has any issue.

I’ve also tried with a local installation of WordPress on PHP 8.0.17 with 512MB available and otherwise default settings (apart from enabling the relevant extensions), no improvement.

Can confirm, error 500 both on Add new and Edit of existing ones.

While it’s indeed an error occurring with a GET/Request URL https://…/wp-admin/admin-ajax.php?action=wpf_edit&nonce=…&slug=kategorien&_fs_blog_admin=true call, the network log shows other calls from the same page to https://…/wp-admin/admin-ajax.php succeed fine.

I also have no issues with anything else on my site, and the existing filters continue working fine.

(Most recent versions of everything in WordPress, PHP 8.0.12 with memory_limit 512M, nginx)