XOOPS 
Forum
Forum Index General Forums Community Support Modules Support Themes Support Development International Support Module Hack Reviews Theme Designer Talk
  1. Board index / 
  2. XOOPS Modules Support forums / 
  3. Module reviews 
  4.  / Extgallery nightmares...
Register
11
Mamba
Re: Extgallery nightmares...

  • 2013/2/26 20:07

  • Mamba

  • Moderator

  • Posts: 11409

  • Since: 2004/4/23


I would suggest to upload the images to a photo service such as Flickr and provide links to them, so we don't have to download the images in order to view them.

Especially since your images are relatively small and of low resolution, and it's hard to see anything on them
On Flickr you could upload higher resolution.

Also, it is always helpful to make some annotation on the image itself to show the problem areas.
Support XOOPS => DONATE
Use 2.5.11 | Docs | Modules | Bugs
12
Anonymous
Re: Extgallery nightmares...

  • 2013/2/26 20:48

  • Anonymous

  • Posts: 0

  • Since:


It would help to enable bigger file attachments to the forum module and allow us to show them in a post

I hope this image is more clear! Resized Image


Just click to see the whole picture. The '1960 to 1970' category title normally has to show up underneath the thumbnail. The 'Albums' tag normally shows up on the left in line with 'fotoalbum'
13
Mamba
Re: Extgallery nightmares...

  • 2013/2/26 21:39

  • Mamba

  • Moderator

  • Posts: 11409

  • Since: 2004/4/23


Quote:
It would help to enable bigger file attachments to the forum module and allow us to show them in a post

Well, we don't allow attachments in the Forums, you were able to do it because you're a moderator

The problem is that if we allow that, then we'll end up with GBytes of data on our server. Plus, somebody could post a virus too

The normal recommendation is to use photo services like Flickr and then post the links here.

Now I see the issue here. How I do it, is to compare to another standard XOOPS theme, like Zetagenenis to see if this is a module problem, or theme problem.

In your case, it seems like you wan to have the column title aligned to left, and you could fix it in CSS code.

Reg. the Title of the picture, it seems like there is a missing line break tag in HTML. This could be a module problem, so check it, because we might have to fix it in the module.
Support XOOPS => DONATE
Use 2.5.11 | Docs | Modules | Bugs
14
blackrx
Re: Extgallery nightmares...

  • 2013/3/18 13:50

  • blackrx

  • Quite a regular

  • Posts: 227

  • Since: 2008/2/5 1


Quote:

flipse wrote:
I did some extensive testing with the Photoview block. Most Ajax types to choose from do not function.

Working are Lightbox, Tooltip and Normal view

Failing are Prettyphoto, Overlay, Fancybox and jCarousel

To be sure I cleaned caches in between and tried with jquery disabled at block and module level. Debug does not show any Extgallery related errors.


confirmed
XOOPS 2.5.5
PHP 5.3.1
MYSQL 5.1.41


15
Cifug
Re: Extgallery nightmares...

  • 2013/3/20 1:58

  • Cifug

  • Quite a regular

  • Posts: 208

  • Since: 2007/12/13


Hi guys, in preferences I have set "Max Photo Size (for all sides)" to 5000.

When I try to upload a photo 4000x2800 (1132kb) I get a white page. No errors, just a white page.

The largest photo I can upload is 2600 pixels wide.

Any ideas?

Not sure if I have the latest version of eXtGallery? Is there a link to the latest version?

eXtGallery 1.11
XOOPS Version XOOPS 2.5.5
PHP Version 5.3.17
mySQL Version 5.0.96-community
post_max_size 8M
file_uploads On
upload_max_filesize 2M

Cheers,
Marty.
16
Mamba
Re: Extgallery nightmares...

  • 2013/3/20 11:32

  • Mamba

  • Moderator

  • Posts: 11409

  • Since: 2004/4/23


Quote:
When I try to upload a photo 4000x2800 (1132kb) I get a white page. No errors, just a white page.

How did you try to upload it?

I've tried the same size picture:

1) Manually through Admin - no problem

2) Via a batch function in Admin - no problem

3) via Java's Public Upload, and I've got error: "Expecting MD5 Checksum", but I have no idea what it means in this aspect.

I've found only this post, and it seems like this is related to GD manipulation. So my assumption is that this is related to extGallery trying to resize the photo to Medium size. And a lot of times, there could be an issue with available memory. If smaller pictures are working fine, and you only have issue with a large picture, that this might be an issue.

