News:

cpg1.5.46 Security release - upgrade mandatory!The Coppermine development team is releasing a security update for Coppermine in order to counter recently discovered vulnerabilities. It is important that all users who run version cpg1.5.44 or older update to this latest version as soon as possible.[more]

Taking a deeper look at the resources used I figured out that the silk iconset has been used: that's not possible! The license that the silk iconset comes with does not allow the usage with GNU GPLed projects. That's why I have removed them in favor of crystal icons along with some other minor improvements in v0.6. Additionally, the changelog format was changed to cpg standards. Please let me know your thoughts.

The license that the silk iconset comes with does not allow the usage with GNU GPLed projects

The license of the silk icon set has changed a few times during its existense. But I agree: Why use them if there are other nice ones under GPL.Histogram and BBCode icons were my own work and may be used in the future (the current ones are not that intuitive).Current SVN snap shot doesn't work in IE6/7/8 at all.Edit: found bug and fixed. TW

Quote

There is currently no button to return a pic from fullsize to intermediate

Correct. The main reason for using intermediate images and not generally using the big ones is avoiding the loading times. Once the HQ image is loaded - where's the sense in switching back to the small one? EnlargeIt takes care so it will always fit into the browser viewport.

Quote

The second is the z-index is not high enough

The zIndex of EnlargeIt's objects starts with 9700. Some older browsers do not support setting zIndex via Javascript > 10000. I recommend to reduce the zIndex of your Menu a bit.

giood work. Sadly, I have been working in in-depth changes as well, so our commits might have overlapped. Currently, I have left the svn repository in a state where the plugin doesn't fully work as expected, so that's something I could use your help with. But let me report first what I did and why:I have changed the installer and uninstaller functions and dropped the extra table that was used to store the plugin's settings. Instead, I have converted everything to use the config table.This works as expected and the config page should give you a new look that's is pretty impressive compared to the old one imo. However, I need to figure out how to transport the data from PHP to JS. The recommended way in cpg1.5.x is to use the set_js_var method, which I did for some variables. Others don't work so well, especially the arrays. That's where I could use your help with. Please take a look at what I did inside the function enlargeit_head. To be able to fix this I swapped from the compressed js file to enlargeit_source.js for development reasons. I'm having a hard time the to read the button array; maybe you could take a look at that first.However, the enlargeit script now just loads on the pages it is needed on: if the js part of enlargeit is needed on more pages, just edit the $enlargeit_pages_array.

