T_STRING is a bit of a misnomer. It does not denote a "string", but refers to raw identifiers like name, bare words / plain text within the source.
Misquoted strings
Quite typically it occurs within misquoted strings however. If you forgot to correctly escape the content of "strings", have stray
"/' quotes in it for example: ⇓ ⇓
echo "<a href="http://example.com">click here</a>";
Syntax highlighting will make such mistakes super obvious. It's important to remember to use backslashes for escaping \" double quotes, or \' single quotes - depending on which was used as string enclosure.
For convenience you should prefer outer single quotes if you want to output HTML with double quotes within. Use double quote string encloseres if you want to interpolate variables, and then watch out for escaping. For lengthier output, use multiple
echo/print lines instead of trying to escape in and out, or better yet consider a HEREDOC section.
Unclosed strings
If you miss a closing " then a syntax error typically materializes on a later line:
⇓
echo "Some text", $a_variable, "and some runaway string ;
success("finished");
⇯
It's not just
T_STRINGs which the parser may protest then (but it's the most common occurence). For example Unexpected '>' often points out unquoted literal HTML after strings.
Again, you can probably see the helpful syntax highlighting here on Stackoverflow which makes it apparent.
Non-programming string quotes
If you copy and paste code from a blog or website, you sometimes end up with invalid code. Typographic quotes aren't what PHP expects:
$text = ’Something something..’ + ”these ain't quotes”;
They're often Unicode characters, thusly interpreted as constants, and therefore the following text handled as bareword/T_STRING.
The missing semicolon again
As always it's sensible to also look into the preceding line. PHP will complain about a word in one line (the parser doesn't know yet if that's a constant or a function call or something else). But the culprit is higher up in the code:
⇓
func1()
function2();
Short open tags and <?xml headers in php scripts
If short_open_tags are enabled, then you can't begin your PHP scripts with an XML declaration:
⇓
<?xml version="1.0"?>
PHP will see the <? and reclaim it for itself. It won't know what to do with the stray xml following the open marker however. While that might pass as an undeclared constant, the following version bareword will trigger a parser failure.
It's commonly advised not to mix in XML in PHP scripts, or at least have the courtesy to turn off short_open_tags if that's a common use case.
Invisible unicode characters
A most hideous cause for syntax errors are unicode characters, such as the non-breaking space (commonly ). PHP allows Unicode characters as identifier names. If you get this parser error for unsuspecting code such as:
<?php
print 123;
You need to break out your hexeditor. What looks like plain spaces and newlines here, may contain invisble constants. Try to reedit everything, remove whitespace and add normal spaces back in. Or use this evil trick to discover the culprit:
<?php
;print 123;
The redundant ; semicolon here will convert the preceding invisible character into an undefined constant reference (expression as statement). Which in return will trigger a notice.
