Make all pages .php?

[Bruce W...1]

This is a best practices question.

For a website where PHP is used, does it make sense to have both .htm and .php
files? In other words, for pages that have no active content there's no point
in naming them with a .php extension.

Is there any advantage or disadvantage to making all files .php, or the same for
mixing them with .htm files?

What do you do, and why?

Thanks for your input.

[Andy Jeffries]

On Wed, 17 Sep 2003 10:52:52 -0400, Bruce W...1 wrote:

This is a best practices question.

For a website where PHP is used, does it make sense to have both .htm and .php
files? In other words, for pages that have no active content there's no point
in naming them with a .php extension.

Is there any advantage or disadvantage to making all files .php, or the same for
mixing them with .htm files?
Slight speed disadvantage to making all files .php.
What do you do, and why?

Make everything a .phtml file (set up in Apache to be the same as .php).

The speed disadvantage is unnoticable and it means if I have to add some
dynamic content to a page I don't have to change every link to it.

However, my recent sites are virtually object generated so every page has
objects in it that form the layout.

Cheers,
Andy

[Jean-Baptiste Nizet]

Bruce W...1 wrote:

This is a best practices question.

For a website where PHP is used, does it make sense to have both .htm and .php
files? In other words, for pages that have no active content there's no point
in naming them with a .php extension.

Is there any advantage or disadvantage to making all files .php, or the same for
mixing them with .htm files?

What do you do, and why?

All my pages are PHP

Here are my reasons:
- I'm using sessions. If the user only plays with .htm URLs for a small
period, the session will expire, and it shouldn't expire since the user
is still using the site.
- If the user doesn't support cookies, the session ID will be
transmitted by PHP in URLs (URL rewriting). Plain HTML pages will thus
lose the session.
- I use PHP to have a coherent look for all the pages. The header, left
menu, right menu and footer of all the pages are the same, and are each
defined in their own single PHP file, which are included by PHP. Using
HTML would force me to hardcode all these parts in every HTML page,
which would lead to a maintenance nightmare.

JB.
Thanks for your input.

[Martin Lucas-Smith]

This is a best practices question.

For a website where PHP is used, does it make sense to have both .htm
and .php files? In other words, for pages that have no active content
there's no point in naming them with a .php extension.

Is there any advantage or disadvantage to making all files .php, or the
same for mixing them with .htm files?

I am a strong believer that, for best practice, one should never use .php
but use .html instead. Certainly using a mixture is asking for trouble.
The same applies to nasty extensions like .php3, .php4, .phtml and the
like.

Using .php advertises your server technology, is less familiar to people
if you are having to print an address, results in you having to change all
your URLs if you then decide to change to some other technology, and can
result in a mixture of .html and .php. Also, if you then decide to add
bits of PHP to an existing .html file you don't then have to change the
URL (and mess about with redirections).

Given that many sites these days will be using PHP for some sort of house
style use (as well as anything else..) PHP will, by definition, need to be
parsing most if not all files. Therefore, set .html to be parsed for PHP.

I've never encountered any noticable performance hit, even on sites that
barely make use of the PHP parser. I dare say there might be on an
extremely busy site, but I suspect most people would never run into that
and the above maintenance advantages outweigh the disadvantages.

Just add

AddType application/x-httpd-php .html

to your .htaccess file or Apache config. What could be simpler?
Martin Lucas-Smith www.geog.cam.ac.uk/~mvl22
www.lucas-smith.co.uk

[Bruce W...1]

Martin Lucas-Smith wrote:

I am a strong believer that, for best practice, one should never use .php
but use .html instead. Certainly using a mixture is asking for trouble.
The same applies to nasty extensions like .php3, .php4, .phtml and the
like.

Using .php advertises your server technology, is less familiar to people
if you are having to print an address, results in you having to change all
your URLs if you then decide to change to some other technology, and can
result in a mixture of .html and .php. Also, if you then decide to add
bits of PHP to an existing .html file you don't then have to change the
URL (and mess about with redirections).

Given that many sites these days will be using PHP for some sort of house
style use (as well as anything else..) PHP will, by definition, need to be
parsing most if not all files. Therefore, set .html to be parsed for PHP.

