Page 1 of 2

PHP Filetypes

Posted: Wed Mar 23, 2005 3:25 pm
by Ambush Commander
I'm a programmer, and I'm used to only using .php files.

So, when I saw the .inc files for classes, I was wondering whether or not there were other filename conventions for PHP files?

.php - Generic
.inc - Class Definitions
.php4, .php5 - Is this real?
.phpt - Testing PHP code?
.phps - Letting people see PHP code?

Are there other filenames like this?

Posted: Wed Mar 23, 2005 3:29 pm
by Joe
.php4, .php5 are real yes. You would need to add them as a mime type extensions within your mime.type file in order for them to work if you are using an outdated version of php.

This is where the glory of .htaccess comes in handy. :)

Posted: Wed Mar 23, 2005 3:33 pm
by feyd
.phps is real too.

.inc has been used to mark include files, versus normal files. The problem comes if the server isn't set to run them as php files, because someone can request the file, and bingo, they have your code.. sometimes it's okay.. but say if it's your database config information.. bad. :)

Posted: Wed Mar 23, 2005 3:36 pm
by Ambush Commander
But you should have your include directories protected with HTACCESS anyway...

Is there any particular benefit to using these particular filetypes?

Posted: Wed Mar 23, 2005 3:39 pm
by Joe
If the following was in reply to "This is where the glory of .htaccess comes in handy." then I think you took it the wrong way.
But you should have your include directories protected with HTACCESS anyway...
What I meant was use .htaccess to add mime type extensions. Use the AddType directive for this.

Posted: Wed Mar 23, 2005 3:41 pm
by Joe
Is there any particular benefit to using these particular filetypes?
I personally do not think so. Using php4/php5 extensions can be a bit confusing for some people. As for the .inc files yeah I use them myself so why not. :)

Posted: Wed Mar 23, 2005 3:45 pm
by Ambush Commander
If the following was in reply to "This is where the glory of .htaccess comes in handy." then I think you took it the wrong way.
Nope, it was to Feyd's post. :)
I personally do not think so. Using php4/php5 extensions can be a bit confusing for some people. As for the .inc files yeah I use them myself so why not.
"Why not. A bit used, but still a perfectly servicable reason for almost anything."

I don't see why I should. Shouldn't we try to keep things simple by just having all our PHP files with .php? Ah well, this was only really a problem when I started taking a look at code libraries and then I saw .inc and I'm like "Wow, I've never seen this before!"

Posted: Wed Mar 23, 2005 3:49 pm
by Joe
Ambush Commander wrote:
If the following was in reply to "This is where the glory of .htaccess comes in handy." then I think you took it the wrong way.
Nope, it was to Feyd's post. :)
I personally do not think so. Using php4/php5 extensions can be a bit confusing for some people. As for the .inc files yeah I use them myself so why not.
"Why not. A bit used, but still a perfectly servicable reason for almost anything."

I don't see why I should. Shouldn't we try to keep things simple by just having all our PHP files with .php? Ah well, this was only really a problem when I started taking a look at code libraries and then I saw .inc and I'm like "Wow, I've never seen this before!"

Ah ok. I totally agree with you mate. Everyone should just use .php, however as the years go by things will start getting more advanced and the .php extension will expand (just mabey).

I remember having a conversation similar to this but it was about html and xhtml. :P

Joe 8)

Posted: Wed Mar 23, 2005 3:55 pm
by Roja
Ambush Commander wrote:But you should have your include directories protected with HTACCESS anyway...
Ah, but that assumes that:

1. You are running on apache (not IIS - it doesnt natively support htaccess, and I dont think zeus does either)
2. You are running on an apache host that ALLOWS your htaccess to override the global settings

While #2 is a fairly reasonable assumption, #1 definitely isn't fair. PHP on IIS is quite usable, and is becoming more popular. Zeus seems to be gaining as well.

Instead, just name them .php, and you get the protection of file parsing without having to resort to a seperate file that only works on one webserver software. :)

Posted: Wed Mar 23, 2005 4:05 pm
by Ambush Commander
Roja wrote:Ah, but that assumes that:

1. You are running on apache (not IIS - it doesnt natively support htaccess, and I dont think zeus does either)
2. You are running on an apache host that ALLOWS your htaccess to override the global settings

While #2 is a fairly reasonable assumption, #1 definitely isn't fair. PHP on IIS is quite usable, and is becoming more popular. Zeus seems to be gaining as well.

Instead, just name them .php, and you get the protection of file parsing without having to resort to a seperate file that only works on one webserver software. Smile
Hmm... that's fair. I guess as it gets easier to install on Window's Server, we'll start having problems with PHP apps who think that they're always going to be run on PHP configured for Apache... but that's besides the point.

The only problems that happen when you label includes .php is that it's so easy to forget to make sure that your working directory is correct (procedural include code can throw lots of errors when it comes to being called directly). But it's nothing a bit of planning can't unentangle.

Now, no one has mentioned .phpt! I've gotten it from Advanced PHP Programming by George Schlossnagle, who, in his chapter about Unit Testing, has labeled all unit testing classes in files with phpt. Is this code automatically parsed or does it have to be protected too?

Posted: Wed Mar 23, 2005 4:09 pm
by Roja
Ambush Commander wrote: The only problems that happen when you label includes .php is that it's so easy to forget to make sure that your working directory is correct (procedural include code can throw lots of errors when it comes to being called directly). But it's nothing a bit of planning can't unentangle.

Code: Select all

ini_set("include_path",".");
Done, or did I misunderstand your issue?
Ambush Commander wrote: Now, no one has mentioned .phpt! I've gotten it from Advanced PHP Programming by George Schlossnagle, who, in his chapter about Unit Testing, has labeled all unit testing classes in files with phpt. Is this code automatically parsed or does it have to be protected too?
No webserver that I know of does so by default. In other words, its bunk. :)

Posted: Wed Mar 23, 2005 4:14 pm
by Ambush Commander
No webserver that I know of does so by default. In other words, its bunk.
Well then, back to .test.php
Done, or did I misunderstand your issue?
Err... I'm not exactly sure what that INI setting does, but I don't think that's what I meant. Basically, if you're opening files with relative paths, it's imperative that the paths are resolved as if they originated from the root directory (that's why cross linking between directories is a nightmare for me). I think chdir() does the trick.

Posted: Wed Mar 23, 2005 4:23 pm
by feyd
server root or document root? document root, I can understand.. but server root.. no.

'.' would be the current directory.

Posted: Wed Mar 23, 2005 4:27 pm
by phpScott
the use of .inc was used to be able to distinguish between standard php files and files that are included. Sometimes you might even see .class for a class file. But the issue raised about parsing files if the server is configured to understand .inc or .class files is a real concern. To aviod this I have often see programmers name their files like database.class.php or commonHeader.inc.php of database_class.php or commonHeader_inc.php to keep the distiction between what the file is used for as well deal with the problem of the file not being parsed.

Posted: Wed Mar 23, 2005 4:30 pm
by Ambush Commander
If you put your files in a directory like /include or /classes, is it redundant to put .class.php (or the like) in a filename?

EDIT:
'.' would be the current directory.
Ah, I see. Then wouldn't that config edit just be the same as the default?