PHP snag when using strange quotes

Question

Copying a mySQL-driven application and its web-pages (in PHP) I spent 2 days of time debugging the problem exemplified by code below. The 2 "didn't work" comment of course do not apply to the source server (where everything works OK) but do apply to the destination server where nothing works! The web pages make use indiscriminately a mixture of single (hex 27), double (hex 22) and "funny" (hex e2 80 99).

What can I do? "sed'ing" every page would be easy but what about next time when I have to re-migrate again these pages?

Thank you very much!

<?php

  echo "Welcome to a quote adventure<BR><HR>";

  $_SESSION['number1']=1;
  $_SESSION['number2']=2;
  $_SESSION['number3']=3;

  echo "my number1 (single-to-single quotes) is: ".$_SESSION['number1']."<BR>";
  echo "my number2 (single-to-double quotes) is: ".$_SESSION["number2"]."<BR>";
  echo "my number3 (single-to-funny quotes) is: ".$_SESSION[’number3’]."-------didn't work!<HR>";
 
  $_SESSION["number1"]=1;
  $_SESSION["number2"]=2;
  $_SESSION["number3"]=3;

  echo "my number1 (double-to-single quotes) is: ".$_SESSION['number1']."<BR>";
  echo "my number2 (double-to-double quotes) is: ".$_SESSION["number2"]."<BR>";
  echo "my number3 (double-to-funny quotes) is: ".$_SESSION[’number3’]."-------didn't work!<HR>";
 
  $_SESSION[’number1’]=1;
  $_SESSION[’number2’]=2;
  $_SESSION[’number3’]=3;

  echo "my number1 (funny-to-single quotes) is: ".$_SESSION['number1']."<BR>";
  echo "my number2 (funny-to-double quotes) is: ".$_SESSION["number2"]."<BR>";
  echo "my number3 (funny-to-funny quotes) is: ".$_SESSION[’number3’]."-------worked!<HR>";
?>

I was expecting the web pages to work unmodified also on the destination server

Answer 1

If you've changed servers and didn't review PHP settings thoroughly, it's very likely that you're relying on defaults that have changed, in particular the ones related to error reporting. Your code was never fully correct, it worked partially by pure chance, but you've only realised now.

PHP has been hardening some error conditions because they were a source of frustrating bugs and didn't really serve any purpose. In particular, reading from a non-existing constant has been promoted from notice to warning:

1. Early PHP: assume you missed quotes and actually wanted a string, trigger notice.
2. PHP/7.2: same assumption, trigger warning.
3. PHP/8.0: no more guessing, trigger fatal error.

... key difference being that fatal errors abort the script, thus cannot be easily missed or ignored.

How does this non-existing constant issue apply here? Well, turns out that ’ is a valid identifier for constants, as long as you don't use it in a location where the parser chokes:

define('’a’', 'example');
$foo = ['example' => 'OK'];
var_dump(’a’, $foo[’a’]);

string(7) "example"
string(2) "OK"

Demo