Unexpected T_CONSTANT_ENCAPSED_STRING, Unexpected T_ENCAPSED_AND_WHITESPACE

Unexpected T_CONSTANT_ENCAPSED_STRING, Unexpected T_ENCAPSED_AND_WHITESPACE

The unwieldy names T_CONSTANT_ENCAPSED_STRING and T_ENCAPSED_AND_WHITESPACE refer to quoted "string" literals.
They're used in different contexts, but the syntax issue are quite similar. T_ENCAPSED… warnings occur in double quoted string context, while T_CONSTANT… strings are often astray in plain PHP expressions or statements.

1. Incorrect variable interpolation

   And it comes up most frequently for incorrect PHP variable interpolation:
   

                             ⇓     ⇓
   echo "Here comes a $wrong['array'] access";

   Quoting arrays keys is a must in PHP context. But in double quoted strings (or HEREDOCs) this is a mistake. The parser complains about the contained single quoted 'string', because it usually expects a literal identifier / key there.
   More precisely it's valid to use PHP2-style simple syntax within double quotes for array references:
   

   echo "This is only $valid[here] ...";

   Nested arrays or deeper object references however require the complex curly string expression syntax:
   

   echo "Use {$array['as_usual']} with curly syntax.";

   If unsure, this is commonly safer to use. It's often even considered more readable. And better IDEs actually use distinct syntax colorization for that.

2. Missing concatenation

   If a string follows an expression, but lacks a concatenation or other operator, then you'll see PHP complain about the string literal:
   

                          ⇓
   print "Hello " . WORLD  " !";

   While it's obvious to you and me, PHP just can't guess that the string was meant to be appended there.

3. Confusing string quote enclosures

   The same syntax error occurs when confounding string delimiters. A string started by a single ' or double " quote also ends with the same.
   

                   ⇓
   print "<a href="' . $link . '">click here</a>";
         ⌞⎽⎽⎽⎽⎽⎽⎽⎽⌟⌞⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⌟⌞⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⌟

   That example started with double quotes. But double quotes were also destined for the HTML attributes. The intended concatenation operator within however became interpreted as part of a second string in single quotes.
   

   Tip: Set your editor/IDE to use slightly distinct colorization for single and double quoted strings. (It also helps with application logic to prefer e.g. double quoted strings for textual output, and single quoted strings only for constant-like values.)

   This is a good example where you shouldn't break out of double quotes in the first place. Instead just use proper \" escapes for the HTML attributes´ quotes:
   

   print "<a href=\"{$link}\">click here</a>";

   While this can also lead to syntax confusion, all better IDEs/editors again help by colorizing the escaped quotes differently.

4. Missing opening quote

   Equivalently are forgotten opening "/' quotes a recipe for parser errors:
   

                  ⇓
    make_url(login', 'open');

   Here the ', ' would become a string literal after a bareword, when obviously login was meant to be a string parameter.

5. Array lists

   If you miss a , comma in an array creation block, the parser will see two consecutive strings:
   

   array(               ⇓
        "key" => "value"
        "next" => "....",
   );

   Note that the last line may always contain an extra comma, but overlooking one in between is unforgivable. Which is hard to discover without syntax highlighting.

6. Function parameter lists

   Same thing for function calls:
   

                            ⇓
   myfunc(123, "text", "and"  "more")

7. Runaway strings

   A common variation are quite simply forgotten string terminators:
   

                                   ⇓
   mysql_evil("SELECT * FROM stuffs);
   print "'ok'";
         ⇑

   Here PHP complains about two string literals directly following each other. But the real cause is the unclosed previous string of course.