1.5beta1 - old image in the cache

[eon]

After you edit an thumbnail and you are back in the "Image"-page you will see still the old thumbnail on the page.
This is because it is still in the cache.

!!!You can solve this problem by give every thumbnail an unique name. *kill this line*!!!
EDIT: You can solve this problem by give every thumbnail a fake name. I assume eon does only change the link ( a fake link) to the image to prevent cache problem. It does not save the thumbnail with a new file name.
That's what I want to say ;).


Example:
$nocache = md5(time());
<img src='../thumbnails/thumb_$image?nocache=$nocache' />

Output:
/thumbnails/thumb_20051221152851_test.jpg?nocache=0e9237285ce7 c81b1847ebc2c1eb58d5

So the browser thinks it is a new thumbnail (new name) and download the image, but the image is still the same image with the same name.

[Joe[y]]

good call... i would add this to our development version but my pc's ethernet adaptor died.

made a mental note though.

[tinyblob]

personally i don't like using complex filenames to get around a client side issue (cache settings are determined by user). so i'm against this change, but we can discuss revisions like this once all the bugs/planned changes are out of the way.

hold on though. the thumbnails are already stamped with the time till minutes, we could just add seconds. nicer than an md5 hash, at least it's still human readable.

[eon]

personally i don't like using complex filenames to get around a client side issue (cache settings are determined by user).

As long as I can't control the cache rules for each website, this solution works for me. :)
This means that I don't have to turn my cache off or set the cache space to zero.

Maybe my BUGS aren't real bugs, but more hacks to make life easier. ;)

[tinyblob]

i am of the belief that if you can "fix" something server side, you shouldn't leave it up to the client.
but only if it doesn't compromise the software.

my personal belief is that the most important elements of the photoblog are the images. i like the filenames to be human readable, otherwise i'd consider using numeric ID's or just storing them in the database as blobs.

i'm okay with adding seconds to the timestamp, but i dislike the idea of a long hash string. overkill.

Maybe my BUGS aren't real bugs, but more hacks to make life easier. ;)

that's a good thing though, there are two parts of software advancement - fixing bugs and enhancing functions. usability is a big deal. infact, it's the field i was educated in, and a big part of my alternate identities dayjob.

[eon]

No extra long filenames in the database. I agree with you.
The code has nothing to do with the filename. The filename in your database will be still the same.

It adds, only on the adminside, a little string to the image.
<image name>?nocache=0e9237285ce7c81b1847ebc2c1eb58d5
So your browser THINKS it is another image and will download the image again.

Let me show you a piece of code where I use this code.
images_edit.php ~row 195.
echo "<li><a href=\"../index.php?showimage=$id\"><img src='../thumbnails/thumb_$image' align='left' hspace='3' /></a>

With the new code it would be:
$nocache = md5(time());
echo "<li><a href=\"../index.php?showimage=$id\"><img src='../thumbnails/thumb_$image?nocache=$nocache' align='left' hspace='3' /></a>

I hope that it is clear that it's not changes the filename in the database. It is just a bypass of the cache. :)

that's a good thing though, there are two parts of software advancement - fixing bugs and enhancing functions. usability is a big deal. infact, it's the field i was educated in, and a big part of my alternate identities dayjob.

Also mine ;). Communication and Multimedia Design.

[Joe[y]]

wheras adding seconds to the filename would alter the filename plus it would mean changing renaming the file anyway - so you might as well jsut give it the new timestamp in minutes.

[eon]

']wheras adding seconds to the filename would alter the filename plus it would mean changing renaming the file anyway - so you might as well jsut give it the new timestamp in minutes.

Humm, sorry, English is not my motherlanguage. Can you explain a little more? Do you think the modification is oke or..

Let me be clear.
This hack is NOT change the filename at all.

[tinyblob]

my mistake! that's what i get for skimming through your post and not actually LOOKING at the code ;)
haha. i figured you were suffixing a unique identifier to the image name. i'm guessing that you got that..

having looked at the code. yep. it's all good.
i've been meaning to look at caching/headers for the whole admin system since i installed the development version of 1.5, never actually got round to it though.

[Joe[y]]

it's a good idea in my opinion too. old cached thumbs really get on my nerves!

[eon]

Phoo, I was all most thinking that I was explaining something stupit ;).

[tinyblob]

Phoo, I was all most thinking that I was explaining something stupit ;).
This line gave me the wrong idea:

You can solve this problem by give every thumbnail an unique name.

[Connie]

well,

this is a browser problem, not Pixelpost problem

1) there is the message "you might reload..." on top of the page

2) every browser has the option to "reload not from cache" (for example shift + F5 or another key combination)

3) we cannot use even longer filenames, that is awful!!!!!

4) the original thumbnail must be replaced, not another one added...
how many postings will come: "I have only 20 images, but 28 thumbnails, I lost 8 images"

5) we can add the following two meta-directives to the header of the admin-html:
<meta http-equiv="cache-control" content="no-cache">
<meta http-equiv="pragma" content="no-cache">that will prevent the reading from cache

more is not necessary and unproductive as well!

[raminia]

I assume eon does only change the link ( a fake link) to the image to prevent cache problem. It does not save the thumbnail with a new file name.

btw, <meta http-equiv="cache-control" content="no-cache"> is great idea. we can add it to the header after each update of thumbnails. (there is a workspace for header of admin panel in 1.5 :) )

[tinyblob]

Connie, i've confused the matter. Eon wasn't suggesting we changed the filename, i just misunderstood.

I'd rather add the pragma and cache control lines in the head, but be aware of the '64K issue' in Internet Explorer:
http://www.htmlgoodies.com/beyond/reference/article.php/3472881

[raminia]

IE sucks:P

[tinyblob]

IE sucks:P
true, but irrelevant.
it's still the industry standard, so we MUST support it natively.

[raminia]

yeap

[Connie]

well, I will add the meta-directives into the header
I do this for some years already at many websites and never had problems

but for sure we will run into problems if we follow these suggestions from the website which Raminia linked to:
If you're really serious about the Pragma working, place another set of HEAD tags at the bottom of the document, before the end HTML tag and re-enter the Pragma. This is a suggestion straight from Microsoft Support. The page would look like this:

<HTML>
<HEAD>
<TITLE>---</TITLE>
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
</HEAD>
<BODY>

Text in the Browser Window

</BODY>
<HEAD>
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
</HEAD>
</HTML>

This way the Pragma is pretty sure to be read when the buffer is filled.The HTML will not validate at all for sure if you do add a <HEAD> after <BODY></BODY> again...

here you see what level these people at MS support have ;=):mad: :p :(
Instead of fixing their bugs, they recommend incorrect code!
I tested it, as I suspected, it does not validate at all

[raminia]

that was not me;)

[tinyblob]

i linked to it ;)
i wasn't suggesting we do it, just that we should be aware of it!

[Connie]

ok! I understood, captain!

[GeoS]

This no cache should be an option. I dont have problem with cache and I dont want to overload server without big need of it. Admin addon would be the best thing.

PS Here we see that admin_html_head is quite useful :)

[blinking8s]

clearing my cache is just common sense, maybe its cause i used to work in flash a lot...humm...