You mention that there is no use statement or namespace declaration that alludes to a 'string' class in the code. Does the code use an Autoloader?
Two possible issues at hand here:
Paths - It is possible that the live environment has another path set up, and/or that a file/class is being loaded/searched for via this 'other path' (outside the code you may be looking at).
Error Handling - Another possible cause is if there is an error handler in the production environment that always returns true.
I had this exact issue where a type-hint wasn't resolving in development, but I didn't realize until we pushed it live and the error handler was no longer registered.
Obviously a fatal parse error can not be stopped, but it turns out a catch-able error can be ignored if the error handler returns true. And this is what I am putting my money on in your case.
Additionally, it is very important to note that there is no way to type-hint a scalar, as one user pointed out.
A simpler way to say it is "it is not possible to type-hint anything that can be represented by a string." This is due to the way in which PHP handles it's more primitive variables, they can all be type-cast to one another, and therefore (because 1
, "1"
and true
can all be == 1
, == '1'
and == true
) it is not actually possible for the interpreter as it is written to actually catch and enforce scalar type-hints.
Answer this question: Is that variable supposed to be $str = "something";
or $str = new string();
(ie, a string or an object)?
If it is supposed to be a string, remove the type-hint, as nothing in PHP allows this support (save for HHVM, but you would know this if you were using it).
Since you say you do not have access to the code, I suggest notifying someone who does.