I’m moving my Omeka S instance from a hoster to another. After transferring the content, and restoring the dumped database, it looks like every omeka URL resolves to “File not found.”
What could cause this error?
I’ve checked that .htaccess is correct. It look like AllowOverride is enabled (tough I can’t really be sure of that). Root page, and admin page show the same error, like any other unexisting page (random url).
I’ve just found out the following error:
example.org [Thu Nov 09 10:42:35.144751 2023] [fastcgi:error] [pid 8980:tid 140396642334464] [client 193.33.56.135:0] FastCGI: server “/home/clients/87af2e1106916e/.config/apache/example.org/.fpm/php5.external” stderr: Primary script unknown
After asking to my hoster support, it appears that they found an error in the default .htaccess file of Omeka S:
RewriteCond %{REQUEST_URI}::$1 ^(/.+)/(.*)::\2$
RewriteRule ^(.*) - [E=BASE:%1]
RewriteCond %{ENV:REDIRECT_OMEKA_REQ} !"1"
RewriteRule ^(.*)$ %{ENV:BASE}/index.php [E=OMEKA_REQ:"1",L]
The first instruction set is creating the BASE variable. The second instruction set redirects index.php toward this BASE which does not exist.
Omeka works again when changing the .htaccess file as follows:
-RewriteRule ^(.*)$ %{ENV:BASE}/index.php [E=OMEKA_REQ:"1",L]
+RewriteRule ^(.*)$ index.php [E=OMEKA_REQ:"1",L]
Do you have an opinion on this error, and on the fix?
I think we’ve seen issues before with a very small number of servers working with the default .htaccess. The purpose of the more complex default rules are to automatically handle servers where the base URL is not typical.
If Omeka S is working fine with the change you showed here, it shouldn’t be an issue.
I feel that the configuration of my server is quite common, quite standard. I read from your answer that the rules that are implemented in the .htaccess file are there to handle specific and atypical configurations.
Don’t you think Omeka should at first support default configuration rather than atypical configuration?
Currently, it looks like default configuration might have some problem while atypical configuration might work well…
My question is a naive one, I might be wrong. And if I am, please tell me why!
The standard code is there to handle the somewhat-common cases where you’d otherwise have to have used “RewriteBase” and manually set it to the right value.
In terms of typical vs. atypical, the only thing I can say on that front is that the out-of-the-box configuration works for the vast majority of hosts. I’m not quite sure what the difference is for yours that makes it incompatible. The “ENV:BASE” version of that RewriteRule line is what Laminas (the basic framework library on which Omeka S is built) uses and suggests, and is where we’ve taken that pattern from.
Ok, thanks for the reply.