How and why is PHP stripped from HTML?

[chrstrbrts]

Hi,

I have used the 'view source' option on chrome (I assume all browsers have similar functionality) to view source code for sites that are clearly dynamic.

However, I've noticed a conspicuous absence of PHP code in the HTML that is generated despite the fact that these sites show .php in the address bar when the browser generates their pages.

I see HTML (of course), CSS, and JavaScript.

But no PHP, Perl, or Python and by extension, no SQL.

It seems that the server scripting is removed before the code is presented to the user.

How and why is this done?

I'm assuming that despite the user not being able to see the server scripting, the browser can, right?

Thanks.

P.S.

I'm still new to all of this, but I do believe that you have the option of inbedding the HTML inside of PHP scripts.

In theory, your entire web page could be incoded within one PHP script.

In such a case, if you attempted to use the 'view source' tool, would you just get an empty page back?

 

[Ken g6]

I'm assuming that despite the user not being able to see the server scripting, the browser can, right?

No. Of course not. There's a reason it's called "server-side scripting". The server interprets the script, which produces HTML that's sent to the browser.

 

[Markbnj]

No. Of course not. There's a reason it's called "server-side scripting". The server interprets the script, which produces HTML that's sent to the browser.

Yep, OP is missing a fundamental piece of the picture. The server gets a request from the browser. The server runs any server side scripting or code and the output of that is some html that is sent back to the browser as a response. The html the browser receives can include markup and script, as well as links to other resources like images, style sheets, and more script. Eventually the browser fetches all the resources and executes all the script that needs to be run before the page is complete, and then displays the result to the user.

 

[DaveSimmons]

In such a case, if you attempted to use the 'view source' tool, would you just get an empty page back?

No, when you embed raw HTML in a PHP script, that's a shorthand for echo / printing that part of the text file instead of running it. think of an invisible ' echo' right before that text, and quotes around it.

<?php
$foo = true;
if ($foo}
{
?>
echo some raw HTML here if foo is true
<?php
} else {
?>
echo different raw HTML here if foo is false
<?php
}
echo "send more HTML to the client now";
?>

 

[Cogman]

In the beginning, servers only served static content. There was no programming involved it was simply barfing out html and images. Then people started clamoring for stuff to happen dynamically in response to user interaction. That was the birth of the modern web. C++ was briefly used as the dynamic renderer of choice, but it was quickly replaced by perl. However, perl is unwieldy, not well suited for dynamic webpage development. As a result, PHP was born, trying to be a better fit to dynamic webpage generation. PHP didn't really innovate much, it more copied perl and tweaked the syntax. It also made itself really easy to integrate with the top webserver dog of the time, apache (Perl was a bit of a beast to integrate with apache).

PHP maintained its top dog status for many years. However, as time went on, people started to want more and more complex webpages. PHP started to show its flaws as a language, and slowly, but surely, people started to look elsewhere for languages to fill the gaps. Java filled some holes with its JSP pages, but that was nearly as painful as PHP was for large applications. It wasn't until ruby on rails came on the street that there was a total paradigm shift in the way web development is done. It espoused strong MVC relationships, DRY principles, and general good practices for writing a webapp.

The good times with rails, however, would not last. Rails was constantly changing its API. The developers using rails were unexperienced with development in general. The environment quickly became very hard to deal with. Rails revved fast and changed things drastically, apps written for old versions of rails had no chance with newer versions without total rewrites to hand the "new" ways of doing things.

This caused an explosion of frameworks in various languages. Play, Django, CAKE, etc. Every language seemed to have 1, 2, or more frameworks that tried to be "like rails but better". Some focused on simplicity, others focused on ease of use, and others still focused on being backwards compatible.

This went on for a few years, then things changed. Google and others started to focus on single page apps. All of the sudden, server side rendering of webpages fell out of vogue. Javascript and html, we said, that is where we should be doing our rendering. That is where we should build our rich applications. This shift eventually spawned the birth of many frameworks for the clientside. Ember, Knockout, Angular, etc. All the sudden the server's responsibility shifted. The server became, once again, a static content host. The only difference now being that the server provides endpoints to access and look into the database.

Now a days, we are in a weird mixed state. The current hot stuff is doing everything in javascript, but also prerendering the pages on the server side so that end user/search engines don't have to wait for the content to load, then the endpoints to be hit, then the data to arrive. It can all be loaded on the initial page load with future content/data being loaded by ajax requests.

Where we go from here is a mystery. I see javascript frameworks stabilizing, but I also see the role of "compile to javascript" languages starting to take a much stronger lead role. I see it being the case that we will strive (and probably fail) to ensure that the server and client use the same language everywhere.

What would be funny is if we see a full circle made, where C++ compiled to javascript becomes the main webpage rendering experience. We already have the C++ to javascript compiler.

Tl;dr, You can't see server code on the client, you can only see what the server sends you. Older web technologies tend to do more on the server than newer technologies do.

 

[Red Squirrel]

The php code is actually executed locally on the server. If you put something like system("dir") (I might have that syntax/command wrong) it will output the info from the server. When the script is executed the output is then sent to the client, not the code itself. That's why you can't see the code.

Now there are different ways to set up stuff on a server. For example if you put php code in a .htm file and .htm files are not setup to run as php, then you'll get the code client side because the server was not told to execute it. This can be very dangerous as if scripts have passwords hard coded they can at some point be visible to public if a bad setting on the server causes a php file to not be treated as such. Something to watch out for.

 

[Graze]

lol just a little bit.
You have been on here from what is seems trying to digest as much as you can in programming and in something this basic you have a face palm worthy question?
It's called server side scripting for a reason....the html is rendered on the SERVER not the client.

 

[Ken g6]

Alright, I think the OP should have gotten the concept by now. Thread closed. -- Programming Moderator Ken g6