Trying to update a working Omeka S 2.0.2 installation to version 3.0.1.
On following step 7 “In your web browser, go to your site’s admin page (yoururl/admin) and run any migrations that are needed.”, I received the above mentioned (php related?) message.
PHP Version 7.4.3 with OPcache
Any ideas?
Hmm. That is the kind of error message you get when your server’s PHP setup doesn’t know what script to run, basically.
Just to check one fairly likely possibility, did the .htaccess file for Omeka S possibly get lost or deleted during your upgrade process?
Your guess was kind of right.
Although the .htaccess file for Omeka S 3.0.1. was in place, it produced the error.
By replacing it with the .htaccess file for Omeka S 2.0.2 the 3.0.1 installtion started to work.
Omeka 3.0.1 .htaccess file content as follows:
SetEnv APPLICATION_ENV "production"
RewriteEngine On
# The following rule tells Apache that if the requested filename
# exists, simply serve it.
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule !\.(php[0-9]?|phtml|phps)$ - [NC,C]
RewriteRule !(?:^|/)\.(?!well-known(?:/.*)?$) - [C]
RewriteRule .* - [L]
# Strip any trailing slashes from incoming requests
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} ^(.+)/+$
RewriteRule .* %1 [R=307,L]
# The following rewrites all other queries to index.php. The
# condition ensures that if you are using Apache aliases to do
# mass virtual hosting, the base path will be prepended to
# allow proper resolution of the index.php file; it will work
# in non-aliased environments as well, providing a safe, one-size
# fits all solution.
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]
# 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>
Omeka 2.0.2 .htaccess file content as follows:
SetEnv APPLICATION_ENV "production"
RewriteEngine On
# The following rule tells Apache that if the requested filename
# exists, simply serve it.
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [L]
# Strip any trailing slashes from incoming requests
RewriteCond %{REQUEST_URI} ^(.+)/+$
RewriteRule .* %1 [R=307,L]
# The following rewrites all other queries to index.php. The
# condition ensures that if you are using Apache aliases to do
# mass virtual hosting, the base path will be prepended to
# allow proper resolution of the index.php file; it will work
# in non-aliased environments as well, providing a safe, one-size
# fits all solution.
RewriteCond %{REQUEST_URI}::$1 ^(/.+)/(.*)::\2$
RewriteRule ^(.*) - [E=BASE:%1]
RewriteRule ^(.*)$ %{ENV:BASE}/index.php [L]
# 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>
Hmmm, that’s odd.
If you use the 3.0.1 version but make this change: this line
RewriteRule ^(.*)$ %{ENV:BASE}/index.php [E=OMEKA_REQ:"1",L]
to
RewriteRule ^(.*)$ %{ENV:BASE}/index.php [E=OMEKA_REQ:"1",END]
does it make any difference?
did not make any difference. 
Output is still: “No input file specified.”
The problem seems to be in the upper part.
Replacing these lines in the 3.0.1 version
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule !\.(php[0-9]?|phtml|phps)$ - [NC,C]
RewriteRule !(?:^|/)\.(?!well-known(?:/.*)?$) - [C]
RewriteRule .* - [L]
with the lines from version 2.0.2
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [L]
once again delivered a working installation.
Hmmm. Do you control your server or is it run by a hosting company or an IT department or something like that?
The difference in those lines is just eliminating some types of files within the installation from being served directly: ones with .php and similar extensions and “hidden” files (those starting with a period).
It’s a problem I can’t reproduce personally, with version 3 running on several different Linux distributions… I imagine the difference is down to Apache version or configuration of how PHP is getting run on this server, but it’s hard to say much more without an idea of what that difference might be.
My assumption would be that simply removing the second line of the 3.0.1 block you quoted, the one that mentions php, would also work. That’s the most likely culprit, anyway. As for making it work as-is as intended, my best guess would be that something could be changed about how Apache is configured to pass PHP requests to the PHP-FPM server.
Your assumption about the following line as the most likely culprit was right.
RewriteRule !\.(php[0-9]?|phtml|phps)$ - [NC,C]
Removing it did the trick.
Now I find myself a little bit stuck. The server is run by a hosting company. They already confirmed that the general system requirements are met by their server:
* Linux
* Apache (with [AllowOverride](https://httpd.apache.org/docs/2.4/mod/core.html#allowoverride) set to "All" and [mod_rewrite](http://httpd.apache.org/docs/current/mod/mod_rewrite.html) enabled)
* MySQL 5.6.4+ (or MariaDB 10.0.5+)
* PHP 7.1+ (latest stable version preferred, with [PDO](http://php.net/manual/en/intro.pdo.php), [pdo_mysql](http://php.net/manual/en/ref.pdo-mysql.php), and [xml](http://php.net/manual/en/intro.xml.php) extensions installed)
Any specific questions I could ask their support in order to track down the problem?
Hmm, I feel like any such problem might be too “in the weeds” and in any case probably isn’t something you’re likely to make much headway on through hosting support.
Here’s another possibility: take the 3.0.1 .htaccess as-is, except replace the whole last set of rules (the three lines after the large comment starting “The following rewrites”) with this:
RewriteRule ^(.*)$ index.php
The block of three lines there is a more complex setup designed to account for differing server setups seamlessly, but for the “usual” situation the single line above is sufficient, and eliminating that complexity may sidestep this issue you’re having.
Failing that, the previous version will still work fine. The offending line blocking .php files being served is really more of a “belt and suspenders” approach: it’s really only intended to provide a backstop in case an Omeka administrator decides to alter the default security settings and allow .php files to be uploaded.
So my adapted Omeka S 3.0.1 .htacces file now reads like:
SetEnv APPLICATION_ENV "production"
RewriteEngine On
# The following rule tells Apache that if the requested filename
# exists, simply serve it.
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule !\.(php[0-9]?|phtml|phps)$ - [NC,C]
RewriteRule !(?:^|/)\.(?!well-known(?:/.*)?$) - [C]
RewriteRule .* - [L]
# Strip any trailing slashes from incoming requests
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} ^(.+)/+$
RewriteRule .* %1 [R=307,L]
# The following rewrites all other queries to index.php. The
# condition ensures that if you are using Apache aliases to do
# mass virtual hosting, the base path will be prepended to
# allow proper resolution of the index.php file; it will work
# in non-aliased environments as well, providing a safe, one-size
# fits all solution.
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]
RewriteRule ^(.*)$ index.php
# 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>
Is that o.k.?
That’s OK, yes. If it’s working, there’s not an issue or downside of the version you’ve posted.
I was actually slightly inaccurate in my last post: I meant to say it was 4 lines you could remove, not 3. So the 2 lines you’ve left in place right after the large comment, you could comment them out as well. They won’t harm anything still being there as you have it now, but they also serve no purpose (they only go along with the other 2 lines you’d already commented out).
Done!
Thank you for your support.
This topic was automatically closed 250 days after the last reply. New replies are no longer allowed.