I've never encountered any noticable performance hit, even on sites that
barely make use of the PHP parser. I dare say there might be on an
extremely busy site, but I suspect most people would never run into that
and the above maintenance advantages outweigh the disadvantages.
================================================== ===========

That makes sense, but how do you set .html to be parsed for PHP? I'm using IIS
on Windows 2000. I suspect this is done in IIS?

If that's the case I'm screwed because I use a hosting company (also running Win
2000) and they would not let me access the IIS settings. But perhaps they
already have it setup this way, I'll ask.

Thanks. Just add

AddType application/x-httpd-php .html

to your .htaccess file or Apache config. What could be simpler?

Martin Lucas-Smith www.geog.cam.ac.uk/~mvl22
www.lucas-smith.co.uk

[Bruce W...1]

Jean-Baptiste Nizet wrote:

All my pages are PHP

Here are my reasons:
- I'm using sessions. If the user only plays with .htm URLs for a small
period, the session will expire, and it shouldn't expire since the user
is still using the site.
- If the user doesn't support cookies, the session ID will be
transmitted by PHP in URLs (URL rewriting). Plain HTML pages will thus
lose the session.
- I use PHP to have a coherent look for all the pages. The header, left
menu, right menu and footer of all the pages are the same, and are each
defined in their own single PHP file, which are included by PHP. Using
HTML would force me to hardcode all these parts in every HTML page,
which would lead to a maintenance nightmare.

JB.

================================================== =========

Very good point. The session state is an overwhelming reason.

I'm new to PHP. Can you point me to information on how to put the common page
elements in separate files, assuming you are not using frames? Can this be done
without using frames?

I know that a similar ability is done with ASP.NET User Controls.

Thanks.

[Jeff Skeith]

bruce, i'm pretty new to php, however, i use php includes to keep my
repetitive html code in one location (ex, header, menu bars, footer).
since all my pages use includes, they have are .php.

if you aren't using includes for repetitive html code, i recommend you
do so.

if you hve straight html, my bet is to not to use .php if you have no
php code b/c it doesn't make sense to send those pages to the php
processor - that's inefficient.

"Bruce W...1" <br***@noDirectEmail.com> wrote in message news:<3F***************@noDirectEmail.com>...

This is a best practices question.

For a website where PHP is used, does it make sense to have both .htm and .php
files? In other words, for pages that have no active content there's no point
in naming them with a .php extension.

Is there any advantage or disadvantage to making all files .php, or the same for
mixing them with .htm files?

What do you do, and why?

Thanks for your input.

[Jeff Skeith]

bruce, it works like this...

<?PHP

INCLUDE ('includes/logoHeader.inc.php');

INCLUDE ('includes/hNavBar.inc.php');

INCLUDE ('includes/vNavBar.inc.php');

?>

i have three files in a my include folder. One for the header, one
for the horizontal navigation bar and one for the vertical one.

just put your plain old vanilla html code into the logoHeader.inc.php
file. php will bring it in as is.

i put these "includes" on every page.

"Bruce W...1" <br***@noDirectEmail.com> wrote in message news:<3F***************@noDirectEmail.com>...

Jean-Baptiste Nizet wrote:

All my pages are PHP

Here are my reasons:
- I'm using sessions. If the user only plays with .htm URLs for a small
period, the session will expire, and it shouldn't expire since the user
is still using the site.
- If the user doesn't support cookies, the session ID will be
transmitted by PHP in URLs (URL rewriting). Plain HTML pages will thus
lose the session.
- I use PHP to have a coherent look for all the pages. The header, left
menu, right menu and footer of all the pages are the same, and are each
defined in their own single PHP file, which are included by PHP. Using
HTML would force me to hardcode all these parts in every HTML page,
which would lead to a maintenance nightmare.

JB.

================================================== =========

Very good point. The session state is an overwhelming reason.

I'm new to PHP. Can you point me to information on how to put the common page
elements in separate files, assuming you are not using frames? Can this be done
without using frames?

I know that a similar ability is done with ASP.NET User Controls.

Thanks.

[Bruce W...1]

