Carl Gross

Thanks for the reply. Here are my follow-ups.

>> simply check within the code you have integrated into the site.

Where can I view this code? Is it the code in the iubenda–>Cookie Solution–>Code field (screenshot)?

>> you can also verify it from the Cookie Solution configurator

How do I open the “Cookie Solution configurator?

Thanks.

Sorry, I was going to wait a few more days to confirm. But it seems like the issue has gone away on it’s own, for the most part. So let’s consider this resolved. But I’m still puzzled why it is occurring in the first place, and what to possibly do to resolve it if it returns.

Thanks for your help.

>> Unfortunately when I try to run the sample test in my plugin I get the response Class ‘WP_UnitTestCase’ not found.

I don’t have that particular error–or anything similar–in my notes. So sorry, I can’t be of too much help. I know that the cause of many of my frustrating errors were in the .sh file. I had to do some debugging of code in that file and even make some changes.

>> I have not succeeded yet but I have developed hate and resentment against the official wordpress testing documentation.

Yes I was pretty frustrated too for a bit. If WordPress wants to foster/encourage better plugin development, some accurate instructions for installing/running tests would be great. After I got mine working, I had grand plans to update the instructions and write down what worked for me. But alas I got busy with work, and my time shriveled up :-/

One thing I was planning on doing as a very last resort was to login to the WordPress plugin development channel on Slack and see if anyone could give any tips. If you’re hard pressed, you might be able to try that.

I was able to get it working in Windows. I setup a simple WordPress site in XAMPP, and used that site for my testing.

grep: /tmp/wp-latest.json: No such file or directory
grep: /tmp/wp-latest.json: No such file or directory

I was getting those when I was using a WordPress site I had created using Local by Flywheel. When I started using the WordPress site I created with XAMPP, I no longer had that issue. I had several other issues using my Local by Flywheel for testing–could never get it to work.

Let me know if you run into other specific issues, as I kept detailed notes. I know at one point I had to manually change a line in the .sh file.

I personally have encountered this BackWPUp issue many times over the past few years. And I know there are other posts in the forum about it. Is it still such a head scratching issue, with no possible troubleshooting or resolution? Is my only recourse to just hope that the warnings don’t mean anything? Is there anything we can do–aside from carrying out a full restore of each backup–to ensure the backup was actually taken properly? I’d really prefer a backup system which didn’t produce error messages on every backup.

Hello. Any update on this issue?

In my Dropbox folder, the two most recent zip files are present (as desired/expected).

Usually, while logged in to Dropbox, I am able to open a zip file and browse its contents. But with these two zip files, I cannot (screenshot).

If I try to download each of files, they both download without issue. I can then open each on my local computer without issue.

The zip files contain sensitive info (e.g. wp-config.php), so I don’t want to share it with you. Is that OK? Or would it help if I removed sensitive info, then shared it with you?

>> The warning shows up means the uploaded file size(in bytes) reported from Dropbox server did not exactly match the one created.

Right. I understand it is saying that. But I don’t understand how that can occur. How can the uploaded file size be different from the one created? Does BackWPUp (or Dropbox?) somehow alter the file size aftercreating the zip file, but beforeuploading to Dropbox? If so, why, and how can we resolve that?

A zip file appears to be created, with approximately the correct file size, and uploaded to Dropbox. But I don’t know if this is corrupted in any way due to the error in the log. I’m still clueless as to why and how this error is appearing in the log.

Any update on this? Daily update are being imitated by BackWPUp, as desired/expected. Each completes, with the same error (Uploaded file size and local file size don't match.). But it looks like a backup zip file is still created and uploaded to Dropbox. So what is this error and why is it displaying? Does it mean the backup is corrupted?

Also, the issue wasn’t present for the first few days, but suddenly started (screenshot).

>> maybe your site did not have much traffics so the pseudo-WordPress Cron not fired correctly.

OK understood. The site in-question is indeed my staging site, and I am the only person to access it. So it makes sense that the backup would begin as soon as I login to the staging site, which has been about 6:00 pm lately. So consider that resolved.

It’s been a few days since I made the changes to the BackWPUp job, and the deleting old backups in my Dropbox folder are now automatically deleted, as expected. So I’m glad that’s fixed.

But on my staging site, a backup just failed with this error:

ERROR: Uploaded file size and local file size don't match.

I’ve seen this error frequently with the plugin, but have never understood the reason, or the proper solution. Do you want me to open a new ticket for it?

>> BackWPUp relies on the WordPress Cron Schedule system, so the time depends on your site Settings ^^

In my WP settings my timezone is Bangkok, and the BackWPUp cron settings are to run the backup at 3:00 am every day (screenshots). But every day, the backups begin ~6:00 PM Bangkok time. Why is that?

OK. I deleted all the existing backup files from my Dropbox, deleted the existing BackWPUp job, and created a new BackWPUp job which runs daily. In the process, I changed the Dropbox destination folder from Kabultec/staging/ to /Kabultec/staging/ Maybe that was the cause of the issue. Let’s give it ~4 days to see if the job properly deletes old backups in the Dropbox folder. I’ll report back here.

Also, when I create a daily backup, on a set schedule, and specify a time–what is the timezone of that time? Is it GMT?

• This reply was modified 4 years, 10 months ago by Carl Gross.

OK thanks for all.

Sorry, I didn’t note the previous value of the field. It started with something like /var/www and it ended with uploads/backwpup-1b50a2-logs/

The new value I entered was:

uploads/backwpup-1b50a2-logs/

I was able to resolve my issue. In my case, I did so by opening Settings–>Log, and specifying a correct, relative, path for the ‘Log file folder’ field.