Thumb_Rotate plugin for cpg1.5.x

[Timos-Welt]

I think a plugin like this would be a very good start to learn more about SVN, committing etc.

I see you solved the issue that caused the strange folder permissions. $CONFIG['default_dir_mode'] was set correct in my 1.5 installation (0750), I had already checked that. But I never had done file and folder handling with PHP before, so I sat a few minutes in front of the two lines without finding the problem. (Then the phone ringed and a financial adviser wanted to tell me the usual lies that his offer was the best of them all).

I've added the unsecure announcement to the 1.4.x version, too.

regards
Timo

[Joachim Müller]

I think a plugin like this would be a very good start to learn more about SVN, committing etc.

I agree.

@all interessted devs: Please register at sourceforge.net (if you haven't already done so) and let me know your sf.net user name, as I need that to add you to the list of devs with SVN write access. Please read up the details on how to access the SVN in the dev section of the cpg1.5.x docs.

[Joachim Müller]

OK, thanks for the PMs with the Unix names - I have added SVN access for you. Remember to always check out before checking in.

[Timos-Welt]

Version 0.7 should be secure.

[Joachim Müller]

@Timo: Good work - I had a look at your commit - looks OK. Only one issue: please do always comment your SVN commits.
Sadly, both your efforts as well as mine have been simultaneous, while my changes are much more dramatic: in fact I did re-code quite a lot of the plugin, providing a fallback for the function imagerotate, moving the code from thumb_rotate.php into codebase (there was no need for that extra file, it just caused a lot of extra resources consumption, generating the rotated thumbnail twice. Now the plugin should be safe to use in terms of security. As both code changes happened simultaneously, only one can remain.
I have commit my changes and attached a packaged version, counting the version counter up to 1.0 to mark the re-write and subsequent change of the way the plugin works. Please take a look at the code improvals and the readme file.

@all: When updating the plugin, make sure to manually delete the cache from the old version - the files inside the edit folder are not needed any longer.

Because of the impact of the security vulnerability I have temporarily disabled the plugin on the site I initially refered to as well to make sure nobody will attack it using the weakness. I recommend temporarily turning off the demo as well.

I have re-enabled the plugin on the site I refered to initially. It's safe to re-enable your demo as well imo.

Cheers

Joachim

[Timos-Welt]

please do always comment your SVN commits

I will, sorry.

Regarding your changes:

I think it's not a good idea to do the image calculation inside of codebase.php - in the end, it's very ressource intensive, and it's quite likely that people will get server error messages on large thumbnail pages with for example 4 colums and 20 rows, especially on slow servers and/or free hosting services. GD is much more CPU hungry than Imagemagick, at least on my server.

[Joachim Müller]

But how is this suppossed to make a difference? The little overhead of coppermine's array definitions and database calls will not hurt in comparison to the resources comsumption of the GD image manipulation, so I can not see your point here to stick this into a separate file. To make it secure you'd have to apply the coppermine logic (db queries tec.) to the extra file as well, so what is gained? Maybe I'm not getting the concept you propose - could you please elaborate why you insist on two files?
Please take a look at the nifty cache creation that I have come up with - the cache will eventually grow as needed. Quite frankly, the method I have chosen is far less resources-consuming than the original, as you do heavy manipulation of the entire HTML output with regular expressions. You do that constantly, for all pages generated by coppermine - that's overkill. In the new version since 1.0, there's only a moderate str_replace going on on the thumbnail param array. Maybe someone can do benchmarks and compare the two versions to try to find out which version is less resources-hungry.

The image creation process in itself is not optimal yet and can be improved still to eat less resources, especially in memory consumption.

I have added most of the features in the version 1.1 that I have attached (is in the SVN as well). Please review.

Cheers

Joachim

[Timos-Welt]

But how is this suppossed to make a difference? The little overhead of coppermine's array definitions and database calls will not hurt in comparison to the resources comsumption of the GD image manipulation, so I can not see your point here to stick this into a separate file. To make it secure you'd have to apply the coppermine logic (db queries tec.) to the extra file as well, so what is gained? Maybe I'm not getting the concept you propose - could you please elaborate why you insist on two files?

Most webhosts I know of limit the php script duration time that a server will execute, the CPU time of a script as well as the memory consumption. If you exceed these limits, the server will time out with a blank page or deliver an error message. If you execute the graphic creation as a seperate php script, every single call has the full ressources on its own. If you do it inside of the CPG script, all thumbs together will have to share the server limits, so it's quite likely that a server time out will appear on slow or restrictive configured web servers.

Let's assume a thumbnail page is called with 4 columns and 20 rows, that's 80 thumbnails. And let's assume that it's the first call of this page, so all thumbs have to be created on the fly. That's 80 files of input with 3-5 Kbyte, and 80 transparent rotated thumbs as output with 22-24 Kbyte, together 3,2 MB of files that have to be touched. Each new thumb is created in five steps (create new bigger empty picture, make transparent, create border inside it, paste existing thumb in the middle, rotate it) that are CPU intensive. Cheap or free web hosts will limit the CPU time a script may use to 2-10 seconds. IMO this alltogether smells like time out. 

I really like your codebase.php, it is very well done and much more clever than mine. What I miss is the correct width and height of the generated thumbnails; while the previous versions ignored these info completely, now the thumbs are presented scaled down to the size of the source thumbnail, which looks ugly and/or unsharp in some browsers. If you adhere to the thumb creation inside of codebase.php, I propose that <tt>thumb_rotate_image_create($CURRENT_PIC_DATA)</tt> should return as well the width and height of the generated thumb so we may save these information to the new table as well and use them when displaying the new thumbs.

regards
Timo

[Joachim Müller]

Let's assume a thumbnail page is called with 4 columns and 20 rows, that's 80 thumbnails.

And that's the reason why this is wrong imo. Part of the concept: this plugin is a resource hog. People on servers with limited resources should not display 80 thumbnails on one page anyway. They should not use this script neither. Yes, this script can bring down your page, but you will notice as well. I'll look into a workaround for those one small resources as well - it will probably help to provide admin tools as well that do not only delete the cache, but a tool that builds the cache in the first place, but slowly.

[Hein Traag]

Goodmorning!

Tried the plugin on my testbed. Albums folder and all child folders set to 777. And it does make the rotate_** files but it does not display the images.

Any idea what might be wrong here?

Cheers
Hein

[Timos-Welt]

Hein, which version of the plugin are you trying? 0.7? 1.0? 1.1? The current SVN? I tried out 0.7 and 1.1, both work well here.

regards
Timo

[Hein Traag]

I am using 1.1 but i think it has something to do with rights. It does make the new rotate files with borders but without the actual thumb inside it. I'll do some more testing and probing..

[Joachim Müller]

@Hein: is your testbed publicly accessible, so we can have a look?

@all: I have added some more features and updated the SVN files accordingly. A new package with (version 1.2) is attached. To upgrade the plugin, please uninstall the plugin (using the plugin manager) and then re-install to make sure the database changes have an impact.

In version 1.2 I'm trying to cover some of the issues that Timo has brought up. Trying to solve Timo's concerns about resources consumption on "weaker" servers I have added two options to the config: one allows to make the plugin admin-only to allow the admin to build the cache in advance for a larger site and only after having built the cache finally turn the admin-only toggle off to let visitors access the rotated thumbnails. The other option allows you to specifiy a delay period between each time a rotated image is created. For this, the script will return the unrotated thumbnail if it has created a rotated thumbnail within the past XX seconds (where XX is the period you specify for the delay). The delay will as well be taken into account for the batch-fill screen that I have come up with: this screen will allow the admin to batch-create the rotated thumbnails without the need to click through the entire gallery thumbnail pages.
Please test thoroughly and post your feedback.

Joachim

P.S. I have started to work on an unfinished option that allows you to create thumbs with rounded corners as well. That option currently will only show on the config screen, but it can not be selected yet.

[Hein Traag]

Sure, it's at cpg15.rondvierkant.nl

I installed the 1.2 version and now it does show the regular thumbnails and when i check the ftp album folder it does have rotate files.. I'm guessing it's a rights issue but have not figured out what it might be yet.

[Timos-Welt]

@Hein:
I can reproduce your issue when I install other plugins at the same time (e. g. EnlargeIt! v0.3) and play with the plugin order. Seems to me like thumb manipulation conflicts. But I still have no idea why it happens.

@Joachim:
I like the idea of rounded borders, a shadow would be nice as well. I already tried to code this, but it would require alpha transparency in the png files, and different php/gd versions handle this quite different, and some browsers (the terrible IE6 for example) cannot display them anyways, so I dropped the idea.

What's still missing is the correct sizes of the manipulated thumbs; ATM, they have the size of the original ones and are displayed scaled down. thumb_rotate_image_create should return the sizes of the generated thumb, so it can be saved to the plugin table together with the thumb name:

Code Select Expand


function thumb_rotate_image_create($CURRENT_PIC_DATA) {
...
...
...
// rotate image
$rotate = imagerotate($finalimg, $degrees, $fin_bg);
$finalsizex = imagesx($rotate);
$finalsizey = imagesy($rotate);

// set transparency
imagecolortransparent($rotate, $fin_bg);

// deliver png and save to cache
$result = imagepng($rotate, $CONFIG['fullpath'] . $CURRENT_PIC_DATA['filepath'] . $CONFIG['plugin_thumb_rotate_thumb_pfx'] . $CURRENT_PIC_DATA['filename_without_extension'] . '.png');
if ($result) {
$return = array($CURRENT_PIC_DATA['filepath'] . $CONFIG['plugin_thumb_rotate_thumb_pfx'] . $CURRENT_PIC_DATA['filename_without_extension'] . '.png', $finalsizex, $finalsizey);
} else {
$return = '';
}


[Hein Traag]

@Timos
I deinstalled all the other plugins but no luck yet. It stil only creates the empty rotate pictures. I'll upgrade first to the latest build op 1.5 and go from scratch.

[Joachim Müller]

@Hein: do you actually have the function imagerotate available or does the plugin fall back to the surrogate it comes with?

@Timo: thanks for your input - I'll look into it.

Regarding IE's lack of support for PNG transparency: that's why I toyed with the idea to completely rely on the config option for the background color and create jpg files in the first place, as an alternative.

Joachim

[Hein Traag]

The function imagerotate is not avaible to me. So the plugin seems to fallback to the surrogate.

[Joachim Müller]

That's probably the reason - I haven't been able to make the surrogate work as expected on every setup.

[Hein Traag]

Okay so should that be mentioned somewhere that it works better if that function is avaible? Or does that not matter once the surrogate is functioning as it should?

Either way i do like this little plugin a lot. Although it eats up space it stil adds a bit of extra to the look of a site. Nice work guys!