How do I know when to put the HTML tag in a PHP file?

-|Neo|- · 09-03-2007

I've just begun to learn PHP. I just would like to know when I have to put the <html></html> tags into a PHP file, and when not to put it in. Thanks!

Jolt · 09-04-2007

Anytime you are displaying content in a browser window you should have html tags.

While it's true that

PHP Code:


			
<?php
print 'Hello world';
?>

or

PHP Code:


			
<?php
echo 'Hello world';
?>

will spit out text to a browser, for proper web formatting you still need all the standard html tags. So to spit the same php out in a properly formatted web page you need the following:

PHP Code:


			
<?php
echo '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Your Page</title>
</head>
<body>
Hello world
</body>
</html>';
?>

*notjustgraphics* · 09-04-2007

Hi Guys...

It may be preferential to do the following instead:

HTML Code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Your Page</title>
</head>
<body>
  <?php echo 'Hello world';  ?>
</body>
</html>

You get far better results from search engines this way plus fewer browser incompatibilities.

NOTE: The file must be have a .php extension or you must configure your server to parse PHP code from .htm or .html files. (Usually through .htaccess)

Mike.

Jolt · 09-04-2007

Be aware that including lines of php in html files is not terribly secure. PHP should always be executable if you want to maintain security.

As for "search engines this way plus fewer browser incompatibilities" I don't understand your point at all. PHP is executed at the server level, so either way the browser (and search engines) see exactly the same code. The only difference is how secure your php code is.

*notjustgraphics* · 09-04-2007

Hi Jolt...

Search engines (especially Google) give less weight to dynamically generated pages than it does to static pages. That means pages with a php entension will rank lower than pages with a .htm or .html extension. Even if they have identical content.

Also, i've heard (never personally experienced) that some obscure and older browsers (ie: mobile, non MS/MAC OS'es etc) behave differently when the extension of the file is not the predicted .htm .html or .mob

Inline PHP is executed and parsed at the server level the same as it is in your example... to my knowledge it is no less secure. PHP Injection threats exist in both methods.

If you are suggesting the security risk is in protecting the code itself, please explain... I am not aware of any such threats and i'd really like to know what those threats are.

Mike.

Jolt · 09-04-2007

Quote:

Originally Posted by NJG

Inline PHP is executed and parsed at the server level the same as it is in your example

