Jeffrey Schutzman

I have debugged this and know the issue. In the function ‘sgr_verify’ there is a check for the request method and recaptcha response from google. If these things aren’t found the function does a wp_die with an error.

Problem is that when WooCommerce checkout is setup to automatically create an account on checkout sgr_verify is executed without presenting a recaptcha form.

Either the recaptcha form has to be presented, or sgr_verify should not run on checkout.

The build in table rate shipping module should be able to do the calculation

That looks like a script that is only used by Gold Cart if your WP-eCommerce version is before 3.8?

if ( ( get_option( 'show_search' ) == 1 ) && ( get_option( 'show_live_search' ) == 1 ) ) {
		if ( (float)WPSC_VERSION < 3.8 ) {
			$siteurl = get_option( 'siteurl' );
			if ( is_ssl() ) {
				$siteurl = str_replace("http://", "https://", $siteurl);
			}
			$deps[] = 'wpsc-iautocompleter';
			wp_enqueue_script( 'wpsc-iautocompleter', "{$site_url}/wp-content/plugins/" . WPSC_DIR_NAME . '/js/iautocompleter.js', array( 'jquery' ) );
		}
	}

If you are using a version that old you might want to consider upgrading?

Looking at the code you could also make the error go away if you turn off live search or show search in the settings.

@andyadams you are correct in identifying part of the scalability issue with the visitors implementation.

It is a somewhat long standing problem that comes about in large part of not wanting to risk breaking older sites by not liberally creating visitor records in the tables. Currently a visitor record is created when any HTTP request that could turn into a real shopper is received. THe current implementation does take into account the well known bots, so that isn’t causing an issue.

The root cause of the problem is those tables growing out of control. There is definitely something amiss in your configuration that is either ( or both ) causing too many visitor instances to be created in the database or the cleanup process never running.

One thing that can bring a site down is being hit by a bot that repeats attempts to gain access to the site. Any type of intrusion attempt is likely to cause a burst of records to be created.

Think about things that could cause cookies to blocked, or crons to not run.

There is a utility on my site you can grab to do a quick check of your configuration and common configuration issues. I also have a plugin that will let you browse through the visitors, and can purge inactive visitors.

http://pyebrook.com/store/product-category/site-checkup-wp-ecommerce/

It is pretty safe to manually prune out the visitor and visitor meta tables. You can delete records that don’t have a user id or common checkout data with SQL commands, then flush your object cache.

As far as deleting the items in a single query. That was part of the old implementation and brought with it very serious performance and data reliability issues. The server to server AJAX should be quick and efficient, **IF** the visitors data isn’t growing out of control.

One thing that I have seen cause the too many visitors issue is an improperly configured cache that prevents the WPEC customer cookie from being retained from one page view to the next. That means that if 20 page view requests, each with maybe 10 related http cookied HTTP requests, you could see 200 visitor records. I have helped a few people that were not aware that their hosting provider had a reverse proxy cache in front of their web servers, and that proxy was not configured to handle the cookies properly.