Make all pages .php?

With total disregard for any kind of safety measures Gerhard
Fiedler <me@privacy.net> 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.....

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

fyi... check with you hosting company. my host won't send html files
through php so that means i must use php extensions.


jskeith1@san.rr.com (Jeff Skeith) wrote in message news:<ce78746a.0309172038.1b69a34@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" <bruce@noDirectEmail.com> wrote in message news:<3F6892BF.7526E047@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

Martin Lucas-Smith <mvl22@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/ tim@tt1lock.org Remove lock to reply.

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

> >> 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

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
>

Andy Jeffries <news@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/ tim@tt1lock.org Remove lock to reply.

> 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

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 - spam@koivi.com
PHP POSTERS: Please use comp.lang.php for PHP related questions,
alt.php* groups are not recommended.