For WordPress administrators WordPress MainWP BackWPUp job creation should be a simple process.

MainWP is a very handy console for those of us managing lots of WordPress sites.

BackWPUp is a very popular plugin to assist with managing those sites.

My experience has been not so supportive of either notion.

WordPress MainWP BackWPUp job creation proved to be a lengthy process of diagnosis of multiple bugs and ‘features’ that were eventually worked out but with a lot of time wasted.

This was using MainWP with MainWP Child and BackWPUp plugin in both the MainWP central dashboard and the child site.

MainWP and Child Utility

I use MainWP as a centralised management tool and it offers a connection or interface to manage BackWPUp from the central dashboard. In the main it works, but there are a number of gotcha’s.

Modifications are not Sync’d

The first is when you modify a backup job in the child site (the client site) and you sync from the child site to the MainWP dashboard. The changed configuration of the BackWPUp job is NOT changed in the MainWP dashboard from what was previously configured. (At least this is the case with fields in the FTP transfer and job name fields. I did not test every setting field)

So you must make changes only from the MainWP dashboard as a ‘sending’ sync will transfer the details from MainWP to the child site, but my testing shows that it will not ‘get’ or receive setting changes from the child site. So management is only one way for BackWPUp at least. I trawled the MainWP documentation but cannot find any precise description of what a Sync Data process is meant to do.

Allowed Tags Do not Transfer

Secondly, the instructions in MainWP for BackWPUp are really misleading (I wasted hours on this task alone because what seemed clear and concise was completely misleading).

The MainWP BackWPUp page setting for the backup job name and archive name state that you can use variable tags:

Allowed tags: %sitename%, %url%, %date%, %time%

and this would appear to be straight-forward. You should be able to make the date / time variable in the archive name in order to retain multiple day backups where needed.

So I confidently applied an archive name of daily-%sitename%-%date%-%time% with the expectation that MainWP would pass this to the child site in the archive name field for the BackWPUp job.

Gotcha !! MainWP takes the variables and converts them at the time that you save the job in MainWP and transfers the resulting archive filename to the child site for the BackPWUp job !

So in the child site we now have an archive filename that does NOT get a changing date / time stamp and will replace the archive on a daily basis. Nasty if you think you have 7 days of backups.

Allowed Tags are Inconsistent

Finally, I tried copying and pasting the daily-%sitename%-%date%-%time% parameter for the archive file name field value directly into the child site job. But the was perplexed as I got some crazy file name that included % signs etc…… but another Gotcha!

Yep, the MainWP “Allowed Tags” only apply within MainWP, which would be fine if they worked, but they don’t.  So the %sitename% parameter is interpreted in BackWPUp as %s (for seconds as in time) and the ‘seconds’ is inserted in the archive name along with “itename%-“.

The rest of the archive filename consists of correctly interpreted but clearly invalid ‘tags’. This is because BackWPUp provides for a completely different set of parameters or allowed tags that are completely inconsistent with the MainWP configuration.

So as a last resort, I configured the child site job for BackWPUp with something like daily-thowden.com.au-%Y%m%d-%H%i so that I get a changed date / time within the archive file name.

I then manually copied that from the child site to the MainWP dashboard.  (Yes, manually, remember that the sync process is one-way!). From that point on I now have a working backup cycle.

BackWPUp

Ok, so I now have a configured BackWPUp job ready to test and schedule on my child site.

BackWPUp Date Time Stamp Issue

Now that the backup would run I got to check the BackWPUp logs and found that they are incorrectly date / time stamped with the system date being ignored and using UTC / GMT time instead. Painful when trying to confirm local time of events. The date/time issue also impacts on the scheduling which must be done as at UTC 0000 to get the right timing for the schedule.

When an Error is not!

If we get over the date / time stamp issue, the log reports an ERROR: as 2 errors when in fact it completed successfully!!!

If an FTP transfer attempt fails, an initial error is flagged with ERROR: and then a 2nd (and a third) attempt will be made for the FTP transfer.

If that second transfer attempt is successful the job completes, but because of the first upload ERROR: condition existing the whole job is flagged as ERROR: Failed.

The crazy thing is that the last line ERROR: condition is also counted so that 2 errors are reported in the summary from a successful completion!

Arghhh… this of course wastes a heap of time checking what are in fact successful backups.

It works ! but…. it would be a whole lot easier and better if all the above had worked as expected.

Issue Summary

1. MainWP need to correct their process so that the sync is bi-directional.
2. MainWP need to correct the description of the allowed tags so that they are consistent with what BackWPUp actually uses.
3. MainWP must pass the ‘tagged’ version of the archive file name to the job and not do the conversion.
4. BackWPUp really should fix the date / time issue so that the logs and schedules are accurate and consistent with the WordPress site configuration so that they make sense.
5. BackWPUp should fix the ERROR reporting so that successful backups that may have contained one FTP transfer error but do complete successfully are not flagged as ERROR (twice)