Gallery Not Working Properly

[jspittler]

I have noticed that my galleries are not working correctly. They seem to display some error messages when run.

Also, when I run Gallery setup, the first page indicates a lot of warnings. Many of these are related to not being able to find things like jhead, imagemagick, etc. I am guessing that perhaps these utilities haven't been restored yet.

Is anybody else having similar issues?

I opened a ticket, but now that the forum is open, I thought I would make a post.

Thanks,

Judd

[Julian Muñoz]

I had problems with my gallery. They changed the path to mogrify (a command from imagemagick).

Before the server update, mogrify was located on /usr/bin/mogrify. Now it's on /usr/local/bin/mogrify.

i couldn't find jhead on my server though, i guess you can request it to support.

[raphaeln]

I'm having a problem with imagecreatefromJPEG(). The GD is not installed!!

[Julian Muñoz]

Yeah, no GD support here.... I don't know why they didn't activate it on the servers...

[stone]

I am running into problems with gallery also on Photon.

I am getting Error: Unable to make thumbnail (0)! when I try to upload an image. Then when I shell to my account the image is gone and all the permission in the album are turned to nobody with only read access so I can't even delete the directory of the files it made.

Anyone know what the deal is with this?

[raphaeln]

I've had good success with the rare support tickets that I have had to submit, but this time I've not had a response for 3 days. I was afraid of the day when this would happen. Sometimes I wonder if the absence of a tech support number is a reason not to host with Aletia.... such great features, but when there's a problem if you can't call them it hardly makes sense even if it was FREE.

Anyone got a response to a support ticket yet?

[jspittler]

I got almost "realtime" response when requesting that I get shell access. I think that was yesterday... or the day before.

It is a pain when you don't get quick response from a web host, but in this case, it seems like Jag is currently having some BIG (short-term) problems, so I am not surprised in the delay. Hopefully things will be back to normal in a few days.

Oh, I should probably mention that I withdrew my ticket regarding my problems with Gallery. I was able to get things going by doing a chmod to account for file ownership being changed from "nobody" during the restore. Also, I had uninstalled and reinstalled the FrontPage extensions for my account to solve another problem... unfortunately that clears out all the .htaccess files on my site. I didn't realize that .htaccess files are used in Gallery, so I had to figure out how to get them back and working again.

Oh, also, I think that as has been said, some of the "server" files used by Gallery had been moved to other locations, or not restored at all. I had to make adjustments for that as well.

[clio]

Just install the NetPBM binaries if you ave problems. DL them from the sourceforge page. They're easy to install.

[stone]

Ok I can install the libraries but how do I get control of the dirs that are owned by nobody and the group nobody and I only have read access to the dir.

I can't do a chmod or chown to get me back on it. I get the message Operation not permitted

I have opened a ticket but they seem just a tad busy with keeping the servers up and running.

[jspittler]

Hey Stone, I don't necessarily fully understand the issue you are seeing, BUT, I do know that many problems people have after a web host has "messed with" Gallery files can be fixed by going to the album directory and doing (I think this is right):

chmod -R 777 *

The idea is that since you can't change ownership, you can at least allow anybody to modify the files. I have never had problems with this command working.

On the other hand, I HAVE noticed that I can no longer fully delete old gallerys... well, I can delete them, I just can't empty them from the wastebasket... oh well.

[stone]

Ok heres what I have/get

I do a ls -al and here is what one of the many files look like
-rw-r--r-- 1 nobody nobody 2 Apr 4 15:13 photos.dat

If I do as you say with the CHMOD -R 777 *
I will get the following message for all files in this dir

chmod: changing permissions of `photos.dat': Operation not permitted


Therefore I cannot modify or delete anyting in these dirs.

[jason]

You can't change the permissions of the files because you are not the owner of them. The user "nobody," who owns the Apache and PHP process is the owner of the files. In Unix/Linux systems, the user who runs a process will be the owner of any files that that process creates.

I posted a soultion to this kind of problem back when JPC was moving accounts to the new servers in Houston last year. Basicly, I wrote a PHP script to change the permissions to a level that anyone could use to access, then I had the users go in with FTP or SSH and copy the files to a different location. The copied files would be owned by the user, solving the problem. Then, you could delete the old files and copy the ones that you owned back into their proper place.

I can't find the thread on that right now, but if I do, I'll post a link.

Alternatively, you could just ask support to chown (change ownership) the files for you, but they are obviously still very busy and it could take them some time. If you do change the ownership, though, you'll need to make sure you adjust the permissions on the changed files so that they can still be accessed through the web (if that's what you wnat).

--Jason

[jason]

Here's that thread:

http://forums.jaguarpc.com/showthread.php?threadid=1646

Good luck.

--Jason

[jjsmith]

On my server, PHP was recompiled and installed without '--with-gd' and '--with-jpeg-dir=/usr/local' config options which caused ImageCreateFromJPEG() calls to fail. JaguarPC responded to ticket quickly with a recompile including the necessary options - nice work. Here are the calls I use:

$src = ImageCreateFromJpeg($image);
$dst = ImageCreateTrueColor($tn_width,$tn_heigh t);
ImageCopyResized($dst, $src, 0, 0, 0, 0,$tn_width,$tn_height,$width,$height);
header("Content-type: image/jpeg");
ImageJpeg($dst, "", 100);
ImageDestroy($src);
ImageDestroy($dst);

[efrog]

Before the server update, mogrify was located on /usr/bin/mogrify. Now it's on /usr/local/bin/mogrify.

All I had to do (after TONS of reading every troubleshooting thing I could find! LOL!) was change: /usr/bin/ to /usr/local/bin/

It all seems to work again.

Though I *do* have a support ticket in - I guess I can go cancel it now.