A : Starting with v0.2.3-16 MyBackup supports PHP 7.0 and nevertheless all three MySQL extensions: mysql, mysqli and pdo_mysql.

A : Only Administrator and Network Super Admin users will see this plug-in in their site Tools menu. See the question 5 below.

A : Although WordPress supports the relocation of wp-contents, plugins, themes folders to a non-standard path this plug-in was never tested in such environment. It doesn’t mean it won’t work, it means it was never tested that way.
If you plan to use it in such environment please do an exhaustive test before enabling it in production. Any question related to this matter should be addressed on Get Support page.

A : WP Multi-Network extends WordPress by allowing one to use only one network/domain with multiple sites but multiple networks with multiple sites. Although I never made an exhaustive test but a basic one I assume it would work.
Please note that this plug-in was designed to work with a standard WordPress Network of sites.

A : On single site installation you may access all WordPress files (like admin, includes, content, themes, plugins, etc) and database without any restriction. While you are a WP Administrator, to be more explicit if you can access the administration interface, it is assumed that these are your files, thus you are entitled to access them.

The multisite installation is another story. The WordPress installation belongs to the network, not to you. What belong to you are your site’s files (ie. active themes and plugins, your site upload folder) and the site’s tables only (not the entire database).

However, if you are Network Super Admin, to be more explicit if you have manage_network_options capability, then you may access (additionally to your site’s files) all the plug-ins and themes, admin, includes and the whole content directory. Nevertheless you are entitled to backup all tables within network database.

A : This is a known behaviour with older versions of Opera browser due to its caching mechanism (at least on Opera 12.16). Try to clear the browser’s cache then try again.

A : This is a warning that WP MyBackup generates when it detects that your WordPress (a theme or a plug-in) throws some extra white-spaces (like %0A) when it should not.

How does this affect you? Well, if you want to download the MySQL database script or a remote file via WP MyBackup then it’s very likely that the WordPress will throw these extra white-spaces before the download file content is sent to the browser. As such the file will be prepended with these extra white-spaces. If it is a text file then you should be able to see its content (although truncated) but if it’s a binary file (like an ZIP archive) then 1 byte more/less makes the difference.

How to fix this issue?

There are at least two different approaches:

1. if you are a skilled WordPress user (software developer, website administrator) then first make sure you check the browser’s console (for JavaScript exceptions). The test is done usually hourly but if you want to check sooner then set the Support expert option `Extra-whitespace check` = 1. When that alert is generated an message like the one below will be printed on the browser’s console:
   

   Challenging string `test` but got `XXX`

   , where `XXX` is the encoded text (eg. `%20%20test` which means two spaces prepended to the challenging string) that has been received instead of the expected one. That being said:

   • if you have access to a SSH console then run the following terminal command:
     
     WPROOT=<wp-root>
     head -n 1 `find $WPROOT -type f -name “*.php”` |grep -H -E “^\s+<\?php”
     where wp-root is the absolute path of your WordPress root directory (or any directory you want to scan)
   • the command above might return one/many (troublesome) lines like in the example below:
     {space}{space}{space}<?php {some-string} ?>
     where {space} denotes a whitespace character (like space, tab, CRLF, etc) and {some-string} denotes the string following the PHP start tag <?php
   • now we know what {some-string} causes the problem but not which file; we are going to search which file(s) contains this {some-string}:
     grep -r “{some-string}” `find $WPROOT -type f -name “*.php”`
   • you will get one/many files where {some-string} appears in their first line
   • edit these files (make a safe-copy of them first) by removing these {space} characters from their first line, just before the PHP start tag <?php
   • if that worked please notify the theme/plug-in author about this issue/fix such that he/she can update their software

   A better version would be the following BASH script (let’s call it find0A.sh):

   #!/bin/bash
   for f in `find $1 -type f -name "*.php"`;do
   a=$(head -n1 $f|grep -E "^\s+(<\?php)?"); # check file’s first line only if [ -n "$a" ];then printf "%s\n%s" $f $a;fi # found whitespaces? print them! a=$(head -n1 $f|grep -c -E "^$"); # check file’s first line only if [ "$a" != "0" ];then printf "Found an empty lines at beginning of %s\n" $f;fi b=$(tail -n1 $f|grep -E "(\?>)?\s+$"); # check file’s last line only
   if [ -n "$b" ];then printf "%s\n%s" $f $b;fi # found whitespaces? print them!
   b=$(tail -n1 $f|grep -c -E "^$"); # check file’s last line only
   if [ "$b" != "0" ];then printf "Found an empty line at end of %s\n" $f;fi
   done

   and you call this script like: find0a.sh $WPROOT

