Hi, ubuntu 14.04.3 updated this AM. Omeka 2.3.1. Apache 2.4.7.
mod_rewrite is enabled.
.htaccess exists, is readable by www-data, and has ReWriteEngine on uncommented.
It also has ReWriteBase /webroot uncommented - and I tried ReWriteBase /webroot/ as well. Nothing.
I've rebooted the server, I've restarted apache2.
There are issues with this going back 5 years, probably should be addressed.
What's the actual problem you're having? The installer complaining about mod_rewrite not being enabled, or something else?
I'm assuming it's the installer, because Apache 2.4.7 has a bug that makes Omeka's mod_rewrite detection not work. This bug was fixed in later versions of Apache. It also looks like Ubuntu backported the fix to trusty's version of 2.4.7. The upshot is that Apache version 2.4.7-1ubuntu4.6 or higher should work correctly.
Regardless, the RewriteBase you're mentioning doesn't look right. Is "webroot" actually part of the URL you use to get to your Omeka install? That would be a fairly uncommon setup. The correct RewriteBase setting is based on what the URL is, not the local path. For many or most server setups, you don't need to set the RewriteBase at all, which is why it's commented out in the default .htaccess.
Ack, I have been affected by ubuntu mirrors that are >12 days old. Have changed to the official repos, will report back.
Installation of version 2.3.1 results in an error 'mod_rewrite is not enabled' notwithstanding that mod_rewrite is up and running on my system.
The following are key attributes of the operating environment:
| Operating System | Arch Linux (fully updated) |
| Apache Version | 2.4.27 |
| php Version | 5.6.15 |
| Linux Kernel | 4.2.5-1 Arch |
The mod_rewrite service is known to be running by viewing a file localhost/index.php consisting of the next eight lines of code.
<html>
<head>
<title>PHP Test</title>
</head>
<body>
<?php phpinfo(); ?>
</body>
</html>
The following describes key attributes of the file /etc/httpd/conf/httpd.conf
LoadModule rewrite_module modules/mod_rewrite.so is enabled. This line appears around line 184.
There are two directory sections of interest:
Appearing around line 238 is
<Directory />
AllowOverride all
Require all denied
</Directory>
Located immediately below a documentRoot "/srv/http" follows the next Directory entry (line 251) which reads, in essence:
<Directory "/srv/http">
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
/Directory>
I have also experimented with adding a new Directory entry, pointing to /srv/http/omeka-2.3.1.
I have also worked on the ./.htaccess file modifying the 'base directory' as described on line 25.
I have tried every known permutation of the options for AllowOverwride, Require and Satisfy directives as well as different settings in ./.htaccess all to no avail. Generally if both AllowOverride are set to "all" attempting to open localhost/test.php or the omeka installer results in 'not found' or 'forbidden' messages.
Needless to say, every modification to the http.conf is followed by a shutdown and restart of the Apache server. Interestingly, some of the permutations cause Apache to take up to 2 minutes to shut down. With others, Apache shuts down promptly when sending the shutdown signal.
Omeka-2.3.1 is known to work on an external server where we have hosting.
The copious blogs and internet entries on the subject of mod_rewrite suggest there is a serious problem in the Omeka coding that has involved a lot of minor modifications to this mod_rewrite business on the part of a lot of hard working individuals. Unfortunately, that there is again an incompatibility, this time with some versions of the latest (version 2.4) Apache server.
Any help, or suggestions for other tests would be appreciated.
There's no such version as Apache 2.4.27, the most recent one is 2.4.17.
AllowOverride for the DocumentRoot directory (the second one you posted) needs to be All. When it's None the .htaccess file that comes with Omeka is simply ignored by Apache. You shouldn't need to make any more changes to the httpd.conf or do any more restarts of the server once that's set to All.
It's usually best to just leave RewriteBase in the .htaccess file alone (commented out) unless you know you need it.
For the great majority of servers, all that's needed is that mod_rewrite is enabled (as you've confirmed) and that AllowOverride is set to All. What result do you get with those settings?
You are right Apache 2.4.17 (my typo)
I changed the second instance of AllowOverride to All per your recommendation.
No success after Apache restart. 'mod_rewrite is not enabled'.
Okay.
Judging by how you described your setup, just an omeka-2.3.1 folder directly in your localhost DocumentRoot, the "stock" .htaccess should be working fine for you with no changes to RewriteBase or any other setting within.
If you want to just test (and therefore rule out) whether the .htaccess is being read at all, you can add a line like the following to the bottom:
CauseAnErrorIf your AllowOverride setting's right and the .htaccess is getting read by Apache, having that line in the file will cause an Internal Server Error immediately whenever you try to go to your Omeka install.
If you instead still get the Omeka "mod_rewrite is not enabled" page, then you know that Apache can't or won't read that file and that's probably the source of the problem.
Interesting and odd results.
I add the line CauseAnError to the bottom of the .htaccess file. I get Error 500 'Server Error'. This is expected.
I then remove the line CauseAnError from the bottom of the .htaccess file, I get Error 403 'Access Forbidden'
This (to me) is not expected.
Believing this could be a permission issue, I changed permissions of .htaccess from (stock) 644 to 666. Put the line back in, I get 'error 500 - server error' as expected. I take the line out and get 'error 403 - access forbidden' as experienced above and (to me) not expected.
Thanks for your continuing help and patience!
So, wait, now when you just have the regular, unchanged, .htaccess file, you're getting a 403 Forbidden error instead of the "mod_rewrite is not enabled" page? That's odd, because there's nothing about changing the .htaccess that would persist once you took the line back out. Anyway, since adding the "CauseAnError" line did cause a 500 error, you can tell for sure that Apache's successfully reading that file.
Are there any "strange" permissions on index.php or install/install.php?
What happens if you go directly to "omeka-2.3.1/install/install.php"?
So, wait, now when you just have the regular, unchanged, .htaccess file, you're getting a 403 Forbidden error instead of the "mod_rewrite is not enabled" page? Yes. That is what makes this so vexing. To clear that error, I have to remove Apache, delete the httpd.conf file and then reinstall Apache and change the AllowOverride parameters in httpd.conf. Simply restarting Apache is not enough. Then the 403 error goes away and the mod_rewrite error returns.
Permissions for omeka-2.3.1/index.php are 644
Permissions for omeka-2.3.1/install/install.php are 644
Running omeka-2.3.1/install/install.php produces a few lines of junk. The text of that from the latest instance follows:
-----------
setinipath(BASE_DIR . '/db.ini'); $application->getBootstrap()->registerPluginResource($dbResource); } // Explicitly load the Zend FrontController resource, not the Omeka modification. // Because the Omeka FrontController resource is too heavily coupled for use. $application->getBootstrap()->registerPluginResource('Zend_Application_Resource_FrontController', array( 'controllerDirectory' => APPLICATION_PATH . '/controllers', 'throwExceptions' => true)); // This line is a workaround for what seems like a bug in Zend_Application. // It loads the plugin resources, which need to be loaded before the bootstrap() // call so as to prevent loading the wrong resource (e.g. // Omeka_Application_Resource_Frontcontroller instead of // Zend_Application_Resource_FrontController). $plugins = $application->getBootstrap()->getPluginResources(); $application->getBootstrap()->bootstrap(); if (APPLICATION_ENV === 'testing') { return; } try { $application->run(); } catch (Exception $e) { echo '
' . $e->getMessage() . '
';exit; }
Basically, going directly to install/install.php totally skips any mod_rewrite checks or requirements, so if you can't do that, then your server setup has more basic problems than mod_rewrite.
That junk you're seeing is just un-executed PHP code. What that means is right now you don't have your server set up to execute PHP files. It sounds like maybe something didn't get reinstalled or set back up correctly after you uninstalled Apache.
I can't think of any situation where any change to an .htaccess file would require you to uninstall or reinstall Apache entirely.
'What that means is right now you don't have your server set up to execute PHP files.'
Enabling php (you know php is running by viewing localhost/index.php in a browser) is not enough. There are several additional php modules that must be installed. Once installed, the basic installation procedure works.
Execute the following commands (oriented to Arch Linux, other distros are probably similar)
sudo pacman -Syu (insure your installation is fully up to date)
sudo pacman -S apache php-apache php-pear php-embed php-gd php-xsl.
Obviously apache and php-apache were installed and configured ahead of time. I was missing the pear, embed, gd and xsl modules. Omeka depends on some or all of these to install.
Once installed, I was able to get into and complete the installation process.
Thanks for your help.
FWIW, I can happily go to install/install.php and it works. I *still* get the mod_rewrite error though.
Server version: Apache/2.4.7 (Ubuntu)
Server built: Oct 14 2015 14:20:21