mod_rewrite is not enabled - but it is

I have been trying to install omeka all day. I get the error mod_rewrite is not enabled but it is. I use godaddy and they have confirmed it is enabled. I have gone in to the .htaccess file and tried uncommenting where it says

# If you know mod_rewrite is enabled, but you are still getting mod_rewrite
# errors, uncomment the line below and replace "/" with your base directory.


I have tried every possible thing that could be my base directory. It is installed in a folder called archive in the root directory so I tried

RewriteBase /archive/
RewriteBase /

then i saw on godaddy's file browser that it is in a folder called "webroot" so i tried

RewriteBase /webroot/
RewriteBase /webroot/archive/

Nothing works.

I have no idea what else to try.

I have the latest version of Omeka 2.1.1

Any help would be greatly appreciated!

I am having similar issues, also using godaddy. Extremely frustrating since I had omeka successfully installed prior to doing a clean wipe and now can't figure this out. Edited my .htaccess file, no go.

I'm thinking I may roll back to omeka 2.0.3?

Would appreciate any help.

I ended up getting it to work by going directly to install/install.php

So a fresh database and fresh install of Omeka 2.1.1 in the root of my site. and then I went to

This got me to the page where you put in your info about the site and create it. IT DID show an error message about fileinfo but it does not seem to be an actual problem. Everything seems to be working fine.

So...that also worked.

Makes little sense.

But thanks for your work around. I am very grateful, if my text doesn't convey it, its because this has eaten up like seven hours of my day.

Thanks again!

Glad I could help, I spent an entire day trying to figure it out myself :)

Omeka on xampp under Windows 7.

Went to localhost/mysite/install/install.php and sure enough, it allowed an installation and I got the "Omeka - Success! Omeka is installed" page with links to "Public Site" and "Admin Dashboard."

However, the "Public Site" takes me to the (mostly) blank page set up by the installation and no useful links on it. The "Admin Dashboard" is a "404 error"

Any suggestions?

Wow this mod_rewrite issue is pretty crazy. I'm surprised it continues to be such a common thing even by Omeka v2.1.4.

I just hit the mod_rewrite wall while installing Omeka locally on a windows 7 machine running WAMP.

The above comment about going to /install/install.php worked for me.

I was even able to login to a functioning dashboard, and have the default public appearance page.

thanks ckarpinski!

I am trying to install on an Apache MySql platform. Have gone through the .htaccess suggestions. Checked with my webhost and they confirm that mod_rewrite is running. I would really like to examine this for our local library, but I don't have hours to spend debugging. I am used to Wordpress where i have done literally dozens of installs without any troubles. Occasionally do Drupal without troubing installs.

Any help appreciated.


I tried the insktall/install.php tip. Received the following error message:
Fatal error: Uncaught exception 'Zend_Cache_Exception' with message 'Could not determine temp directory, please specify a cache_dir manually' in /home/markorto/www/omeka/application/libraries/Zend/Cache.php:209 Stack trace: #0 /home/markorto/www/omeka/application/libraries/Zend/Cache/Backend.php(219): Zend_Cache::throwException('Could not deter...') #1 /home/markorto/www/omeka/application/libraries/Zend/Cache/Backend/File.php(131): Zend_Cache_Backend->getTmpDir() #2 /home/markorto/www/omeka/application/libraries/Zend/Cache.php(153): Zend_Cache_Backend_File->__construct(Array) #3 /home/markorto/www/omeka/application/libraries/Zend/Cache.php(94): Zend_Cache::_makeBackend('File', Array, false, false) #4 /home/markorto/www/omeka/application/libraries/Zend/Cache/Manager.php(173): Zend_Cache::factory('Core', 'File', Array, Array, false, false, false) #5 /home/markorto/www/omeka/application/libraries/Zend/Application/Resource/Locale.php(106): Zend_Cache_Manager->getCache('locale') #6 /home/markorto/www/omeka/application/librarie in /home/markorto/www/omeka/application/libraries/Zend/Cache.php on line 209

This is way beyond my skill set.


My webhostong company, ICDSOFT, always helpful, found the error when trying to access via install/install.php:

We fixed the error by editing the file at /www/omeka/application/libraries/Zend/Cache/Backend/File.php and replacing this line:

'cache_dir' => null,


'cache_dir' => '/tmp',

I am now up and running.

Sorry for returning to this issue, but it is somewhat omnipresent and I really wonder what might going on. I observe the following behavior:

Apache's mod_rewrite is enabled and the .htaccess file contains the following parameters:

RewriteEngine on
RewriteBase /sites/omeka/

Going to ....omeka/install I get "mod_rewrite is not enabled." But if I disable the following two lines, I get a rudimentary Install page (only the form on white background, no template files are included it seems) leading finally to a broken installation (backend doesn't work properly etc.):

# RewriteRule !\.php$ - [C]
# RewriteRule .* - [L]

Now I wonder what I shall conclude from this. I don't have yet much experience with the configuration of .htaccess files. It confirms at least that mod_rewrite is indeed activated and the standard rewrite rules are odd, or?

Are there any ideas how to solve this?



Getting rid of just the two lines you mention is going to incorrectly apply a condition to Omeka's other rewrites, likely disabling many of them, and also making it impossible to load files like CSS and Javascript, which would be why you saw an unstyled installer.

If you truly think it's just the "detection" that's wrong, which does seem to happen, the answer isn't editing the .htaccess. Instead, keep the .htaccess as it was, but just go to install/install.php to access the installer. This "skips" the initial rewrite that's used to detect if mod_rewrite is working.

I'm also having this problem (Ubuntu Saucy, Apache 2.4). I tried the install/install.php workaround, and it seemed at first to work but then the admin console gave a 404 and the front page continued to insist that RewriteEngine is not enabled (it is.)

What is the initial rewrite that is used for the detection, anyway? Knowing that would make it a lot easier to debug the actual problem (file/directory permissions? Execution problems? PHP misconfiguration? and so on.)

Something beyond the installer is happening in your situation. The front page doesn't ever say anything about RewriteEngine, so what you're seeing as the "front" is some different page entirely.

The rule that's the basis of the installer's "test" is a one-liner:

RewriteRule ^install/.*$ install/install.php [L]

Saucy uses Apache 2.4, which seems to have what's basically a bug that makes the DirectoryIndex take precedence over the RewriteRule when it shouldn't. There apparently is an unreleased fix for the issue. Anyway, all that is only relevant for the specific rewrite between install/index.html and install/install.php.

Going directly to install/install.php completely skips the problematic rewrite, so any other problems you're having are unrelated.

I am being a bit sloppy with what I call the 'front' page - I meant the thing I initially saw when I first tried to go to the site, which I believe is a redirect to the /install/ URL. At any rate, once I tried the workaround, neither the "Go to site" nor the "Go to dashboard" button did what they should have.

Rather than debug it further, I've simply installed an older version of Ubuntu and I'm up and running now. Thanks for the followup in any case!

I haven't had a chance to get back to my server that runs Apache 2.4 to take a look, but my latest agitations on their bug tracker indicate the problem might be solved in Apache 2.4.9.

That's newer than the version even in Trusty, so maybe not immediately helpful, even if it fixes the issue.

The odd thing is that in my experience the Apache 2.4 issues are strictly limited to the installer, and the "direct path" workaround should be fine. The behavior you're reporting sounds basically like Omeka didn't actually get installed.