Questions about htaccess file

[vscianca]

First, thanks for reading this and for your help. I’m using Reclaim Hosting and editing through cPanel. Last month, after making a copy, I edited the htaccess file to allow error logs to be read. I changed the first line from SetEnv APPLICATION_ENV "production" to SetEnv APPLICATION_ENV "development" It looked like this when I was done:

# SetEnv APPLICATION_ENV "development"

RewriteEngine On
RewriteBase /

RewriteCond %{REQUEST_FILENAME} deleteme\.\w+\.php
RewriteRule (.*) - [L]


# The following rule tells Apache that if the requested filename
# exists, simply serve it.
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule !\.(php[0-9]?|phtml|phps|phar|hphp)$ - [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>

Today, I am getting the same error message that wants me to change the first line of my htaccess file. When I opened the file this time, it looked completely different:

# BEGIN cPanel-generated php ini directives, do not edit
# Manual editing of this file may result in unexpected behavior.
# To make changes to this file, use the cPanel MultiPHP INI Editor (Home >> Software >> MultiPHP INI Editor)
# For more information, read our documentation (https://go.cpanel.net/EA4ModifyINI)
<IfModule php7_module>
   php_flag display_errors Off
   php_value max_execution_time 90
   php_value max_input_time 60
   php_value max_input_vars 1000
   php_value memory_limit 256M
   php_value post_max_size 150M
   php_value session.gc_maxlifetime 1440
   php_value session.save_path "/var/cpanel/php/sessions/ea-php74"
   php_value upload_max_filesize 150M
   php_flag zlib.output_compression Off
</IfModule>
<IfModule lsapi_module>
   php_flag display_errors Off
   php_value max_execution_time 90
   php_value max_input_time 60
   php_value max_input_vars 1000
   php_value memory_limit 256M
   php_value post_max_size 150M
   php_value session.gc_maxlifetime 1440
   php_value session.save_path "/var/cpanel/php/sessions/ea-php74"
   php_value upload_max_filesize 150M
   php_flag zlib.output_compression Off
</IfModule>
# END cPanel-generated php ini directives, do not edit
<IfModule mod_deflate.c>
    SetOutputFilter DEFLATE
    <IfModule mod_setenvif.c>
        # Netscape 4.x has some problems...
        BrowserMatch ^Mozilla/4 gzip-only-text/html

        # Netscape 4.06-4.08 have some more problems
        BrowserMatch ^Mozilla/4\.0[678] no-gzip

        # MSIE masquerades as Netscape, but it is fine
        # BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

        # NOTE: Due to a bug in mod_setenvif up to Apache 2.0.48
        # the above regex won't work. You can use the following
        # workaround to get the desired effect:
        BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

        # Don't compress images
        SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png)$ no-gzip dont-vary
    </IfModule>

    <IfModule mod_headers.c>
        # Make sure proxies don't deliver the wrong content
        Header append Vary User-Agent env=!dont-vary
    </IfModule>
</IfModule>

During the last month, I created a second Omeka S site attached to our institutional account. Did I break something? Can I remove the new htaccess file and replace it with the original one, or will that be even worse? I’m very familiar with using Omeka S as a database, but not so much with using it from the very back end. None of this makes very much sense to me and I regret being overconfident in my abilities.

[jflatnes]

Are you sure you’re looking at the right .htaccess file, and/or that you’re in the right folder?

The second one there, that does look like it was autogenerated by your host at some point. But if it really replaced the Omeka S one entirely, your site wouldn’t be working at all: you’d probably be getting a 404 error on every page that’s not the homepage.

[vscianca]

Sorry, I should have been more specific. I said “error message,” but it happens on every page of the sites. I didn’t know what error it was, because Omeka wouldn’t show me the logs, but it sounds like what you’re saying is the problem I’m having.

[jflatnes]

You’re getting the “Omeka has encountered an error” page on every URL? That isn’t really the same as the “htaccess” type of problem you’d see; with the .htaccess gone/replaced you’d see a generic “Not Found” error page on everything except the home.

So I’d still double-check to make sure you’re looking at the correct .htaccess file. If you’re sure, or you want to try anyway, what you could do is put the contents of the original Omeka S .htaccess you had before after all the stuff that’s in the .htaccess now, so just add it to the end.

[vscianca]

I didn’t realize there was more than one htaccess file! Okay, I see that there are two, one in /home/domekas and one in public_html. The one in public_html has the # SetEnv APPLICATION_ENV "development" line in it, so that must be the one I edited a month ago. Is it not the right one to be able to see error logs?

Anyway, I apologize, I didn’t realize you could attach files. This is what the page looks like when you try to view any page or item:

Knowing all of this, do you think there’s an issue with the htaccess file(s) at all, or do you think it may be something else entirely?

Thank you again, this is very much appreciated.

[jflatnes]

I don’t think this is an .htaccess error.

In terms of the message not showing, if the line in your .htaccess actually reads

# SetEnv APPLICATION_ENV "development"

that would be why it’s not working: the # at the front of the line marks the line as a comment and makes it not apply. You’d want to delete that # for the line to take effect.

On the actual error you’re seeing, with this screenshot I’d say it’s a high chance that the problem is related to your selected theme. The most common situation where I’ve seen people get into this situation is when they have a theme version that’s not compatible with their current Omeka S version.

[vscianca]

Yes, that was it, I needed to delete the #. And once I did, the error logs showed that the current theme was not compatible with our version of Omeka S. Thank you so much again!