PHP 8.4: Deprecation warnings from bundled Crypt libraries

Bug report: PHP 8.4: Deprecation warnings from bundled Crypt library (Crypt/Base.php, Crypt/Rijndael.php) Environment Plugin: WPvivid Staging v2.0.22 Also active: WPvivid Backup Pro v2.2.44, WPvivid Backup Plugin v0.9.125 PHP: 8.4.20 (FPM) WordPress: 6.9.x Webserver: nginx (WordOps stack) Database: MariaDB Summary Two PHP deprecation warnings fire on every backend request where the plugin is loaded, caused by PHP 8.4 strictness against the vendored phpseclib Crypt classes shipped inside wpvivid-staging/Crypt/ . They do not affect functionality, but they flood the WordPress debug log and make real issues hard to spot. Log evidence [PHP Deprecated] Creation of dynamic property Crypt_Rijndael::$key_size is deprecated in wpvivid-staging/Crypt/Rijndael.php on line 279 [PHP Deprecated] substr(): Passing null to parameter #1 ($string) of type string is deprecated in wpvivid-staging/Crypt/Base.php on line 1944 On our staging install these appear roughly 16 times per admin page load (8 Rijndael + 8 Base) — consistently on every /wp-admin/ request, including the Dashboard. Expected vs. actual Expected: No PHP deprecation warnings on a site running a supported PHP version (8.4 entered security fixes phase and is fully supported). Actual: The plugin’s bundled Crypt library still uses: Untyped dynamic properties on Crypt_Rijndael (deprecated since PHP 8.2). substr( null, … ) (deprecated since PHP 8.1). Reproduction Install WordPress on PHP 8.4. Activate WPvivid Backup + WPvivid Staging v2.0.22. Enable WP_DEBUG and WP_DEBUG_LOG . Visit /wp-admin/ once. Tail wp-content/debug.log . Suggested fix For Crypt/Rijndael.php:279 — declare the property: // Before class body class Crypt_Rijndael { /** @var int */ public int $key_size = 16; // or ?int if it can remain null // … } For Crypt/Base.php:1944 — coerce to string at the call site: $result = substr( (string) $input, 0, $length ); Better long-term: replace the vendored legacy shim with upstream phpseclib v3 , which is PHP 8.4-clean and actively maintained. Workaround currently in use Our staging site currently silences only these two specific deprecation sources (file+error-type) via a narrow set_error_handler in a mu-plugin. This is a Band-Aid; a real fix upstream would remove the need. If you need further info, please let me know, however I believe this report should help dev team to fix the issue with the next update. Thanks Saskia Hello! Thank you for the report. We’re going to look into this and will provide you with an update shortly. Hello! Could you please reach out to us at support(a)wpvivid.com so we can provide you with specific troubleshooting details? To help us assist you more efficiently, please include a link to this thread in your email. This will allow us to quickly reference your case and address your inquiry. @nicholas2019 Hej there! There is no need for help from my side. I was able to fix it by using my workaround described in my initial post. Please consider this a bug report without further support request from my side. Thanks and have a great sunday! Saskia Hello @jyria Thanks for the update. We are going to check into the issue further and get back to you as soon as we can. All the best, Hello @jyria , a fix for this issue is scheduled for our next version. Stay tuned for updates. @nicholas2019 Thanks a lot, mates! No problem at all! Thank you for reporting this to us. Keep an eye out for the upcoming version for the fix. Let us know if you need anything else! Hello! The new version of staging is now available, so please be sure to update. We’ll go ahead and mark this thread as resolved for now. For future support requests, kindly submit a ticket through WPvivid’s support system instead of the WordPress support forum, as discussions about the Pro version are not allowed here.