More than one .htaccess file on my site

When I try to start the omeka installation by opening this URL I get a 404 error:

http://www.thehaikufoundation.org/omeka/

Upon reflection, I think I was supposed to copy the .htaccess file from the omeka folder to the site root. Is that right?

If so, I could not do that because I have WordPress and other applications installed on the same root, and I can't simply replace my current root .htaccess file with the omeka version. Is there some way I can merge content from the omeka .htaccess file with the current contents of the root .htaccess file?

Nope, you're not supposed to move the .htaccess files anywhere. If Omeka is installed in the "omeka" folder of your site, that's where the .htaccess file should be.

If you look closely, it seems that the basic Omeka .htaccess is working, because it's successfully redirecting you to "omeka/install". Make sure you've uploaded the "install" directory correctly (it contains its own .htaccess file as well).

Thanks for your reply, John.

I compared my local copy of the "install" directory to the remote copy. They look the same.

This is the message I ses in the error log, after I attempt to access the "install" dir:

26-Jan-2012 17:30:57 UTC] PHP Catchable fatal error: Argument 1 passed to Omeka_Core_Resource_Options::_convertMigrationSchema() must be an array, null given, called in /home/gatordav/public_html/omeka/application/libraries/Omeka/Core/Resource/Options.php on line 49 and defined in /home/gatordav/public_html/omeka/application/libraries/Omeka/Core/Resource/Options.php on line 79

That error you're seeing is basically irrelevant. The error is fixed (again) in the upcoming 1.5 version, but it shouldn't actually negatively affect the installer.

I still think that it's most likely that there's some problem with the "install" directory, or it's possible that you have some pre-existing .htaccess rule that's interfering with things.

Is there a way I could send you a copy of my .htaccess file without sending it to the forum? I'm not sure that it is a good idea to expose the contents of my .htaccess file to the forum.

On second thought, I'll ask my web host to investigate the relevant .htaccess file. More later.

My web host reports:

1. "We have investigated the issue and found that wordpress .htaccess redirects are causing the 404 error."

Our main site is indeed a WordPress site. I hope to make one or more Omeka ollections available from the main navigation menu on or site. No other integration. Similiar ot the way that we have a Simple Machines forum: a completely separate area.

Do you have any suggestions for such an implementation?

* * *

2. "Also there is a premature end of the script error for index.php in omeka directory:

[Thu Jan 26 19:18:46 2012] [error] [client 216.110.94.228] Premature end of script headers: index.php

Might be caused by a bad upload."

I will re-upload.

In an attempt to fix a possible bad upload of the Omeka folder, I zipped the configured omeka folder, FTP'd it to my web server, then expanded it on the server. Sadly, this made no difference, although it eliminated a possible source of error.

* * *

If someone from Omeka can tell me what must be done to install Omeka in the context of a WordPress installation, I can tell my web host.

Or perhaps I can contact someone from Omeka outside the context of this forum and I can describe the configuration of my site in sufficient detail for you to help me.

Alternatively, I am not adverse to paying for support from someone who knows how to install Omeka in the context of a WordPress installation.

Please let me know if one or more of these options is possible.

Hi, I can offer paid support if you are interested. Please feel free to contact me and let me know what services you need (if there is anything beyond the installation). My email address is ebellempire at gmail.com. Best -- Erin Bell

Thanks, Erin. For now we're working with one of our regular contractors on this. Nice site there at CU!

I'm still working on this issue.

Does Omeka have any suggestions for how we can solve the problem caused by a conflict between the .htaccess files for WordPress and Omeka?

Without knowing what the offending directives are, it's hard to say, but I'm assuming this is a conflict between some RewriteRules created by WordPress to do permalinks and the rules Omeka needs to run.

A simple rule like

RewriteRule ^$ index.php

