Gallery, problems running as php-cgi

I am trying to get Gallery working but am having trouble running it as php-cgi. I am able to install it, but as soon as I add the “AddType php-cgi .php” line to the Gallery .htaccess page it can no longer find the ImageMagick on the Dreamhoast server (/usr/lib/ImageMagick). So, I can’t upload images.

This is what the config page is reporting:

Apache is not obeying your .htaccess file. Try entering the following into your web server’s httpd.conf file:

<Directory /home/.jackdandy/arted/>
AllowOverride Options FileInfo

Is this something Dreamhost can help me with?

I think you can ignore that message. Take a look at my instructions for installing Gallery on a DreamHost shared server. Especially this part

More of the “Warning: exec() has been disabled for security reasons in …” lines may appear. If so, go to the gallery directory in a ssh client and add to the gallery/.htaccess file the following line:

AddType php-cgi .php

That should get rid of the exec() warnings. However, it will cause two more warnings (Apache ignoring .htaccess and magic quotes enabled) to appear on the System Check Page if you go back to it.

Is that when you saw the message about Apache ignoring the .htaccess file?

Hi, yes, I did follow your instructions (after reading everything I could about Gallery and Dreamhost in the forums/KBase), and hoped that I could just ignore the warning. I also just tried installing Gallery on another Dreamhost server (I have a couple of accounts on different machines) to see if my problem was server specific but ran into the same problem. As soon as I switch to php-cgi, by adding it to the Gallery .htaccess file, Gallery can no longer access ImageMagick, so no thumbnails, no uploads. Also, Gallery will only finish the config if I wait and add the “AddType php-cgi .php” line at the very end, when it gives me the open_basedir warning.

In your instructions you mention adding it earlier, just as you’re going into the album defaults, but then I get a “can’t find ImageMagick” warning and Gallery won’t configure. I was running into permissions problems too. Is it true that albums should be chmod 777? despite the suexec set-up at Dreamhost?

I’m stumped. It seems that getting Gallery working at Dreamhost is tricky, but, since others have done it, it is possible. Any other ideas? I feel like maybe I’m missing something obvious… Do you think I should try installing ImageMagick locally (that doesn’t seem too easy to do)? What is the path to ImageMagick in your setup? /usr/lib/ImageMagick? leave blank?

Thanks! (and thanks for your instructions, I used your MT instructions too, and had a flawless install of that).

Oh yeah, I also heard from Dreamhost that they won’t allow the Override, so, as you say, that error shouldn’t really be breaking the access to ImageMagick, because other users have gotten Gallery working with this restriction…

I just chmod’d my albums directory from 777 to 755 with no apparent impact on browsing the albums or logging in as an admin and manipulating them. I’ll update my install notes tonight.

The setting for the path to ImageMagick for my install is


The instructions seem kind of weird, but I followed them exactly when I did a second install of Gallery, and they worked perfectly. Once you get to the Album Defaults page, switch to your ssh client and update the .htaccess file, making sure to save it. After you click the Save Settings button, do you see any errors?

Hi, I’m beginning to think that I don’t have the right ImageMagick files on my servers (I’ve tried two where I have accounts, monkey and annie). What happens is that, when I add the AddType line to the .htaccess page I get this error:

$gallery->app->ImPath = “/usr/lib”;
Error: I can’t find ImageMagick at the location you provided. Gallery prefers ImageMagick version 5.4.8 and up. You can compile and install the entire ImageMagick package from Note: They also have binaries available for assorted operating systems. If you can’t get it working, try leaving the ImageMagick path blank and using NetPBM instead.

And, indeed, if I look at the diagnostic page I see these errors:

Checking /usr/lib/ImageMagick/identify
Error! (File /usr/lib/ImageMagick/identify does not exist.)

Checking /usr/lib/ImageMagick/convert
Error! (File /usr/lib/ImageMagick/convert does not exist.)

Checking /usr/lib/ImageMagick/composite
Error! (File /usr/lib/ImageMagick/composite does not exist.)

I tried both /usr/lib and /usr/lib/ImageMagick, no difference.
So, it seems that there is not a complete install of ImageMagick on my server. Unless these are false errors. I did a locate and the files are not there. There’s some ImageMagick stuff, but not what Gallery is looking for.

Do you get the same errors? I’m trying to see if it’s my problem, if I can get Dreamhost to update/install ImageMagick on my server or if I have to start messing around with NetPBM.

I don’t think its a chmod prob, I was running into those session errors, have that figured out. I’ve tried both gallery 1.3.3 and 1.3.4, same problems with both.


andor% which convert
andor% which composite
andor% which identify

Instead of /usr/lib, use /usr/bin for the path. That’s what works for me.

