Late last night, a new client called us and told us that he can’t login to his Joomla website; that he’s being redirected to the login page with no errors when he logs in with either correct or wrong credentials. Of course, we’ve seen this issue several times, and so we thought it was an easy task, but we were wrong.
The problem with this task is that there were several issues causing the problem, and, if that wasn’t enough, there was a unpredictable twist that made our eyes bleed (they still are very red!). Let’s start with the normal issues:
- The log and the tmp folders defined in the configuration.php file were wrong. We suspect the cause of the issue was a change in the environment (we don’t really like it when hosts change environments on Joomla administrators without telling them).
-
Apache was not able to write to the current session path, so we explicitly forced Apache to use another folder to save session data to by adding the following code (note that the below code is specific to Windows and is specific to our client’s filesystem):
session_save_path(‘C:\\sites\\webroot\\joomla\\tmp’);
-
The session.php located under the libraries/joomla/session/ folder had the session_start line commented out. We really have no idea how that happened, but we think it was a developer who was trying to solve the problem but ended up creating a bigger problem. The reason why we think so is because when we uncommented this line out, we started seeing the following error on every page:
php – Warning: session_start() [function.session-start]: Cannot send session cookie – headers already sent by (output started at configuration.php…).
After doing all the above, we still had a problem logging in, but the warning generated by fixing the last issue gave us a hint on what the idea was: the configuration.php file was outputting something when it shouldn’t (any output prior to initializing the session will break it and will cause the session to being re-initialized on every refresh, causing the login to fail). The problem is, we checked, double-checked, triple-checked, zillion-checked the configuration.php file and we couldn’t find any issue: there was no trailing space neither before the opening PHP tag nor after the closing PHP tag.
So we started banging our heads against every wall in the office, and between each bang, we checked the configuration.php file one more time to see if the problem is there. And then, suddenly, a mix of luck and inspiration merged into a huge lightning that hit us, making us notice that the configuration.php file was saved in UTF-8 format, with signature. Ah ha! So the configuration.php file had a Byte Order Mark (BOM) that was causing the issue.
We saved the configuration.php file in UTF-8 format, without signature (using EmEditor, which is, in our very humble opinion, the best editor out there) and that fixed the problem.
But what is a “Byte Order Mark”?
Without getting into too much details, a Byte Order Mark (BOM) is an invisible unicode character (which is, if you really need to know, U+FEFF) that is added to the beginning of a file to let the application using the file know which byte order the file is using. When you save a UTF-8 file with signature, then the BOM is added to the beginning of the file.
But why was the BOM added to the configuration.php file?
The BOM was added to the configuration.php file because our client had Thai characters in that file (specifically in the $MetaDesc, $MetaKeys, and the $MetaTitle values of that file), and used the host’s File Manager to save that file, and that File Manager was saving files with UTF-8 characters with signature (which it should have saved such files without signature). By the way, Notepad saves any UTF-8 encoded file with signature, which is why you should use an editor such as, ahem, EmEditor (we swear we are not making money every time we mention that editor) which allows the user to save a file in UTF-8 without signature.
If you’re having login issues to your Joomla website and you’re not seeing errors, then check, in addition to the methods described in the posts linked to above, that your configuration.php is saved in UTF-8 without signature (if it is already saved in UTF-8). If you’re still having problems, then your best option would be to contact us. We’ll solve the problem rapidly, affordably, and efficiently, and we promise you that we will be your friends as long as we live!