How can a query parameter be injected into a PHP script processed as input to an object during object embedding? The case in point concerns a Shockwave player fed a music playlist produced by the script, as in the code specimen:
<object type="application/x-shockwave-flash" data="swf_player.swf?sort=track&skin_url=player/skin.xml&playlist_url=music/Playlist_Generator.php">
where swf_player.swf recognizes query parameters 'skin_url' and 'playlist_url' and Playlist_Generator.php recognizes parameter 'sort'. The playlist generator script identifies .mp3 tracks in a designated directory and de-constructs them to pick up ID3 information tags (artist, title, track number, album, etc.). It then emits a playlist consisting mainly of a track list with associated track information which points at the .mp3 directory where swf_player can find the tracks.
Playlist_Generator.php extracts the sort parameter from the query string when the generator is invoked directly on a browser's address bar, as in
http://localhost/music/Playlist_Generator.php?sort=track
by way of
$sort_type = $_REQUEST['sort'];
$sort_type = !empty($sort_type) ? $sort_type : 'title';
The sort parameter indicates the user's preference for track ordering in the playlist. Direct script invocation was the setup used when the playlist generator was under development as it facilitated copious debugging information. However, once the generator is used 'inline' with the player, as described above, query parameters are not available to it. In the embedding specimen shown above, the playlist generator's PHP code is processed during query expansion, and thus query parameters, in particular 'sort', are not available to it.
I should be most grateful to any of you who may have devised a method for a PHP script to acquire external information when processed 'on the fly'. While the above problem has been framed as an inability to access query parameters, alternatives may exist whereby a script can acquire external information. All questions, comments and especially suggestions welcome!
In advance, thanks to all who contribute.
I believe an answer to your question is:
<?php
$sort = isset($_GET["sort"]) ? $_GET["sort"] : "title"
?>
<object type="application/x-shockwave-flash" data="swf_player.swf?sort=<?php echo $sort ?>&skin_url=player/skin.xml&playlist_url=music/Playlist_Generator.php">
EDIT: on second thought, I doubt this is the answer you're looking for. That do you mean by 'the generator is used inline' ?
A server side include (SSI) of XSPF_Playlist_Generator.php which creates a playlist file does the job quite nicely. (Enabling SSIs on the server may be required. See e.g. http://httpd.apache.org/docs/current/howto/ssi.html and other SSI sites which the search phrase 'server side includes' elicits for configuration and syntax reference.) Note the use of PHP to insert query parameter sort's value, obtained from the browser's address line, into a query string attached to the php file's url:
<!--#include virtual='music/XSPF_Playlist_Generator.php?sort=<?php echo $_GET['sort'];?>' -->
In addition to an emitted XSPF playlist, the playlist generator is also able to write the playlist to a file. This capability was enabled, and the playlist file then read into the SWF player as:
<object type="application/x-shockwave-flash" data="swf_player.swf?skin_url=player/skin.xml&playlist_url=music/XSPF_Playlist.xspf">
... creating (regrettably) a two step process. The intermediate step appears necessary since I have not discovered a means to inject the value for query parameter 'sort' off the browser address bar directly into the php file. For those who are curious, the player recognizes two types of values for parameter playlist_url: a .php file which generates a playlist 'on the fly' (injection into which would have been a one step process), and a (quasi-)static .xspf file which can be re-generated whenever the page is refreshed (the tedious, intermediate second step).
The solution has been successfully tested on IE, Opera, Safari, Firefox and Chrome. Note that Apache, nginx, lighttpd and IIS are the four major web servers that support the SSI language.
Thank-you to all who contributed. Anyone who may have been unable to follow along and would like the complete source code, please email me your request: kanone@rogers.com.