How I caused and solved “Infinite loop detected in JError”

I should have known better than to try and postpone moving a site from our development server to it’s live environment on a Friday afternoon, merely an hour before I’d stop working. As usual, that’s why things go wrong.

After creating the back-up of the development server, I uploaded it to the server and fired up Akeeba Kickstart. (Read an article here on how to use Akeeba Kickstart with your own distro, an new article will come soon)  Because of a bad experience with the mysql server the day before, I decided to create a new database. I decided to be as “safe as possible”, and generated this cool fellow:

Xk;&7~F>sR9k=5ZVo2]q?>>~ka=a_#s3vDs”

I used Akeeka Kickstart to deploy the site on the live environment and this time I encountered no problems with the database. I was relieved. Until I tried to vied the site, and was greeted with the following message:

Infinite loop detected in JError

Solving this issue

I’m not claiming credit where it’s not due. An article in the Joomla! knowledge base explains perfectly what the cause of this problem is. To summarize, this file indicates that something’s wrong with your configuration file. Read the document for more information, it’ll set you on the right path.

As for me, the “problem” was… the password for the MySQL database. I’ve learned that, generally speaking, it’s not a good idea to end your password with a “.  Or any other setting in the configuration.php file, as it turns out…

30 thoughts on “How I caused and solved “Infinite loop detected in JError””

  1. You can also get this infinite loop error from having the incorrect database credentials in your configuration.php file. It seems this is a default error for various issues.

    1. Yeah, the explanation in the article I linked to is “something is wrong with either of these (insert configuration.php options) settings.” Not the best of error reporting, but okay. 🙂

  2. Hi, I have encountered this problem a few times, with several causes. Today I came across a new one and thought it would be useful to share.

    Scenario
    A failed HDD on my macbook pro caused me to have to re-install the stock drive and restore from time machine (thank Jobs for TM). After a time machine restore it is usually necessary to fix privileges in Disk Utility. I did this and everything seems fine except that my localhost mamp sites are returning the infinite loop error (this happened before and after the privilege fix)

    Solution
    My config files are actually fine, no problems there. It took me opening phpmyadmin in mamp to discover the problem… the databases are there but the users have disappeared! The solution was to just re-create the users (using the credentials from the sites config file), grant privileges to the databases (in mamp) and presto, site back online

    I hope this helps someone else track down the cause of this error. It’s likely that mine is a fairly rare scenario… but it’s one more possibility to check off your list!

    1. Luke, thank you for charing your experience. There is something I would like to point out, though. If, like in your case, the users are removed, technically you still have a problem with the config file. After all, your config file now tells you to use a MySQL user that no longer exists!

      But you’re right of course. There could be many reasons for this problem to appear. Wrong password, missing users, wrong link to server… you name it.

      Again, thank you for sharing. It’s always appreciated.

      – Steven.

  3. Hello everybody,

    I experienced the same problem on my MAMP configuration on Mac OS Lion after upgrading Joomla 1.7.0 to version 1.7.3. Perhaps I’m using the wrong approach but what I did was copying all new files over the existing Joomla installation. After copying the files, I got the “Infinite loop detected in JError” message on the frontend.

    I read many articles about wrong passwords or databasenames in the configurationfile. But that file never changed so it made no sense. The same for wrong paths to tmp or log directories.

    In the end I found out that “copying” the files by FTP (locally) to overwrite the old files was the answer to my problem! It might work for someone else as well, that’s why I wanted to share this information.

    To make FTP work I had to do the following: (I’m not running the server edition)
    # launchctl load -w /System/Library/LaunchDaemons/ftp.plist
    # ftp Peter@127.0.0.1

    Best regards,
    Peter.

    1. Hi,

      I can’t tell you in detail what the problem is. It could be any setting in your configuration file, so I suggest you check your config file and see if all settings are still correct. 🙂

  4. I had Infinite loop detected in JError in xampp. when using 2 identical sites and dbs, different names though.
    All configs were correct. Still the error.

    final solution was to look at privileges for the entire localhost in phpMyAdmin. That revealed a “no” in the password setting for the test server. I gave him a password and made sure he had all the privileges he needed. And it worked. No more Infinite loop detected in JError.

    The hardest problems to solve are the ones we cause ourselves.

  5. Hello,

    I was using Wampserver (multiple sites), when the same thing suddenly happened on every site.
    My solution was to use system restore, problem solved.

    Perhaps it’s not the normal route to take; but having the same problem on all sites at once did not make any sense either. In my case, I think it was down to a recent Wampserver upgrade.

    The important thing, is to always back up each site. So you can turn the clock back.
    I don’t know how many times Akeeba backup has saved me.

  6. I found the best solution is to do a MySQL restart. If you you do not have server access to do a restart you will have to ask your hosting company to do it.

  7. thanks, worked like a charm. moving site over to godaddy and found that there was a space at the end of the dB name. removing it fixed the problem.

  8. Thank you, thank you, thank you! I scrutinized my configuration.php and indeed when I ported it from my local development environment up to hostgator, I didn’t realize I had to change that stuff.

  9. I actually got the same error just now (that’s how I landed at this article 😉 )
    Problem ended up being that somehow permissions for the configuration file were changed to 444 – changing them back to 644 fixed it!

  10. I’ve been tearing my hair out over this one, checked the configuration file and saw no problem, and eventually – in desperation – started searching for articles on the web which would help me.

    Your article made me stop and think, and give the configuration file one more careful look.

    I’d put the database name in the user field and vice versa. Duh!

    There are probably a million stupid permutations of the same kind of mistake here…

  11. Thanks for every one for giving clues on the perticular error. I have suffer from this problem for two days. There was no error in perameters in the configuration.php file. First of all check wheather your mysql is up[ and running.

    Thanks.

  12. I found the same error after moving running webpage between two servers.
    There was one difference between servers – “$offset” variable. After change its value on destination server, the site came to live.

  13. i just fixed it all i did was gave my tmp file an absolute path
    and the permission for my config file to 644

  14. Just got the same issue solved. Issue was permission on the configuration file too (444 instead of 644).

Comments are closed.

Discover more from PowerUser Guide

Subscribe now to keep reading and get access to the full archive.

Continue reading