Upload applet (JUpload) : the easiest upload ! - Page 13 Upload applet (JUpload) : the easiest upload ! - Page 13
 

News:

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

Main Menu

Upload applet (JUpload) : the easiest upload !

Started by etienne_sf, April 28, 2007, 10:41:28 AM

Previous topic - Next topic

0 Members and 6 Guests are viewing this topic.

etienne_sf

Quote from: phill104 on October 27, 2007, 11:10:25 AM
Insert big clapping emoticone here.

I have tried uploading with various canons and yes, with that set to true the purple stuff goes on but setting to false cures it.

I've tried with files from Pentax and Nikon and it doesn't seem to cause a problem either way. Must be to do with Canon's metadata.

It would be nice if SUN could get their applet working properly to take this into account.

Well done.

Nice that the trick works. For SUN to correct the stuff: I'll need to make a little sample of the problem. As all reflex Canon seems to have the problem, I guess they will correct it.
I have an EOS 20D, but almost never shot in portrait mode. I prefer RAW files, and thus I use the 'advanced' modes.

Etienne

dke

Awesome work etienne_sf thanks alot for the changes!

erostew

There's a couple of things I can point out after testing things fully.

First is that if you change the metadata upload to false it seems impossible to change it back without breaking something. I tried to reset it to true to test a couple of things, and after that every attempt at upload generated an exception. That continued until I changed it back to false. I even uninstalled the plugin, deleted the jupload folder from the server and deleted anything related to jupload from the database. After reinstallation, without touching any settings the exceptions still occurred. After changing the parameter to false in the config, it started working again.

Second is that this mod is not really compatible with Stramm's ModPack. Both Mods use non-standard picmgmnt.inc.php files. So files get resized, rotated and uploaded okay, but if you are using "exact" thumbnails they are distorted because j_picmgmnt.inc.php doesn't support cropping. It also doesn't support watermarking or mini thumbs. So after upload you have to go into admin tools and regenerate your thumbs and images to get watermarking and cropping.

It's still worth using just for ease of use with uploading, rotating and resizing, but my wishlist would include compatibility between the 2 mods. I used WinMerge to compare the files, but unfortunately there are way too many differences to make it easy for me to figure out what to change. My first couple of tries just broke the jupload mod so I gave up on it.

Regards

etienne_sf

Quote from: erostew on October 28, 2007, 02:50:13 AM
First is that if you change the metadata upload to false it seems impossible to change it back without breaking something. I tried to reset it to true to test a couple of things, and after that every attempt at upload generated an exception. That continued until I changed it back to false. I even uninstalled the plugin, deleted the jupload folder from the server and deleted anything related to jupload from the database. After reinstallation, without touching any settings the exceptions still occurred. After changing the parameter to false in the config, it started working again.

Hum, hum,

That's strange. I would say: this can not happen !
Would you say, there is a bug somewhere ...  :o

  I'll check that.

Quote from: erostew on October 28, 2007, 02:50:13 AM
Second is that this mod is not really compatible with Stramm's ModPack. Both Mods use non-standard picmgmnt.inc.php files. So files get resized, rotated and uploaded okay, but if you are using "exact" thumbnails they are distorted because j_picmgmnt.inc.php doesn't support cropping. It also doesn't support watermarking or mini thumbs. So after upload you have to go into admin tools and regenerate your thumbs and images to get watermarking and cropping.

  I actually didn't check JUpload with other plugins. I've downloaded modapack. I'll play with it. Assuring compatibility between plugins, that updates the same part of the code is probably rather complex: it would probably need an internal restructuring of Coppermine, with new hook points.
  I'll discuss with stramm to check that.

Etienne

erostew

Quote from: etienne_sf on October 28, 2007, 10:26:06 AM
Hum, hum,

That's strange. I would say: this can not happen !
Would you say, there is a bug somewhere ...  :o

  I'll check that.
I tried setting to "0", "true" and even "1" but the only thing to make it work again was setting it to "false"

QuoteI actually didn't check JUpload with other plugins. I've downloaded modapack. I'll play with it. Assuring compatibility between plugins, that updates the same part of the code is probably rather complex: it would probably need an internal restructuring of Coppermine, with new hook points.
  I'll discuss with stramm to check that.

Probably not as serious as it sounds. That part of code should not usually be active at the same time in both mods. The only real conflict is with making thumbnails after upload. Stramm's mod adds the setting "exact" which uses cropping. If the thumb setting is not "exact" there is no problem.

There is no conflict with watermarking because that uses a setting that jupload makes no use of. So it just doesn't get done. The same should be true for mini thumbs, but not certain because I don't use that portion of Stramm's Mod.