2. if you are a non-skilled WordPress user
   • We assume that the main theme is the cause. Try to switch to a WordPress built-in theme (like TwentyFifteen). Try to download the same thing: does it work? – you are done, otherwise is a plug-in which causes the trouble
   • Determine which plug-in does this by deactivating them (except WP MyBackup) one at a time then retry to download the same thing.
   • If it’s not fixed then continue deactivating the next plug-in.
   • After you tried everything and finally works then you know which plug-in/theme caused the problem. Just report the incident to the plug-in/theme author, hopefully he/she will fix it.
3. if you are a mixt between the two above (an adventurous one) then start with the steps (2) and if that doesn’t fix the problem you might try the steps (1)

A : Everything made by man’s hands can be fixed by man’s hands, right? Basically we have to check if the archive was really prepended with those undesired extra white-spaces and if it did then we have to count how many then to extract them from there.
On Unix like systems it can be fixed with the aid of tools like hexdump and dd:
The batch of commands above will create a fixed-* filename that will contain the archive content excluding those unexpected prepended extra white-spaces.

A : Perhaps the WordPress internal cache (or a cache plug-in) cached the old version of some JavaScript or maybe your browser cached the old version of some JavaScript file that comes with MyBackup plug-in. It doesn’t really matter which one is true. What matters is that now it is loaded from your browser’s cache instead being pulled from the WordPress web server.

To fix this inconvenient just press the F5 key which will force your browser to reload the current page content including those (plug-in) new JavaScript files from the WordPress web server.
Note: starting with version 0.2.2-4 this issues should not happen due the fact that the plug-in detects itself this situation and then it reloads automatically the page.

A : This is a warning message thrown by PHP which basically tells you that your hosting provider has limited the directory this plug-in – or any other PHP application – may use (see open_basedir PHP directive). Most likely you are using a free hosting service.

Perhaps the screen you are seeing has a Path parameter (or alike) which is set to a location (eq. /tmp) with access restricted by the limitation mentioned earlier. Just try to set a location that is permitted (eg. a folder within your website boundaries).

Obviously I could catch and mask these messages but the reason for letting them show in their raw format was to help you notice them and eventually search Google for a solution (which has nothing to do with the plug-in itself).
Note : please note that this plugin supports the `open_basedir` PHP directive; it has special routines that do all their best to accommodate in such environment.

A : The same issue as #10 above. It has to do with a limitation imposed by your hosting provider (see disable_functions PHP directive). Most likely you are using a free hosting service.

A : The plug-in still uses the native PHP mysql extension which is, as far as I know, the fastest available out there. However, it has pluses (like performances) and minuses (like security) and thus, the PHP core team is planing to remove it entirely starting with PHP v7.0.

So the message is just a warning thrown by your PHP engine.

Please note that starting with v0.2.3-16 MyBackup supports all three MySQL extensions: mysql, mysqli and pdo_mysql (see #1 above).

A : Google account not linked yet. Please authenticate within the web interface then try again.”]The following message appears in some places within the backup log file:

[!] Google account not linked yet. Please authenticate within the web interface then try again.

What does it mean?

A : It looks like your Google backup target is/was enabled but your Google account doesn’t seem to be authorized any more. The same thing may happen also with the Dropbox (or alike) cloud storage drive.

Normally a Google/Dropbox Drive authorization expires after a while, however the plug-in is programmed to renew the authorization when it detects it expired. If for some reasons it wasn’t able to do that automatically then this backup target is is a conflictual state: one one hand it is enabled which means you configured the plug-in to upload the backup (also) to this destination, on the other hand when the plug-in tries to upload a file there it notices that this cannot be accessed due to the lack of authorization.

