Sometimes it helps if you don't start hacking away, but stop and think for a moment. Here's what I've come up with - please don't take this as criticism, but as a discussion in an effort to play code pong.
There are two major flaws that this plugin has:
1) the fact that the URL parameters for the call to
http://example.com/gallery_folder/plugins/thumb_rotate/thumb_rotate.php contain so much sensitive information including paths and filenames that are hard to sanitize and easy to tamper with.
2) All thumbnails get stored within one folder, which will be no drama for 100 files, but it will become a problem for 1,000 files or 10,000 files.
The fix for problem #1 is easy: there's no reason why we have to pass all that sensitive data in the URL - we just need the file thumb_rotate.php (where the actual image calculation happens) aware of the data coppermine already "knows", then we can use what we already have: the picture ID (pid). For that, we don't call the file like this any longer
http://example.com/gallery_folder/plugins/thumb_rotate/thumb_rotate.php?img=albums/userpics/10001/thumb_flower.jpg°=348&bg=EFEFEF&brd=10&path=albums&brdcol=A2DB14, but like this
http://example.com/gallery_folder/index.php?file=thumb_rotate/thumb_rotate&pid=123All the parameters that we need already are known if you invoke coppermine. From that point on, you just need to accomplish that.
The second problem (with all files being stored in a silly manner inside the cache folder) isn't that hard to solve neither: if storing all those files within one folder causes so much trouble, then let's just not do that. So, where could we store the rotated thumbnail instead? Sure, within the folder in which the orginal thumbnail resides in as well. In fact, we do the very identical thing when using the watermarking mod - we store another copy of each file with another prefix. For this purpose, the prefixes "rotate_left_" and "rotate_right_" come to mind (as we need to store two copies after all). So what do we do now: we could create those two extra copies when the orginal file get's uploaded and maybe even alter the admin tools to come up with a mass-creation routine, but that would be beyond the scope of a plugin. So what then? Well, let's use the best out of both worlds and create the rotated thumbs on the fly (when they are needed), but keep them permanently. Basically, the lookup already exists in the code - it just needs to be edited to make it look into the proper folder.
Now on to the last issue: the cached copies of the rotated thumbs get obsolete if the user changes one of the options, so how could we handle that? In the existing code, you renamed all files, adding the possible parameters to the file name. This would make things nearly impossible to maintain, so this is where the database comes into play: let's add a column to the pictures table during plugin install. Into that field (for each image record), we'll just store a flag "rotated thumbnail exists" (true/false). Whenever a rotated copy was created, that database field is being updated. Whenever the config for the plugin is changed and all rotated thumbails become obsolete, you just run a query to empty the entire column.
So, this is all doable. The question is: who (if at all) is going to code this? Please give me your thoughts on my proposals.
Joachim