I will continue using jupload in any case but have to admit that full compatibility between mods would be great.  ;)

Thanks for your hard work to date!

Regards

etienne_sf

Quote from: erostew on October 28, 2007, 05:26:31 PM
I tried setting to "0", "true" and even "1" but the only thing to make it work again was setting it to "false"

For me it works like a charm: the problem is not exactly what you've seen.

From my tests, upload is blocked when pictureTransmitMetadata is true (or anyvalue differente from false, which is forced to the default 'true' value). There is an error saying that the file is too big.
Works ok for file without accent.

Is it the case for you ?

If yes: it will be corrected soon, as my next task on my TODO list is to correct the annoying management in JUpload of accents in filenames (or other 'strange' characters, like Japanese, Chinese...)
If no: can you tell me what error you get?

Quote from: erostew on October 28, 2007, 05:26:31 PM
Probably not as serious as it sounds. That part of code should not usually be active at the same time in both mods. The only real conflict is with making thumbnails after upload. Stramm's mod adds the setting "exact" which uses cropping. If the thumb setting is not "exact" there is no problem.

The problem is serious: I can't use the standard editpics in any way, as the page is profoundly changed:
- The cirteria for picture display is not the same: it's the list of last uploaded pictures, and not the album list.
- Action on pictures is removed fom the page. Could be done through the Coppermine hook functions.

IMHO: it's up to modpack to become a standard plugin, by using existing hook functions. Then, it would add its link to the JUpload editpics without knowing that it's not the standard editpic page !
  I'll check that and see with Stramm.


Quote from: erostew on October 28, 2007, 05:26:31 PM
There is no conflict with watermarking because that uses a setting that jupload makes no use of. So it just doesn't get done. The same should be true for mini thumbs, but not certain because I don't use that portion of Stramm's Mod.

I was writting my answer when you submitted this message !

Some questions here:
- What is watermarking ? mini thumbs ?   Are these other plugins ?
- What do you mean by j_picmgmnt.inc.php doesn't support cropping. It also doesn't support watermarking or mini thumbs ?

FYI: I was not able to make modpack work on my installation: admin got 'not allowed' errors, and standard users won't see the 'crop' link...    I just discover that my test installation, on which I tested modpack, is a 1.4.8 and not 1.4.13. I'll upgrade it and test again.

Etienne

erostew

Quote from: etienne_sf on October 28, 2007, 05:42:35 PM
For me it works like a charm: the problem is not exactly what you've seen.

From my tests, upload is blocked when pictureTransmitMetadata is true (or anyvalue differente from false, which is forced to the default 'true' value). There is an error saying that the file is too big.
Works ok for file without accent.

Is it the case for you ?

If yes: it will be corrected soon, as my next task on my TODO list is to correct the annoying management in JUpload of accents in filenames (or other 'strange' characters, like Japanese, Chinese...)
If no: can you tell me what error you get?
Okay it's even stranger. The settings today are being changed correctly. I changed to true and tested and then changed to false and tested. No errors in either case. Maybe this was caused by some strange Windows Vista thing. It might not have been allowing the applet to get changed settings from the server for some reason, and caused an error that way.

I have not tried uploading a file with any non-english characters in the name.

But I did find something interesting when I had meta upload set to true. It appears that the portrait rotation bug is NOT caused by JUpload. I uploaded 3 photos shot in portrait orientation. 1 was not yet rotated. 2 was rotated in ACDSee. And 3 was rotated by JUpload before uploading. ONLY the file rotated by ACDSee showed the green/purple corruption. The unrotated photo and the one rotated by JUpload appeared as normal. Didn't have a chance yet to try a photo rotated in another application.
Quote
The problem is serious: I can't use the standard editpics in any way, as the page is profoundly changed:
- The cirteria for picture display is not the same: it's the list of last uploaded pictures, and not the album list.
- Action on pictures is removed fom the page. Could be done through the Coppermine hook functions.

IMHO: it's up to modpack to become a standard plugin, by using existing hook functions. Then, it would add its link to the JUpload editpics without knowing that it's not the standard editpic page !
  I'll check that and see with Stramm.

It isn't possible for Stramm's Mod to use the standard because he has added functions that are not in core CPG. I.E. Watermarking, cropping, exact sized thumbs, mini thumbs, etc. Stramm can surely tell you more. This is a different cropping function from the one found in editpic.php The cropping is done on upload or if you use admin tools. Same for watermark, etc.