Another minor issue that is not working as expected is the farbtastic color picker; it used to work in a version on my testbed, (sadly a version that didn't get preserved by a commit to the svn), but then I must have over-edited, as it stopped working at some stage while I performed some more hacks on the plugin_config page. Maybe someone would like to take a look at that issue as well....

I hope you don't mind me butting in that massively; looking forward to your reply.

Just had a quick look at the latest codebase.php. The EnlargeIt! javascript is a seperate product. To ensure that users of the plugin can safely use the latest javascript version at any time in order to benefit from bug fixes and new features, it's essential IMO to not change anything inside enlargeit.js and enlargeit_source.js. This means, the 'standard' way of setting Javascript variables inside of cpg1.5 should not be used in this case. Parameters should be modified by embedding the script and directly after it setting the variables as desired.

Try it yourself: Get the latest stable version (the script version that comes with the plugin is a newer development release) and copy the js files to the plugin folder. The plugin should work as before, just these new features will be missing / not working. Using EnlargeIt! Building Blocks, the user can even generate his own javascript version with only the features that are really needed. This way the additional Javascript file can easily kept < 20 KByte. Please restore the original comments in the JS files for the same reason. I think the line "This comment MUST stay intact for legal use, so don't remove it." says it all.

The other changes are very neat IMO and I really appreciate your work.

Please restore the original comments in the JS files for the same reason. I think the line "This comment MUST stay intact for legal use, so don't remove it." says it all.

As far as I can see the comment is still in the file, at the very top. I'm very picky with such issues, that's why I haven't removed that first line, but converted it just to sit inside the "regular" header. But if you're not fond of that I will of course go back to the original method, with the shorter credits at the top.

The EnlargeIt! javascript is a seperate product. To ensure that users of the plugin can safely use the latest javascript version at any time in order to benefit from bug fixes and new features, it's essential IMO to not change anything inside enlargeit.js and enlargeit_source.js. This means, the 'standard' way of setting Javascript variables inside of cpg1.5 should not be used in this case. Parameters should be modified by embedding the script and directly after it setting the variables as desired.

I can see your point and of course I will respect it. Please give me some days to roll my changes back and come up with a solution that will work with the enlargeit.js out of the box.

However, I'm concerned that the method you propose to use will have a negative impact on the caching performance of the enlargeit script in the long run.I agree to undo my edits inside the core of the script for the said reasons, but I'd really like you to review the following proposal: you already have a line inside enlargit_source.js that reads

// stuff to leave alone. I suggest renaming that to "do not edit below this line". All edits of the JavaScript file should come before that line. They could be used to "translate" the variables from external scripts like I did partially with lines like

var enl_brdsize=js_vars.enl_brdsizeThis way, the third party app (coppermine in this case) will not interfere with the way that enlargeIt works in the first place.

Another thing I suggest to review is the way you handle the array for the buttons: it's not that intuitive to come up with custom features or custom buttons as long as you stick to one single icons graphic that you chop into bits script-wise: I understand that there can be a slight performance penalty for single images (instead of the script only having to load one monolithic image) to be used as buttons, but I guarantee that there will be only very few non-coppermine users who will be ready to look into enlargeIt in detail just because of the handling of the icon bar.

Gongrats for your documentation though: it's excellent. I suggest making it available as an HTML document as well for better results in search engine ranking.

I've been testing out this at www.windsurf.me.uk/cpg133 . One little bug (I think, it could just be my computer) and a little idea.

First the potential bug. On the bbcode page in IE8 on Vista ( ) I cannot highlight the code top copy it, it is ok in FF.

And now for the idea. For the bbcode [IMG] copy I like to display the intermediate pic, other gallery admins might prefer the thumb. With this in mind how about changing the dropdown in the config page to - yes, with link to intermediate : yes, with link to thumb : no. I simply adjusted the code but it might be nice for admins to have a simple choice.

Logged

It is a mistake to think you can solve any major problems just with potatoes.

$superCage->server->getRaw('HTTP_USER_AGENT');, but remember not to trust what is returned using that method: you need to explicitely sanitize the content. But why don't you just use the function cpg_determine_client that is built into the core for something as simple as checking the browser?

@Timo: rev 6761 contains the code that I have changed as per your suggestions to restore the js files as they were. I'm having troubles though to figure out why the JavaScript variables that I populate using the function definition for enlargeit_head in codebase.php are not being taken into account at all. Could you please look into this particular issue? Thanks in advance.

I'm having troubles though to figure out why the JavaScript variables that I populate using the function definition for enlargeit_head in codebase.php are not being taken into account at all. Could you please look into this particular issue? Thanks in advance.

I think I found it, SVN has an updated codebase.php. You set enl_brd to nothing (it shouldn't be configurable, as the border is the AJAX window - without it, none of the AJAX buttons will work. Use border size = 0 for no border instead).

Some things I found:- works only on thumbnail.php, but should work on index.php as well- Umlauts are cryptic on config page (see screenshot)

Thanks for the report. The fix was dead easy: the German language file was not encoded in utf-8 (as all coppermine files should be), but in iso8859-1. I changed the encoding - now the Umlauts should no longer look scrambled. Please take a look at your editor: if you can, you should set it to use utf-8 as default encoding for new files to avoid such issues.

What happened today@Timo mainly: rev 6769 contains my fixes from today: note that I have changed around the population of the JS vars in codebase.php, as there is no such thing as $CONFIG['plugin_enlargeit_brd'] nor $CONFIG['plugin_enlargeit_shadow']; I have deliberately dropped those options from the plugin as I find them useless double-option: instead there's a lookup wether the border width / shadow width are set to zero - if that is the case, the corresponding JS var is being toggled. I have added some other minor fixes, but my main issue remains: the buttons till don't show up. I would appreciate your help once again: please perform a full checkout to get the current images folder with it's sub-folders populated properly, because the code you committed didn't work for me. Also please keep in mind to always come up with a comment that describes what you are doing when committing to the SVN. If you can, please edit the readme file as well and add your comments to the changelog section there.

PackageI want to encourage others who are interessted to look into this plugin as well, that's why I'm packaging the current SVN stage and attaching it to this posting: the attached plugin does not fully work as expected, so it's merely meant for contributors who are willing to look into this code-wise. The attachment is not meant to be used live. The version count currently is at version 0.10 (which is not the same as 0.1, but the minor release that followed v0.9); I plan to go to v1.0 once the buttons work as expected to mark a first production-ready stage.

WishlistI understand that you don't want me to change the file enlargeit.js or the correpsonding source file over. That's why I want to request changes to go into the enlargeit core for the benefit of the coppermine plugin that at least won't hurt for the standalone code you maintain:

Add a variable to specify the icon-subfolder

Add a variable to specify the backgrounds-subfolder

Add a variable to specify the flash-file subfolder

Add a variable to specify the cursors subfolder

Add a variable to specify the path to the loader.gif animation

The term "drag&drop" does not describe properly what the option "Drag & drop of enlarged pictures" is used for: drag & drop means dragging an element from one container on another container or element and then let it drop to make something happen when you drop it. That's not the case. I suggest renaming that feature to "move around" instead of "drag&drop"