Elemtentor, pagina

[flashprice2020]

Avvertimento : count(): il parametro deve essere un array o un oggetto che implementa Countable in /home/flashpri/public_html/wp-includes/formatting.php on line 3366

Ciao quando inserisco un file SVG non viene visualizzata la pagina creata con Elementor mi potreste aiutare ad indicarmi come faccio a cambiare il paramentro in Array o Implementare Countable

grazie anticipatamente

[costdev]

Hi @flashprice2020, welcome to Trac and thanks for opening this ticket!

There are two issues here:

1. A warning is received.
2. The warning is triggered by null being returned from preg_replace_callback() due to a failure.

---

The warning

This warning (PHP < 8) and error (PHP 8+) is caused by the following line:

<?php
if ( count( $matches ) == 0 ) {

$matches assumes an array comes from preg_replace_callback.

However, preg_replace_callback may return null. See ​preg_replace_callback.

A guard is needed to return an empty string if $matches is null.

---

The failure

This is trickier to track down without more information. This could be an issue with Core, with Elementor, another plugin, or your theme.

@flashprice2020: did you insert any emoticons, for example: :-), into your page?

• Which version of WordPress are you using?
  • Update: 5.8.3
• Which version of Elementor are you using?
  • Update: 3.5.3
• What other plugins do you have activated?
  • Update: WooCommerce, WooCommerce One Page Checkout, Conditional Payments for WooCommerce, WooCommerce Blocks, others unknown)
• What theme is your website using?
  • Update: OceanWP

---

Update
After visiting the website and determining the limited information above, I was not able to reproduce this error after installing all of the above (excluding One Page Checkout - Premium) and creating a page.

Awaiting reporter-feedback about content added so that we might determine if this is a Core issue or an issue for the support forums.

Guard against $matches being null.

Trac ticket: https://core.trac.wordpress.org/ticket/54827

[costdev]

The PR to guard against non-array values for $matches is ready for review.

[costdev]

Per the discussion in the bug scrub, I'm adding the commit keyword for commit consideration.

[jrf]

More than anything, this needs a backtrace of what is causing the error and fixing in the actual problem code, not here.

I'm not strongly opposed to adding the extra defensive code in the function, but it would hide an error which in all truth should be fixed elsewhere.

[peterwilsoncc]

Let's hold for now given the discussion above.

If the bug is in convert_smilies() then, yes, it would be good to fix it there.

The function _expects_ to receive an array. It's documented as requiring an array. Thus passing it any other data type is doing it wrong.

The guard added hides the problem if anything other than array is passed to translate_smiley(). The new guard clause change is actually doing input validation of the parameter.

There's a broad architectural discussion happening (the Trac ticket number escapes me) about how to handle input validation throughout the code base. Rather than implementing an isolated fix here, IMO this PR should wait and be included as part of that system-wide architectural change.

[hellofromTonya]

More than anything, this needs a backtrace of what is causing the error and fixing in the actual problem code, not here.

I agree.

After evaluating, I am not adding the php-compatibility focus. Why? This ticket seems to be something outside of Core doing it wrong, rather than an incompatibility with PHP 8.0. The code expects and is documented as expected an array. Passing it anything else is doing it wrong.

I agree with @jrf about adding defensive code to protect Core's source code. However, I think the topic of input (parameter/property) validation is more of an architectural consideration, one that should be discussed and considered for application across all of Core, rather than in individual functions.

I'm inclined to close this ticket. Why?

• The root cause does not appear to be Core. Thus it needs to be fixed in the code that is passing something other than an array.
• Input (parameter/property) validation is more of an architectural consideration. Rather than adding a guard in this one function for something that should not happen, I think the discussion of input validation should move to a more broad architectural discussion. Once there's consensus, then functions like this one could receive the same defensive protection that will be applied to all others.

I'm marking this ticket as close candidate and reporter-feedback to hopefully learn if the backtrace happened to identify which plugin, theme, or script caused it.

[hellofromTonya]

I'll close this ticket, as it's been 5 months with no report follow-up. As I previously noted, the root cause does not appear to be Core and a backtrace is needed to determine which plugin, theme, or script caused it.