OK – this post is Part II because we have discussed the same exact issue before – however, the cause of the issue was different then. In fact, we knew there must be other reasons for this problem to happen, and, unfortunately, we were not disappointed…
Earlier today a lady who has an apparel website called us and told us that she’s not able to login to her Joomla website with her usual password. So we reset her password, and we tried to login, but it didn’t work, and we didn’t see any error. Immediately we thought that the cause for this problem was the same to the one we had before, and so we checked whether all the plugins related to the login activity were enabled, and they were. Odd!
So we thought, maybe some of the files related to the login were corrupted, and so we overwrote all the client’s core Joomla files with copies from a fresh installation (we ensured, of course, that we were using the same version of Joomla, and we backed up the website before doing this). This didn’t work either…
So, we started debugging the Joomla website at a lower level. We printed, in the index.php file (that is under the administrator folder), the $_POST variable. We did this by adding the following line to the beginning of that file:
print_r($_POST);
We then tried to login, and, to our surprise, the $_POST array was empty. This means that the fields filled in in the login form where not transferred to the page that Joomla was submitting to. That was extremely odd. We have been working with PHP since the late 90s and we have never seen this before (well, $_POST was called $HTTP_POST_VARS back then, but still). We thought it was a problem with the website’s server, but after doing a quick test (e.g. uploading a self-submitting HTML form to another web accessible location on the server and making sure that the $_POST array is not empty), we were sure that the problem only existed on the website itself.
So what could make a website’s environment different from the rest of the server?
According to our experience, there are two files that can override the server’s settings (in a LAMP environment) at the website level:
- The .htaccess file.
-
A local php.ini file.
The website didn’t have a php.ini file, but it had a weird .htaccess file. Here’s how it looked like:
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^ourclientjoomlawebsite [NC]
RewriteRule ^(.*)$ http://www.ourclientjoomlawebsite/$1 [L,R=301]
Options +FollowSymLinks
RewriteCond %{THE_REQUEST} ^.*/index.php
RewriteRule ^(.*)index.php$ http://www.ourclientjoomlawebsite/$1 [R=301,L]
## ERROR PAGES
##
ErrorDocument 404 /404.html
Hmmmmmm! That’s not what a Joomla .htaccess file should look like. So we overwrote the .htaccess with a fresh copy from a clean Joomla installation (same version), and the problem was solved! It was as easy as that!
It literally took us hours to solve this problem – we hope that those of you who are reading this post (and who have this problem – if you’re reading this post just for fun then we’re flattered, but maybe you should consider finding another hobby! ) can solve it in under a minute. If you can’t, then feel free to contact us and we will solve your problem. Our fees are extremely affordable, our work is professional, and we are super friendly!