RichHelms

I wish Michael would just make the fix in the plugin. The modified program works fine in MySQL and MariaDB. I have installed in both. I have about 50 sites and run this plugin in all of them. About 10 of them are on MariaDB and throw the error

Still not fixed in 4.5

I updated to 4.5 on my host which uses MariaDB rather than MySQL

It is still giving error

[21-Apr-2016 00:04:27] WordPress database error Column ‘offset’ cannot be null for query INSERT INTO wp_wpb2d_processed_files (file, uploadid, offset) VALUES (‘/home/richard/public_html/abc.com/wp-content/wflogs/.htaccess’, NULL, NULL) made by do_action_ref_array, call_user_func_array, run_dropbox_backup, WPB2D_BackupController->execute, WPB2D_BackupController->backup_path, WPB2D_Processed_Files->add_files, WPB2D_Processed_Base->upsert

The key is inserting null into offset. The field is configured to not accept null and put in a default of 0.

On MySQL this works fine. On MariaDB it throws an insert null error.

All I do to fix the issue is change in

wp-content/plugins/wordpress-backup-to-dropbox/Classes/Processed/Files.php

Change lines 69 to 74 from

$this->upsert(array(
‘file’ => $file,
‘uploadid’ => null,
‘offset’ => null,
));
}

to

$this->upsert(array(
‘file’ => $file,
‘uploadid’ => null,
‘offset’ => 0,
)); // fix MariaDB null insert error
}

Problem resolved. As 0 is what the DB is storing, no idea why the plugin insists on inserting null vs a 0

The email is being sent via WP-Mail-SMTP using a valid email account in the config of the SMTP plugin and the same email address as the from address field of the form.

The WP-Mail-SMTP can send test emails to the same email address as the to email address in the form. Also I can use the WordPress Database Backup plugin to email a backup to the same address as used in the form.

This is not a spam issue as the form works with 4.4 and fails with 4.4.1. When I install 4.4 it works. When I install 4.4.1 it fails.

No error messages are being logged.

I think some validation was added in 4.4.1. My guess is it is returning false. I am happy to install some test plugin or test code and run if this helps

I did. Same result.

The issue is file wordpress-backup-to-dropbox/Classes/Processed/Files.php
The only problem line is ‘offset’ => null,

By changing it to
‘offset’ => 0,

the problem goes away. I have done this on all of my sites at a particular host and it has solved the issue.

I was hoping that Michael would come out with a new version but so far no luck. In my case the problem host is using MariaDB instead of MySQL. MariaDB does not allow the insert with null like MySQL does.

This is driving me nuts so I decided to look deeper.

The issue is file wordpress-backup-to-dropbox/Classes/Processed/Files.php

Toward the bottom of the program change from

$this->upsert(array(
‘file’ => $file,
‘uploadid’ => null,
‘offset’ => null,
));

to

$this->upsert(array(
‘file’ => $file,
‘uploadid’ => null,
‘offset’ => 0,
));

so change the offset default from null to 0 and the issue goes away

It should not be a problem but it seems some versions of MySQL are not handling defaults right. Hopefully if this is the solution Michael will update and release as 4.4.2

If I execute in PHPMyAdmin

INSERT INTO bt101_wpb2d_processed_files (file, uploadid, offset) VALUES (‘/home/richhelm/public_html/course/wp-content/themes/uber/single-project.php’, NULL, NULL)

I get the error #1048 – Column ‘offset’ cannot be null

If I try
INSERT INTO bt101_wpb2d_processed_files (file, uploadid, offset) VALUES (‘/home/richhelm/public_html/course/wp-content/themes/uber/single-project.php’, NULL, 0)

it works

The table is defined as
CREATE TABLE IF NOT EXISTS bt101_wpb2d_processed_files (
file varchar(255) NOT NULL,
offset int(11) NOT NULL DEFAULT ‘0’,
uploadid varchar(50) DEFAULT NULL,
UNIQUE KEY file (file)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

so it should default to 0 but why not just put in 0

This appears to be a MySQL issue with some version or interface. Problem is I can not change the version of MySQL and it looks like I am not alone.

Sorry but I have 4.4.1 installed and it is still happening

For those of us who installed the AJAX version and reconfigured, when you install the non-AJAX version you have to reconfigure again.