So the question is:

1) How did you try to upload it?

2) If it was through a "Public Upload", and it is only you who uploads pictures, why don't you just go through the Admin?
Support XOOPS => DONATE
Use 2.5.11 | Docs | Modules | Bugs
17
Anonymous
Re: Extgallery nightmares...

  • 2013/3/20 21:34

  • Anonymous

  • Posts: 0

  • Since:


Quote:
3) via Java's Public Upload, and I've got error: "Expecting MD5 Checksum", but I have no idea what it means in this aspect.


There is a solution for this problem, has someone fixed this in the svn version yet? https://xoops.org/modules/newbb/viewtopic.php?post_id=350768#forumpost350768
18
Mamba
Re: Extgallery nightmares...

  • 2013/3/20 23:08

  • Mamba

  • Moderator

  • Posts: 11409

  • Since: 2004/4/23


Quote:
There is a solution for this problem, has someone fixed this in the svn version yet?

Yes, it was fixed inSVN, I just didn't update my version

Thanks for reminding me about it!
Support XOOPS => DONATE
Use 2.5.11 | Docs | Modules | Bugs
19
Cifug
Re: Extgallery nightmares...

  • 2013/3/20 23:32

  • Cifug

  • Quite a regular

  • Posts: 208

  • Since: 2007/12/13


Quote:
Mamba wrote:
How did you try to upload it?

1) Manually through Admin - no problem

2) Via a batch function in Admin - no problem

3) via Java's Public Upload, and I've got error: "Expecting MD5 Checksum", but I have no idea what it means in this aspect.

4) If it was through a "Public Upload", and it is only you who uploads pictures, why don't you just go through the Admin?

Hi Mamba, sorry, I should have mentioned these things...

I think I have the latest files but cannot be 100% sure, it's quite confusing...

