Caleb

I would always tend to preliminarily “trust” anything that reports an error. And attempt to fix based on that. 🙂

However, I do see a failure here in the Backup-plugin’s error checking process/handling, that personally I would fix QUICKLY if I was the developer.

The process.. Your local issue to fix:

The Backup ZIP is first created locally on your disk.. That’s where YOUR local Quota issue is met. You need to check your local hosting limitations against your userid’s/account’s overall disk-storage usage. Then either get allowance for a higher quota (or unlimited), or remove some of the accumulated stuff to get down under the quota. Clean your space.

Notice, that a userid’s quota counts EVERYTHING.. Which means that you can have automated backups working fine for years, and then suddenly because of uploaded stuff over time (such as image galleries and other wordpress files) you blow into the Quota limit, and backup’s WILL start failing. Even though you “backup to DropBox”, that does not mean that the initial backup processing writes directly to the cloud. The backup file is first created locally. Then afterwards saved in the cloud. So, if you cannot create a full-size local backup file to be uploaded, you are toast.

The process.. The plugin’s issue:

Backups need to be of HIGHEST TRUST and INTEGRITY. Main requirement for any backup software. If you cannot trust the content in a backup to be correct and restorable, then the result cannot even be called a backup. Backup software that cannot be trusted is worthless. That includes producing the correct errors and maintaining integrity when something out of the plugin’s control happens. Such as your Quota issue, which the backup plugin has no control over.

So in this case, The backup plugin passes on the ZIP software’s Quota error message (from inc/class-create-archive.php), code sleeps for 1 second, and then according to your log simply proceeds with the next steps of the “save a backup” process after the zip creation apparently actually failed half-way through. Which in your configuration includes copying the actually only half-made and BAD temporary ZIP archive to DropBox. As if it was a good backup file.

But a ZIP file creation that stopped in the middle because of space or quota issues is NOT A BACKUP file. It is practically nothing but a junk file. A partially made archive, that is missing unknown parts of the intended backup is worse than worthless and almost worse than nothing. Worse because the log indicating success and the (failed) archive files uploaded to DropBox gives the site admin a false sense of security..

“See all the nice backup files I have in DropBox..” Each file in reality worthless, because it is a half-completed archive that does not actually restore a site the way it should. (Backup Parts missing)

So.. in my opinion, you need to fix your Quota issue. That will allow your backup’s to be completed correctly without this quota error.

The plugin owner (Inpsyde) subsequently need to fix the plugin’s error checking and process to ensure that when archive creation fails because of space or quota issues, ALL further processing stops, and failure is reported to the Admin. That includes making sure that corrupted (half completed) archives are not saved away or uploaded to the cloud as if they were actually backups. Because they are not. A corrupted backup is not a backup.

As I mentioned in the post right before this one (about catching code 400 responses), the one issue if you use CDNs in Super-Cache is that you must add the string bwp-minify to your Super-Cache do-not-touch filter. Otherwise Super-Cache will attempt to redirect the BWP-Minify calls to the CDN, which will not work.

Otherwise the two together seem to work fine.

I am seeing this problem still. Fresh downloaded plugin.
This report was originally done 6 months ago.

Is there a version with a fix?

I sent this earlier on another thread with the same issue, but Re: Login, but I refreshed this one instead, since it actually has the right subject. 🙂

Ran, you stated “We did not use and will not use these addresses to send unsolicited email.”.

That might in some worlds sound real, but the plugin did in fact use its “hooked-in” nature to schedule (at both 2:50 AM and 3:00 AM on my system), pick up, and send very specific email from what the content names as “vCita Inc, support@vcita.com 218 Main st, suite 363, Kirkland WA 98033, +1 855 824 8244”.

Bypassing normal spam protections to send us Spam (UCE – Unsolicited Commercial Email). I was targeted by multiples of these emails across addresses. So was yeahwow. I still have the emails, if you do not remember what they looked like.

Emails that were set up to look as if they were coming from our own email addresses, sent from our own local servers, but with Reply-To: pointing to support@vcita.com, and all links pointing to vCita. Advertising the selling points of vCita, such as “increasing our web-leads”, “collect payments”, and so on.

There was absolutely no difference in nature between these “direct pumped” emails from vCita and all the other Spam I catch and track every day, other than the fact that because it had been hooked into an installed WordPress plugin running on my system, it suddenly had the power to circumvent my layers of DKIM, SPF, and DNSBL blockers.

PLUS.. If one clicks on the link in one of the emails, one runs straight into a vCitas advertising landing page, with all of FSCF affiliate ID, the originating Blog domain (mine) AND the email address (mine) from one’s contact-page stuck in the URL to be nicely logged away as the source. Contact email addresses in my case created specifically for receiving contact email and nothing else. They would never otherwise have been passed on to any service, anywhere. Before this, they were fresh as newly blooming daisies.

So, “We did not use and will not use these addresses to send unsolicited email”??

That is certainly up for a debate. I know that I never “solicited” emails from vCita or voluntarily signed up for anything, and yet I got multiple “unsolicited” emails that are clearly advertising vCita and from vCita.

yeahwow,

To be fair. The issue I mentioned of the Banner link passing off email was not a new issue introduced.

The vCita ad banner was always setup so if you clicked on it, the URL would pass your email-address as a parameter to vCita. Most likely to pre-fill a sign-up form. For “user convenience” as Ran called it.

I think that in the hurry to fix some of the issues and get the 3.1.4.1 version out there, Mike probably just did not notice that additional issue, so it still showed in the new 3.1.4.1 version of the plugin.

BTW.. I think your idea of adding hooks in the plugin to allowing the install of a separate vCita add-on is a great idea. That would separate the issues entirely. A clean contact plugin, with a separate “Meeting” add-on people can choose to install.

I agree with you there.. Mike have a great plugin. Great work as I also stated in my other post. Until the connection with vCita.

I am personally OK with having vCita as meeting functionality (or better a service that does not take advantage of the connection by hooking themselves into my sites to use my system as a Spam sender).
I don’t mind Mike making some money from hooking up people that want such a service either. Good for him.

BUT. It should be a non-default. No handing off random email-addresses to the meeting provider by default. If I were to sign up for a meeting service I would NEVER have used the email address I created for the contact form. They are assuming that this is an email address for public consumption, that I would want meeting requests on.

Also, it should be clearly documented up front what the side-effects will be both Spam and Privacy wise if one (as a personal, actual decision) enable the functionality in a plugin.

vCita’s method of abusing the connection seems very backhanded, when used on someone that never voluntarily signed up for their services or voluntarily gave them these multiple email addresses.

Why I would want my sites to start picking up Spam from someone else’s server in the middle of the night when am sleeping is beyond my comprehension. My server mail-logs clearly show that my web-server (apache user) started distributing Spam both at 2:50 AM and 3:00 AM, naming vCita as the culprit. Those timestamps matching my every 10 minute cron-job to call on wp-cron to refresh caches and assure scheduled postings.