Getting array from query string

[csdude55]

I need to send data from one page to another, and I need it in a specific order. I'm pushing it to an array, so the original data might look like:

$arr[0] = '123_0.jpg';
$arr[2] = '123_2.jpg';
$arr[3] = '123_4.jpg';
$arr[7] = '123_8.jpg';

I'm finding two ways to retrieve this in the second page, but neither seem great so I'd like your feedback.


Option 1
I create the $arr array in a loop that reads from MySQL, so I could build a string inside of that loop to create:

$str = 'arr[0]=123_0.jpg&arr[2]=123_2.jpg&arr[3]=123_4.jpg&arr[7]=123_8.jpg';

Then I can include that in the query string for the next page.

Retrieving the data is a little tougher, though. I found that I can do this:

parse_str($_SERVER['QUERY_STRING'], $temp);

$arr = $temp['arr'];

print_r($arr);

/* Results:
*(
*  [0] => 123_0.jpg
*  [2] => 123_2.jpg
*  [3] => 123_4.jpg
*  [7] => 123_8.jpg
*)
*/

Downside here is that parse_str() plugs in all of the query string params to $temp, not just the ones I need. Since I can test to make sure that it fits the /\d+_\d+\.[a-z][a-z][a-z]/ format I don't think there's a concern of an attack, but I guess it's still possible.


Option 2
I can convert the original $arr to JSON to be included in the query string after the loop:

$str= 'arr=' . json_encode($arr, JSON_FORCE_OBJECT | JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES | JSON_NUMERIC_CHECK);

Then the second page would simply use $arr = json_decode($_GET['arr'], true); to convert the JSON back to the $arr array.

Downside there is that I'm not sure how to properly URI-encode that JSON string. I think that all of the flags I have listed here will do it right, but I'm not positive.


Is there a better option that I'm not considering?

If not, which of the two do you think is better?

[csdude55]

Downside there is that I'm not sure how to properly URI-encode that JSON string. I think that all of the flags I have listed here will do it right, but I'm not positive.

Well, I guess the obvious answer is:

$str= 'arr=' . url_encode(json_encode($arr, JSON_FORCE_OBJECT | JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES | JSON_NUMERIC_CHECK));

I'm leaning this direction, more or less with the logic that if it uses more built-in functions and seems more complicated then it must be better... LOL

[Sgt_Kickaxe]

Option 3? - use a php flat file database instead of JSON or SQL.

Create a php file, lets call it picture-data.php to keep it simple.

Add your info to it

$pic1 = './pics/123_0.jpg';
$pic2 = './pics/123_2.jpg';
$pic4 = './pics/123_4.jpg';
$pic8 = './pics/123_8.jpg'; 

The from your page you can perform an include_once of picture-data.php file from the top of the page and echo:$pic1; or whichever pic you want from inside the content where you want it to appear.

I added the ./pics/ because I assume you want the pictures in a folder called pics and the period is because the values are relative and don't have the full filepath. The pics folder is relative to the picture-data.php location, which you can put on your domain root level. Absolute urls work too in picture-data.php ie: $pic2 = 'https://example.com./pics/123_2.jpg';

A benefit to doing it this way if you can make changes to the picture-data.php file and they will apply to every page that calls the file AND it is much faster than requiring a database. It also works for writing to an array but you have to make sure you clear the array properly or junk will remain and make a mess the next time its called.

[csdude55]

In this case, the images are related to classified ads posted by site users, so there's no constant file that I could use like that :-/ It has to originate from a database.

The script that I'm rebuilding runs when the user clicks on an image to see a larger version. That second script (that shows the larger image) needs the entire array, though, so that the user can scroll through to see any other (enlarged) pics.

The first script loads the list of images from MySQL to show thumbnails, then would send the ID# in an Ajax call to a second script. That second script then ran the same MySQL query to recreate the image list for that ID.

My goal here was to send the array to the second script via the URL, rather than doing a second query that gets the same information.

[robzilla]

You can use $_SESSION to store data between requests. Or a key/value memory cache like APC.

Feels a little dirty to send that sort of data via the URL, but you could.

Honestly though, it seems to me that you shouldn't need two scripts for a simple slideshow.

[dstiles]

There is a length limit on query-strings. Also a possible security hazard? How about pushing the array to a session then recovering it from that session?

[csdude55]

I was using sessions before, but just recently eliminated it! LOL The cost of loading it was more than the savings. It wouldn't be too hard to bring it back if necessary, though.

Since I call the second script via ajax (JavaScript), I realize that I could potentially use localStorage. But since the second script is in PHP, I don't think that there's a way to retrieve the data.

Honestly though, it seems to me that you shouldn't need two scripts for a simple slideshow.

It's hand rolled so there's probably a lot of room for improvement. But right now, clicking to open a larger version of the image requires a second script that then uses the same JavaScript file for the slideshow. Even if it was the same script, I'm not sure how to do that with a single MySQL query. I'm totally open to suggestions!

[robzilla]

I'd think the page that shows the thumbnails initially ought to contain an array of the enlarged images so that clicking on any image does not require any additional queries, just the DOM changes required to load the enlarged image and the navigation elements. Depends on how you've set everything up, of course.

Do you have a memory cache in place? I'm assuming yes because you're always optimizing everything. APC is one of my favorite performance "tools", although I also sometimes use flat file based caching as mentioned by Sgt_Kickaxe.

But MySQL also has a query cache, of course. If you're firing the same query twice in a row, it's going to come back pretty quick the second time.