Support

Hello Marcel,

can you please attach the error log? You might have to ask to your host to help you, since sometimes the CLI error log is not directly available.

I meant the PHP error_log: I suspect something wrong is happening, but I need to take a look at it to understand what's going on.

Yes, let's give it a try.

Can you please try to force the debug mode by adding these lines to the cli file, immediately after the <?php tag?

define('AKEEBADEBUG', 1);
ini_set('display_errors', 1);
error_reporting(E_ALL);

Is the backup running in the backend? Can you please double check if there are any additional databases added to the same profile?

I suspect there's a different PHP setup for CLI and web. Most likely your CLI PHP executable does not have support for mysql/mysqli or the host address is not reachable under CLI (ie you are using localhost but the database server requires an IP address).

I think you should contact your hosting about this issue, saying that you can't connect to the database under CLI.

Please let me make this abundantly clear. There is absolutely no security reason whatsoever in any possible and conceivable universe for moving your configuration.php file outside the site's root. This is a myth. For the very detailed arguments please refer to my blog post "Keep your files where I can see them!" which I wrote all the way back in September 2012.

Since you followed the instructions to modify Joomla! to load a configuration.php file from outside your site's root you should have been told that you need three defines.php files for the three different Joomla! areas:

1. Your site's public front-end (in the site's root)
2. Your site's administrator backend (in the administrator directory)
3. Your site's CLI scripts (in the cli directory)

Apparently you forgot the third (or, typically, the person who wrote the instructions forgot all about it), which is a site configuration error. OK, you can fix it easily.

You should, however, be aware of the pitfalls for restoring a site with a moved configuration.php. It will be impossible for the installer script (ANGIE) to find the configuration.php file of the site since we're only looking at the site root. We cannot include defines.php to detect custom JPATH_CONFIGURATION folders, at least not without risking a white page of death should your defines.php reference something not available on the server where your site is now being restored to. Not finding a configuration.php is a nuissance you can work around, a white page of death means it's impossible to restore the site so that is why we chose to not load defines.php.

The result of not finding a configuration.php is that all values normally read from there will be reset to default and have to be entered from scratch in the ANGIE restoration script. Moreover, the generated configuration.php file in the site's root will be not read since defines.php tells it to read it from somewhere else. That "somewhere else" will not exist (if it's a new site) or will contain the old values (if it's the same site), so the restored site will not work without manual adjustments! At worst your site won't even load with "configuration.php not present and installation code not found", or it will loop back to the restoration script. At best your site will load, but it will be loading the wrong configuration. Which might not be the best case scenario.

This could become a nightmare scenario if you are cloning your site to create a dev site. Both sites will be reading the same configuration.php file, therefore both will be talking to the same database. Any change in the dev site will modify the live site and you will only find out when it is way too late. We've had people accuse us of being idiots or worse when this happened to them. However, this is a self-inflicted problem: we do warn you not to move your configuration.php file in our documentation. There's a good reason we do that.

My suggestion is to move your configuration.php file back to your site's root. There's no added security in storing it elsewhere.

One more thing. If someone says "do X for security reasons" don't rush into action. Ask them why and expect a detailed reply with reasonable arguments. If someone told you to do something pointless, e.g. start singing yama yama yama "for security reasons" would you do that? Of course not, that would be silly and have nothing to do with security. You see where I'm getting at? :)