No my hosting company does not have IIS set for PHP to parse HTML files, though
I can request this.

If you really want to hide your technology there's an easier way. At your
domain registrar have the name server forward with masking. This hides all file
names.

[Bruce W...1]

Thanks. I'm now learning about this, it's a very good idea. Never realized
that includes can be used with straight html files as well. I thought it was
just an ASP thing. In ASP.NET they are now called User Controls.

[Jeff Skeith]

bruce, why not go with apache? it is pretty simple to set up on
windows. do a google for apache install tutorial on win2000. php was
designed to work with apache.

also, i kinda like the idea of making html files automatically go to
the php processor. i think i'll set my site up like that in which
case all my files will be html and all will be php processed since
that's a requirement anyway due to my include statements.

"Bruce W...1" <br***@noDirectEmail.com> wrote in message news:<3F***************@noDirectEmail.com>...

Martin Lucas-Smith wrote:

I am a strong believer that, for best practice, one should never use .php
but use .html instead. Certainly using a mixture is asking for trouble.
The same applies to nasty extensions like .php3, .php4, .phtml and the
like.

Using .php advertises your server technology, is less familiar to people
if you are having to print an address, results in you having to change all
your URLs if you then decide to change to some other technology, and can
result in a mixture of .html and .php. Also, if you then decide to add
bits of PHP to an existing .html file you don't then have to change the
URL (and mess about with redirections).

Given that many sites these days will be using PHP for some sort of house
style use (as well as anything else..) PHP will, by definition, need to be
parsing most if not all files. Therefore, set .html to be parsed for PHP.

I've never encountered any noticable performance hit, even on sites that
barely make use of the PHP parser. I dare say there might be on an
extremely busy site, but I suspect most people would never run into that
and the above maintenance advantages outweigh the disadvantages.

================================================== ===========

That makes sense, but how do you set .html to be parsed for PHP? I'm using IIS
on Windows 2000. I suspect this is done in IIS?

If that's the case I'm screwed because I use a hosting company (also running Win
2000) and they would not let me access the IIS settings. But perhaps they
already have it setup this way, I'll ask.

Thanks.

Just add

AddType application/x-httpd-php .html

to your .htaccess file or Apache config. What could be simpler?

Martin Lucas-Smith www.geog.cam.ac.uk/~mvl22
www.lucas-smith.co.uk

[Adams-Blake Co.]

Jean-Baptiste Nizet wrote:

Is there any advantage or disadvantage to making all files .php, or the
same for mixing them with .htm files?

What do you do, and why?

All my pages are PHP

Here are my reasons:
- I'm using sessions. If the user only plays with .htm URLs for a small
period, the session will expire, and it shouldn't expire since the user
is still using the site.

I have to question this. Where is this documented? I did some testing. I have
a aaaa.php page with a pop-up link (_blank) that passes a querystring to
bbb.php page which does a header redirect to an myhelp.html "help" screen. I
can close the pop-up and my session variables have not gone away and my
application continues to function normally

Even if I had a link from a php page to an .html page, I don't see where the
server would know to cancel the session.

I'm not saying you are wrong, its just that I have not experienced this. Have
others?

Al


- If the user doesn't support cookies, the session ID will be
transmitted by PHP in URLs (URL rewriting). Plain HTML pages will thus
lose the session.
- I use PHP to have a coherent look for all the pages. The header, left
menu, right menu and footer of all the pages are the same, and are each
defined in their own single PHP file, which are included by PHP. Using
HTML would force me to hardcode all these parts in every HTML page,
which would lead to a maintenance nightmare.

JB.

Thanks for your input.

[Jean-Baptiste Nizet]

Adams-Blake Co. wrote:

Jean-Baptiste Nizet wrote:

Is there any advantage or disadvantage to making all files .php, or the
same for mixing them with .htm files?

What do you do, and why?

All my pages are PHP

Here are my reasons:
- I'm using sessions. If the user only plays with .htm URLs for a small
period, the session will expire, and it shouldn't expire since the user
is still using the site.

I have to question this. Where is this documented? I did some testing. I have
a aaaa.php page with a pop-up link (_blank) that passes a querystring to
bbb.php page which does a header redirect to an myhelp.html "help" screen. I
can close the pop-up and my session variables have not gone away and my
application continues to function normally

