Given my new understanding of the power of "includes" with PHP, it is my guess that ALL of my pages on my site will be .php extension.
Would this be considered strange?
I used to think that most pages would be .htm or .html, but in looking around the net, I am noticing that there really isn't any "standard".
I don't really think I have a choice, if I want to call my menus from a php file. It is just going to be that way, far as I can see... so just bouncing off you all to get a feel for what "real programmers" feel about such issues.
The thing that actually matters to the browser isn't the file's extension; it's the MIME Type that it gets sent in the HTTP headers. Headers are data that gets sent before the actual file and tell what kind of data it is, how big it is, and a bunch of other unimportant junk. You can configure your server to send any file extension as an HTML page, but the most common extensions for HTML pages are .htm, .html, .php, .asp, .aspx, .shtml, .jsp, and several others.
As for it looking "strange", a surprisingly small number of users will actually look at the address bar at all, let alone notice that the file extension is .php instead of .html. I wouldn't worry about it if I were you; it really doesn't make a difference.
generally - make sure your URLs are easily read, reflect the content beneath them, and don't change. the "not changing" part can be tricky, especially when you shift technologies over time (html>php>aspx).
to achieve this just ensure that each area of your site appears to reside in its own subdirectory.
you can either do this by physically structuring your site in this fashion and using default documents (default.html/php/aspx), or using something like mod rewrite, ISAPI rewrite, or similar to rewrite these paths to the appropriate docs.
someone who's keen on SEO or marketing might have a different idea about what constitutes a "good" URL, but as a developer this is how i see it.
Ending URLs in .php is fine technically, but I think these days many people are trying to make the urls independent of the actual code/file structure.
I actually think that's a good thing from a software engineering perspective as well. URLs are conceptually different (read: not related at all) to the file/directory structure used to organize the system powering the website.
The "resource" that a URL "locates" is not the .php or .asp file that contains the code to display it.
Look at stackoverflow for example, the URL of this question is /questions/322944/uql-etiquette, there's nothing in it that can be used to "guess" the underlying framework/system. The resource in this case is the question and all the answers to it, as well as the comments, votes, edits, and various other stuff.
It doesn't matter what your URLs end with, .php is fine, and fairly common. The only thing people care about these days when it comes to URLs is making them pretty for Search Engine Optimisation, but that's a whole new question.
Real programmers use URLs like /noun/verb/id/ & don't show file extensions at all :p
Personally I use Apache's mod-rewrite.
(on a slightly less tongue-in-cheek note) It's worth mentioning, specifically for includes, that you should ensure your actual files have the extension .php. I've seen more than one site where programming logic can be viewed in-browser 'cos the developer ended their files .inc (or insert non-auto-parsed extension of choice here).
As far as url etiquette goes - I really don't think etiquette is involved; however if you have sophisticated users visiting your website who have strong views on platforms and technologies, using .php or .aspx extensions could put off users - perhaps subconsciously.
If you use apache, it's fairly easy to make a .php be read as a .py and vice versa by changing the httpd.conf file. My current practice is to use .html extensions (or no extensions at all) and treat all files as .php.
Whatever you decide, do make sure that you never break an existing url. It's possible to achieve that even if you keep .php as the extension and decide to change the technology later.