Quote:
Originally Posted by Jolt
Both pages must have a .php extention
|
That's not true at all. You can configure Apache to execute any file extension as if it were PHP (providing it contains PHP code within <?php tags.
Quote:
Originally Posted by Jolt
if search engines rank dynamic pages lower (which, I've never heard of before and would not explain current #1 listings in 99.5% of all searches)
|
Search engines definitely penalize dynamic urls. I was wrong to suggest that the extension .php itself would create the issue. Rather, the issue occurs when you generate pages using variables in the URL (using the ? ). For those who don't know, with PHP it is possible to pass variables from one page to another (or back to itself) using the URL. We've all seen URLs like this example: 'http://www.mysite.com/index.php?userid=1234'
Quote:
Originally Posted by Jolt
So why not code in a more secure, better configured manner?
|
I agree, this is the preferred method. I'm not sure i agree that it is more secure, but it is definitely the better practice. However, it's not practical in many cases, especially the 'Hello World' application where you would be increasing server load and page load time to output a simple string of text.
Quote:
Originally Posted by Jolt
The security risk comes mainly when using includes. If your includes are not executable then can be seen in a browser, often giving away server side information that you don't want given away. For instance, if you include header.htm or header. tpl, or header.inc and it contains a bit of inline php to run a query. All one has to do is call header.xxx in a browser and they will see all the code, including the query. In your example above, if that file were an include.... and called in a browser, I could see what php is doing. In my code above, if that were an include and called in a browser, only the html would be seen. Thus protecting the php content. It's simply good practice to code all php as executable and not php lines embedded in html.
|
Yes, you're absolutely right although the name of the included filename is never revealed... you would either have to KNOW the filename and it's location or be able to surf the open directories to view the files. In any case, your method is preferable in that situation but does not apply to the 'Hello World' example.
Quote:
Originally Posted by Jolt
FYI, I've been using a Mac since 1984... I've never seen a case where a Mac browser refuses to parse code if the server is set up and running properly. And I've used just about every Mac browser since the birth of the modern internet. I've seen some odd things, but never a script that refuses to parse simply because a user is on a Mac. If the script fails, it fails on a PC just as easily. That is when considering php. And nowadays, with the Unix-based Mac OS, php is basically at home on the Mac OS. ASP is another matter since asp Windows based and can not run on a Mac.
|
I never said Mac's were a problem... i said Non MS/MAC OS's meaning machines running an OS OTHER than Microsoft or MAC OS... mainly this issue (to my knowledge) comes into play with Mobile Browsers... especially early versions.
Quote:
Originally Posted by Jolt
I can't comment on mobile devices. I've never had an issue with php/css based sites on a mobile device. But it's impossible to test every mobile device.
|
Neither have I... i've only heard of these issues on forums... The PSP's first browser version exhibited this issue I believe.
Quote:
Originally Posted by Jolt
In short... (finally  ) .. I just meant that if you're learning php, it's better to learn the way the pros like to see it done. Why not learn the preferred manner if you're starting from scratch? |
If you have the time and your project requires such a degree of development, than absolutely! Do it right! However, if you're creating a personal website and want to create a widget to display the current date, you don't necessarily need to create that much additional work. Not to mention the increase in server load is not necessary.
Mike.