Even if I had a link from a php page to an .html page, I don't see where the
server would know to cancel the session.

I'm not saying you are wrong, its just that I have not experienced this. Have
others?

Al

It's simple. Here's how sessions work: each time session_start() is
called, PHP updates a timestamp associated with the session ID contained
in the session cookie (or in the URL is URL rewriting is used). If
session_start() is not called for, let's say 20 minutes, and if PHP is
configured to time out sessions after, let's say 10 minutes, then the
next time session_start() is called, the session has been removed.
So, if during the 20 minutes you're still browsing the web site without
calling any PHP page, session_start() will never be called, and the
session will be lost.

look at http://www.php.net/manual/en/ref.session.php for more details.

JB.

[Tim Tyler]

Martin Lucas-Smith <mv***@cam.ac.uk> wrote:

: I am a strong believer that, for best practice, one should never use .php
: but use .html instead. Certainly using a mixture is asking for trouble.
: The same applies to nasty extensions like .php3, .php4, .phtml and the
: like.

: Using .php advertises your server technology, is less familiar to people
: if you are having to print an address, results in you having to change all
: your URLs if you then decide to change to some other technology, and can
: result in a mixture of .html and .php.

Using:

DirectoryIndex index.html index.jsp index.shtml index.php index.htm

....in Apache encapsulates the server-side technology you use fairly well.

Using URLs with .php in them seems like a questionable practice to me -
but then so it using URLs with .html in them - for the same reason.

I don't think using the ".html" file extension for PHP files is a good
way to deal with the issue.
--
__________
|im |yler http://timtyler.org/ ti*@tt1.org

[Martin Lucas-Smith]

i put these "includes" on every page.

Consider using auto_prepend_file and auto_append_file in your .htaccess
file or Apache config if you are using Apache, to save yourself the
bother. Then your actual pages need only be content without having server
includes all over the place.

www.webmasterworld.com/forum88/421.htm

has some further info.

Martin Lucas-Smith www.geog.cam.ac.uk/~mvl22
www.lucas-smith.co.uk

[Martin Lucas-Smith]

If you really want to hide your technology there's an easier way. At
your domain registrar have the name server forward with masking. This
hides all file names.

All this does is create a 100%-size frame, which prevents users
bookmarking your pages, creates issues for search engines, results in your
site being listed by search under the 'real' domain name rather than the
masked name, and is trivial to break out of to find the real file names.

Martin Lucas-Smith www.geog.cam.ac.uk/~mvl22
www.lucas-smith.co.uk

[Martin Lucas-Smith]

Using:
DirectoryIndex index.html index.jsp index.shtml index.php index.htm

...in Apache encapsulates the server-side technology you use fairly
well.
No it doesn't - that merely avoids you having to specify a filename for
the default file in a directory, i.e.

www.site.com/directory/
rather than
www.site.com/directory/index.html

(which is good practice in itself, not least as you can then just link to
"/directory/" rather than "/directory/index.html".)
Using URLs with .php in them seems like a questionable practice to me -
but then so it using URLs with .html in them - for the same reason.

Sorry, I don't see your point.

Don't forget, if you really want to hide your server technology, you
should also prevent your server spewing it out in the HTTP headers.

http://webtools.mozilla.org/web-snif...geog.cam.ac.uk

for instance gives no indication whatsoever that that site is using PHP.

Do this by setting
expose_php = Off
in your php.ini or presumably
php_flag expose_php Off

(Personally I believe the developers should switch this off by default.)
Martin Lucas-Smith www.geog.cam.ac.uk/~mvl22
www.lucas-smith.co.uk

[Adams-Blake Co.]

Jean-Baptiste Nizet wrote:

Adams-Blake Co. wrote:

Jean-Baptiste Nizet wrote:

Is there any advantage or disadvantage to making all files .php, or the
same for mixing them with .htm files?

What do you do, and why?
All my pages are PHP

Here are my reasons:
- I'm using sessions. If the user only plays with .htm URLs for a small
period, the session will expire, and it shouldn't expire since the user
is still using the site.

