Support

Akeeba Backup for WordPress

#19921 – site:akeebabackup.com ERROR: Could not find wp-config.php

Posted in ‘Akeeba Backup for WordPress’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Friday, 25 April 2014 08:12 CDT
bbloom
Thank you for your excellent Akeeba Backup for WordPress. Stunning.

Your CRON job CLI script works. It is not broken.

First, the CLI email message:

==================================
ERROR: Could not find wp-config.php

Technical information
--
integration.php directory /home4/media/public_html/wp-content/plugins/akeebabackupwp/helpers
filePath /home4/media
isRecognised false
--
=================================

I keep the wp-config.php above the webroot.

If WP does not find wp-config.php in the webroot, then it searches for it above the webroot.

This is a WP feature, not a bug. Here is the link:
http://codex.wordpress.org/Hardening_WordPress#Securing_wp-config.php

So, your CLI script properly fails!

I think you have this check elsewhere in AB solo as well, not just in the CLI script.

Very happy to test your fix and report back to you.

Again, brilliant getting AB into WP.

-Bob

Custom Fields

WordPress version (in x.y.z format) 3.9 (latest!)
Which troubleshooter articles did you read? None
Have you searched the tickets before posting? Yes
Which documentation pages did you read? None
PHP version (in x.y.z format) 5.3.28
MySQL/database version  
Host (who is hosting your site, not your domain)  
Akeeba Backup version (x.y.z format) Akeeba Solo CLI 1.0.b2 (2014-04-01)
Kickstart version (x.y.z format)  
 
Friday, 25 April 2014 10:38 CDT
nicholas
As written on that page:
Note: Some people assert that moving wp-config.php has minimal security benefits and, if not done carefully, may actually introduce serious vulnerabilities. Others disagree.

I belong to those who assert that moving configuration files around –be it Joomla! or WordPress– has no security benefits. As long as the application can read this information so can a hacker. THe only thing it would protect you would be a known file location dump vulnerability but, in this case, you only stall the hacker, not deter them. Instead of 1 request they will need two (WP) or three (Joomla!).

In any case, what you describe is a bug in Akeeba Backup for WordPress because I anticipated this situation and I'm supposed to be handling it in the CLI scripts. Please download the latest dev release from https://www.akeebabackup.com/download/developer-releases/backupwp-dev.html


Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Sunday, 27 April 2014 21:20 CDT
bbloom
Indeed. I remember your blog post about this at http://www.dionysopoulos.me/keep-your-files-where-i-can-see-them/.

Joomla keeps configuration.php in the webroot; but, WordPress allows one to place wp-config.php above the webroot.

Thank you for your as-usual incredibly quick reply with an update. Your update works, the CRON job runs fine.

However, you have a related problem: wp-config.php is *NOT* included in the .jpa.

I was curious, so I extracted the .jpa file. Yup, the file is missing.

I have two WordPress sites myself (one with wp-config.php in the webroot, one above the webroot), and am happy to test your update on my own live sites.

All my best, Nicholas!
-Bob

 
Monday, 28 April 2014 02:00 CDT
nicholas
Technically, Joomla! aso allows you to move the configuration.php file around. In fact, it allows you to place it anywhere in the filesystem. You just have to change the JPATH_CONFIGURATION define in defines.php in both back- and front-end. It's my conviction that this does not offer any security benefits and the cost of devising, documenting and maintaining a workaround for this practice in Akeeba Backup is unjustified and overcomplicated. The same applies for Akeeba Backup for WordPress and wp-config.php

The only support offered in both cases is that when the backup is run from inside the CMS we are supposed to be able to read the configuration file and complete the backup. The configuration file itself will NOT be included in the backup by design. The only files added in the backup are those under the site's root and any extra directories you have specified unless you have explicitly excluded the directory or file. Yes, there is a reason for that.

Let's say that your source site is on a typical cPanel shared host. Your files are inside /home/foobar/public_html and your configuration file is inside /home/foobar (one level above the root). You take a backup and you restore it to an Ubuntu Server with stock Apache configuration, meaning that the files must be written in /var/www. Note that for security reasons only root can write to /var and there is no /home/foobar directory because your user in Ubuntu is called baz, not foobar. We have the following options when extracting/restoring the backup archive as far as the configuration file's placement, ranging from bad to despicable:
  • Try to restore using the absolute path (/home/foobar). The directory doesn't exist, the extraction fails and the backup archive can no longer be restored to any server.
  • Try to restore using the relative path (../). The directory in question, /var, is not writable, the extraction fails and the backup archive can no longer be restored to any server.
  • Restore the configuration file inside the site's root, or in a special directory (like off-site directories). This makes it mandatory for the user to read the restoration documentation before he can make the site work. Moreover, accurate instructions to handle this situation cannot be written making it impossible to tell the user to read a documentation page about it. Each site setup would need its own set of instructions. That's impractical.
  • Not extract the file at all. In this case, why expend the energy to make engine and archive file format changes (which cause a domino effect in half a dozen software and as many documentation books) to accommodate for the file which will typically not be extracted when you can simply not include it at all?


So, yeah, while both CMS allow you to move the configuration file around your server it's not a good idea. Just because you can doesn't mean you should.


Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Monday, 28 April 2014 08:05 CDT
bbloom
Excellent explanation!

I will move my wp-config.php back to the webroot. I do want it backed up as it contains more than just the default settings.

 
This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!