Testing a 4000 pixel wide picture (or anything wider than 2600 pixels) fails on all of the above methods :(

1. Manually through admin: Pictures under 2600 pixels work fine, any picture larger than 2600 pixels get a white page.

2. Via a batch function in Admin: Same as above.

3. The "Extended Upload" still gets the below errors and can't upload any pictures at all:
Java Plug-in 10.17.2.02
Using JRE version 1.7.0_17-b02 Java HotSpot(TM) Client VM
User home directory = C:Users****
----------------------------------------------------
c:   clear console window
f:   finalize objects on finalization queue
g:   garbage collect
h:   display this help message
l:   dump classloader list
m:   print memory usage
o:   trigger logging
q:   hide console
r:   reload policy configuration
s:   dump system and deployment properties
t:   dump thread list
v:   dump thread stack
x:   clear classloader cache
0-5: set trace level to <n>
----------------------------------------------------
The applet must be signed (original error message: access denied ("java.io.FilePermission" "C:Users****Documents" "read"))
java.lang.SecurityException - The applet must be signed (original error message: access denied ("java.io.FilePermission" "C:Users****Documents" "read"))
java.lang.SecurityException: The applet must be signed (original error message: access denied ("java.io.FilePermission" "C:Users****Documents" "read"))
    at wjhk.jupload2.context.JUploadContextApplet.checkAppletIsSigned(JUploadContextApplet.java:115)
    at wjhk.jupload2.context.JUploadContextApplet.<init>(JUploadContextApplet.java:71)
    at wjhk.jupload2.JUploadApplet$1JUploadAppletInitializer.run(JUploadApplet.java:74)
    at java.awt.event.InvocationEvent.dispatch(Unknown Source)
    at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
    at java.awt.EventQueue.access$200(Unknown Source)
    at java.awt.EventQueue$3.run(Unknown Source)
    at java.awt.EventQueue$3.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
    at java.awt.EventQueue.dispatchEvent(Unknown Source)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.security.AccessControlException: access denied ("java.io.FilePermission" "C:Users****Documents" "read")
    at java.security.AccessControlContext.checkPermission(Unknown Source)
    at java.security.AccessController.checkPermission(Unknown Source)
    at java.lang.SecurityManager.checkPermission(Unknown Source)
    at java.lang.SecurityManager.checkRead(Unknown Source)
    at java.io.File.exists(Unknown Source)
    at java.io.Win32FileSystem.canonicalize(Unknown Source)
    at java.io.File.getCanonicalPath(Unknown Source)
    at sun.awt.shell.Win32ShellFolderManager2.createShellFolder(Unknown Source)
    at sun.awt.shell.Win32ShellFolderManager2.getPersonal(Unknown Source)
    at sun.awt.shell.Win32ShellFolderManager2.get(Unknown Source)
    at sun.awt.shell.ShellFolder.get(Unknown Source)
    at javax.swing.filechooser.FileSystemView.getDefaultDirectory(Unknown Source)
    at javax.swing.JFileChooser.setCurrentDirectory(Unknown Source)
    at javax.swing.JFileChooser.<init>(Unknown Source)
    at javax.swing.JFileChooser.<init>(Unknown Source)
    at wjhk.jupload2.context.JUploadContextApplet.checkAppletIsSigned(JUploadContextApplet.java:90)
    ... 16 more
java.lang.reflect.InvocationTargetException
    at java.awt.EventQueue.invokeAndWait(Unknown Source)
    at java.awt.EventQueue.invokeAndWait(Unknown Source)
    at javax.swing.SwingUtilities.invokeAndWait(Unknown Source)
    at wjhk.jupload2.JUploadApplet.init(JUploadApplet.java:79)
    at com.sun.deploy.uitoolkit.impl.awt.AWTAppletAdapter.init(Unknown Source)
    at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.SecurityException: The applet must be signed (original error message: access denied ("java.io.FilePermission" "C:Users****Documents" "read"))
    at wjhk.jupload2.context.JUploadContextApplet.checkAppletIsSigned(JUploadContextApplet.java:115)
    at wjhk.jupload2.context.JUploadContextApplet.<init>(JUploadContextApplet.java:71)
    at wjhk.jupload2.JUploadApplet$1JUploadAppletInitializer.run(JUploadApplet.java:74)
    at java.awt.event.InvocationEvent.dispatch(Unknown Source)
    at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
    at java.awt.EventQueue.access$200(Unknown Source)
    at java.awt.EventQueue$3.run(Unknown Source)
    at java.awt.EventQueue$3.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
    at java.awt.EventQueue.dispatchEvent(Unknown Source)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.security.AccessControlException: access denied ("java.io.FilePermission" "C:Users****Documents" "read")
    at java.security.AccessControlContext.checkPermission(Unknown Source)
    at java.security.AccessController.checkPermission(Unknown Source)
    at java.lang.SecurityManager.checkPermission(Unknown Source)
    at java.lang.SecurityManager.checkRead(Unknown Source)
    at java.io.File.exists(Unknown Source)
    at java.io.Win32FileSystem.canonicalize(Unknown Source)
    at java.io.File.getCanonicalPath(Unknown Source)
    at sun.awt.shell.Win32ShellFolderManager2.createShellFolder(Unknown Source)
    at sun.awt.shell.Win32ShellFolderManager2.getPersonal(Unknown Source)
    at sun.awt.shell.Win32ShellFolderManager2.get(Unknown Source)
    at sun.awt.shell.ShellFolder.get(Unknown Source)
    at javax.swing.filechooser.FileSystemView.getDefaultDirectory(Unknown Source)
    at javax.swing.JFileChooser.setCurrentDirectory(Unknown Source)
    at javax.swing.JFileChooser.<init>(Unknown Source)
    at javax.swing.JFileChooser.<init>(Unknown Source)
    at wjhk.jupload2.context.JUploadContextApplet.checkAppletIsSigned(JUploadContextApplet.java:90)
    ... 16 more


4. "Public Upload": Same as in 1. and 2.

The only reason I can think of that it works for you in some methods but not for me is that maybe I don't have the latest files. I've read through all the posts and branched posts but I may have missed something.

Mamba, could you post a link to the absolute latest zip?

Cheers,
Marty
20
dbman
Re: Extgallery nightmares...

  • 2013/3/21 13:24

  • dbman

  • Friend of XOOPS

  • Posts: 172

  • Since: 2005/4/28


Check your php.ini, look for the directive:

upload_max_filesize = 2M


Ensure the filesize is set large enough to accomodate your images. I think 2Mb is the default (used to be 8).
« 1 (2) 3 4 5 ... 7 »

Login

Register now!  |  Lost Password?

Search

Advanced Search

Recent Posts

Who's Online

294 user(s) are online (190 user(s) are browsing Support Forums)

Members: 0

Guests: 294

more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Nov 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits