Image manipulation for cpg1.5.x

[Timos-Welt]

@Joachim:
Your changes in install/uninstall functions seems to have introduced a bug for me, see screen shot. I assume it's again a wrong cr/lf thing (see screen shot), but even if I correct it, I get

Code Select Expand


While executing query 'UPDATE cpg15x_config SET value= WHERE name='transparent_overlay'' in plugins/image_manipulation/codebase.php on line 171

mySQL error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'WHERE name='transparent_overlay'' at line 1


everytime trying to uninstall the plugin.

[Joachim Müller]

Not sure what went wrong. Please try rev 7066.

[Timos-Welt]

Fixed in SVN

[Αndré]

Okay here is what I found out using v1.8.

View an intermediate sized picture. Everything works fine.
Then (using Firefox) press ctrl+shift+r or ctrl+f5 (with that shortcuts you reload the page without loading data from the cache). Now the different effects will be applied after each other.
Now press f5 or call the page again. Everything works fine.

I cannot replicate that behavior in Chrome, as I don't know the correct shortcuts or the bug doesn't exist there.

Can someone confirm that behavior? I cannot reproduce it without the mentioned page reload, even if I remove the <button> tags.

[Timos-Welt]

That's correct, behaves here the same way, but only after force reload.

[Αndré]

I removed the <button> tags from the sliders in r7080. I cannot determine any unexpected behavior. Can everyone please test if the effects are applied simultaneously and not one after each other? Thanks.

[Timos-Welt]

Works, but doesn't look nice with my skin (or classic) because you removed the button class and now the font of the LED description is different from the button description.

[Αndré]

You're right. I hadn't noticed that. Changed in r7081.

[Timos-Welt]

Released v2.0. I don't think there's much more room for improvement to be honest.

[dougyang83]

nothing happen... something wrong?

[phill104]

nothing happen... something wrong?

Is that supposed to be a test report? You should be aware that there is currently no support for CPG1.5.x. Additionally you should read the board rules - http://forum.coppermine-gallery.net/index.php/topic,55415.msg270616.html#msg270616

[Joachim Müller]

That guy is a board spammer. I'm just currently deleting his postings and banning him.

[Αndré]

I noticed an issue.

Set 'Use cookies' to 'Yes' and login as admin or user. Now view some pictures (in my case I try to view a whole album, start at the first image and click 'next', 'next', 'next', ...).

After a few pictures (sometimes 1, sometimes >50) I get logged out. Reason: the session cookie will be updated (or a new one is created and the old one deleted, I'm not sure). The client_id (cookie name) stays the same, but the session_id (cookie value) differs.

I haven't figured out why it happens. Everything works fine if you disable the cookie usage in the plugin configuration.

Can someone confirm that issue? I tested it with Firefox 3.5, Chrome 3, IE6 and IE8 on my online gallery (updated from 1.3.x -> 1.4.x -> 1.5.x) with lots of plugins and on a new local installation without any other plugin installed.


I've attached 3 screen shots of my Firefox cookie console (if you keep it opened while surfing, it doesn't remove 'old' cookies. If I re-open my cookie console, only one cookie (the latest) exists).


Edit: I've traced it back to that function

Code (plugins/image_manipulation/js/image_manipulation.js) Select Expand

function im_createCookie(im_name,im_value) {
    var im_date = new Date();
    im_date.setTime(im_date.getTime()+62208000000);
    var im_expires = "; expires="+im_date.toGMTString();
    document.cookie = im_name+"="+im_value+im_expires+"; path=/";
}
Maybe it's better to save only one cookie that consists an encoded array instead of saving one cookie per image?

[Timos-Welt]

Please check the current SVN version, try it out and give some feedback if it improves things for you and if it works correctly.
It is impossible to save all data to just one cookie (max cookie size is 4096 byte). So the script will now use one cookie per 100 files, meaning
0 <= pid < 100 is saved in cookie im_0
100 <= pid < 200 is saved in cookie im_1
200 <= pid < 300 is saved in cookie im_2
...
So the number of cookies has dropped to a hundredth. Hopefully this won't overstrain Firefox anymore.  

