lancermedia

I’m having this same issue since moving hosts and trying to understand it.

MySQL Collation I believe is utf8_unicode_ci (even switching to utf8mb4_unicode_ci doesn’t change anything). I see this in phpMyAdmin under Server connection collation.

Server info:
Server: Localhost via UNIX socket
Server type: Percona Server
Server version: 5.5.44-37.3-log – Percona Server (GPL), Release 37.3, Revision 729fbe2
Protocol version: 10
Server charset: UTF-8 Unicode (utf8)

If I have define(‘DB_CHARSET’, ‘utf8mb4’); in my config file I get black diamonds.
Switching the config file to define(‘DB_CHARSET’, ‘utf8’); everything goes away.

Trying to understand what and why?

-Kevin

@respectyoda

Not what we want to do. We already have that extension.

For this client site they have 2 forms…..a short form and a long form. People start out with the short form, this has only a few required fields to get the most basic info. When this form submits, the client gets that critical data and the user gets sent to the long form.

The long form collects a lot of data, so some people bail on it.

What the client wants is any of the fields from the short form that are also in the long form to be pre-populated with the data already entered in the short form.

Doing just 1 multipart long form is not an option as the conversion rates are way lower. The client wants to at least capture the critical data is the user bails.

-Kevin

Did you ever get an answer to this? We’d like to do this as well. We have 2 forms, a short and long form.

When a user fills out info on the short form, they are redirected to the long form. We’d like to be able to pull certain fields from the submitted short form and pre-populate them in the long form.

Anyone done this?

-Kevin

We use htaccess while in development and have never had any core WordPress issues other than cron not running. It’s a temporary situation. I’m not keen on installing yet another plugin just to manage something while in development.

Even without htaccess, the latest version is still really slow. We have databases that are no larger than 300k, but it still takes minutes for the backup to run.

Not sure what the decision was to change from the way 3.1.4 worked, but in my opinion it took a great plugin and made it bad.

-Kevin

I hope so and will remain as patient as possible. The problem is we have some clients that will update the plugin themselves, and then run the risk of having their sites no longer protected.

-Kevin

Yup, same for me. 3.1.4 works great. Anything after it is spotty at best.

I thought at one point having a site behind PW protection was causing issues…..but I removed the PW and still can’t get a backup to complete. No errors…..just spins and no backup file ever created.

Sadly, we have installed this on so many client sites, we have to start looking for alternatives as it seems there hasn’t been any progress.

-Kevin

Complete and Database manual backups working ok with 3.2.1, but still not working if site is PW Protected.

Also, both DB and complete manual backups take longer than with 3.1.4.

-Kevin

So version 3.2.1 looks like breaks the plugin altogether.

EDIT: looks like backups are being made…..although the plugin is super slow to update the display. Looks like files are being created quickly, but the interface just spins and spins. Still can’t create any manual backups while being PW protection.

Losing faith in this plugin. Off to look for something else.

-Kevin

Also, I notice that when I get 3.2.0 to run….it’s MUCH slower to finish. Even on small database dumps.

-Kevin

Ok, enabled support on the pw protected site and I’m ran a backup now.

Still no file created.

-Kevin

UPDATE:

Tested on another site that wasn’t password protected and 3.2.0 seemed to work.

So wondering what happened to not allow manual backups when password protected.

-Kevin

Paul,

Plugin 3.2.0. WP 4.1.1, and PHP 5.4.38 at Hostgator.

I was doing a manual backup.

These sites I was testing on were development sites that are password protected by .htaccess. Now I am fully aware that auto backups don’t run when behind .htaccess because wp-cron can’t run…..but in the past I’ve never had an issue running a manual backup.

With 3.2.0 I can run the backup…..watch it run, but no files ever get created and no errors are shown.

What do I need to do when enabling support? Email you something?

-Kevin

Curious about this as well. For the time being I’m including the checkbox, just hiding it via CSS.

-Kevin