The solution is trivial: just go to that backup target screen (eg. Backup targets -> Google tab) and make sure you authorize the account again. That’s all folks!

A : On Windows it is used the SWbemLocator object to connect the WMI framework that gives us access to some OS information like system load, CPU info and memory info used in various parts of the software. In order to access the WMI framework via PHP script the web server must be set such that the website user can access that OS component. On IIS this is done at the website level, Directory Security -> Authentication Method. Make sure the Anonymous access user set there has the permission to use the WMI (learn more).

A : If your web site uses (or enforces the use of) SSL, moreover if your `php.ini` configuration has the `open_basedir` option in effect then it may be possible that you get a Curl error no. 60 like the one below:

Peer certificate cannot be authenticated with known CA certificates

I see at least two reasons for that:

1. your server’s SSL certificate is signed by an unknown Certification Authority(*) (eg. self-signed SSL certificates)
2. the path where your SSL certificates are stored is not accessible to the PHP (check your open_basedir option)

(*) The known Certification Authorities (CA) are stored in the `ssl/cacert.pem` within the plug-in install directory.

A : While running a backup/restore job (under Linux) you might see on the job log a message like the one below:

is_readable(): open_basedir restriction in effect. File(/dev/urandom) is not within the allowed path(s)

MyBackup does not produce this message (not that I know). However, when your PHP has the open_basedir option in effect (see php.ini), depending on what plug-ins you may have installed and how they handle the `open_basedir` effect, such a message may be generated by some other plug-ins which run (even if you are not aware about that) in parallel with the backup/restore jobs. Our plug-in just happen to be there to capture that message, so more or less it acts as a “error handler” not only for itself but also for other WordPress plug-ins that run in the same time. See also the question #10.

A : While running a backup job you might see on the job log a messages like the one below:

realpath(): open_basedir restriction in effect. File(/folder) is not within the allowed path(s)

Depending on what directory you included in the backup and what directories you allowed via the PHP `open_basedir` option there is a possibility you will get such message.
Make sure you backup only these directories that you are allowed to. See also the question #10.

A : While running a backup/restore job they might forcibly end with an error message like the one below:

Fatal error: Maximum execution time of `XX` seconds exceeded

The PHP has an option named max_execution_time which limits the number of seconds a script is allowed to run before it is terminated by the parser. The default limit is 30 seconds (ie. `XX`=30). In order to overcome this limit (a backup/restore job might run for minutes) the MyBackup has an Expert Setting named `Max execution time` (see the `Backup` tab) which will override the default PHP value (default is set to 600s).

One trick that worked on my tests is to set more than one backup target. If for instance you chose only the “Disk” as a backup target (where the backup archive(s) will be copied) then by selecting an additional backup target (like Dropbox/Google, etc) this will succeed into tricking the PHP, although it’s rather a secondary effect than a trick. Check also the related question #20.

A : When trying to start a backup/restore job it might fail with the following message:
The MyBackup does not allow multiple concurrent jobs. The message indicates that a backup|restore job already started SSS seconds ago and is marked as `running` (check the job log for ID=XXX).
When it starts a job it creates a special locking file (tmp/logs/wpmybackup-jobs.lock) and when the job is done the locking file is cleared automatically. If for some reason or another the last job failed without being able to clear that locking file (eg. when the web server crashes, when PHP fails unexpectedly, etc) then all you need to do is to delete it manually.

A : While running a backup|restore job will get this error message IF the maximum execution time of a PHP script exceeded the value of max_execution_time PHP directive. If PHP is NOT set to run on a safe_mode then this value can be overridden. However, if your PHP IS SET in safe_mode then there is no way to override this directive. Regardless of server’s PHP configuration please check the answer of a related question #18.

