[5.5] Resolve issue with queuable notifications

[brendt]

This PR fixes the error reported by several people after a change in #22119

[brendt]

Maybe @aaronhuisinga and/or @stevebeyatte who reported having issues with #22119 could take a look if this fix solves their use case?

[aaronhuisinga]

This fixes the issue for me.

[taylorotwell]

How does this actually affect anything? All you did was get rid of a temporary variable.

[brendt]

The temporary variable calls new $value->class which throws this exception when serialising queueable notifications.

Symfony\Component\Debug\Exception\FatalThrowableError · Class name must be a valid object or a string". Thrown from Illuminate/Queue/SerializesAndRestoresModelIdentifiers.php on line 51

I restored it to the way it was before my previous PR, whilst keeping the added functionality.

A better solution seemed to write a more explicit check:

if (class_exists($value->class)) {
    $model = new $value->class() //... ;
}

But this seemed more intrusive, so I opted for the way it was in 5.5.21. If you'd like a more explicit condition, I'm more than happy to make the changes and add a test or two.

[Daursu]

The issue occurs when trying to serialize an empty collection. Can you add a test on this so it's covered for future changes.

// ModelSerializationTest.php

    /** @test */
    public function it_serializes_an_empty_collection()
    {
        $serialized = serialize(new ModelSerializationTestClass(
            new \Illuminate\Database\Eloquent\Collection([])
        ));
        unserialize($serialized);
    }

[brendt]

Thanks @Daursu , added your test.

The question still stands if it would be a better idea to make the check before making a model based on $value->class more explicit by using class_exists .

[Daursu]

An empty collection will always have $value->class = null, but $value->id = [] will always be an array.

The code looks fine as it is now, and it preserves the intended behaviour in #22119.