Main Content

Parse error: parse error, unexpected T_STRING on brand new web site - why?

Archive - Originally posted on "The Horse's Mouth" - 2012-03-03 23:30:06 - Graham Ellis

A brank new web site, written with standard commercial software, running on one of our dedicated servers which has dozens of other sites on it, with standard installs of Apache httpd, MySQL and other LAMP componets (Perl, PHP and Python) - and yet the following error:

Parse error: parse error, unexpected T_STRING in /home/httpd/vhosts/melkshammuseum.org.uk/httpdocs/index.html on line 1

What's the problem?

It turns out that the HTML of each page generated by this software starts out
  <?xml version="1.0" encoding="UTF-8"?>
and that's causing a conflict the way that our server is configured, with the .html extension being parsed as PHP across the sites we're running there, and with short tags switched on. There was indeed a suggestion that, come PHP 6, short tags would be deprecated because of confusions such as this which they can cause; that was raised in an RFC - [here], together with a suggested alternative short solution to avoid syntax getting longer to drop variables in place. However, as I understand it that RFC is not being taken forward and short tags remain as the are; I'll admit to being happy with that, even if the XML people aren't, but I take it as a warning that something may need to be changed in the future and it just might end up being the syntax of PHP.

Specifically, the lines within my configuration files that caused the issue were (in httpd.conf):
  AddType application/x-httpd-php .php .html .htm
and in php.ini:
  short_open_tag = On

And what's the solution?

"Turn short tags off across the server"?
"Remove the PHP processing from .htm and .html extensions"?

No, and no! Such changes could potentially effect dozens of sites that are running well and have been for a long time. Yes, it could be fixed on each of those sites, but by adding code to the .htaccess file on each of them - and that's repeated work. There has to be an easier way, surely? And there is:

Apache httpd's little used RemoveType directive comes to the rescue. Leave the main httpd.conf file (and files that it includes) unaltered, and add the following into the .htaccess file in the document root of the brand new web site:
  RemoveType .html .htm
So short open tags and .html expansion / checking as PHP are still running server-wide, but then the .html expansion is switched off for all files served on or below the new web site / virtual host that needed fixing.

Notes:

a) If you've not got a .htaccess file in your docuent root, you can simply create one - it's not a mandatory file, so it may not exist
b) If you want to turn PHP processing off just for a part of your website, you can put your .htaccess file into a subdirectory - indeed .htaccess files work in general in a hierarcy that gives you directory level control and flexibiity without the need to keep repeating directives at each level.

But that isn't my problem

Similar Parse error error messages are generated by PHP in other circumstances too - this is a sort of "catch all" error, so it's probable that - at some time -someone may find this page and decide that there error was NOT caused by the issue above.

If that's you:

1. Take a look at the line number in the report, (and also the file name as the error might be in an included or rewritten page) and have a look at the source code of the web page at that point.

2. Still no solution from looking at the code? Run it through the PHP intepretter on the command line and see what that chucks out at you.

You're probably into understanding / debugging PHP by now - a huge subject that we cover on our various PHP training courses, and if you're saying "but I don't know PHP" you should ask someone who does, or come on a course. If the file that you're looking at isn't supposed to be PHP at all, then take a look at your web server configuration - again, if you're pushing the bounds of your knowledge there are people who can help you, or you can attend either our Deploying LAMP course or our Linux Web Server course.