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!
Related
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.
How to modify URL such www.mysite.com/dir.php?ID=123
to www.mysite.com/dir/123 without using or involving .htaccess
cause I can't access .htaccess on our server.
If this is your own application and not the standard framework/CMS then you can implement your own rewrite engine in PHP so the URLs would look like www.mysite.com/index.php/dir/123.
That's slightly worse than the clean URLs but that's the best you can achieve.
When you run the url like that the $_SERVER['PATH_INFO'] PHP variable would store "/dir/123" which is then your job to parse and transform to the params you need and then invoke or include the right script.
IIRC Kohana is built like that. So you can look their code for an inspiration.
The only other option is using a rewrite engine on the web server software, e. g. mod_rewrite for Apache.
But as long as you don't even control files on your server, you probably don't have access to Apache configuration.
Your web app/CMS should have support for nice URLs too.
Short story is:
You can't
At least you should be able to use .htaccess to normally do this. If you can't even use that, other options will most probably also be limited out for you.
But there is one work-around that you MAYBE (I'm absolutely not sure) can use...
Are you allowed to set your own 404 error pages?
If so, try setting a 404page.php that acts as your entry point, sends out a http_response_code(200); and does what it further should do.
Off course you should remove any index.php from your public_html and not use any of the URLS that should be handled by the handler, so they will lead you to the 404page.php.
(Let me know if this worked :). )
Does anybody know of a software program that will convert a website built with PHP, JSON and jquery into a mainly HTML format. We need to do a conversion for SEO purposes and don't want to have to rewrite the whole site.
HTML is a language used for markup, PHP is an object oriented functional language. You cannot convert one to the other, I'm sorry.
If you're trying to make sure that you have nothing but .HTML extensions on your public URLs for SEO purposes:
Someone's selling you a line of BS.
You need access to your server configuration.
You don't have to convert anything but your links.
The .PHP extension is the default file extension configured to be sent from Apache to the PHP engine for parsing. You can change what file extension gets parsed in your configuration file.
http://encodable.com/parse_html_files_as_php/
This will allow you to keep .HTM files static and have .HTML files parsed as if they were .PHP files.
Try this: http://www.httrack.com/
It will only return a static HTML site. But it might be a good base for you.
Since the only thing which really knows what type of file you're using is the server itself, it does not really matter what you're using on the back end. Most search engines are smart enough to know that so they don't really care so much. Now, people might care. People might say, "Hm, well, this is .html, that means that this person must have a flat file which is constantly being updated," but I doubt it.
If you're really concerned about having a .html extension, then you can fake it by using htaccess:
RewriteRule ^(.*)\.html$ $1.php [L]
If that is placed in a .htaccess file at the root of your site, it will redirect all requests which end with .html to a corresponding page with .php. It will do that transparently both to the user and to the crawlers.
Of course, every link on your site will need to convert from linking to .php, but it will replace the impossible task of using only .html files with the annoying task of replacing all of your .php links.
As to removing JavaScript, well, you could do that, or you could design your site in such a way that it still uses AJAX but it works with the search engines instead of against them. The biggest trick is to make sure that your site can work with as little AJAX as possible and then use AJAX to supplement. We've come a long way from requiring that all websites work in lynx, but it is still good practice to make sure that they are still sane without the benefit of JS/CSS.
Besides, search engines are getting smarter. Google has been working to read AJAX intelligently since 2009. But even if they weren't, there are plenty of articles out there on using AJAX without hurting SEO.
There is no need to nerf your site because of SEO -- You can have your AJAX and SEO too.
This is hard to accomplish if there is a lot of dynamic data. For a simple website you can just cache every page and make that your new website. I am not sure how useful that would be. For example if you have forms or other user input fields then things will just not work. In any case this is how you do it using wget.
$ wget -m http://www.example.com/
More reading here.
Is it possible to hide the the url in the address bar of the web browser so that it won't necessarily match the location of the files.
For example, this url:
http://localhost/exp/regstuds.php
You will always know by looking where to find the files in the computer.
Is it possible to distort or disarrange or hide the url in such a way that the location of the files will not be revealed
Yes, if you're using Apache look into using mod_rewrite. There are similar rewrite modules for pretty much all other web servers too.
I hope your sole motivation for doing this is not "security through obscurity". Because if it is, you should probably stop and spend more time on something more effective.
If you are hosting your php on an Apache server, you probably have the ability to use the mod_rewrite utility. You can do this be adding rules to your .htaccess file...
RewriteEngine on
RewriteRule ^RegStuds/ regstuds.php
This would cause http://localhost/RegStuds/ to actually render regstuds.php, but without ever displaying it in the address bar.
If you are on IIS, you can perform the same function using an ISAPI Rewrite Filter.
If you don't have mod_rewrite or an ISAPI Rewrite Filter, you can get a similar result using a folder structure, so you would have a physical path of RegStuds/index.php - and you would never need to link to "index.php" as it is the default file. This is the least recommended way of doing it.
No its not.
Each bit of functionality must have a unique identifier (URI) so that the request is routed to the right bit of code. The mapping can be non-linear using all sorts of tricks - mod_rewrite, front controller, content negotiation...but this is just obscuring what's really going on.
You can fudge what appears in the address bar on the browser by using a front-controller architecture and using forms / POSTs for every request but this is going to get very messy, very quickly.
Perhaps if you were to explain why you wanted to do this we might be able to come up with a better solution.
C.
I was going to ask what the best way to do this is, but then decided I should ask whether or not it is even necessary. I have never seen it done in JSP development, but it appears to be common practice in PHP. What is the reasoning behind this, and if I do not protect against this, what else should I be taking into consideration?
The reason this is more common in PHP than other similar languages has to do with PHP's history. Early versions of PHP had the "register_globals" setting on as a default (in fact, it may not have even been a setting in really early versions). Register_globals tells PHP to define global variables according to the query string. So if you queried such a script thusly:
http://site.com/script.php?hello=world&foo=bar
... the script would automatically define a variable $hello with value "world" and $foo with value "bar."
For such a script, if you knew the names of key variables, it was possible to exploit the script by specifying those variables on the query string. The solution? Define some magic string in the core script and then make all the ancilliary scripts check for the magic string and bail out if it's not there.
Thankfully, almost nobody uses register_variables anymore, but many scripts are still very poorly written and make stupid assumptions that cause them to do damage if they are called out of context.
Personally, I avoid the whole thing by using the Symfony framework, which (at least in its default setup) keeps the controllers and templates out of the web root altogether. The only entry point is the front controller.
If you include everything from outside web root then it's not an issue as nothing can be loaded directly.
Well, This is to prevent sensitive includes from being sent to the web-server directly. It's certainly not an all-inclusive security measure, but it could help with your particular setup.
If however, your user was in a position to include the file from their own script, it won't help at all
I emit a 404 page, not as a serious security measure but only because I don't like leaking information about the internals of a site, even the names of internal files.
But if the file just contains functions then there's no real harm in omitting the check.
It also isn't just a security feature in php but more of how many MVC based PHP sites function. If for example in SugarCRM you were to call a module file directly the page load would fail because the controller, view and model were not previously loaded and you'd have no db config/connection information either, so to make sure all dependencies are loaded the users is forced through a known entry point - i.e. index.php
I just found an approach in the .Net MVC system that you could replicate for PHP using Apache Rewrites, .htaccess files or if you are using IIS, a web.config file.
As the MVC pattern doens't need the user to directly access aspx files these are not served and a 404 is sent instead. If you have a naming convention for included files "inc.php" for example you could redirect *.inc.php requests to a 404 for specific folders - in Apache Rewrite supply R=404 at the end of the rule will return that HTTP status to your client.
Some of these examples may help: Apache Rewrite Examples
As already mentioned in some of the other answers, you shouldn't need to do this. If a file isn't supposed to be served up by the web server, you shouldn't leave it within the web folder. Includes should be placed in a directory outside the web root.
Apart from that, the proper way to tell the user that a page doesn't exist, is by emitting a status 404, using:
header("HTTP/1.0 404 Not Found");
exit;
If you don't do this, it is hard for non-humans (Eg. search-engines) to distinguish between a regular page and a non-page.
This is very important because if you are editing your site running Google Toolbar, it will find your inner php files and then put them into search results. At best this will create an awkward experience for users but if you are a sloppy programmer, could reveal database connection information.