Serializable is deprecated: stored PHP objects

What the message means

The Serializable deprecationA deprecation is an early warning that a feature still works today but will be removed in a future PHP version, so code using it must be changed in time. concerns a class implementing Serializable without also providing __serialize() and __unserialize(). Since PHPPHP is a programming language that builds your web pages on the computer that hosts your site, just before they reach the visitor. WordPress runs on it. 8.1, that combination produces a deprecation. Serialization converts an object into a representation that can be stored.

Investigate both writing and reading it back, rather than checking only whether a page opens.

Before changing anything

Keep the complete error line and its timestamp in a private note. Record the action that failed, the active PHP versionA PHP version is a numbered edition of PHP, like 8.3. Each edition is looked after for a limited time, then gets security fixes only, then nothing. and the components updated at the same time. Share only information needed for the investigation.

Public support forums are not an appropriate place for customer details, credentials or complete server paths.

Back up files and the database before making changes. Check that the backupA backup is a separate copy of your website's files and database, so you can bring the site back after a mistake, a hack or a failed update. is usable. Work on a private test copy with the same PHP version and relevant settings.

Disable real payments and outgoing customer email there. Agree who will make the change and who will check the outcome. The steps below are investigation advice rather than a diagnosis of your particular website.

Possible cause

Locate the named class and identify its maintaining package. Ask where its objects are stored and how long those records must remain usable. Do not simply remove the interface or existing storage methods.

Revised code must handle the agreed existing records. Successfully saving new objects alone does not establish that compatibility.

Fix it in five steps

1. Record the class and supplier from the error. Identify the methods used for writing and reading and the application data that depends on them.
2. Create a representative example on the test copy using the existing code. Keep its expected fields in a readable note beside the test data.
3. Assess an appropriate package update or targeted implementation. Ask explicitly how previously stored objects will be read and whether additional migration work is required.
4. Test a previously stored object and a newly stored object. Compare their contents after reading them back, not just whether processing finishes without a warning.
5. Repeat the visitor action that uses those records. Check that settings remain intact and record which code versions performed the writes and reads.

A concrete acceptance test

A saved report configuration provides a useful acceptance example. Before the change, create a test configuration with a title, selection and sort order. Reopen it after the change and compare every field.

Save a new configuration and repeat the check. This is a proposed test, not evidence of a defect in a specific extension. Establish who will handle recovery if existing records cannot be read.

Use only trusted records from your own test environment for this exercise, and retain the expected values for comparison.

Identify who maintains the code

For a pluginA WordPress plugin is an add-on you install in WordPress to give your site extra features, such as contact forms, SEO tools or a webshop. or themeA WordPress theme is a ready-made package that decides how your WordPress site looks and how its pages are laid out. Change the theme and the design changes., first ask which release fits the intended PHP environment. Give its maintainer the error line and the action that reproduces it. Request a focused change with an explanation of the expected result.

The same explanation belongs in a handover to the developer of custom code.

Avoid changing unrelated components during the same investigation. Keep the original message separate from any new messages after an adjustment. Record the code version and test inputs for each attempt.

This lets you associate a result with a specific change. A test where nobody knows which files changed cannot provide useful acceptance evidence.

Agree in advance what would make the test fail. Examples include incorrect content, lost settings or a visitor action that can no longer be completed. Making a warning disappear is only part of the check.

Ask the website owner to assess the result that a visitor actually needs, alongside the technical review of the change.

When to get help

Use the existing PHP update service or the help form below if you cannot access the code or do not maintain the affected library. Describe the failed action and intended outcome. Do not send passwords.

Ask which correction is proposed and which test will establish that it works.

Use the Exposure Check through the Check your PHP version link as an initial version check. A public check cannot always determine the PHP version and does not prove the cause or repair of this error. If the result is unknown, ask the host to confirm the active version for this website.

After repair, keep versions, test results and fresh log entries with your maintenance notes. Let the responsible administrator decide when the tested change can reach the live website.

Compare both what appears on screen and what returns after saving again. Ask whether the maintainer checked both storage directions. Retain the earlier test configuration until the administrator has assessed the transition and attached its outcomes to the change record.