QuoteSome questions here:
- What is watermarking ? mini thumbs ?   Are these other plugins ?
- What do you mean by j_picmgmnt.inc.php doesn't support cropping. It also doesn't support watermarking or mini thumbs ?

FYI: I was not able to make modpack work on my installation: admin got 'not allowed' errors, and standard users won't see the 'crop' link...    I just discover that my test installation, on which I tested modpack, is a 1.4.8 and not 1.4.13. I'll upgrade it and test again.
Watermark (overlay image with a logo), mini thumbs (second size of thumbnail in addition to standard) are both added to the main picmgmnt.inc.php by Stramm because they are new features not available in the core CPG.
j_picmgmnt.inc.php doesn not support those features because they were not in the picmgmnt.inc.php that you modified for your own plugin, I am sure.

I found it slightly confusing to find the correct version of Stramm's ModPack because he has multiple versions for several different CPG versions.

Hope this helps! Maybe it IS a bigger job than I thought at first.  ;D

erostew

Quote from: etienne_sf on October 28, 2007, 05:42:35 PM
For me it works like a charm: the problem is not exactly what you've seen.

From my tests, upload is blocked when pictureTransmitMetadata is true (or anyvalue differente from false, which is forced to the default 'true' value). There is an error saying that the file is too big.
Works ok for file without accent.

Is it the case for you ?

If yes: it will be corrected soon, as my next task on my TODO list is to correct the annoying management in JUpload of accents in filenames (or other 'strange' characters, like Japanese, Chinese...)
If no: can you tell me what error you get?

Okay the strange config error is back. I tried to set the meta upload again to true to try a pic rotated in Photoshop. After that I got the same error you describe of "filesize too big". This seems different from the first error I encountered, but I am not 100% certain. The filename was normal with no accents or other non-english characters.

I have attached the Jupload log for you. The info regarding local path usernames and the webserver domain have been replaced by ****.

mpolfindo

I am getting this error with both the latest cpg and JUpload plugin:

'basic: Exception: java.lang.UnsupportedClassVersionError: Bad version number in .class file'

Of course, the applet doesn't load at all.

I'm running OS X Leopard and tried both Safari and Firefox.  JRE version 1.5.0_13

If I'm not mistaken, this is caused by compiling with a later version of JDK than the JRE.  As I'm on a mac, I have to wait for Apple to release an update.

I tried the demo on your site and it worked on my system.  Is that a lower version of JUpload?

eka

Hi etienne_sf,

The images in my editpics page are way too big.

How do I reduce the size of these Juploaded pics to the size of thumbnails?


Pse help.


vastre

#250
Hi Etienne,

I have a problem with the Jupload, I can upload pictures using the normal upload tab but the Jupload reports an error and wont complete the upload of the files.
I have set the debug to 100 and this is part of the output.

Can you tell me what the problem might be?