That's my point. There's no difference in what the browser displays. Both pages must have a .php extention therefore, if search engines rank dynamic pages lower (which, I've never heard of before. Not arguing it --- just stating that's a new one on me that doesn't make a whole lot of sense.) then both pages will be ranked the same because they both must have a .php extension to parse the code. The only difference is how the file is structured before the script spits out the page. So why not code in a more secure, better configured manner? This is generally the basis for templating systems like Smarty or even vBulletin... keep the php and html separate as much as possible in order to allow the php to spit out whats needed for the browser without embedding php code inside html code. Thinking from a serving point of view, php is parsed first, then html is sent. So it makes sense to code php with embedded html, not vice versa.

The security risk comes mainly when using includes. If your includes are not executable then can be seen in a browser, often giving away server side information that you don't want given away. For instance, if you include header.htm or header. tpl, or header.inc and it contains a bit of inline php to run a query. All one has to do is call header.xxx in a browser and they will see all the code, including the query. In your example above, if that file were an include.... and called in a browser, I could see what php is doing. In my code above, if that were an include and called in a browser, only the html would be seen. Thus protecting the php content. It's simply good practice to code all php as executable and not php lines embedded in html.

FYI, I've been using a Mac since 1984... I've never seen a case where a Mac browser refuses to parse code if the server is set up and running properly. And I've used just about every Mac browser since the birth of the modern internet. I've seen some odd things, but never a script that refuses to parse simply because a user is on a Mac. If the script fails, it fails on a PC just as easily. That is when considering php. And nowadays, with the Unix-based Mac OS, php is basically at home on the Mac OS. ASP is another matter since asp Windows based and can not run on a Mac.

I can't comment on mobile devices. I've never had an issue with php/css based sites on a mobile device. But it's impossible to test every mobile device.

In short... (finally

) .. I just meant that if you're learning php, it's better to learn the way the pros like to see it done. Why not learn the preferred manner if you're starting from scratch?

It's kind of like if you're learning to build web pages from scratch. Your time is much better spent learning css-based web building as opposed to table-based layout. Sure they both will work and it helps to understand both, but one will take you ahead into the future, the other simply lets others know you're a step or two behind your competition.

*notjustgraphics* · 09-04-2007

Quote:

Originally Posted by Jolt

Both pages must have a .php extention

That's not true at all. You can configure Apache to execute any file extension as if it were PHP (providing it contains PHP code within <?php tags.

Quote:

Originally Posted by Jolt

if search engines rank dynamic pages lower (which, I've never heard of before and would not explain current #1 listings in 99.5% of all searches)

Search engines definitely penalize dynamic urls. I was wrong to suggest that the extension .php itself would create the issue. Rather, the issue occurs when you generate pages using variables in the URL (using the ? ). For those who don't know, with PHP it is possible to pass variables from one page to another (or back to itself) using the URL. We've all seen URLs like this example: 'http://www.mysite.com/index.php?userid=1234'

Quote:

Originally Posted by Jolt

So why not code in a more secure, better configured manner?

I agree, this is the preferred method. I'm not sure i agree that it is more secure, but it is definitely the better practice. However, it's not practical in many cases, especially the 'Hello World' application where you would be increasing server load and page load time to output a simple string of text.

Quote:

Originally Posted by Jolt

The security risk comes mainly when using includes. If your includes are not executable then can be seen in a browser, often giving away server side information that you don't want given away. For instance, if you include header.htm or header. tpl, or header.inc and it contains a bit of inline php to run a query. All one has to do is call header.xxx in a browser and they will see all the code, including the query. In your example above, if that file were an include.... and called in a browser, I could see what php is doing. In my code above, if that were an include and called in a browser, only the html would be seen. Thus protecting the php content. It's simply good practice to code all php as executable and not php lines embedded in html.

Yes, you're absolutely right although the name of the included filename is never revealed... you would either have to KNOW the filename and it's location or be able to surf the open directories to view the files. In any case, your method is preferable in that situation but does not apply to the 'Hello World' example.

Quote:

Originally Posted by Jolt

FYI, I've been using a Mac since 1984... I've never seen a case where a Mac browser refuses to parse code if the server is set up and running properly. And I've used just about every Mac browser since the birth of the modern internet. I've seen some odd things, but never a script that refuses to parse simply because a user is on a Mac. If the script fails, it fails on a PC just as easily. That is when considering php. And nowadays, with the Unix-based Mac OS, php is basically at home on the Mac OS. ASP is another matter since asp Windows based and can not run on a Mac.

I never said Mac's were a problem... i said Non MS/MAC OS's meaning machines running an OS OTHER than Microsoft or MAC OS... mainly this issue (to my knowledge) comes into play with Mobile Browsers... especially early versions.

Quote:

Originally Posted by Jolt

I can't comment on mobile devices. I've never had an issue with php/css based sites on a mobile device. But it's impossible to test every mobile device.

Neither have I... i've only heard of these issues on forums... The PSP's first browser version exhibited this issue I believe.

Quote:

Originally Posted by Jolt

In short... (finally

) .. I just meant that if you're learning php, it's better to learn the way the pros like to see it done. Why not learn the preferred manner if you're starting from scratch?

If you have the time and your project requires such a degree of development, than absolutely! Do it right! However, if you're creating a personal website and want to create a widget to display the current date, you don't necessarily need to create that much additional work. Not to mention the increase in server load is not necessary.

Mike.

Jolt · 09-05-2007

I know google does devalue anything after a variable passed in the url. In fact, most times, it will only even track 2 or 3 variables in the URL so content may not even be seen. But simply adding a .php extension doesn't devalue the page. It's only pages passed with variables that get devalued. You can use global variables, sessions, or other methods to avoid using the URL to pass variables between scripts.

*notjustgraphics* · 09-05-2007

Thanks Jolt!

Everything i've read advises against using Globals... and in some cases I know certain servers won't allow it, so I usually use sessions if data needs to be passed...