[Timos-Welt]

BTW:
Number of cookies per domain allowed in modern browsers are
IE7/IE8 => 50
Firefox => 50
Opera => 30
Safari => no limit

If you set more cookies, the oldest ones will be deleted. So the new cookie solution will work for galleries with 4500 files without a problem in most browsers, but afterwards we're in trouble again... In the long run, it would be sensible to save the value in the database via PHP / AJAX.

[phill104]

What do you propose, adding it to the users table? Could lead to some very big databases. Maybe have an admin tool to clear data for any user that has not visited for x days.

[Αndré]

Seems to work better now. I've viewed about 400 pictures and didn't get logged out.

I suggest adding the data to the cookie only if the user has manipulated the image (value != 0). Currently I have cookie contents like

Code (Cookie 'im_877') Select Expand

_87753_0_87754_0_87755_0_87756_0_87757_0_87758_0_87759_0_87760_0_87761_0_87762_0_87763_0_87764_0_87765_0_87766_0_87767_0_87768_0_87769_0_87770_0_87771_0_87772_0_87773_0_87774_0_87775_0_87776_0_87777_0_87778_0_87779_0_87780_0_87781_0_87782_0_87783_0_87784_0_87785_0_87786_0_87787_0_87788_0_87789_0_87790_0_87792_0_87793_0_87794_0_87795_0_87796_0_87797_0_87798_0_87799_0_87701_0_87703_0_87705_0_87707_0_87709_0_87711_0_87713_0_87715_0_87717_0_87719_0_87721_0_87723_0_87725_0_87727_0_87729_0_87730_0_87731_0_87732_0_87733_0_87734_0_87735_0_87736_0_87737_0_87738_0_87739_0_87740_0_87741_0_87742_0_87744_0_87745_0_87746_0_87747_0_87748_0_87749_0_87750_0_87751_0_87752_0

Furthermore you could store only the pid%100 instead of the whole pid (i.e. if the pid is 87753 and the cookie name is im_877 you store only '53') and then drop one underscore to save some space.

Example.
Now:

Code (Cookie 'im_877') Select Expand

_87753_0_87754_0_87755_0_87756_0_87757_0

With my suggestion:

Code (Cookie 'im_877') Select Expand

530_540_550_560_570

What do you propose, adding it to the users table? Could lead to some very big databases.

Yes. That should be configurable in the plugin config. First we need to change the code in a way, that it don't stores unmanipulated images (value = 0).
If you think of exif data and hit/voting stats tables, we already have some space consumer. But that's the decision of the webmaster.

[Timos-Welt]

Just did that and encoded the values with toString / parseInt so we have now 400 pids per cookie. Meaning it will work in galleries with up to 18000 pid's. Values of 0 are not saved anymore. I think that's enough for most purposes.

[Joachim Müller]

I second Phill's suggestion to store stuff inside the database and not inside the cookie. Pruning old records in the database is of course mandatory. This should take care of registered users, which is our target audience imo. The feature to store something is not that important for guests imo - we could store some stuff inside a cookie for the guests, but ideally only a unique visitor ID that correlates to the database table that actually stores the per pic preferences.
If you decide to implement storage inside the database I suggest to ask the admin on the plugin's config screen what amount of records should be kept before the pruning of older records (the database garbage collection) kicks in. You could provide an estimate there as well about the space consumption of those records inside the database.
However, I suggest coming up with a database table of it's own instead of using the user table - to keep our table clean. Additional benefit would be that the unique ID for the guest and subsequently storage of the guest records inside the database could be implemented that way as well.
Using more than one cookie is bad design imo and should be discarded.

[Timos-Welt]

Might be a good way to handle it, but this would produce one AJAX request everytime a button or LED slider is touched. 
I think that's just plain overkill for many servers, and it certainly would drop the performance of the plugin in a negative way.