Arrays, Sessions and serializing images

stephenrs

Hello,

I'm trying to store an array of serialized images (gifs) in a user session for recall and display in a later page. I'm thinking that this should be possible, but I'm not having much luck. Here's a trimmed down version of the code I'm using:

Page 1:

function X($imgdata){
global $imgctr, $serimgs;

$serimg = base64_encode(serialize($imgdata));
session_start();
if (!session_is_registered('imgctr') || !session_is_registered('serimgs'))
{
    $imgctr = 0;
    session_register('imgctr');			
    $uimgs = array();
}
else
{
    $imgctr++;
    $uimgs = unserialize($serimgs);

}

$uimgs[$imgctr] = $serimg;
$serimgs = serialize($uimgs);

session_register('imgctr'); 
session_register('serimgs');

}

Page 2:

session_start();
if (session_is_registered('serimgs') && session_is_registered('imgctr'))
{
$uimgs = unserialize($serimgs);
$imgdata = unserialize(base64_decode($uimgs[$imgctr]);
header("Content-Type: image/gif");
echo $imgdata;
}

The original image is being read from a MySQL database, and so far I've been able to serialize a single image, store it in a session, and recall/display on a separate page - but when I try to use an array of images, it won't work.

Is there any reason I shouldn't be able to do this? Am I doing something wrong?

Any help would really, really, really be appreciated.

Thanks,

Stephen

Weedpacket

Well, for one thing the sessioning routines already do appropriate (un)serialisation; so you don't have to do any of that encoding/decoding business yourself.

Second is that things are a lot simpler when you use the $_SESSION[] array, instead of session_register() and session_is_registered() and so on. Using the latter is just an unnecessary complication that leads to confusions. For example, registering a session variable after giving it a value is a sure way for that value to be trashed by a value already in the session.

stephenrs

I forgot to mention that the server I'm working on for this project is running php v4.04, so $SESSION hasn't been born yet. I'm guessing that $HTTP_SESSION_VARS with $GLOBALS will work though?

I found a workaround that involves an extra call to the db (which is what I was trying to avoid), but there seems to be some wisdom in your post, so I'll try it without the extra serialization, and/or session_register-ing in the right place.

Thanks,

Stephen

stephenrs

No luck with the suggestions above...I guess I'll have to live with the extra db calls for now...Any other suggestions out there?

Weedpacket

$HTTP_SESSION_VARS[] should be sufficient. Declare it global at the start of the function.

I guess the extra db calls are so that you can session ids, and use them to call the image back out on each page. That's what I'd probably end up doing, but - honestly - only if I was forced to store the image in the database in the first place. I've got problems with the idea of using a database as an inefficient sort of filesystem; I'd be much happier storing the images in a suitable directory, and then I only need to store their filenames in the database.

stephenrs

apparently there is a 4k limit on the size of session data. so i guess, what i was trying to do was really an abuse of the session concept. and the reason it worked with one image (<4k), and not an array of them (>4k) is now clear.

so basically, i solved this by pulling the image from the db later in the application flow...

i hear you on storing images in the db in the first place, and i debated this, but i'm building a site/app that will have to be maintained by non-programmers (to put it nicely), so i'm thinking it will be a little cleaner, and more idiot proof to keep the images in the db, and give the client bullet-proof tools to manage their content.

thanks for your input.

Weedpacket

Originally posted by stephenrs
i hear you on storing images in the db in the first place, and i debated this, but i'm building a site/app that will have to be maintained by non-programmers (to put it nicely), so i'm thinking it will be a little cleaner, and more idiot proof to keep the images in the db, and give the client bullet-proof tools to manage their content.

I've written plenty of administration tools for end users that involve uploading, storing and manipulating images. They don't care how they're stored, just so long as the pretty Web interface I wrote for them does what it's supposed to.

stephenrs

it's not a question of whether or not the users care where the images are stored - of course, in any case this will be transparent to them. i've written a few admin systems also, but this is the first time images were involved. so, i'm reusing code modules that are geared toward databases, and i'll be able to write a tighter app by adding a BLOB field to a table (for example), rather than writing file system access code for images. not involving the file system means fewer pieces, which by definition means fewer potential problems.

for this particular site, this also means that rather than >1 trips to the server and file system to get content/data+images, it can all be done at once. further, the system will be more easily portable if i (or someone else) need to move it down the road. a few html templates, some php, and a database - very self contained, and easy to maintain.

also, we're talking about relatively few, and small images (10's, not 100's or 1000's) - the images are a side dish, not the main course...

...and if it turns out that i run into unforeseen problems, i can always change the BLOB into a varchar, and keep a filename there (for example), but so far i haven't thought of, observed, or been shown a real techincal reason for storing them on the file system...