A WordPress booking platform I built went completely white on me. No content, no visible browser error, just a blank page. I had just pasted a small helper into the theme's functions.php, copied from some notes in a document, and hit refresh. When I opened the log, this is what greeted me:
PHP Parse error: syntax error, unexpected '”' (T_STRING) in /wp-content/themes/custom-theme/functions.php on line 42The code that triggered it looked perfectly ordinary. Here is the snippet I had just pasted:
function get_listing_data( $id ) {
$type = get_post_meta( $id, “listing_type”, true );
return $type;
}Look at the second line. To my eyes in that moment, “listing_type” read like a normal string. I reread it three times and found nothing wrong. But PHP rejected it outright, and that one broken file was enough to take down the entire page.
Why this happens
The problem was not in the logic. It was in the quote characters. When I copied the snippet out of a document, the document editor had silently converted plain straight quotes into "smart quotes." What landed in my file was not " (ASCII, U+0022) but ” and “ (Unicode, U+201C and U+201D). Single quotes get the same treatment: ASCII ' becomes ‘ and ’ (U+2018 and U+2019).
To PHP, this is a disaster. The PHP parser only recognizes straight ASCII quotes as string delimiters. As far as the parser is concerned, a curly quote is not a string opener at all, it is a foreign token showing up somewhere it cannot make sense of. That is why the message reads unexpected '”'. PHP stops parsing dead, the file fails to compile, and in a production setup that hides errors, the result is a white screen of death with no clue attached.
What makes this bug nasty is that it is almost invisible. In many editor fonts, the gentle curve of a smart quote and the straight stroke of an ASCII quote look nearly identical, especially at small font sizes. Your eye reads "a quote" and your brain marks it as correct. Yet at the byte level the two characters are completely different: an ASCII quote is a single byte, while a smart quote is a multibyte UTF-8 character (three bytes). One invisible character was all it took to bring down an entire PHP file.
The fix
The core fix is trivial once you know the cause: retype the quotes as plain ASCII. I deleted both smart quotes on that line and typed them again directly in my code editor (which does no auto-correct), rather than pasting once more.
function get_listing_data( $id ) {
$type = get_post_meta( $id, 'listing_type', true );
return $type;
}After saving, the file compiled and the site came back to life. But retyping by hand only works once you know which line is at fault. While I was still groping in the dark, the fastest way to find it was to search for the character's bytes explicitly. I grepped the whole theme for the smart-quote characters directly:
grep -rn $'\xe2\x80\x9c\|\xe2\x80\x9d\|\xe2\x80\x98\|\xe2\x80\x99' wp-content/themes/Those three bytes e2 80 9c are the UTF-8 encoding of “, and so on for the other quote variants. This pointed me straight at the offending line and column instead of leaving me to guess.
If you would rather not play with bytes, there are two other routes. First, turn on "show invisibles" or special-character rendering in your editor; many editors will draw smart quotes with a slightly different glyph once you know to suspect them. Second, plenty of linters can be configured to flag non-ASCII characters in source. I ended up configuring my editor to warn whenever a smart quote or any non-ASCII character sneaks into a code file, so this can never slip in silently again.
The takeaway
The biggest lesson: never paste PHP straight from rich-text sources. Documents, word processors, and many chat apps have a habit of quietly turning straight quotes into smart quotes for the sake of nicer typography. Great for prose, poison for source code. If you must lift a snippet from somewhere like that, run it through a plain-text editor first, or just retype the quotes by hand.
And the most maddening part of a bug like this is that the code "looks" correct. There is no logic typo, no missing bracket, no forgotten semicolon. Everything reads clean, yet a single invisible multibyte character can crash the whole file and, through it, the whole site. Ever since that incident, whenever I hit an "impossible" parse error on a line that looks flawless, the first thing I suspect is a hidden character, not the code's logic.
