Quote:
|
Originally Posted by NJG
Inline PHP is executed and parsed at the server level the same as it is in your example
|
That's my point. There's no difference in what the browser displays. Both pages must have a .php extention therefore, if search engines rank dynamic pages lower (which, I've never heard of before. Not arguing it --- just stating that's a new one on me that doesn't make a whole lot of sense.) then both pages will be ranked the same because they both must have a .php extension to parse the code. The only difference is how the file is structured before the script spits out the page. So why not code in a more secure, better configured manner? This is generally the basis for templating systems like Smarty or even vBulletin... keep the php and html separate as much as possible in order to allow the php to spit out whats needed for the browser without embedding php code inside html code. Thinking from a serving point of view, php is parsed first, then html is sent. So it makes sense to code php with embedded html, not vice versa.
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.
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 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.
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?
It's kind of like if you're learning to build web pages from scratch. Your time is
much better spent learning css-based web building as opposed to table-based layout. Sure they both will work and it helps to understand both, but one will take you ahead into the future, the other simply lets others know you're a step or two behind your competition.