The PHP 8.5 deprecations RFC voted to deprecate __sleep() and __wakeup(), which would have triggered a warning and pushed you toward __serialize() and __unserialize(). That vote passed 18 to 9, just over the two-thirds line. This RFC from Nicolas Grekas and Jakub Zelenka walks it back by turning the change into a soft deprecation, where the documentation tells you to migrate but PHP doesn't emit a warning.

Why walk it back

The authors argue that the first RFC made migration sound easier than it is. Here's their simple case, a class that uses __sleep() to pick which properties to serialize:

public function __sleep(): array {
    return ['id', 'email', 'createdAt'];
}

With __serialize(), you have to write out every property by hand:

public function __serialize(): array {
    return [
        'id' => $this->id,
        'email' => $this->email,
        'createdAt' => $this->createdAt,
    ];
}

That adds up for classes with many properties. The RFC lists other costs too:

  • Stored data. Private properties are serialized under special mangled names, and data you've already saved in a database uses those names. New code has to read both the old and new formats.
  • Child classes. If other code extends your class and overrides __sleep(), you need extra code to keep it working.
  • No pressing need. The authors say __sleep() isn't broken. Its only limit is that it can't reach private properties in parent classes, so the push to remove it is about tidiness, not safety or bugs.

The RFC also says some voters later said they would have voted differently with the full picture.

What changes

  • The deprecation becomes documentation-only.
  • The magic methods page lists __sleep() and __wakeup() after __serialize() and __unserialize().
  • The page adds a note that the old methods are kept for backward compatibility and that code should move to the new ones.

What it means for existing code

Your __sleep() and __wakeup() methods keep working without a warning, though you're still encouraged to move to __serialize() and __unserialize(). A real deprecation warning could come later, once the migration path is better understood.

The vote

Accepted 26 to 5, clearing the two-thirds majority it needed. Voting closed on October 4, 2025.