11:52:22.234 [DEBUG] HTTP status: 200 OK
11:52:22.234 [DEBUG] No error message found in HTTP response body
11:52:22.234 [ERROR] Upload stopped with errors [wjhk.jupload2.exception.JUploadExceptionUploadFailed: wjhk.jupload2.policies.CoppermineUploadPolicy.checkUploadSuccess(): The string "SUCCESS" was not found in the response body]
11:52:28.750 wjhk.jupload2.exception.JUploadExceptionUploadFailed: wjhk.jupload2.policies.CoppermineUploadPolicy.checkUploadSuccess(): The string "SUCCESS" was not found in the response body
11:52:28.750 at wjhk.jupload2.policies.DefaultUploadPolicy.checkUploadSuccess(DefaultUploadPolicy.java:588)
11:52:28.750 at wjhk.jupload2.upload.DefaultFileUploadThread.doUpload(DefaultFileUploadThread.java:731)
11:52:28.750 at wjhk.jupload2.upload.DefaultFileUploadThread.run(DefaultFileUploadThread.java:486)
11:52:28.750 [DEBUG] -------- Response Body Start --------
11:52:28.750 [DEBUG] <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
11:52:28.750 [DEBUG] <html lang="en">
11:52:28.750 [DEBUG] <head><title>Vastre Homepage</title>
11:52:28.750 [DEBUG] </head>
11:52:28.750 [DEBUG] <frameset rows="100%,*">
11:52:28.750 [DEBUG] <frame title="Http://vastre.homelinux.com/coppermine/index.php?file=jupload/jupload&action=add_picture&album=2" src="Http://vastre.homelinux.com/coppermine/index.php?file=jupload/jupload&action=add_picture&album=2" name="mainframe" frameborder="0" noresize="noresize" scrolling="auto">
11:52:28.750 [DEBUG] <frame title="empty frame" frameborder="0" scrolling="no" noresize="noresize">
11:52:28.750 [DEBUG] <noframes>Sorry, you don"t appear to have frame support.
11:52:28.750 [DEBUG] Go here instead - <a href="Http://vastre.homelinux.com/coppermine/index.php?file=jupload/jupload&action=add_picture&album=2">Vastre Homepage</a></noframes>
11:52:28.750 [DEBUG] </frameset>
11:52:28.750 [DEBUG] --------- Response Body End ---------
11:52:28.750 [ERROR] wjhk.jupload2.exception.JUploadExceptionUploadFailed: wjhk.jupload2.policies.CoppermineUploadPolicy.checkUploadSuccess(): The string "SUCCESS" was not found in the response body
11:52:28.781 [DEBUG] PicturePanel.paint(): offscreenImage is null
11:52:29.484 wjhk.jupload2.exception.JUploadExceptionUploadFailed: wjhk.jupload2.policies.CoppermineUploadPolicy.checkUploadSuccess(): The string "SUCCESS" was not found in the response body
11:52:29.484 at wjhk.jupload2.policies.DefaultUploadPolicy.checkUploadSuccess(DefaultUploadPolicy.java:588)
11:52:29.484 at wjhk.jupload2.upload.DefaultFileUploadThread.doUpload(DefaultFileUploadThread.java:731)
11:52:29.484 at wjhk.jupload2.upload.DefaultFileUploadThread.run(DefaultFileUploadThread.java:486)
11:52:29.484 [DEBUG] FileUploadThread: within run().finally
11:52:29.531 [DEBUG] PicturePanel.paint(): offscreenImage is null
11:52:30.890 [DEBUG] PicturePanel.paint(): offscreenImage is null
11:52:30.921 [DEBUG] JUploadPanel: after !fileUploadThread.isAlive()
11:52:30.921 [WARN] CoppermineUploadPolicy.afterUpload: No file were uploaded! (0)
11:52:33.765 [DEBUG] PicturePanel.paint(): offscreenImage is null

erostew

Quote from: vastre on November 03, 2007, 01:14:50 PM

Can you tell me what the problem might be?


11:52:28.750 [DEBUG] -------- Response Body Start --------
11:52:28.750 [DEBUG] <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
11:52:28.750 [DEBUG] <html lang="en">
11:52:28.750 [DEBUG] <head><title>Vastre Homepage</title>
11:52:28.750 [DEBUG] </head>
11:52:28.750 [DEBUG] <frameset rows="100%,*">
11:52:28.750 [DEBUG] <frame title="Http://vastre.homelinux.com/coppermine/index.php?file=jupload/jupload&action=add_picture&album=2" src="Http://vastre.homelinux.com/coppermine/index.php?file=jupload/jupload&action=add_picture&album=2" name="mainframe" frameborder="0" noresize="noresize" scrolling="auto">
11:52:28.750 [DEBUG] <frame title="empty frame" frameborder="0" scrolling="no" noresize="noresize">
11:52:28.750 [DEBUG] <noframes>Sorry, you don"t appear to have frame support.
11:52:28.750 [DEBUG] Go here instead - <a href="♦?file=jupload/jupload&action=add_picture&album=2">Vastre Homepage</a></noframes>
11:52:28.750 [DEBUG] </frameset>
11:52:28.750 [DEBUG] --------- Response Body End ---------
11:52:28.750 [ERROR] wjhk.jupload2.exception.JUploadExceptionUploadFailed: wjhk.jupload2.policies.CoppermineUploadPolicy.checkUploadSuccess(): The string "SUCCESS" was not found in the response body


Looking at that it's obvious that you are running CPG in a frame. So of course it will not give a proper success message to the JUpload applet. Remove the gallery from your frame and it will likely work fine. Also you have "Http" in your url. Most times this won't cause a problem but it should still be "http" for maximum compatibility.


Looking at the url "Http://vastre.homelinux.com/coppermine/index.php" in my browser I just get a timeout. You probably don't have the server up.
Checking http://homelinux.com I see:

Dynamic Network Services, Inc. (DynDNS) Redirection Page

homelinux.com is a domain owned by Dynamic Network Services, Inc. (DynDNS), but there is no content at this domain. Our homepage can be accessed at www.dyndns.com. You should be automatically redirected there in approximately 10 seconds.

If you need to report abuse of a subdomain of homelinux.com, this is probably owned by a customer of ours, and should be reported to our abuse department. Please send e-mail to abuse@dyndns.com with the full details of the abuse you are reporting, and we will investigate it as soon as possible.