I have to question this. Where is this documented? I did some testing. I
have
a aaaa.php page with a pop-up link (_blank) that passes a querystring to
bbb.php page which does a header redirect to an myhelp.html "help" screen.
I can close the pop-up and my session variables have not gone away and my
application continues to function normally

Even if I had a link from a php page to an .html page, I don't see where
the server would know to cancel the session.

I'm not saying you are wrong, its just that I have not experienced this.
Have others?

Al

It's simple. Here's how sessions work: each time session_start() is
called, PHP updates a timestamp associated with the session ID contained
in the session cookie (or in the URL is URL rewriting is used). If
session_start() is not called for, let's say 20 minutes, and if PHP is
configured to time out sessions after, let's say 10 minutes, then the
next time session_start() is called, the session has been removed.
So, if during the 20 minutes you're still browsing the web site without
calling any PHP page, session_start() will never be called, and the
session will be lost.

look at http://www.php.net/manual/en/ref.session.php for more details.

JB.

Yes, JB. You are right. I see what you mean. But in your earlier post you
seemed to be saying that by going to a html page you would lose your session.
The only reason you would loose the session is if you stayed on the page too
long. That's the same if you link to a .PHP page. The difference is that you
get an extra amount of time on a php page because the time stamp will be
updated.

But in actual practice it probably won't make much difference. If you come
into page1.php at 12:00 noon. You stay on the page one minute. You click a
link to pageA.html and stay on that for 3 minutes. You come back to page1.php
you still have plenty of time.

If you spend 30 minutes on page2.html, you will lose your session.

The big difference is if you spent 19 minutes on page1.php and then went off
to page2.HTML. you would not update the clock and only have a few minutes.

So, yes I see where you are coming from on this. So what you are saying is
that if we have mostly html pages, we should still have a
<?php
session_start();
?>

<html>
<head>
<body>
etc.

that starts off the page and make it a .php and not a html page, correct?

Al

[D K Woods]

But in actual practice it probably won't make much difference. If you come
into page1.php at 12:00 noon. You stay on the page one minute. You click a
link to pageA.html and stay on that for 3 minutes. You come back to page1.php
you still have plenty of time.

If you spend 30 minutes on page2.html, you will lose your session.

I didn't read it as spending X time on *one* .html page, but that the
problem arises on a site with some .php and some .html, when a user doesn't
happen to return to a .php page before the session expires. He could be
happily jumping from page to page to page, and if he just never happens to
hit a .php page the session's gone.

One way to avoid this is to create a php file named 'session_refresh.php':

<?
session_start();
?>

Then in all you non-php .html files, just call it like this:
<SCRIPT LANGUAGE=Javascript SOURCE="session_refresh.php"></SCRIPT>

As far as the script tag is concerned it's an empty file and gets ignored
but it still runs the php.

Though you might run into problems if the user doesn't have cookies
enabled. I'm not sure about the specifics of URL rewriting. Has anyone
tried this option?

david
--
It is of interest to note that while some dolphins are reported to have
learned English -- up to 50 words used in correct context -- no human being
has been reported to have learned dolphinese.
-- Carl Sagan
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

[Gerhard Fiedler]

On Thu, 18 Sep 2003 09:39:06 -0500, D K Woods wrote:

One way to avoid this is to create a php file named 'session_refresh.php':

<?
session_start();
?>

Then in all you non-php .html files, just call it like this:
<SCRIPT LANGUAGE=Javascript SOURCE="session_refresh.php"></SCRIPT>

As far as the script tag is concerned it's an empty file and gets ignored
but it still runs the php.

are you sure that this gets run as php? even though the "master" file
is html? looks kind of strange, in terms of control of whether or not
a file gets interpreted.

[Phil Roberts]

With total disregard for any kind of safety measures Gerhard
Fiedler <[e-mail]> leapt forth and uttered:

On Thu, 18 Sep 2003 09:39:06 -0500, D K Woods wrote:

One way to avoid this is to create a php file named
'session_refresh.php':

<?
session_start();
?>

Then in all you non-php .html files, just call it like this:
<SCRIPT LANGUAGE=Javascript
SOURCE="session_refresh.php"></SCRIPT>

