I often see examples in PHP that include.inc files. What is the meaning of .inc? What it is used for? What are the disadvantages and advantages of using it?
It has no meaning, it is just a file extension. It is some people's convention to name files with a .inc extension if that file is designed to be included by other PHP files, but it is only convention.
It does have a possible disadvantage which is that servers normally are not configured to parse .inc files as php, so if the file sits in your web root and your server is configured in the default way, a user could view your php source code in the .inc file by visiting the URL directly.
Its only possible advantage is that it is easy to identify which files are used as includes. Although simply giving them a .php extension and placing them in an includes folder has the same effect without the disadvantage mentioned above.
If you are concerned about the file's content being served rather than its output. You can use a double extension like: file.inc.php. It then serves the same purpose of helpfulness and maintainability.
I normally have 2 php files for each page on my site:
One named welcome.php in the root folder, containing all of the HTML markup.
And another named welcome.inc.php in the inc folder, containing all PHP functions specific to the welcome.php page.
EDIT: Another benefit of using the double extention .inc.php would be that any IDE can still recognise the file as PHP code.
Generally means that its a file that needs to be included and does not make standalone script in itself.
This is a convention not a programming technique.
Although if your web server is not configured properly it could expose files with extensions like .inc.
It's just a way for the developer to be able to easily identify files which are meant to be used as includes. It's a popular convention. It does not have any special meaning to PHP, and won't change the behaviour of PHP or the script itself.
This is a convention that programmer usually use to identify different file names for include files. So that if the other developers is working on their code, he can easily identify why this file is there and what is purpose of this file by just seeing the name of the file.
Just to add. Another disadvantage would be, .inc files are not recognized by IDE thus, you could not take advantage of auto-complete or code prediction features.
In my opinion, these were used as a way to quickly find include files when developing. Really these have been made obsolete with conventions and framework designs.
Note that
You can configure Apache so that all files With .inc extension are forbidden to be retrieved by visiting URL directly.
see link:https://serverfault.com/questions/22577/how-to-deny-the-web-access-to-some-files
Related
Whenever I want to include a document with PHP, or perform any other PHP action which requires a path to be described, I need to write something like, ../../../../../document.html. This works, but it's tedious, and in some cases, the path is wrong, resulting in code appearing on-page, and debugging.
This can, obviously, be bypassed by using the $SERVER_['DOCUMENT_ROOT'] command, but that, too, requires a sometimes unmanageable amount of code (again, when many, many paths are present).
Is there any way to simply define all PHP paths site-wide to be document root-relative, as in HTML (/document.html is root relative)?
I have a detailed answer on this in another question:
finding a file in php that is 4 directories up
It explains the caveats of relative file paths in PHP. Use the magic constants and server variables mentioned there to overcome relative path issues.
Yes. Most experienced developers would tend to define constants in a config file for various paths important to the application. So perhaps something like this if you want to define the webserver document root as your application root, and perhaps have another path otuside the web server directory where you place application includes (classes, etc.) that you don;t want exposed in the web directory.
define('WEB_ROOT', $_SERVER['DOCUMENT_ROOT']);
define('INCLUDE_DIR', '/path/to/directory/');
You can then just reference these constants in your application.
I would certainly recommend going away from relative paths as they are problematic when refactoring your code or moving your code from one server to another. If you need relative type of paths (for app portability for example) you might be better served using the PHP magic constants like __FILE__ and __DIR__.
I used to do that and have those problems. Then I switched my site to use mod_rewrite for the urls. I then had all of my php pages in the same directory so I didn't have to go a confusing 4 times up the directory structure to find the root. You can have a php file on your server at:
/var/www/index.php
And, using mod_rewrite in your .htaccess file, you can have that map to:
http://domain.com/really/long/path/structure/page.html
When I moved over to that structure, it really helped me on the php side of things specifically regarding navigating to different directories.
Im creating a website and i am very OCD when it comes to security so i heard that if you store all of your .php files outside of your public_html folder and invoke them with another .php file that is inside your public_html folder then your risk of an attack is lower. Is this true, if so how would i do this. I read something about using .htaccess but I'm not sure if that was the correct way to do it. I though i could maybe use include but im not sure how include works with parameters.
There isn't a huge amount of extra protection offered by this strategy. Mainly, it ensures that if your server is misconfigured and fails to send PHP scripts to the PHP interpreter, it doesn't allow PHP code to be sent directly down to the browser.
You don't store all your PHP scripts outside document root. You typically store only files which are not intended to be accessed publicly outisde the doc root. Store your include files outside the doc root and include them as you would any file. Store files which are are public views inside the document root, as they need to be web-accessible.
There is a design pattern known as the Front Controller pattern whereby a single index page (index.php) accepts routes and includes other files as appropriate. Numerous PHP frameworks support this out of the box.
See PHP include function: http://www.php.net/manual/en/function.include.php
However, I doubt what you're trying to do will increase security. Where did you hear that it increases security?
I have been inspecting some PHP source codes and I more often than not find files starting with
defined('__someconstant__') or exit();
I know that this prevents the file to be accessed directly if a previous file defining __someconstant__, but then I wonder if this is really necessary... Isn't there (even non-PHP based) a cleaner way of doing it without introducing this extra code in every file?
Isn't there (even non-PHP based) a cleaner way of doing it without introducing this extra code in every file?
Presence of such snippets indicate bad code structuring, namely code automatically executing in global scope. You shouldn't have this or exit(); code in pure function/class includes. It would be redundant there.
Code that does perform potentially dangerous actions shoult not be web-accessible in the first place. The or exit; approach is a workaround. It should always be accompanied by a FilesMatch and Deny from All in a .htaccess file however. Best set the whole include directory inaccessible.
To avoid those (useless) lines at the top of (nearly) each file, your could:
Store a public "controller" file (like index.php in a directory called web or public on which your web server's alias or virtual host points to
Store in other directories like lib, config, apps... all the files that should not be directly accessed through the webserver by simply typing an URL.
This is typically the structure of existing frameworks such as Symfony 1.x
Additionally you can (and certainly will, for URL rewrites) put a .htaccess file, but a server misconfiguration can incidentally disable it, so keeping source files in distinct directories is IMO better.
Adding to #NullUserException's answer...
Yes there are other ways of preventing a file from being accessed directly (.htaccess being one), but for software that is shared with a wide audience, you can't really rely on those technologies being there. You can rely on a simple condition at the top of the files though.
I have been developing my own PHP MVC framework. Now I have seen different frameworks implementing different extensions for the View files. I am using simply php extension for my view files.
Now is there anything wrong if i use php extension.
Are there any merits or de-merits of it?
Why use other extension such as:
phtml
etc
If you're talking about using these extensions in public facing URLs, then I would say don't use either:
File name extension. This is a very
common one. "cgi", even ".html" is
something which will change. You may
not be using HTML for that page in 20
years time, but you might want today's
links to it to still be valid. The
canonical way of making links to the
W3C site doesn't use the extension.
(Taken from W3C URL style guide)
You can achieve this with mod_rewrite, for example.
However, if you're talking about how to name your files in the filesystem, it's largely a matter of taste. I think both the extensions you suggested (phtml and php) make sense, the main thing is being consistent.
Edit: Also, since you said this is for a framework, you should consider choosing a non-standard extension may require extra webserver configuration. For example, to support both .phtml and .php in Apache:
AddType application/x-httpd-php .phtml .php
There's nothing wrong with using PHP extension if the code inside is valid PHP. It's nice to indicate somehow that a file is a view script. That's why some use .phtml. But I guess, you put them in a separate place-for-views anyway, right?
A benefit of .phtml is that it's obvious what kind of file it is when displayed in a "Jump to file" list. It's a feature of my IDE I use a lot: just typing a part of any file name in a project and picking the one to jump to.
It really doesn't matter what you use and as far as Apache goes its exactly the same if you are directly including the files.
Some use .tpl, some use .php and some use .phtml. Just pick the one you like the look of most.
My friend asked me to update a PHP application that his company uses. I found out that the application uses .ini extension for DB configuration file. The file contains DB host address, username, and password!!. The problem is that I can access the file on web-browsers.
I am trying to understand why. Is there any particular reasons to use a regular php file with .ini extension??? I just don't get it.
Readability is one of the main reasons I've used ini filies for php script configs in the past. People who are not coders have run into an ini file at least once before, and can understand what it is much easier than even a simple php file.
The issue of ini files being readable by everyone can be prevented by server side configuration, or even better, by simply adding a single line of code inside a comment line at the top of the file.
That way php will output an 'Direct access forbidden' when the file is accessed via a browser, and the ini file will continue to function as before.
You can use Zend_Config_Ini. It is comfortable and easy. Just simply do not put config files where any user can reach them (for example public_html).
INI files are just one way of dealing with configuration, perhaps the developer came from a Windows-developing background and used whatever he was familiar with :). Besides, PHP offers a convenient way of parsing INI files through the parse_ini_file function.
You'll want to make sure the .INI file is not accessible from the web though. Move it below the docroot so your PHP script can still access it, but random browsers cannot.
For what it's worth, PHP has traditionally used php.ini to configure PHP. So maybe it's some kind of legacy thing?
Seems like this is just former programmer's wish to use different file type for configuration. If there is no other uses for this file, rename it to *.php and forget it. If not, configure webserver to parse ini as php or, better, move it to directory, not reachable from web-server.