Obviously you are using the redirection service of dyndns.com and they use a frameset to redirect to the IP of your server. The JUpload java applet doesn't support frames so it will never get to your server. Use a direct 222.33.444.555 url if possible and it will probably work.

Normal upload uses your browser and browsers DO understand framesets. Go in the config to the 4th item in General settings: "URL of your coppermine gallery folder (no 'index.php' or similar at the end". Change "Http://vastre.homelinux.com/coppermine" to "http://222.33.44.55/coppermine/" (USE YOUR REAL IP - NOT 222.33.44.55). JUpload should work.

etienne_sf

Quote from: mpolfindo on November 01, 2007, 09:06:19 PM
I am getting this error with both the latest cpg and JUpload plugin:

'basic: Exception: java.lang.UnsupportedClassVersionError: Bad version number in .class file'

Of course, the applet doesn't load at all.

I'm running OS X Leopard and tried both Safari and Firefox.  JRE version 1.5.0_13

If I'm not mistaken, this is caused by compiling with a later version of JDK than the JRE.  As I'm on a mac, I have to wait for Apple to release an update.

I tried the demo on your site and it worked on my system.  Is that a lower version of JUpload?

Correct: the current demo version is not the last one. it uses the 2.6.0 version (you can read that at the end of the upload page). You can get this version, as any old versions, on my wiki:
http://etienne.lesgauthier.fr/wiki/doku.php?id=jupload_coppermine_download_gb

  I've reinstalled my PC, due to hard drive crash   :(

I actually didn't reconfigure correctly my eclipse: it was compiling for the last JRE (1.6) and not 1.5. I'll check that for the last version.

Etienne

etienne_sf

Quote from: eka on November 02, 2007, 04:55:46 PM
Hi etienne_sf,

The images in my editpics page are way too big.

How do I reduce the size of these Juploaded pics to the size of thumbnails?

Seems to be a bg on some Coppermine configuration. But I didn't find which one.

Are you in approval mode ?  (I mean do upload pictures need approval ?)

Etienne

etienne_sf

#254
Quote from: erostew on November 03, 2007, 05:36:03 PM
Obviously you are using the redirection service of dyndns.com and they use a frameset to redirect to the IP of your server. The JUpload java applet doesn't support frames so it will never get to your server. Use a direct 222.33.444.555 url if possible and it will probably work.

Normal upload uses your browser and browsers DO understand framesets. Go in the config to the 4th item in General settings: "URL of your coppermine gallery folder (no 'index.php' or similar at the end". Change "Http://vastre.homelinux.com/coppermine" to "http://222.33.44.55/coppermine/" (USE YOUR REAL IP - NOT 222.33.44.55). JUpload should work.

  I agree with erostew (nice to see answer from other people here !  :) )

The only trouble now is... you currently can not change the postURL given to the applet from JUpload configuration page. I added this to my TODO list.

Workaround:
- The solution proposed by erostew needs that you change your Coppermine configuration. It's probably the best one: I think the URL won't be shown.
- Another solution is to edit the plugins/jupload/page/upload_page.php, find the definition of the $URL variable, at the beginning of the script,  and change the value given to the postURL parameter, to the one given by erostew (just replace the $CONFIG['site_url'] part).

Etienne

vastre

Changed the URL and it work fine now.

Many thanks Etienne_sf and erostew. ;D

erostew

Quote from: vastre on November 04, 2007, 07:52:40 PM
Changed the URL and it work fine now.

Many thanks Etienne_sf and erostew. ;D
A pleasure to help!

eka

Hi etienne_sf,

Registered users need no approval to upload pictures.

See example in editpics page: 

website:  photograffs.com
username:  test1
password:  test2

it would be nice to have the images smaller.

thanks.

etienne_sf

Quote from: eka on November 05, 2007, 03:30:02 AM
Hi etienne_sf,

Registered users need no approval to upload pictures.

See example in editpics page: 

website:  photograffs.com
username:  test1
password:  test2

it would be nice to have the images smaller.

thanks.

Are you talking about the standard editpic page, or about the page that is opened by JUpload just after a successful upload ?

If you talk about the JUpload page, question: can I really upload pictures to your site ?

Etienne

eka

Hi etienne_sf,

I misunderstood you - users can only upload to their own albums and not others'.

Can the JUploaded pictures be reduced in size on the editpics page?
My editpics page images are 600 px in width - way too big.
Can these images be the size of my thumbnails?

This may require some re-coding - but I don't know how.