[Resolved] PHP 8 Fatal error

[Author]

Posts

[smileBeda]

It seems there is an issue with Views, AJAXified searches and PHP 8

I am still looking for the precise setup to replicate the case, but I have it now on 2 sites both on pages where a form of AJAX update in search is used, and it should be happening as soon you have some select search with AJAX setup and PHP 8 running.

This is the error triggered:

[14-Apr-2021 11:34:10 UTC] PHP Fatal error:  Uncaught ArgumentCountError: array_merge() does not accept unknown named parameters in /var/www/html/wp-content/plugins/wp-views/embedded/inc/classes/wpv-cache.class.php:358
Stack trace:
#0 /var/www/html/wp-content/plugins/wp-views/embedded/inc/classes/wpv-cache.class.php(358): array_merge()
#1 /var/www/html/wp-content/plugins/wp-views/embedded/inc/classes/wpv-cache.class.php(580): WPV_Cache::generate_post_data_cache()
#2 /var/www/html/wp-content/plugins/wp-views/embedded/inc/wpv-archive-loop.php(812): WPV_Cache::generate_native_cache()
#3 /var/www/html/wp-includes/class-wp-hook.php(292): WPV_WordPress_Archive_Frontend::extend_archive_query_for_parametric_and_counters()
#4 /var/www/html/wp-includes/class-wp-hook.php(316): WP_Hook->apply_filters()
#5 /var/www/html/wp-includes/plugin.php(484): WP_Hook->do_action()
#6 /var/www/html/wp-content/plugins/wp-views/embedded/inc/wpv-archive-loop.php(1004): do_action()
#7 /var/www/html/wp-includes/class-wp-hook.php(292): WPV_WordPress_Archive_Frontend->initialize_archive_loop()
#8 /var/www/html/wp-includes/class-wp-hook.php(316): WP_Hook->apply_filters()
#9 /var/www/html/wp-includes/plugin.php(484): WP_Hook->do_action()
#10 /var/www/html/wp-includes/template-loader.php(13): do_action()
#11 /var/www/html/wp-blog-header.php(19): require_once('...')
#12 /var/www/html/index.php(17): require('...')
#13 {main}
  thrown in /var/www/html/wp-content/plugins/wp-views/embedded/inc/classes/wpv-cache.class.php on line 358

On one site I was able to resolve it by selecting "Let me choose individual settings" in the AJAX search options, and on the other site I am still debugging it.
I am pretty sure it is due to PHP 8 since several other plugins have similar error reporting all due to PHP 8 update, even composer had the report here hidden link

I post it here in the hope that you are already aware of it and I can spare the time of finding the precise steps, but it seems like when select Search with AJAX update on user input change is used, this error is happening.

At least on both sites affected, it happens only where Views AJAX search is present and as said, is solved if I select a "Let me choose individual settings" or completely disable AJAX search.

I am also aware that PHP 8 is not yet fully supported by core itself but I have seen support tickets here in the Toolset Forum stating that Toolset is 100% compatible with anything above 5.6, so... 😉

PS:
On the offending line, Toolset uses call_user_func_array, which calls the callback given by the first parameter with the parameters in args.
So, looking at the offending line

$id_posts = call_user_func_array( 'array_merge', $id_posts_for_column );

This means array_merge() is called, with $id_posts_for_column passed as args. This is precisely the same as happened with composer and was fixed here hidden link.
Looking that that arg, it is a valid array but has 0 as array keys which might be the cause for this trigger:

[14-Apr-2021 12:57:18 UTC] Array
(
    [post_author] => Array
        (
            [0] => 1752
        )

    [post_type] => Array
        (
            [0] => 1752
        )

)

Anyway, I am pretty sure you will be able to replicate this and even without replication a developer probably will be able to tell immediately what needs to be changed.
You may want to look into this.

Let me know if you need more details and wether or not you already have some internal tickets for this that would resolve this issue hopefully soon?

[smileBeda]

Well, "Compatible with PHP 8" may be quite exaggerated.
Note - "Toolset is PHP 8 ready" is *not* my own word
First, there is no big fat warning on the minimal requirement page, I simply assumed it is compatible.... and second, I read it on the forums after I found above issue that it is compatible
https://toolset.com/forums/topic/is-toolset-form-php-8-ready/

