I’m having this problem installing Omeka-S, but I didn’t get any takers when posting in the Omeka-S forum and it seems likely to be a problem that could occur installing normal Omeka too, so I thought I’d check here…
I’ve followed the instructions in the user manual to install Omeka-S (2.1.2), but have hit a wall. I’ve uploaded the files to an /omeka-s directory in my (Linux) server’s html folder, they’re all writable, readable and executable by www-data as far as I’m aware, and I’ve put the SQL user (who has all permissions for this db) and database info in database.ini. But when I go to /omeka-s/admin, I get an ERR_CONNECTION_REFUSED (on https; on http I get a 404). What could I be missing here?
When you go to just “/omeka-s” on HTTP, do you get redirected to “/omeka-s/install” (which is then a 404)? If that’s what’s happening your issue there is almost certainly a mod_rewrite issue: in particular check to make sure that the .htaccess file is present in the omeka-s folder, and that you have enabled AllowOverride in your main Apache configuration.
The “connection refused” error on HTTPS is probably unrelated to Omeka one way or the other, that’s usually just a situation where your server is not configured for HTTPS.
No, I don’t get a redirect, just a 500 error. There is an .htaccess file there and mod_rewrite is enabled, but I see that I indeed (if I’m not forgetting about something) didn’t fiddle with the configuration. Where do I need to enable AllowOverride - do I create a new rule for the omeka-s directory specifically?
And yeah, I think you’re right that the “connection refused” is a server-wide problem; I hadn’t realized that my installations of other things weren’t working on https either. Thanks!
A 500 is typically going to be logged on the server: if it’s an Apache issue it should be in Apache’s log. If it’s a PHP problem it could be in a couple places depending on how your PHP is set up, but possibly also in the Apache log (if you’re using mod_php). Something like having too low of a version of PHP can manifest like this, just as an example.
AllowOverride can be enabled wherever you want as long as it’s covering the Omeka or Omeka S directory. Typically we tell people to enable it for their document root, just because that’s an existing Directory section (and many people are installing Omeka at the root anyway). If you’re getting a 500 it’s probably not AllowOverride that’s your immediate issue, though.
Sorry for the delay. I enabled AllowOverride but you’re right that I’m still getting a 500 error. It’s in the log as: PHP Parse error: syntax error, unexpected ‘const’ (T_CONST), expecting variable (T_VARIABLE) in /var/www/html/omeka-s/vendor/doctrine/dbal/lib/Doctrine/DBAL/Platforms/MySqlPlatform.php on line 38
The line in the PHP file that’s throwing this error is: public const LENGTH_LIMIT_TINYTEXT = 255;
The server is currently running PHP 7.0.33. Do you think the issue is that this needs updating, then? I didn’t realize it was running a version this old (this is meant to be our new server) and I’ll talk to our IT.
Makes sense. I’d assumed that we were running an up-to-date version since this was the entire point of getting a new server, so hopefully this’ll be sorted soon. Sorry for the runaround!
PHP has been updated, but I’m still getting a 500 error at omeka-s/admin, omeka-s/install, omeka-s etc., with the same log entry. Any idea? (Do I need to delete and reinstall Omeka-S and the database? I’m not sure why I would)
Have you confirmed this with, say, a test file that just contains
<?php phpinfo();
to see what version the server is really using for web content?
The “public const” thing it’s complaining about there became legal in PHP 7.1, so if you’re getting an error referencing that, I can only conclude that you’re still using a version older than 7.1
Sorry for the delay, I had to fix this with IT. phpinfo now shows it running the correct version, and I was able to get to the install screen after installing the xml extension and restarting apache. Thanks for all your help and patience!