Updating one plugin may not change the library actually loaded by WordPress. Follow the file path and retest the affected request and scheduled job.
Quick answer
WP Rocket 3.23.3.1 includes compatibility updates to bundled Action Scheduler and Mobile Detect libraries for PHP 8.4 and 8.5 deprecation notices. Capture the warning path and loaded library before updating. Another active plugin may supply the library used at runtime. Verify the original browser request and background work after the update, rather than only checking that the plugin version number changed.
Read the severity before changing PHP
A deprecated notice usually signals code that needs modernization; it is different from a fatal exception that ends execution. Nevertheless, excessive logging consumes disk space, obscures more important failures, and can corrupt an API response if diagnostic text is displayed publicly. Record whether users see a failure, whether the server merely logs a notice, and whether the request returns the expected content.
Use the host log or WordPress debugging configuration appropriate to the environment. Keep error display off on public pages and store logs outside publicly served paths where practical. Do not disable all error reporting as the fix. Preserve enough evidence to identify the source, then return temporary debugging to its previous state after the investigation.
Find the library that WordPress actually loaded
Copy the full file path, line, message, and stack context from one occurrence. A message mentioning Action Scheduler does not automatically make WooCommerce or WP Rocket the active owner. Several plugins can bundle it, and runtime loading determines which copy executes. Compare the loaded path against installed packages and deployment records.
For Mobile Detect, record which request triggered device detection and whether a theme or another plugin also includes a copy. Avoid editing files inside vendor directories because the next plugin update can replace them. If an old library remains active after an update, inspect the package providing that path and any custom loader. A clean plugin dashboard does not establish that every web process is running the newly deployed code.
Illustrative diagnostic worksheet. Values are examples, not measurements from a customer site.
Compare the real PHP environments
Record PHP from WordPress Site Health and from the command line. Hosting systems often use different binaries for web requests and cron jobs. A CLI command that runs without warnings on PHP 8.3 does not prove the same operation is clean in the web pool on PHP 8.5. Note the PHP version for each observed warning.
Use a staging copy with the same plugin set and relevant settings. First run the failing request on the current runtime; then test the supported package updates while keeping other variables fixed. Changing PHP, the theme, and several plugins at once makes attribution difficult. If the host restarts PHP workers or clears opcode caches during deployment, record that step as part of the change.
Check background work and device behavior
For Action Scheduler, find a representative pending action using the application tools that expose it. Record its hook, scheduled time, attempts, and expected side effect. After the update, verify completion and check that retry behavior did not duplicate email, feed, or cache work. A quiet log can also mean that the worker stopped, so confirm actual progress.
For Mobile Detect, test the page or feature that used device detection with representative mobile and desktop requests. Compare visible content, cache variants, and any device-dependent redirect. Do not infer correct classification from a screenshot alone if the server caches device-specific HTML. Use the same request conditions and inspect the resulting page to catch cache contamination or an altered decision path.
What if the notices persist?
Compare the new stack with the old one. The path may have moved to another plugin, or a different deprecation may now be visible. Send support exact versions, the redacted trace, affected URL or job, runtime, and reproduction steps. If users are blocked, use the tested rollback or a host-supported compatible PHP version while the specific package is corrected. Make that an explicit temporary decision with a review date, not an indefinite suppression of errors.
Working example
Use this as a read-only starting point or an evidence worksheet. Replace example identifiers with the approved staging fixture.
php --version
wp core version
wp plugin get wp-rocket --field=version
# Also record PHP shown in WordPress Site Health.
# CLI PHP can differ from the web server runtime.
Before closing the work
- The matching deprecation stops on the tested path.
- Scheduled work completes once.
- Mobile and desktop rendering remain correct.
- Logs stay private and temporary debugging is removed.
For help applying these checks to a live site, HandL WP WordPress support can review the affected configuration and verify the result. Continue with WP Rocket preload job troubleshooting when that adjacent issue matches your evidence.
Helpful references