Forums » Alpha Release Candidate

1. kerim | Member

   9 months ago # | |

   Strange, I'm trying to install Omeka, but I'm getting 500 errors:

   http://kerim.joyeurs.com/omeka/

   I changed the default permissions for all files to 755 and for the archives folder to 777.
   I checked the database settings 3 times.
   I double checked that invisible files had all uploaded.
   I checked that I'm running the right versions of PHP and mysql.

   Its likely that I still missed something, but I'm wondering if there is an easy way to tell whats going wrong?

   Thanks.

   Here are my server's PHP settings:

   http://wiki.joyent.com/facebook:kb:swphp

2. kerim | Member

   9 months ago # | |

   UPDATE: Nothing new, except that I deleted the install linked above, hoping to install from SVN, as per the Codex - but was unable to do so without an SVN password, so I wrote the developers asking if I could get one.

3. kerim | Member

   9 months ago # | |

   I tried again with the final release of RC4, but I'm still getting 500 errors.

   Seem to be talking to myself ...

4. DaveLester | Developer Community Lead

   9 months ago # | |

   There have been some internal discussions about SVN access, and I know your email sent directly omeka.support has been receieved. I'll double check that some got back to you, although I know many of us are on vacation (myself included) for the holiday break.

   In regard to the 500 error you've experienced, an error log should be written to whenever a request is made to your server with a 500 error message. If you could tell us the specific errors being reported, then it'd be easier to help out.

5. kerim | Member

   9 months ago # | |

   Thanks for getting back to me. I turned on error reporting on my server, but when I open the log it is blank. I'll submit a ticket to my webhost to see if I can get this working better.

6. kerim | Member

   9 months ago # | |

   Problem solved - and it explains both the errors and the lack of an error log:

   "the most common case for a 500 error is a broken .htaccess file, which basically prevents Apache from doing *anything* (including outputting any useful hint into the error log). You have two php_value and two php_flag lines in .htaccess and those are only valid for PHP that is served via mod_php. We do not use mod_php, but rather the more powerful mod_fcgid approach, and the lines you have there are thus evaluated as 'invalid'. Just remove them."

   (NOTE: <blockquote> does not seem to work in these forums.)

7. kerim | Member

   9 months ago # | |

   Same is true for the "admin" .htaccess file.

   By simply removing these lines, rather than modifying them in some way, do I break any functionality?

8. KrisKelly | Omeka Developer

   9 months ago # | |

   Thanks for catching that. We'll be sure to fix that in the next release, and I will push for setting up svn access after the holiday break, so that you and the other active testers can have consistent access to bug fixes.

   W/r/t to the .htaccess, display_errors and zip.output_compression can both be taken out without any break in functionality, though the 'register_globals' is a bit trickier, it shouldn't break anything but having it set to 'on' has been known to create security holes. For now I'd say remove all the lines that are causing breakage, and we'll fix it in an upcoming version.

RSS feed for this topic

Topic Closed

This topic has been closed to new replies.