in your install/.htaccess file might be enough to override whatever WordPress rules are mucking things up. (That rule should go right before the existing RewriteRule line in that .htaccess file.

Thanks,John. I'll give that a try.

Before I try what John suggested, I decided to post the .htaccess files for WordPress and Omeka. Perhaps this will help identify what must be done to resolve any conflicts.

WordPress .htaccess file

ErrorDocument 401 /401.html
AuthUserFile "[path_deleted]"
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

# BEGIN Custom Security
## Makes it harder to exploit index.html access.
Options All -Indexes
# END Custom Security

Omeka .htaccess file

# Remember to enable display_errors on development environments only.
<IfModule mod_php5.c>
php_value display_errors 0
php_flag register_globals off
</IfModule>

RewriteEngine on

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

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^admin/ - [C]
RewriteRule .* admin/index.php [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .* index.php

<FilesMatch "\.(php|ini)$">
Order Allow,Deny
Deny from all
</FilesMatch>

<Files index.php>
Allow from all
</Files>

# Uncomment the lines below in order to enable caching of some files via Apache (after a finished site has gone live)
<IfModule mod_expires.c>
# <FilesMatch "\.(js|ico|gif|jpg|png|css)$">
# ExpiresActive on
# ExpiresDefault "access plus 10 day"
# </FilesMatch>
</IfModule>

I hope that Omeka -- well, OK, John ;-) -- can evaluate these two .htaccess files and tell me what can be done to make Omeka and WordPress play well together. Otherwise, we might manage to get Omeka installed only to fall prey to some RewriteEngine malady.

Hi,

I think you might want to scroll back up and see the post by Erin Belle who has experience working with Omeka and WordPress and ask him for some specific help: ebellempire at gmail.com.

Thanks for your suggestion, Sheila. Of course Erin was responding to the possibility of paid support. While I am not against paying for support, I was hoping that Omeka might have some free advice about this issue.

I understand that Omeka cannot support every possible combination of software. But I would think that the installation of Omeka in the context of WordPress is common.

If John or anyone else has anything further to add about this issure, I would appreciate it. Otherwise I will see about paid assistance.

Have you tried my suggestion from earlier? I believe, even after seeing your files, that it should work.

The "normal" Omeka redirects, the ones that are important for Omeka to work *after* installation are working correctly; this is the only reason you are getting redirected to "omeka/install" in the first place.

Assuming that all the files exist as they should in the "install" directory, that rule should be all you need.

Thanks for your reply, John.

I have not yet tried what you suggested earlier. Your earlier suggestion, while a good one, was not based on full knowledge of the contents of the two conflicting .htaccess files. Since you were kind enough to review these two files and affirm that your original advice still applies, I feel better about proceeding.

As I mentioned in a previous post in this thread, I wanted to avoid a situation where "... we might manage to get Omeka installed only to fall prey [later] to some RewriteEngine malady."

Thanks for your help and your good work with Omeka.

Hi all,

I'm looking into this for John and see that mod_rewrite seems to be disabled.

See http://www.thehaikufoundation.org/omeka/install/mod-rewrite.php

error displayed: "mod_rewrite is DISABLED"

Might this be the problem? And if so, any clue as to the cause?

Also worth noting, we only get the WordPress 404 error when the database credentials are correct. If I muck up db.ini, we get an Omeka error, so I actually think the problem is somewhere in the install script/directory. Or not, but this seems notable.

The correct URL to see if mod_rewrite is enabled or not would be "omeka/install/check-mod-rewrite.html", and on that site, it confirms that mod_rewrite is enabled.

If you can sometimes get an actual Omeka error message from the installer, that would tend to point away from mod_rewrite as the culprit.

1. "mod_rewrite is DISABLED" -- My web host assures me that mod_rewrite is enabled for the server where both WordPress and Omeka (and a Simple Machines forum) are installed. If mod_rewrite were not enabled (in general), wouldn't WordPress throw an error?

2. "only get the WordPress 404 error..." Sorry I don't know enough to comment on this. I can say that I zipped the configured omeka folder, FTP'd it to my web server, then expanded it on the server. So I would think that the files would be as intact as they are ever likely to be.

FYI... I have installed many applications and modules this way, but of course I could have made some sort of error this time. But I am not aware of any obvious source of error.

Erin, if you think that there might be a problem with the Omeka files that I uploaded, I suppose that you could save the relevant config file somewhere and re-upload the files. Only if that seems a likely source of error.

I could also open a ticket with my web host and enable you to post questions directly to them, if that would help.

So the issue seems to be that when Omeka attempts to connect to the database using valid credentials, something causes a redirect/404 error (while invalid credentials cause the expected Omeka database error). The error is not happening until the install script is initiated, after the database is verified. Does this sound like an accurate assessment (or rather one that might have a readily identifiable cause)? I've never seen this happen.

Dave, I actually already re-uploaded Omeka and edited the db user settings just to be sure.

My web host says:

"Redirects are determined almost exclusively by .htaccess files and the Apache configuration. There is nothing I can think of in the default Apache configuration that would cause any redirects as described, so it would be worthwhile to check the relevant directories and parent directories for any .htaccess files that could be causing the redirects. Redirects can also be coded directly into web pages, but this is likely something the developer would be aware of in their own code."

I have concluded that the problem we are seeing is not an Omeka problem.

After consulting with John in this forum; Erin outside of this forum; tech support from my web host; and two database developers who have customized certain aspects of our site . . . I have concluded that our difficulties are caused by a hard-to-diagnose combination of factors.

Given that we are a small nonprofit without technical staff, we will investigate the possibility of hosting a collection on Omeka.net.

Thanks to all who offered assistance.

The problem I cited in this ticket seems to have been caused bu the PHP image on our host.

I asked our web host to do certain upgrades in order to meet the Omeka prerequisites. As part of that effort, they installed PHP 5.3.10. This was within the Omeka prereqs (“PHP version 5.3+ or the Fileinfo extension is highly recommended”).

However, this version of PHP (or this particular installed image) seems to have caused the Omeka install script to fail with mysterious errors. All of the experts I consulted swore up and down they’d never seen these errors. The remedy—after a month of trying various things—was to downgrade the version of PHP on our server from PHP 5.3.10 to PHP 5.2.17. This solved our problem.

Thanks to all who offered assistance.

That's a tricky one. Glad you managed to figure it out!