The PHP engine is really picky but not very chatty. If you leave out a necessary semicolon, or start a string with a single quote but end it with a double quote, the engine doesn’t run your program. It throws up its (virtual) hands, complains about a “parse error,” and leaves you stuck in the debugging wilderness.
This can be one of the most frustrating things about programming when you’re getting started. Everything has to be phrased and punctuated just so in order for the PHP engine to accept it. One thing that helps this process along is writing your programs in an editor that is PHP-aware. This is a program that, when you tell it that you are editing a PHP program, turns on some special features that make programming easier.
One of these special features is syntax highlighting. It changes the color of different parts of your program based on what those parts are. For example, strings would be pink, keywords such as if and while would be blue, comments would be grey, and variables would be black. Syntax highlighting makes it easier to detect things such as a string that’s missing its closing quote: the pink text continues past the line that the string is on, all the way to the end of the file (or the next quote that appears later in the program).
Another feature is quote and bracket matching, which helps to make sure that your pairs of quotes and brackets are balanced. When you type a closing delimiter such as }, the editor highlights the opening { that it matches. Different editors do this in different ways, but typical methods are to flash the cursor at the location of the opening {, or to bold the { } pair for a short time. This behavior is helpful for pairs of punctuation that go together: single and double quotes that delimit strings, parentheses, square brackets, and curly braces.
These editors also show the line numbers of your program files. When you get an error message from the PHP engine complaining about a parse error in line 35 in your program, you know where to look for your error.
Table 12-1 lists some PHP-aware editors. Prices are in USD and accurate at the time of writing.
PhpStorm, NetBeans, Zend Studio, and Eclipse + PDT are more like traditional integrated development environments (IDEs), whereas Sublime Text, Emacs, and Vim are more like traditional text editors—though they can easily be customized with plugins that help them understand PHP PhpStorm and Zend Studio are the most PHP-specific of these editors, while the others are made to work with many other programming languages as well. All of the non-free editors in Table 12-1 have free evaluation periods, so you can try them out to see which one is most comfortable for you.
Parse errors happen when the PHP engine comes upon something unexpected in your program. Consider the broken program in Example 12-1.
Example 12-1. A parse error
<?php
if $togged_in) {
print “Welcome, user.”;
}
?>
When told to run the code in Example 12-1, the PHP engine produces the following error message:
PHP Parse error: syntax error, unexpected ‘$logged_in’ (T_VARIABLE),
expecting ‘(‘ in welcome.php on line 2
That error message means that in line 2 of the file, the PHP engine was expecting to see an open parenthesis but instead encountered $logged_in, which it thinks is something called a T_VARIABLE. The T_VARIABLE is a token. Tokens are the PHP engine’s way of expressing different fundamental parts of programs. When the engine reads in a program, it translates what you’ve written into a list of tokens. Wherever you put a variable in your program, there is a T_VARIABLE token in the engine’s list.
So, what the PHP engine is trying to tell you with the error message is “I was reading line 2 and saw a variable named $logged_in where I was expecting an open parenthesis.” Looking at line 2 of Example 12-1, you can see why this is so: the open parenthesis that should start the if() test expression is missing. After seeing if, PHP expects a ( to start the test expression. Since that’s not there, it sees $logged_in, a variable, instead.
A list of all the tokens that the PHP engine uses (and therefore that may show up in an error message) can be found in the online PHP Manual.
The insidious thing about parse errors, though, is that the line number reported in the error message is often not the line where the error actually is. Example 12-2 has such an error in it.
Example 12-2. A trickier parse error
<?php
$first_name = “David’;
if ($togged_in) {
print “Welcome, $first_name“;
} else {
print “Howdy, Stranger.“;
}
?>
When it tries to run the code in Example 12-2, the PHP engine says:
PHP Parse error:syntax error, unexpected ‘Welcome’ (T_STRING)
in trickier.php on line 4
That error makes it seem like line 4 contains a string (Welcome) in a place where it shouldn’t. But you can scrutinize line 4 all you want to find a problem with it, and you still won’t find one. That line, print “Welcome, $first_name”;, is perfectly correct—the string is correctly delimited with double quotes and the line appropriately ends with a semicolon.
The real problem in Example 12-2 is in line 2. The string being assigned to $first_name starts with a double quote but “ends” with a single quote. As the PHP engine reads line 2, it sees the double quote and thinks, “OK, here comes a string. I’ll read everything until the next (unescaped) double quote as the contents of this string.” That makes the engine fly right over the single quote in line 2 and keep going all the way until the first double quote in line 4. When it sees that double quote, the engine thinks it’s found the end of the string. So then it considers what happens after the double quote to be a new command or statement. But what’s after the double quote is Welcome, $first_name”;. This doesn’t make any sense to the engine. It’s expecting an immediate semicolon to end a statement, or maybe a period to concatenate the just-defined string with another string. But Welcome, $first_name”; is just an undelimited string sitting where it doesn’t belong. So the engine gives up and shouts out a parse error.
Imagine you’re running down the streets of Manhattan at supersonic speed. The sidewalk on 35th Street has some cracks in it, so you trip. But you’re going so fast that you land on 39th Street and dirty the pavement with your blood and guts. Then a traffic safety officer comes over and says, “Hey! There’s a problem with 39th Street! Someone’s soiled the sidewalk with their innards!”
That’s what the PHP engine is doing in this case. The line number in the parse error is where the engine sees something it doesn’t expect, which is not always the same as the line number where the actual error is.
When you get a parse error from the engine, first take a look at the line reported in the parse error. Check for the basics, such as making sure that you’ve got a semicolon at the end of the statement. If the line seems OK, work your way forward and back a few lines in the program to hunt down the actual error. Pay special attention to punctuation that goes in pairs: single or double quotes that delimit strings, parentheses in function calls or test expressions, square brackets in array elements, and curly braces in code blocks. Count that the number of opening punctuation marks (such as (, [, and {) matches the number of closing punctuation marks (such as ), ], and }).
Situations such as this one are where a PHP-aware editor is really helpful. With syntax highlighting or bracket matching, the editor can tell you about the problem without making you have to hunt around for it. For example, if you’re reading a digital version of this book, the syntax highlighting and color coding of Example 12-2 probably made it very easy to spot the error.
Source: Sklar David (2016), Learning PHP: A Gentle Introduction to the Web’s Most Popular Language, O’Reilly Media; 1st edition.