As far as the script tag is concerned it's an empty file and
gets ignored but it still runs the php.

are you sure that this gets run as php? even though the "master"
file is html? looks kind of strange, in terms of control of
whether or not a file gets interpreted.

<script> tag links are just making a normal HTTP request for the
file, so if you specify a PHP file then it will be executed.

--
There is no signature.....

[John Dunlop]

Phil Roberts wrote:

<script> tag links are just making a normal HTTP request for the
file, so if you specify a PHP file then it will be executed.

Possibly. But heed the familiar caveat: this falls flat on its face
with user agents that do not or will not support scripting.

--
Jock

[Jeff Skeith]

fyi... check with you hosting company. my host won't send html files
through php so that means i must use php extensions.
js******@san.rr.com (Jeff Skeith) wrote in message news:<ce*************************@posting.google.c om>...

bruce, why not go with apache? it is pretty simple to set up on
windows. do a google for apache install tutorial on win2000. php was
designed to work with apache.

also, i kinda like the idea of making html files automatically go to
the php processor. i think i'll set my site up like that in which
case all my files will be html and all will be php processed since
that's a requirement anyway due to my include statements.

"Bruce W...1" <br***@noDirectEmail.com> wrote in message news:<3F***************@noDirectEmail.com>...

Martin Lucas-Smith wrote:

I am a strong believer that, for best practice, one should never use .php
but use .html instead. Certainly using a mixture is asking for trouble.
The same applies to nasty extensions like .php3, .php4, .phtml and the
like.

Using .php advertises your server technology, is less familiar to people
if you are having to print an address, results in you having to change all
your URLs if you then decide to change to some other technology, and can
result in a mixture of .html and .php. Also, if you then decide to add
bits of PHP to an existing .html file you don't then have to change the
URL (and mess about with redirections).

Given that many sites these days will be using PHP for some sort of house
style use (as well as anything else..) PHP will, by definition, need to be
parsing most if not all files. Therefore, set .html to be parsed for PHP.

I've never encountered any noticable performance hit, even on sites that
barely make use of the PHP parser. I dare say there might be on an
extremely busy site, but I suspect most people would never run into that
and the above maintenance advantages outweigh the disadvantages.

================================================== ===========

That makes sense, but how do you set .html to be parsed for PHP? I'm using IIS
on Windows 2000. I suspect this is done in IIS?

If that's the case I'm screwed because I use a hosting company (also running Win
2000) and they would not let me access the IIS settings. But perhaps they
already have it setup this way, I'll ask.

Thanks.

Just add

AddType application/x-httpd-php .html

to your .htaccess file or Apache config. What could be simpler?

Martin Lucas-Smith www.geog.cam.ac.uk/~mvl22
www.lucas-smith.co.uk

[Tim Tyler]

Martin Lucas-Smith <mv***@cam.ac.uk> wrote or quoted:

Using URLs with .php in them seems like a questionable practice to me -
but then so it using URLs with .html in them - for the same reason.
Sorry, I don't see your point.

URLs are part of the public API of your web site.

If you expose the server-side technology you are using, you lose the
opportunity to change it at a later date - without breaking existing
links.
Don't forget, if you really want to hide your server technology, you
should also prevent your server spewing it out in the HTTP headers.

I don't mind the occasional:

Server: Apache/1.3.28 (Unix) PHP/4.3.3
X-Powered-By: PHP/4.3.3

....or two in my HTTP headers ;-)
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.

[Andy Jeffries]

On Tue, 30 Sep 2003 10:36:10 +0000, Tim Tyler wrote:

URLs are part of the public API of your web site.

If you expose the server-side technology you are using, you lose the
opportunity to change it at a later date - without breaking existing
links.

RewriteEngine on
RewriteRule ^(.*)\.html $1.php [R]

That should do it. That way you can easily change your server technology
and people coming from bookmarks will get redirected.

Cheers,
Andy

[Martin Lucas-Smith]

Using URLs with .php in them seems like a questionable practice to me -
but then so it using URLs with .html in them - for the same reason.

Sorry, I don't see your point.

URLs are part of the public API of your web site.