Here instead you say its not compatible, I found that also only now, thanks to google, of course, not thanks to the forum. That is a bit upsetting, to have to google for such things.
https://toolset.com/forums/topic/deprecated-messages-with-php-8/

I think either making it compatible or - given the work for this is not minimal! - at _least_ put it on the minimal requirements page that it is not compatible would be really a wise thing. And kind of a friendly thing as well. I think people and developers would appreciate if someone would warn them - even with a tiny single line, somewhere (on that minimal requirements page) that it should not be used.

The problem is VPS companies started pushing PHP8 to their servers in several occasions and specially when you set up fresh stacks, it comes by default. Then you migrate WP, and other plugins and all works fine. Even Toolset in most cases. Until it starts to pile up errors 🙂
Telling users "No, Toolset is not working with the version of PHP that your expensive VPS wants you to use" is also not the best thing to do
Also note that certain plugins out there have reached PHP 8 compatibility months ago already, see https://wordpress.org/support/topic/php-8-0-x-support-for-the-latest-and-most-updated-official-stable-version-10/ for example.

---

Now, on a fresh install, WordPress alone will work with PHP 8

However if you only install and activate Toolset Forms, Blocks and Types your error log will already have 300+ lines of errors the second.
Those errors are from what I saw just notices in the range of
PHP Deprecated: Required parameter $paged follows optional parameter $exclude_fields in .../wp-content/plugins/cred-frontend-editor/library/toolset/cred/embedded/models/FieldsAbstract.php on line 34
... etc

This is a simple activation of the plugin, nothing else done yet.

From here on you can't even open and edit a page anymore.
It will WPOD and throw hundreds of lines more per second in the logs in the same range as above (always a few different lines and parameters but always the same "issue")
PHP Deprecated: Required parameter $in follows optional parameter $method in .../wp-content/plugins/toolset-blocks/embedded/inc/wpv-query-debug.class.php on line 417

That should already be enough to put a big notice out there "Do NOT update to PHP 8 in ANY case because the site will go away, basically."
Edit experience will be broken, and the error log will pile so fast that not even a VPS will cope with it after a few days 🙂

Note this seems to happen only when all the main plugins are active, with blocks alone, it did not happen (but errors pile nonetheless).

Then I tried further on this clean install to actually create Archives with Blocks and it PHP Fatal error:
Uncaught ArgumentCountError: array_merge() does not accept unknown named parameters in .../wp-content/plugins/toolset-blocks/embedded/inc/classes/wpv-cache.class.php:358

This is the error I found earlier on the existing site mentioned above.
There I do not use Blocks but it still happens when any sort of AJAX search is used, which I logically tried now on this clean install. Well, "clean" is exaggerated, it was clean until I installed the plugins lol. Now it is failing haha.

I really would have appreciated this hint on the actual requirement page _before_ migrating the sites to the new servers of clients, and not find it out on my own on client sites using a fresh VPS with a very expensive stack. Well, its as it is.

I guess I will have them downgrade to PHP 7.4 and hope PHP 8 will soon be available with Toolset as well. Do not forget that we are less than one year away from EOL of PHP 7.3,
After that, PHP 8 is the only truly actively supported version of PHP and PHP 7.4 will only receive security updates.

Thanks.

[Waqar]

Hi Beda,

Hope you're well.

Thank you for your detailed report and I can confirm that PHP 8 compatibility testing is underway and we're aware of the several depreciation notices that you pointed out.

I've passed on the information about the fatal errors that you've shared in scope of Toolset Views/Blocks too, along with the feedback that a warning about the current state of PHP 8 compatibility in form of an admin area notice or a note on the server requirement page would be really helpful.

Appreciate you brought this forward and I'll keep you updated through this ticket.

regards,
Waqar

[Waqar]

Hi Beda,

A note about the PHP 8 compatibility has been added in the Toolset Server Requirements:
https://toolset.com/toolset-requirements/

I'll keep you updated about the errors and compatibility with PHP 8.

regards,
Waqar

[Waqar]

Hi Beda,

Just wanted to share that the PHP 8 compatibility has been included in the latest releases of the Toolset plugins.
( https://toolset.com/2022/05/toolset-1-6-3-full-compatibility-with-php-8 )

You're welcome to update the plugins and let us know if you see any other errors or warnings.

regards,
Waqar