I didn’t have to manually set it. Gallery auto-discovered the ImageMagick binaries and pre-set the IM path to /usr/bin. I’m not sure why your path was set to /usr/lib.

Ok, I’ve got it working on monkey (had to also run the config pages twice, I guess to clear out cashed info), will try annie later. Thanks! Pheew!!

I had the strangest experience setting up Gallery. I could not get it to find NETPBM for the life of me. My desktop is XP home and I was using IE6.0 to run the install command from my browser.

I looked through all of the support and never found the problem. On a whim I tried to install it from Netscape and it worked perfect. I cannot explain this, but I tried it again on another server and had the same thing happen.

I got Gallery working on both of my Dreamhost servers this weekend. Thanks for your help. As I thought, it was something obvious. Since Gallery didn’t autofind ImageMagick, I did a locate and entered the path to usr/lib, instead of usr/bin which is where the binaries are. (I didn’t notice that your instructions clearly said usr/bin!). To compound my problem I had browser issues, so that even after I fixed it, I still got the errors, so I thought it must be something else. Anyway, after clearing out my cache and running the wizard twice, everything worked fine.

On the subject of browser weirdness
On my set-up:
IE 5.0 and 5.1 for Mac, could not run the config wizard.
Mozilla 1.2.1 could run it but would crash on reload.
I think its probably issues with my system.

So, for anyone else trying to get Gallery going. Follow atacama’s instructions, they work. If they don’t work, perhaps look into whether it’s a browser-based or local system error.

[quote]So, for anyone else trying to get Gallery going. Follow atacama’s instructions, they work.


Cool! I’m really happy you got Gallery working. I wrote up those Gallery and Movable Type install notes mainly just to help remind myself how I got things to work in case I needed to reinstall them, but I’ve been amazed and pleased by how many other people have found them helpful.

I’ve gotten so much help from reading what others have written on websites, discussion forums, Usenet news, mailing lists, etc. since I started roaming public FTP servers about 15 years ago that I am glad I’ve been able to return a small bit of the favor.


Thanks to atacama’s instructions, I have gallery running… but something somewhere is corrupting every image I upload, unless I only punt very small ones up. The threshold is somewhere between 10 and 30Kb; everything 30Kb and up emerges mangled.

There’s a known PHP bug that sounds somewhat related:, but I can’t see how to implement any of the work-arounds noted there. I’ve tried adding:

<Files *.php*> LimitRequestBody 10240000 </Files> in my gallery .htaccess, but that appears to have no effect (not a great surprise).

Suggestions, anyone? Is anyone even seeing similar behaviour?

Just thought I’d add a problem I had, and the solution:

If you don’t have the “AddType php-cgi .php” in your .htaccess file, the script runs as “dhapache” and creates its gallery folders as such.

If you later add the AddType line to .htaccess, the script runs as the user specified in your web panel.

So, if you create a gallery as dhapache, and later add the addtype line to try to solve a problem, you will create another problem because you can’t edit the gallery you created. You don’t have the permissions to.

Fun, no?

atacama writes:

<<I’ve gotten so much help from reading what others have written on websites, discussion forums, Usenet news, mailing lists, etc. since I started roaming public FTP servers about 15 years ago that I am glad I’ve been able to return a small bit of the favor.>>

If it wasn’t for forums, and users like you willing to post your hard won tips, I’d never gotten any scripts to run, I don’t think… there’s always something that doesn’t go as you expect it too…

Perhaps I can trouble you for another piece of advice?? (I’ve got this question posted in another thread too). I’ve got gallery running fine but am trying to get it to work as a module in PHPnuke. I’ve done a fresh install and, while everything seems to work ok outside of PHPnuke, it fails (open_basedir errors) from within PHPnuke. It seems to be tied into the safemode. Have you had any success running Gallery as a module in PHPnuke here at Dreamhost?

As far as Gallery ownership issues go (Anonymous), I think if you do a recursive chmod 777 on the albums directory it fixes it.

ok, found my answer. this should help anyone else running into this problem. I do need to run PHPnuke as php-cgi to get Gallery working as a module. Here’s a post from the Kbase that explains what to do.

User Post (2003-01-26 21:10:40 by gsteinmon )
I had a little trouble running Gallery both on it’s own and with postnuke. Here is what worked for me: After finishing the Gallery setup script and saving my settings, I ran I then added “AddType php-cgi .php” line to the .htaccess file within the main directory. Then I created an .htaccess file in the “platform” sub-directory with the only line of text being “AddType php-cgi .php”. I also needed to add an .htaccess file into the main postnuke directory with the "AddType php-cgi .php " line. That seemed to work for me.

Glad you were able to find a solution and thanks for posting it! I haven’t yet worked with PHPnuke, but you never know when the need will arise.