If you expose the server-side technology you are using, you lose the
opportunity to change it at a later date - without breaking existing
links.

That was my point entirely - .html isn't specific to any particular
technology and is preferable to using .php (especially when the site is
substantially making use of PHP parsing on most page)

(Good point about the API - I'd never really considered it in those terms,
but you're absolutely correct.)

Don't forget, if you really want to hide your server technology, you
should also prevent your server spewing it out in the HTTP headers.

I don't mind the occasional:

Server: Apache/1.3.28 (Unix) PHP/4.3.3
X-Powered-By: PHP/4.3.3

...or two in my HTTP headers ;-)

Neither does anyone trying to hack your server :)
Martin Lucas-Smith www.geog.cam.ac.uk/~mvl22
www.lucas-smith.co.uk

[jim]

Question......(assumption-->AddType application/x-httpd-php .html)
Is the php parser/interpreter invoked only when <?php is encountered on
a web page? Or does it scan all accessed .html docs regardless of
existing php code on that page?
Martin Lucas-Smith wrote:

Using URLs with .php in them seems like a questionable practice to me -
but then so it using URLs with .html in them - for the same reason.

Sorry, I don't see your point.

URLs are part of the public API of your web site.

If you expose the server-side technology you are using, you lose the
opportunity to change it at a later date - without breaking existing
links.

That was my point entirely - .html isn't specific to any particular
technology and is preferable to using .php (especially when the site is
substantially making use of PHP parsing on most page)

(Good point about the API - I'd never really considered it in those terms,
but you're absolutely correct.)

Don't forget, if you really want to hide your server technology, you
should also prevent your server spewing it out in the HTTP headers.

I don't mind the occasional:

Server: Apache/1.3.28 (Unix) PHP/4.3.3
X-Powered-By: PHP/4.3.3

...or two in my HTTP headers ;-)

Neither does anyone trying to hack your server :)
Martin Lucas-Smith www.geog.cam.ac.uk/~mvl22
www.lucas-smith.co.uk

[Tim Tyler]

Andy Jeffries <ne**@andyjeffries.remove.co.uk> wrote or quoted:

On Tue, 30 Sep 2003 10:36:10 +0000, Tim Tyler wrote:

URLs are part of the public API of your web site.

If you expose the server-side technology you are using, you lose the
opportunity to change it at a later date - without breaking existing
links.

RewriteEngine on
RewriteRule ^(.*)\.html $1.php [R]

That will redirect EVERY .html page request to fetch a .php page.
That should do it. That way you can easily change your server technology
and people coming from bookmarks will get redirected.

I guess I don't see what reason there is for making the mistake in the
first place and then patching things up retrospectively with an ugly hack
- or an ugly sequence of hacks if you can't transform your whole site
at once - or are using a mixture of page technologies.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.

[Martin Lucas-Smith]

Question......(assumption-->AddType application/x-httpd-php .html) Is
the php parser/interpreter invoked only when <?php is encountered on a
web page? Or does it scan all accessed .html docs regardless of existing
php code on that page?

My understanding is that it will scan it (well, it has to...) but that the
interpreter presumably won't get invoked.

I've found that, even with a fairly busy server serving 30 virtualHosts
covering 10,000 real pages, Apache still takes a mere fraction of system
resources to serve this, with all .html files being parsed for PHP. OK, on
a major international site maybe that wouldn't apply, but I suggest it
will be good enough for the vast majority of uses.
Martin Lucas-Smith www.geog.cam.ac.uk/~mvl22
www.lucas-smith.co.uk

[Justin Koivisto]

Martin Lucas-Smith wrote:

This is a best practices question.

For a website where PHP is used, does it make sense to have both .htm
and .php files? In other words, for pages that have no active content
there's no point in naming them with a .php extension.

Is there any advantage or disadvantage to making all files .php, or the
same for mixing them with .htm files?
I am a strong believer that, for best practice, one should never use .php
but use .html instead. Certainly using a mixture is asking for trouble.
The same applies to nasty extensions like .php3, .php4, .phtml and the
like.

