If someone could point out what I'm missing here, that would be appreciated
I'm new but I haven't encountered a situation where wrongly naming a html file as php can be bad.
Perhaps it's just less confusing for developers?
If you've a web server that understands the .php file extension and has the necessary PHP module installed, there's no issue with simply renaming a .html file to .php (as long as all links to it are also renamed accordingly).
However there's absolutely no benefit in doing this (and I'd dispute any meaningful UX benefit from the user's perspective), as it'll mean that the web server will need to invoke the PHP module to parse the file. This will be a waste of time and memory, as it's just a plain HTML file.
PHP files are sent to be evaluated after the browser requests them whereas HTML files are directly given to the browser.
So if there is no PHP code in your .php file, you are still sending it to be evaluated, though it doesn't do much to the loading time of the page, if anything.
Related
I named a file index.php while writing an app that uses PHP, Javascript and jQuery. In the end I realized there is no PHP code in the index.php file, so I changed the file extension to .html and, after some testing, it seems there are no problems.
Everything that touches the HTML in the index.html file is JavaScript. I'm reading fields from a form, writing to a MySQL database, and then reading the database and writing back to the HTML. The JavaScript is making Ajax requests to various PHP files.
If I use the filename index.html, am I likely I run into trouble if I move the files to a different Web server?
There is no reason to give a file a .php file extension if it doesn't contain any PHP.
There are various different reasons not to build your page so it only works if JavaScript is available though (which implies that the file should contain PHP, given that is your server side language of choice).
I prefer .php because if you want after time add some php code there you just cant.In .html cant be php code.
According to this advisory, .pht files can be used to execute PHP code:https://www.portcullis-security.com/security-research-and-downloads/security-advisories/cve-2015-5074/
However, I am unable to find much information on this file format. I am also unable to get an Apache server running PHP to execute this file.
Does anyone have more information regarding this file format?
It's not used much. This is a quote from file-extensions.org
The PHT file stores HTML page that includes a PHP script, dynamically generates HTML, often by accessing database information.
PHT seems to be very little used format.
These days, you're more likely to see .phtml files. Where there is a mix of PHP and HTML in the file, it still needs to be parsed by the PHP processor to create the right output.
I am not aware of a web server that handles PHT files with the PHP handler by default. Given their nature it's much more likely that they would be templates, included from another PHP file.
In this use case, the included file can have any extension the developer desires and there could be no official association.
As a matter of precaution i always, now, name my index page: index.php, I do this whatever the project. Does anyone use index.html regularly? Can you be concretely sure you'll never need PHP for the page? Are there any performance issues encountered by always using index.php over index.html?
For servers that don't support PHP, avoid the .php extension unless you are trying to mask the server technology by faking a .php extension.
For static sites it doesn't really matter which extension you use as long as you know your server is configured correctly (see Dominic Rodger's answer). For that matter, not many of your visitors will care whether it's a static or dynamic site. Also, some dynamic sites accept URLs that end in .html as opposed to .php.
Are there any performance issues encountered by always using index.php over index.html?
The PHP interpreter will immediately hand your output back to your web server if there is absolutely no PHP code in it (all it does is send some engine-specific headers), so the performance difference is negligible if at all existent.
You should use index.html, and then if you decide you need PHP, create an index.php, and change your DirectoryIndex directive (if you're using Apache).
on most webservers ".html" files will not get parsed with the php interpreter. so i think, yes, there is an speed advantage.
i use .html files for very small sites, without anything special, shure, why not. the will never get updated so there is no need for it.
Of course...if u have static site u know that u wont have PHP code.
i guess that for .php files the server has to parse the file even if it doesnt contain any php tags or code, but i think that its really negligible...
For sure, the main topic's answer is that if you don't need anything in PHP for your site, you can use .html/.htm in the index page - as everybody stated.
But sometimes, I use it as a awesome trick: when I want to update some webpages or I want to fix some issue within the site or even say something for the visitors, I do an upload of an index.html page saying what I want. Note that, in this case, You will need to always use index.php for the site itself - the trick will work for sure.
Of course, your server need to accept PHP files :P
I hope I helped!
On a standard LAMP stack, do .php files without any PHP in them get passed to the PHP interpreter?
In other words, is there a performance/processing loss for creating a .php file without actually including any PHP in it, versus just making it a .html file?
On a standard LAMP stack, do .php files without any PHP in them get passed to the PHP interpreter?
Yup - after all, no other component except for the PHP parser is fit to decide whether the file contains PHP!
In other words, is there a performance/processing loss for creating a .php file without actually including any PHP in it, versus just making it a .html file?
Potentially, yes, although it will be minimal in most cases unless you have really, really loads of traffic.
Why is it a good practice to remove PHP files from the htdocs/public directory?
They are being parsed anyway, right?
if PHP files are at some point not parsed due to a configuration error or, say, a failing interpreter, there is no danger of the source code (and possibly passwords) being revealed to the world as clear text.
Also, human mistakes like renaming a .php file to .php.bak are less dangerous that way.
I had this once, years ago, when a colleague, from the Perl world and totally ignorant about PHP, decided to set "short_open_tags" to "off" on a server we shared, because short_open_tags messed with some XML experiment he had going (<?xml version="1.0"?>). That was fun! :)
and a second thing:
Calling includes out of context
Having includes (i.e. pieces of PHP code that is included elsewhere) under the web root makes you potentially vulnerable to people calling those includes directly, out of context, possibly bypassing security checks and initializations.
If you can't/won't avoid PHP code to reside in the web root, at least be sure to start each file checking whether it is running in the correct context.
Set this in your main script(s):
define ("RUNNING_IN_SCRIPT", true);
and add this to the 1st line of each include:
if (!defined("RUNNING_IN_SCRIPT")) die ("This file cannot be called directly.");
Yes, they are parsed. However, that is completely dependent on you or the server admin not screwing up the config files.
All it takes is a quick typo in the Apache config before Apache forgets to parse the PHP (I've had this happen). Since Apache won't know what to do with a PHP file after that, your source code just gets output as plain text, and can be immediately copied. Heck, it's even cached in the user's browser, so a malicious user can quickly copy all your code and browse it later at their convenience, looking for security holes.
You don't want your source to be visible even for a second. If you have no code files in the htdocs directory, this can't happen. They can easily be included into your code from outside the directory however.
Many MVC frameworks use this method of sandboxing for just this purpose.
The more executable PHP files you have, the more security risks you also have :
What if there is a problem in your configuration (it happens !), and the source code of your PHP file containing your database credentials is sent to the browser ?
what if there is some "bad" thing left in one of those files, you didn't think about, and no-one ever tested ?
The less PHP executable files you have... well, that's a couple of potential problems you don't have to care about.
That's why it's often considered as best to :
put under the document root only the PHP files that have to be called via Apache (like index.php, for instance),
and put outside of the document root the PHP files that are not accessed directly, but only included by the first ones (ie, libraries / frameworks, for instance).