index.php appearing in folder structure

jpgreenwood April 20, 2016

Hello

I transferred my Omeka installation to my new host (InMotion) and had an error 500 on any page I tried to access. I spoke to InMotion support who replaced the default Omeka .htaccess file with the following:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Now the site works as it should, but index.php appears in URLs in the admin panel, ie:

http://lib.itgs.org/admin/index.php/users/login
http://lib.itgs.org/admin/index.php/tags

Obviously I'm happier now than I was, as the website is working, but is it possible to remove index.php from the filename without breaking it again?

Any help would be appreciated!

patrickmj April 21, 2016

A couple things.

First, they kept the rewrite rule for the public side, but not the admin side. Adding this line in the original .htaccess _might_ remove the index.php from those urls

RewriteRule ^admin/.*$ admin/index.php [L]

But it's hard to know for sure, since I don't know why the changes they made to .htaccess made it work -- probably some kind of server setting that I'm not familiar with.

MUCH more importantly, by replacing the .htaccess file, they've not only removed some helpful development tools, and other things. I'd strongly recommend going back to our .htaccess file and figuring out the 500 error with that in place.

jpgreenwood April 22, 2016

Thanks for your reply. I've restored the original .htaccess file, which is generating the following Apache error code when I visit the site at http://lib.itgs.org:

too many redirects

[Thu Apr 21 23:15:44.342660 2016] [core:error] [pid 9034:tid 140560552802048] [client 60.248.109.35:56959] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.

Interestingly, the site works as intended if I visit http://lib.itgs.org/index.php/ - this also goes for pages in the admin panel.

Can you suggest a .htaccess tweak for the original Omeka-generated file?

Thanks again for your help.

jpgreenwood May 3, 2016

Any joy on this? My work with Omeka has kind of ground to a halt & I don't have any other source of help.

patrickmj May 3, 2016

It's hard to impossible to come up with an .htaccess tweak without knowing the underlying server configuration that's causing things. Does the hosting company have any info to guide us?

jpgreenwood May 3, 2016

All I have from the hosting company is the Apache error code above. At the moment, everything works fine with /index.php/ added at the end of the URL:

http://lib.itgs.org/index.php/
http://lib.itgs.org/admin/index.php/
http://lib.itgs.org/admin/index.php/items/show/67

Etc etc. This is with the following .htaccess in place:

# Omeka .htaccess: Apache configuration file
# This file is required for Omeka to function correctly.

# --------------- #
# Error Reporting #
# --------------- #

# Uncomment the SetEnv line below to turn on detailed on-screen error
# reporting.
#
# Note: This should only be enabled for development or debugging. Keep this
# line commented for production sites.
#
# SetEnv APPLICATION_ENV development

# ------------- #
# Rewrite Rules #
# ------------- #

RewriteEngine on

# 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.
#
RewriteBase /

# Allow direct access to files (except PHP files)
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule !\.(php[0-9]?|phtml|phps)$ - [C]
RewriteRule .* - [L]

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

# -------------- #
# Access Control #
# -------------- #

# Block access to all .ini files.
<FilesMatch "\.ini$">
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order Allow,Deny
Deny from all
</IfModule>
</FilesMatch>

# --------#
# Caching #
# --------#

# Uncomment the lines below in order to enable caching of some files
# (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>

# ------------ #
# PHP Settings #
# ------------ #

<IfModule mod_php5.c>
php_flag register_globals off
php_flag magic_quotes_gpc off
</IfModule>

Could it be the rewrite rules above?

patrickmj May 3, 2016

One guess that we came up with is adding a / to the beginning of the rewrite rules, following their original rewrite of .htaccess. So, instead of

RewriteRule .* index.php

maybe 

RewriteRule .* /index.php

will do the trick. Might be that the same thing for the other rewrite rules will be in order.

jpgreenwood May 4, 2016

Thanks for your reply, Patrick. That didn't work, but removing these two lines did:

RewriteRule ^admin/.*$ admin/index.php [L]
RewriteRule .* index.php

Is removing those two lines likely to cause any problems elsewhere? Everything seems fine at the moment.

jpgreenwood May 4, 2016

Oops, spoke too soon - it doesn't work for items:

http://lib.itgs.org/items/show/67/ = 404 error

http://lib.itgs.org/index.php/items/show/67/ works.

Same for anything under /admin/ - collections, etc. The index pages display fine, but no subpages do. Cor, this is frustrating.

florenced May 30, 2016

Hi!
Try this :


# ------------- #
# Rewrite Rules #
# ------------- #

RewriteEngine on

# 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.
#
RewriteBase /

# Allow direct access to files (except PHP files)
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule !\.(php[0-9]?|phtml|phps)$ - [C]
RewriteRule .* - [L]

RewriteRule ^install/.*$ install/install.php [L]
RewriteRule ^admin/.*$ admin/index.php [L]
RewriteRule ^(.*)$ index.php

take care at the last line ^(.*)$ instead of .*

Works for me after some research bcause 1&1 doesn't seems to care...

jpgreenwood June 1, 2016

Sadly not. Still broken. Thanks for the thought, though!

I think I'm just going to have to abandon Omeka.

patrickmj June 1, 2016

The other option is to switch to a different hosting company. Reclaim Hosting has solid credentials with Omeka.