I, on the otherhand believe that you shouldn't use an extension.
Using .php advertises your server technology, is less familiar to people
if you are having to print an address, results in you having to change all
your URLs if you then decide to change to some other technology, and can
result in a mixture of .html and .php. Also, if you then decide to add
bits of PHP to an existing .html file you don't then have to change the
URL (and mess about with redirections).
This is my reasoning... Say I have 5 pages on my site:
index.html - the home page
contact.html - contact information
products.html - listing of the products I sell
quotes.html - email quote form results to me
search.html - site search using Google's site:domain stuff

---
Now, I have decided that my contact page needs a form to email me, so I
use formmail.pl...
---
Yuk, I don't like that so now I decide to write a PHP script instead.
Now my page and all links need to be changed to contact.php
---
Uh oh, I have too many products to add to do updates manually all the
time, let's look at PHP/MySQL.. --> products.php
---
Now I am updating 2 databases for my products! I use MS SQL in-house, so
I'll connect to that from the website. Damn, my host doesn't support MS
SQL in PHP... however, they do have ASP as well... --> products.asp
---
Damn, need to change my form to mail script to asp as well! --> contact.asp
---
I need a better way to handle all these messages about quotes, dump to
database, and have in-house software dole it out the the lemmings -->
quotes.asp
---
Hmm, this search would be great if I could search for in-stock items
first... search.asp
---
My host can blow themselves! Need to switch to a more reliable company.
What? No ASP... well, at least there's JSP -->
index.html - the home page
contact.jsp - contact information
products.jsp - listing of the products I sell
quotes.jsp - email quote form results to me
search.jsp - new site search
---
really need to separate the products -->
products.jsp?category=xx&prod_num=xx

(I think you see the pattern here...)

Now, if I had done this differently, I would have started by using
something to avoid showing file extensions in the first place
(mod_rewrite or ISAPI_rewrite)!

If I would have done that, I would have had:
/ - the home page
/contact/ - contact information
/products/ - listing of the products I sell
/quotes/ - email quote form results to me
/search/ - site search

they would never have changed, and when I decided to break apart the
product listings, I would have had:
/products/category/prod_num/

Now, it doesn't matter what I call my files. If they change, the URI
will stay the same! ;)
Given that many sites these days will be using PHP for some sort of house
style use (as well as anything else..) PHP will, by definition, need to be
parsing most if not all files. Therefore, set .html to be parsed for PHP.
Doing this will make all files with the .html extension start the PHP
processor. PHP will then search through the file for any opening <?php
tags before returning result. Not very efficient if you have a large
html file that gets hit all the time.
I've never encountered any noticable performance hit, even on sites that
barely make use of the PHP parser. I dare say there might be on an
extremely busy site, but I suspect most people would never run into that
and the above maintenance advantages outweigh the disadvantages.
Remember, if you are in a shared server environment, your small hit
combined with the other 1200 sites on that server add up very quickly!
Just add
AddType application/x-httpd-php .html
to your .htaccess file or Apache config. What could be simpler?

Not much, but more efficient is better.

My $.02

--
Justin Koivisto - sp**@koivi.com
PHP POSTERS: Please use comp.lang.php for PHP related questions,
alt.php* groups are not recommended.

[Justin Koivisto]

Tim Tyler wrote:

Andy Jeffries <ne**@andyjeffries.remove.co.uk> wrote or quoted:

On Tue, 30 Sep 2003 10:36:10 +0000, Tim Tyler wrote:

RewriteEngine on
RewriteCondition %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)\.html $1.php [R]

That will redirect EVERY .html page request to fetch a .php page.

now it will only if the .html file doesn't exist. :P

--
Justin Koivisto - sp**@koivi.com
PHP POSTERS: Please use comp.lang.php for PHP related questions,
alt.php* groups are not recommended.

[Justin Koivisto]

Martin Lucas-Smith wrote:

That was my point entirely - .html isn't specific to any particular
technology and is preferable to using .php (especially when the site is
substantially making use of PHP parsing on most page)

However, some hosting companies won't allow you to force parsing other
file types...

--
Justin Koivisto - sp**@koivi.com
PHP POSTERS: Please use comp.lang.php for PHP related questions,
alt.php* groups are not recommended.