Greetings, and thanx in advance for all time & effort.
Installed & using "xampp"
Using Kevin Yank's "PHP & MySQL: Novice to Ninja"
** *<meta charset="utf-8">
** *<title>Today’s Date</title>
** *<p>Today’s date (according to this web server) is
** * *<?php
** * *echo date('l, F jS Y.');
** * *?>
The html, in a html file works, the php in a php file works, but the total in a html file ignores the php.
You can only use HTML in an HTML file, you can use HTML + PHP in a PHP file.
That is entirely based on server setup, but that is generally true (you can setup .html to run against php although that is usually ill-advised.
Rename your html file (the one that contains both html and php to have a .php extension and it will work.
Why would having your HTML file run PHP be ill-advised?
Typically changing the behavior of an extension is ill-advised (as the purpose for doing it, is unnecessary). From a disaster recovery scenario you are adding a step that really isn't needed (the need to change the behavior of an extension so it performs differently).
On an Apache environment, sure you can use an .htaccess file to do it, so it is deployable with your code (not certain you can do that with IIS).
I guess my point is, changing the default behavior of an extension is an unnecessary step since there are extensions that already support what you want to do.
Now don't take my statement to mean you shouldn't perform
// accessed by calling index.php
and your mytemplate.html may very well include php tags.
My statement is directly against using index.html as your serving page and index.html contains php tags and must go through the php parser first (not a default behavior).
So your concern is a performance issue? It forces another step in the process?
How much of a delay in loading the page is caused by this?
No my concern is the not obvious execution of an already defined extension (html). HTML by design does not get parsed server side. It would be like changing an .asp extension to execute against PHP. You can do it, but should you? Or a .cgi to execute against php.
Got it. It now makes sense to this thick headed old man.
Don't get me wrong, it is entirely of my own opinion and everyone can do as they wish. Also, one other small tid-bit, if you were to allow .html to run the php parser, you are in a sense slowing down html pages that have no php in them, as they are still being forced to run through the php parser first (small hit on performance, but it is a hit nonetheless).
I'd suggest there's also a usability/management issue. If another developer looks at the site, they'll see a .html file and assume it's flat HTML. This can cause a headache when it comes to tracking down code, debugging and will cause an issue if moved to another server.
This topic is now closed. New replies are no longer allowed.