We've previously looped over a JSON string,
and never created any security entries.
The bugfix around strict "=== 0" checks
might be a regression from framework, maybe
we used to set those foreign keys to 0,
and now we're leaving them null?
Either way, it's unnecessarily strict for this case.
And the write at the end ... that definitely didn't work.
So I guess we've got partial unit tests where the mocks work differently than the real API?
Not sure how it was supposed to work before this fix. Looking at the earliest stable release in the constraint for https://github.com/sensiolabs/security-checker/tree/v5.0.0, it mentions the use of json_decode() there.
We've previously looped over a JSON string, and never created any security entries.
The bugfix around strict "=== 0" checks might be a regression from framework, maybe we used to set those foreign keys to 0, and now we're leaving them null? Either way, it's unnecessarily strict for this case.
And the write at the end ... that definitely didn't work. So I guess we've got partial unit tests where the mocks work differently than the real API?