Another PHP 8 error: unserialize(): Argument #1 ($data) must be of type string

Hi again,

I know, PHP 8 is tough on developers!

Here is the latest bug I found (paths and server names redacted):

2021/06/24 01:04:41 [error] 3482#3482: *235407 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught TypeError: unserialize(): Argument #1 ($data) must be of type string, array given in /docroot/wp-content/plugins/page-links-single-page-option/page-links-options.php:482
Stack trace:
#0 /docroot/wp-content/plugins/page-links-single-page-option/page-links-options.php(482): unserialize()
#1 /docroot/wp-includes/class-wp-hook.php(294): SH_PageLinks_Options->sanitize_options()
#2 /docroot/wp-includes/plugin.php(212): WP_Hook->apply_filters()
#3 /docroot/wp-includes/formatting.php(4907): apply_filters()
#4 /docroot/wp-includes/option.php(369): sanitize_option()
#5 /docroot/wp-admin/options.php(314): update_option()
#6 {main}
  thrown in /docroot/wp-content/plugins/page-links-single-page-option/page-links-options.php on line 482" while reading response header from upstream, client: WWW.XXX.YYY.ZZZ, server: myservername.tld, request: "POST /wp-admin/options.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/my.sock:", host: "myservername.tld", referrer: "https://myservername.tld/wp-admin/admin.php?page=sh-page-links-options"

My fix was to change all instances I could find of serialize() (a standard PHP function) with maybe_serialize() (a WordPress function), as well as unserialize() with maybe_unserialize().

The WordPress functions were designed to deal with the error I got. This is a common situation: I’ve done the same to my own plugins long ago, exactly because of that reason.

I’ve also removed the error-suppressing @ before the assignment. I’m assuming that this was done to hide the error — which would work well in earlier versions of PHP. PHP 8, by contrast, deliberately ignores the @, to force programmers to do their debugging job properly ??