A : While running a backup|restore job that tries to connect the Dropbox|Google service you might get the following error:When you authorize the MyBackup to upload a backup to your Dropbox|Google account it receives an authentication token that usually has a determined lifespan. Normally MyBackup attempts to refresh the expired token such that it can still upload the backups to your Cloud Storage drive but sometimes this is not possible (or it fails). When this is happening the Dropbox|Google answers with a “Bad Request” error message.
To fix that is enough just to go to the `Copy backup to` tab then to choose the Dropbox|Google sub-tab. If the above is true then you should see a message like this:Just follow the instruction given in that screen.

A : If while running a backup|restore job the server just ends your browsing session throwing an odd error message like:then you should know that is you web hosting provider that has implemented a resource limiting scheme which does not allow your WordPress to send more than XXX requests per time unit. This XXX and time unit varies from provider to provider.
One way to overcome this limitation would be to use the `CPU throttling` expert option available on the MyBackup’s `Backup job` tab.

A : If the plug-in is running on a single-site installation then it creates and keeps its temporary files in a directory within its install path: `<plugin-root>/tmp/`

If the plug-in is running on a multi-network | multisite installation then there are multiple temporary locations where the plug-in keeps its temporary files:

1. while accessing the Network Admin pages as multi-network administrator
   • wp-content/`uploads/wpmybackup/tmp` – keeps various temporary files
   • wp-content/`uploads/wpmybackup_backups` – a working directory if system TEMP is not accessible
2. while accessing a multi-network site
   • wp-content/`uploads/sites/XXX/wpmybackup/tmp`, where XXX is a numeric site ID
   • wp-content/`uploads/sites/XXX/wpmybackup_backups`, where XXX is a numeric site ID
   • `<global-working-dir>/XXX`, where `global-working-dir` is given by `Global working directory` option in Network Settings and XXX is a numeric site ID

So on multi-network | multisite installation each site has its own temporary|working directories such that one user|site cannot interfere with the files of other users|sites.

A : That error should never happen. I guess the root of the problem is our self-signed SSL certificate (the browsers do not like self-signed certificates, they like only the branded-name expensive Certification Authorities ; it makes sense in the today’s crazy Internet world, though).

Anyway, just hit the Back button and try again.
This usually does not happen again if you do accept the “untrusted” certificate usage by adding the certificate exception into your browser (usually this is just click-away, nothing fancy). So usually, after going back and retrying authenticating the Dropbox/Google service it works like a charm.

If it doesn’t then make sure you add (agree with) that exception first then go Back and try again. This is the working solution.

I never could fix this situation, except by buying a $XXX brand-name SSL certificate. Some day I will rewrite the app from scratch and implement the OAuth2 authorization in a much different way.

A : Yes there is and it’s called `wpmybackup_before_job_starts`. It can be hooked by your PHP code by registering a custom WordPress action like this:

add_action("wpmybackup_before_job_starts", "my_custom_hook", 10, 3);
function my_custom_hook (int $job_id, String $sender, int $job_type){
// $job_id: an integer that represents the job identifier
// $sender : a string that represents the job starter name (like WP-Cron, WP-Admin-Async, etc)
// $job_type:{0:backup,-4:restore}
}

A : Yes there is and it’s called `wpmybackup_after_job_ends`. It can be hooked by your PHP code by registering a custom WordPress action like this:

add_action("wpmybackup_after_job_ends", "my_custom_hook", 10, 3);
function my_custom_hook (int $job_id, Array $job_metrics, Array $processed_arcs){
// $job_id: an integer that represents the job identifier
// $job_metrics: array of info that provides info about how the job was done
// $processed_arcs: array of the processed archives (key:archive name, value:array of destination targets where the archive was uploaded)
}

Keep in mind that in case of multiple parallel backup jobs this action is triggered for each distinct job.

A : You could use the `wpmybackup_schedule_last_filter` WordPress filter which should return the last job Cron interval name, eg. daily, weekly, etc.
In case of the PRO version use the `wpmybackuppro_schedule_last_filter` filter instead.
How to use this WordPress filter:

$last_schedule=apply_filters('wpmybackup_schedule_last_filter',false); // free version
$last_schedule=apply_filters('wpmybackuppro_schedule_last_filter',false); // pro version

Note that the second false argument is just a dummy value to comply with the apply_filters default arguments function definition. In reality you can pass whatever you like (eg. null), this argument is discarded.