Native Javascript Ninjutsu: Dynamic JS with PHP
Sensei Says (dark ages, to dojos, to disciplines)
Javascript used to be a dark and ancient art, looked down upon by many web developers as a dishonorable – even malicious – ‘copy and paste’ language. Macromedia’s Shockwave – which later became Macromedia Flash, which even later became Adobe Flash – pushed audio, video, and interactive motion graphics onto the web in a cross-browser compatible format that all but decimated the need and appeal for Javascript. What little Javascript community there was began to seriously dwindle and die out.
And then the frameworks came to rise: Dojo, Yahoo! UI Library, Google Web Toolkit, jQuery, Prototype, MooTools, and many more. With these powerful armies by its side, the Javascript community quickly grew and regained its honor, competing heavily with the fluid animation and complex, real-time interactivity that Flash had delivered for years.
Javascript now seems to be a strong, healthy, and widely accepted language, frequently used and relied upon by web developers across the land. Yet how many of today’s programmers can write pure native Javascript without the aid of a framework? How many can perform AJAX requests without a framework? And most importantly, how many can craft fully cross-browser compatible code without a framework? In order to not become dependent on the frameworks – and thus risk sliding backwards into the dark ages – we must maintain a wide variety of practices: these are the native Javascript disciplines.
Discipline 2: Hensōjutsu (disguise and impersonation)
I mostly use static scripts when working with JS, though recently I’ve completed quite a few missions that involved the use of dynamic scripts. Dynamic scripting allows your JS to be changed based on the server side or client side situation (or both); different scenarios call for different measures, different variables, and sometimes even completely different code altogether.
Let’s begin with variables. Passing variables from PHP to internal JS is very simple:
<html>
<head>
<script type="text/javascript">
var numeric_variable = <?php echo $numeric_value ?>;
var string_variable = '<?php echo $string_value ?>';
</script>
</head
<body>
</body>
</html>
I’ve shown two examples above, the latter of which passes a string value to JS. It’s important to note that you must include quotes around the PHP block. This insures that the outputted value is properly wrapped in quotes, otherwise it could very well break your JS.
It’s also important to note that the above code relies on PHP to create and pass the values to the JS variables, and therefore the file itself must be parsed as a PHP file by the server. This is most easily done by making sure the file has a .php extension (suffix). There will certainly be some cases in which you don’t have the option of changing the main webpage you are working with to a PHP file. In that case there is an alternative solution, but it only works with external JS:
<html>
<head>
<script type="text/javascript" src="some_script.php"></script>
</head>
<body>
</body>
</html>
The above HTML code includes an external PHP script that contains the following code:
<?php echo "var string_variable = '$string_value';"; ?>
This echoes the dynamic JS that should be included into the HTML page. The PHP values are passed directly in the echo string. This works because we’re using double quotes around the echo string and I think it’s one of the most convenient ways to store PHP values in JS variables. If you need to use double quotes within the JS code itself then you must either escape those quotes with a back slash or echo a list of strings/values allowing you to switch to single quotes:
<?php echo "var string_variable = '\"$string_value\"';"; ?>
<?php echo "var string_variable = '", '"', $string_value, '"', "';"; ?>
The latter approach can be quite hard to read, and for this reason I typically stick with escaping double quotes whenever I’m required to use them. When you need to echo multiple lines of JS you can do so by simply putting lines break in the echo string:
<?php echo "var numeric_variable = $numeric_value; var string_variable = '$string_value';"; ?>
Although this has a purely aesthetic effect on the code, I find it to be invaluable in keeping my JS readable, especially considering that the code itself is stored inside of a PHP string (and thus I lose the benefit of syntax highlighting that would normally be applied within my code editor).
Very often my front end missions involve passing values from the client side to the server side. When including an external script you can add query parameters to the source URL and have these values passed by PHP to the echoed JS:
<html>
<head>
<script type="text/javascript" src="some_script.php?string_value=Hello World!"></script>
</head>
</html>
The above HTML code includes an external PHP script that contains the following code:
<?php $string_value = $_GET['string_value']; echo "var string_variable = '$string_value';"; ?>
The PHP code retrieves the value from the header GET method array and echoes it with the JS back to the HTML page.
Earlier this summer I finished my first Facebook Application, in which my work required me to pass an entire PHP array to be stored as a JS array. The technique I used may be helpful in illustrating that you can achieve quite a lot with a bit of creativity and understanding of both languages:
<html>
<head>
<script type="text/javascript">
var new_array = new Array();
<?php
foreach( $some_array as $array_key => $array_value )
{
?>
new_array[<?php echo $array_key; ?>] = '<?php echo $array_value; ?>';
<?php
}
?>
</script>
</head>
</html>
The above code prepares a new array in JS and then runs a PHP foreach loop. Each time the loop is executed the line of JS inside of it is added to the page, complete with the properly echoed PHP values. Once the server side processing is complete, the client side will execute all the prepared lines of JS and you should have an array that is identical to your PHP original; the same keys, and their same values.
By now you should be able to imagine the variety of ways that dynamic JS can be useful. You can use these same techniques to add more dynamic functionality to your front end projects. Now go out there, practice your native, dynamic JS in the field, and stay tuned for next week’s discipline: Including External JS.
Previous Disciplines
Discipline 1: AJAX with XHR
Are you smart? Innovative? Driven? If you’re interested in working on challenging projects in one of the world’s most fast-paced industries, why not check out the openings on our Careers page?
Comments
August 26, 2010 at 1:10 pm
Two tips on this matter: First, I would not use echo to output all the Javascript. It’s tedious and can quickly become quite unreadable when you’re dealing with a lot of code. I’d rather use PHP as a template language here, meaning: You treat the PHP file like it was a pure JS code file, and only use a few occasional PHP bits here and there where you really need dynamic values – much like your first code example, but in a separate file as opposed to inline script. Your code will become a lot easier to read and maintain.
Second tip: Don’t just blindly echo the PHP values into your Javascript – you’re opening a can of worms. The easiest way to shoot yourself in the foot without any malicious intent is to output a string that contains the same kinds of quotes that you’re using in your JS to wrap the PHP string: This wil cause a syntax error in your JS and all subsequent code will cease to work. So, as a minimum you need to escape all quotes in your PHP strings before outputting them. One way to do that could be the function addcslashes() – note the “c” in addcslashes
That alone might not suffice though, as you’ll still be vulnerable code injection attacks. If you’re receiving parameters for output in your JS from an untrusted source (which can be $_GET, $_POST, $_COOKIE, but also a database in case its data in turn comes from external sources), it’s absolutely trivial to inject malicious code into your JS. Say, a keylogger, portscanner, session hijacker or whatever else comes to mind. So escaping the output is not enough, you’ll also need to filter *all* input: Make sure numeric parameters can absolutely just contain numbers (cast to appropriate datatype, but additional logic checks are still recommended), check strings for expected values using either white-/blacklists or regex, or both, and use HTML/Script filters where you expect markup.
Just sayin’
August 26, 2010 at 2:08 pm
Oh, and one more thing: Converting a PHP array to Javascript (or any PHP data structure for that matter) is a one-liner:
var struct =
….with the added benefit of all values being auto-escaped (but not filtered).
August 30, 2010 at 12:08 pm
Thank you for the valuable insight Markus. I appreciate the tips. You are completely right about the validation and cleansing of data, but this article was meant as an introduction only and therefore the code was intended to be as simple and straightforward as possible. This makes it easier to learn and more digestible for beginners.
August 30, 2010 at 12:17 pm
That’s very interesting Markus, though I’m not sure I fully understand your method. It seems you’re suggesting to create a Javacript object and store the PHP data there, no? Where – and in what format – do you output the PHP value(s)? It would be great if you could provide an example.
September 20, 2010 at 9:56 pm
I was just reading this, and allthough I am not placed to discuss safety.
I have been testing this approach using the php heredoc syntax.
This could keep the js code in the some_script.php more simple to write and read, since you would not need to escape double quotes at all:
example some_script.php:
<?php
$str = <<
September 23, 2010 at 10:45 am
Dimitri, I appreciate you taking the time to read the article and post your thoughts. You make a very good point, and I myself have used the heredoc syntac in a lot of projects. There are many instances where it can prove to be an invaluable technique over the standard echo and print functions.
With that said, please realize that the above article is meant to primarily discuss native Javascript and this is why I kept the PHP code as simple and straightforward as possible. I believe that the article would deter from it’s original topic too much if it went into discussions of the various output methods available in PHP or the safety levels involved in each method.
I hope this makes sense. Thank you again for your constructive comment, please come back to read and respond to the rest of the native Javascript articles!