In several threads I've seem people advocating not using .inc for include files and only using .php or .inc.php. I don't see why this is good advice. A quick search of the forum didn't turn up a thread on the topic.
Advantages to .inc:
allows a seperation of viewable pages/scripts from class/include files
allows a File directive in the either httpd.conf or .htaccess to forbid direct viewing of the .inc
Cons of a .inc:
loses the context clue of it being a php file
may lead to a sense of false security (forgetting to remove the .inc~ emacs file or similar)
You can address the first con by naming files .php.inc (the opposite of the often suggested advice in the threads). Yes, ideally, your includes should live outside the webtree, in which case it probably doesn't matter what you name them, but we all know sometimes that isn't possible.
Thinking about it a little more, I guess another con is that if you can't set the File Directive you now reveal the include file if its requested and its the web tree. Do people who name their files .inc.php setup a File mask for *.inc.php and restrict viewing of those files, which would seem to use the best parts of both schemes?
Eric
Why not .inc?
Moderator: General Moderators
Hiho!
That's right. donät ever use inc file for storing username, password etc!
Use PHP files!
Use PHP files!
Yes, I know that a .inc in the web tree will be exposed as plain text if a browser requests it. However, there are other solutions to solving this dilemma than just not using .inc. I'm interested in hearing why people are so against it.
Possible solutions:
Use the File Directive to forbid direct serving of .inc files
Store .inc's outside the web tree
Add .inc to the list of files to give to the php handler
All those options require the ability to either specifiy a .htaccess file, store files outside the webroot, or modify the main server configuration file --- tasks that an arbitrary user installing a php based application may not have based on their method of hosting. However, people on this forum are commonly suggesting things for .htaccess so it seems like most hosting services people use with PHP allow at least some .htaccss overrides.
Is there another reason for avoiding the .inc ending?
Personally I like my .inc's. They are outside the web tree, and should one suddenly appear in the web tree apache will refuse to serve it. Even if apache gets started up without PHP and exposes all my scripts, the includes are safe, regardless of where they live. Executeable scripts are kept seperate from class definations, utility functions, common headers, and configuration files.
However, I'm working on packaging up a project I've been working on and now is the time when I could go through and change my extensions, if there is a good reason to.
Possible solutions:
Use the File Directive to forbid direct serving of .inc files
Store .inc's outside the web tree
Add .inc to the list of files to give to the php handler
All those options require the ability to either specifiy a .htaccess file, store files outside the webroot, or modify the main server configuration file --- tasks that an arbitrary user installing a php based application may not have based on their method of hosting. However, people on this forum are commonly suggesting things for .htaccess so it seems like most hosting services people use with PHP allow at least some .htaccss overrides.
Is there another reason for avoiding the .inc ending?
Personally I like my .inc's. They are outside the web tree, and should one suddenly appear in the web tree apache will refuse to serve it. Even if apache gets started up without PHP and exposes all my scripts, the includes are safe, regardless of where they live. Executeable scripts are kept seperate from class definations, utility functions, common headers, and configuration files.
However, I'm working on packaging up a project I've been working on and now is the time when I could go through and change my extensions, if there is a good reason to.
- twigletmac
- Her Royal Site Adminness
- Posts: 5371
- Joined: Tue Apr 23, 2002 2:21 am
- Location: Essex, UK
Basically the main reason against using .inc files is to prevent them being served as plain text when the web server isn't set to parse them with the PHP scripting engine. If you've got the knowledge and the ability to set them up to be treated as .php files then it's not much of a problem. Personally I tend to call these type of file .inc.php mainly as precautionary measure because I know that if I have to move my stuff to another server I don't have to worry about setting extensions other than .php.
If you're aware of the issues and how to solve them it's really up to you what you decide to do. Oftentimes these sort of things like 'don't use .inc as an extension' are said and then treated like some sort of unbreakable rule because the majority of people don't understand the issues or what they can do to make their .inc pages safe. It's also because a lot of people have web hosts who won't allow them to do things like assign new extensions to PHP (or make it very difficult).
Mac
If you're aware of the issues and how to solve them it's really up to you what you decide to do. Oftentimes these sort of things like 'don't use .inc as an extension' are said and then treated like some sort of unbreakable rule because the majority of people don't understand the issues or what they can do to make their .inc pages safe. It's also because a lot of people have web hosts who won't allow them to do things like assign new extensions to PHP (or make it very difficult).
Mac