Mod_rewrite issue during installation on Webfaction

FYI, I had an issue during installation on a Webfaction server (CentOS, PHP 5.6, Apache 2.4) where the redirect to /install/ succeeded but failed to render the installation form. It instead showed an error indicating that mod_rewrite was not enabled (it was). Navigating directly to /install/install.php enabled me to complete the installation. Everything now seems to be working fine so this might be a bug with the installer. I just figured I’d leave this here in case it’s useful to someone else. Cheers.

1 Like

Thanks much. We occasionally see this with some server configurations, but nailing down all the details into a general fix is tricky, so the more likely it is for someone to search for the situation with solution, the better!

Erin, can you share the version of Apache that Omeka reports for that server in the System Information page?

There’s a known issue with the install redirect for certain versions of Apache (now fixed by later ones) and it would be nice to know if this is that same problem or something else.

I don’t see Apache details in the system info (for any of my sites).

But here’s what the server says.

$ httpd -v
Server version: Apache/2.4.6 (CentOS)

Here’s the system info in Omeka…

System
Omeka	2.4.1
PHP	5.6.24 (cgi-fcgi)
OS	Linux 3.10.0-327.18.2.el7.x86_64 x86_64
MySQL Server	5.6.31
MySQL Client	mysqlnd 5.0.11-dev - 20120503 - $Id: 76b08b24596e12d4553bd41fc93cccd5bac2fe7a $
PHP Extensions
Regular	bcmath, calendar, cgi-fcgi, Core, ctype, curl, date, dom, ereg, exif, fileinfo, filter, ftp, gd, gettext, gmp, hash, iconv, imagick, imap, intl, ionCube Loader, json, ldap, libxml, mailparse, mbstring, mcrypt, memcache, mhash, mssql, mysql, mysqli, mysqlnd, openssl, pcre, PDO, pdo_mysql, pdo_pgsql, pdo_sqlite, pgsql, Phar, posix, pspell, Reflection, session, SimpleXML, soap, sockets, SPL, sqlite3, standard, tidy, tokenizer, xml, xmlreader, xmlrpc, xmlwriter, xsl, zip, zlib
Zend	the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured)

Thanks.

It looks like it is indeed that same known problem: it was fixed in Apache 2.4.9.