Gary Cao

The official release is coming within 24 hours. We wanted to gather as much feedback as we could about the beta so that we’re sure it fixes the issue and doesn’t cause any additional ones.

For any pending issues that are not resolved by our 3.8.13.2-beta package, please give us as much details as possible (your error log, if possible, your server and WP admin access so that we can debug it on your server). We will not delay the official release any longer, so any additional issues after it’s released will have to wait until the next version.

@kscott29:

Please check your error log as I said in the previous post. Any other clue would help. And also please confirm again that the users you’re deleting manually are indeed more than 3 hours old.

Also you need to make sure the “define” line in wp-config.php is not below this line:

require_once(ABSPATH . 'wp-settings.php');

If you can’t find your error log, I can always help you debug this on your server. Please send me an email with FTP / WP admin access to [email protected].

@marwal:

We didn’t get much confirmation that our beta package fixes the issues so we needed to spend more time testing and make sure our fixes don’t break anything else. It’s going to happen within 24 hours anyways.

As indicated in a lot of comments before, we couldn’t under any circumstance replicate the issue where multiple users are created for one unique visit. Hence I offered multiple times to help people debug this on their server by sending me a private email to [email protected] so that we can get our support team to debug it for you asap. Simply saying you have this problem, and then refusing to test our beta package really is not helping us and yourself at all. If you don’t want to give us that chance, I’m afraid there’s nothing else we can do.

Unfortunately for non-techie users, if they are running high-profile shops, it’s best practice to always test a beta or release on a separate testing environment before deploying it to a live store. Or at least maintain regular backups so that they can roll back when necessary (which is what we advised in every blog post). That way we can have your timely feedback and fix issues as soon as they arise while your shop is affected the least by any issues in the new release.

@kscott29:

A lot of users are confused and think anonymous accounts older than 1 hour get deleted. So I just want to clarify this just in case.

The cron job that purges anonymous users run every 1 hour. In each run, it will purge anonymous user accounts older than 48 hours by default. So at any given point in time, it’s expected behavior (not a bug) that there exists anonymous account that are older than a day, but not more than 2 day old.

If you want to reduce 48 hours to 3.5 hours, edit your wp-config.php file and add this line below your database configuration:

define( ‘WPSC_CUSTOMER_DATA_EXPIRATION’, 3.5 * 3600 );

If you’re using the updated package I posted at https://www.ads-software.com/support/topic/spam-users-in-wp_users-after-wpsc-upgrade/page/2?replies=45#post-5075937 , and changing the constant in wp-config.php doesn’t work, I might need to get access to your server (SSH/FTP, WordPress admin account) in order to debug this. I and other developers have been unable to replicate the purging issue after the update posted above.

Also, have you checked your error log? Is there any fatal error, memory issues etc. related to cron jobs in wp-cron.php?

Good news!

If you’re having problem purging outdated anonymous customer data, or you’re encountering memory issues in your error log, we’ve just committed a few additional fixes to our beta package.

Download it here: (same link as before but with updated content)
https://github.com/wp-e-commerce/WP-e-Commerce/archive/3.8.13.2-beta.zip

Upload the extracted folder to your site’s plugins folder. You can either replace your current WP e-Commerce plugin folder, or upload the 3.8.13.2-beta folder along side it, then deactivate the 3.8.13 version and activate 3.8.13.2-beta version (do NOT activate both at the same time).

When the new beta version is ready, run your cron job by visiting:

https://path/to/your/site/wordpress/folder/wp-cron.php

The cron task might not run right away, however, because it’s scheduled hourly. You might need to wait up to an hour before the user rows are purged..

@robin:
There is a long story why each anonymous customer creates a user record in the database. I have to admit this is a limitation due to the way WP e-Commerce was coded a few years ago at the beginning of the 3.8 release cycle. Below is yet another long post explaining why it’s the way it is, because I think being honest about WP e-Commerce limitation will ultimately help you be better informed about the product you’re using.

Until the 3.8.8 release, $_SESSION is used to store customer data. At the beginning of each request, the WPEC plugin initializes many customer data (such as default shipping / billing country, zip code, so that the shipping module can calculate the fee and have it ready for checkout).

Code that manipulates customer data was mixed up with a lot of other code and just willy-nilly initializing and preparing customer data, regardless of whether it is really necessary or not. This is a legacy that was carried on since 3.7 time (which, admittedly, I don’t know much about because I started working on WPEC after 3.8 is out, so excuse me for the hazy details). This doesn’t prove to be much troublesome because storing data in $_SESSION is not as visible to the naked eye as storing the same amount of data in your database. Session data is tucked away often in the /tmp folder of your unix server, so most users are not even aware they are there.

This legacy turns out to be a heavy technical debt when customer data evolved from $_SESSION to transient, and then to user table as we have now. Unfortunately the underlying code that deals with shipping, payment gateway and other parts that manipulate customer data before it was absolutely necessary, did not evolve as quickly as the customer data storage system. We had to prioritize the move from $_SESSION to transient and then user table because it’s reward / risk ratio was simply higher than modifying all the code that unnecessarily initialize customer data and a lot of users were complaining about losing their cart due to certain $_SESSION incompatibility.

Now that the 3.8.13.2-beta is out, we hope it solves the annoying UI issue you’re having on the Users admin page. All the anonymous users have been excluded from the UI. Although they’re still there in the database, they’re mostly harmless and data older than 48 hours will be purged hourly (if this doesn’t happen, take a look at the debugging steps I outlined in a comment above).

Of course, unnecessarily creating anonymous users is still a problem that we promise to solve in 3.8.14 (or 3.8.9, we still haven’t decided what to call the next major release yet). A customer record should only be created when an item has been added to cart. This sounds simple but it means we’ll need to overhaul a lot of code to make sure unnecessary customer data initialization is eliminated. Currently we’re tossing around several ideas and hope to, step by step, eliminate this annoyance completely.

If you’re patient enough to read till this last paragraph, I’m very grateful for your understanding. WP e-Commerce certainly has its quirks, but it’s evolving release by release. Thank you for your understanding and support, and I’m sorry for the mistakes we made.

@nwdwp, @ccolotti:

What you’ve reported could be a bug, but unfortunately I haven’t been able to replicate them on my test sites.

@ccolotti:
If the automated cleanup process is not running, please install this plugin:
https://www.ads-software.com/plugins/debug-bar-cron/

Then on your admin bar, you’ll see a “Debug” button. Click it, and navigate to the “Cron” tab. What you need to look for under “Custom Events” is ‘wpsc_hourly_cron_task’ and note down its next execution time. Then wait until after that time has passed (by at least 5 minutes) and check your user table again and see if any anonymous users (prefixed by _) was older than 48 hours.

If ‘wpsc_hourly_cron_task’ is not listed under Custom Events, please send me an email to [email protected] with the screenshot of that “Debug – Cron” screen. If it is listed, but there are still anonymous user accounts older than 48 hours, then it means somehow WordPress doesn’t run cron on schedule (a general WordPress issue). You can fix that by setting up real cron job on your server (example with cpanel: https://pogidude.com/2011/use-linux-cron-to-trigger-wordpress-cron-scheduler/)

@nwdwp:
If multiple user accounts are created when you only access your store once, please check to make sure that you’re the only person accessing the store during that time (and not other bots or customers).

If you’re on a local test site and certain that you were the only one accessing, but there are multiple accounts created during that time, please let me know via [email protected] as well with a screenshot of your Users screen. I tried to replicate this but have been unable to.

Hi everyone,

3.8.13.2-beta has been tagged and awaiting other core committers approval before we can release this officially.

In the mean time, you can test the beta package by downloading it from here:
https://github.com/wp-e-commerce/WP-e-Commerce/archive/3.8.13.2-beta.zip

Then upload the extracted folder to your site’s plugins folder. You can either replace your current WP e-Commerce plugin folder, or upload the 3.8.13.2-beta folder along side it, then deactivate the 3.8.13 version and activate 3.8.13.2-beta version (do NOT activate both at the same time).

When 3.8.13.2-beta is activated, check your admin users page and confirm that the anonymous users are hidden. This would prevent further confusion about the harmless customer accounts.

@webaware: I just checked our changelog again and indeed it was too generic (“Better customer API”), so thanks for the feedback. We’ll communicate the changes better in upcoming releases.

@bob Baker: I understand your frustration and am working on a fix on the UI (will be released as 3.8.13.2). I didn’t try to justify the problem at all, just merely provided an explanation that all those user accounts are harmless and didn’t affect your site negatively (aside from the admin UI inconvenience).

We always release early alpha and beta versions at least 2 weeks before the official releases so that users can test and give us feedback in time. The same will happen with 3.8.13.2 (although the time difference between this and the official release will be merely days). As a result, it would really be helpful if you could try out the beta as soon as it’s out and give us your feedback. For this 3.8.13.2 release, please send me an email to [email protected] and I will personally notify you when the beta is ready for testing.

@jlowgren:
I’m suspecting this is caused by another plugin that depends on WPEC. Are you by any chance using any user subscription plugin?

@webaware: As we already admit in multiple posts above, not hiding the phantom users in the admin area is a bad idea and we’re fixing this UI issue in the upcoming minor release. That being said, we’re not switching back to using transients and option table as that solution has its own set of problems, and many users were also complaining about their options table being bloated when we did that from 3.8.9 to 3.8.12.

Hi everyone,

First of all I would like to say that this is a common issue and implementation in almost all good e-commerce systems out there, including WooCommerce, JigoShop etc. Here’s an example: https://www.ads-software.com/support/topic/a-lot-of-wc-sessions?replies=14 . Mapping each anonymous customer to a row in your database is unavoidable. If you have 80,000 anonymous hits (spam, bots and real users combined), then invariably, you’ll have 80,000+ new rows in your database (unless there’s a bug in WPEC that create 3 user accounts for one anonymous customer, which is unlikely because the majority of our users and all of our test sites don’t have this problem).

Prior to WPEC 3.8.9 (if my memory serves right), anonymous customer sessions are recorded in PHP sessions, which is not compatible with a lot of server configurations. So from 3.8.9 we switched from using PHP sessions, to storing anonymous customer data in transients, and eventually in user and user meta tables as we’re doing now in 3.8.13.

There are a few things I would like to clarify about the situation with customer data:

1. Your site might have more anonymous traffic than your Google Analytics statistics show. The reason is because Google Analytics (and the likes) have already filtered out traffic from legitimate as well as spam bots (which could be 5 to 10 times the amount of real organic traffic, we’ve seen that many on getshopped.org). A better visit count could be obtained by getting the number of unique IPs in your server’s access log.

2. Every e-commerce system stores anonymous customer data behind the scene, they’re just not showing it. We’re sorry for not hiding all those accounts by default. This will be fixed in the next release.

3. WPEC has a mechanism to filter out as many bots as possible that access your site, so that those will not create new user accounts, but it cannot replace a full-blown spam recognition and protection service. If you have 80,000 anonymous accesses in 4 days, and a lot of them are from spam bots, you need to do something on your server to prevent as many bots as possible. If all those 80,000 visits are by legitimate users, then what you need is a better server to handle that traffic. The size of the database is the least of your worries. Of course I cannot rule out the possibility that you probably have only about 5k anonymous users but somehow 80k accounts are generated, in which case, please email me at [email protected] and I will help you verify whether this is indeed the case.

4. The leading e-commerce plugins such as WooCommerce, Jigoshop and WP e-Commerce in version 3.8.12 all use transients to store customer data (hence, threads like this: https://www.ads-software.com/support/topic/a-lot-of-wc-sessions?replies=14). What this means is, if you have 80k anonymous hits in 4 days, this would be blown into 160k transient rows in your options table. This could be a performance issue when you have a lot of anonymous customers. As a result, in 3.8.13 we migrated to using user account and user meta, which is a more viable option. The anonymous customer data has to go somewhere, and the user & user meta table is the “less bad” place for them. We just need to hide all those ugly anonymous users from your admin UI so that you’re not inconvenienced by them.

5. If your cron job is not being run and anonymous user accounts older than 2 days are still there, this could mean further issue with your server’s firewall or caching system blocking the cron job request (mod_sec could sometimes be troublesome).

So what I would advice you to do if you have a lot of user accounts created in a short amount of time:

1. Edit your wp-config.php file, add this line below your database configuration:

define( ‘WPSC_CUSTOMER_DATA_EXPIRATION’, 12 * 3600 );

What this line does is it will instruct WPEC to clear anonymous accounts that have been around more than 12 hours. Modify the 12 number above to what you deem appropriate.

2. If you find this step complicated, shoot an email to [email protected] along with SSH access to your server and I’m happy to personally help you do this, or point you to our support staff who can: verify the anonymous traffic you have on your site. Don’t rely on Google Analytics alone because that analytics would already filter out the number of legitimate as well as spam bots. Take a look at your server’s access log and you’ll have a better estimate of the traffic you’re handling by filter out the number of unique IP addresses in the last 48 hours (or 12 hours if you follow step 1 which is setting the expiration constant in wp-config.php). Then compare the number of unique IP addresses in your access log with the number of your anonymous user accounts. If the ratio is a lot more than 1 : 1 then this could mean it’s a bug in WPEC. Otherwise, you need to setup another layer of spam bot protection (mod_sec is a great solution).

3. Make sure cron job is not being blocked and are run at the correct interval. Install the debug bar plugin, then install this to take a look at your cron schedule:
https://www.ads-software.com/plugins/debug-bar-cron/

4. If indeed all of these IP addresses are legitimate customers, and you’re concerned about the size of your user table, there are a lot of ways to mitigate this load, such as using memcached / APC, using hyperdb and separate your user table to another server etc. You have to do this anyways if you want to scale no matter what e-commerce system you use.

Hi webmatch,

Thanks for the notification.

We have fixed this on our latest development branch, and this will be included in our upcoming 3.8.9.1 release.

Gary.

Hi!

This issue has been fixed in 3.8.9. So if you’re installing WP e-Commerce on a fresh site, you won’t encounter the same issue again.

Gary.

Morphim, cool down. I didn’t mean to be condescending. Merely stating facts there.

I’m not denying responsibility for the buggy release or anything. I was just reminding ccolotti that he should back up properly next time.

Now, about your entire rant. We have done our best to test this plugin on as many different configurations as we can. We also announce the beta release two months ago. That means you have two months to test it and give us feedback. Let me remind you here, this is free and open source software. We build this software for you and distribute it for free, but we also need your help testing it on your configuration. We’re a small team, so it’s just not possible that we can test every single set of configurations out there. This is not an excuse for us messing up of course. I’m just saying, we need your help and support too.

Two months passed after the testing phases started and we fixed a host of other bugs thanks to efforts and feedback by a dozen of our users. Just a dozen out of our thousands of users. That alone shows how much help we need from you.

I hope you understand my point. I’m not trying to be condescending or anything. But my team worked hard on this, and we did our best with our limited resource.

Now, multisite compatibility is important. We have it on our roadmap, along with many other important enhancements that most of our users need. But, again, we’re a small team, we can’t do everything at once, just focus on one thing at a time. If you feel up to it, you’re always welcome to join and help. Small things count, like posting those issues you found on our issue tracker to bring it into our attention. We’ve got too many things going on at the same time, so some gentle reminders once in a while for issues you want to fix is always appreciated:

https://code.google.com/p/wp-e-commerce/
or https://github.com/wp-e-commerce/wp-e-commerce/

When you upgrade to 3.8.9, there will be a prompt for database upgrade. If you didn’t act on it, then your original database wasn’t changed. Even if it’s run, the upgrade is mostly about updating country codes and currencies, and doesn’t modify any other crucial data.

It’s still recommended that you revert your database to previous stable state as well, just to be on the safe side.

You should have made a backup of the database and files before you upgrade to 3.8.9 though ?? Maybe next time.

You can download 3.8.8.5 from here:
https://www.ads-software.com/extend/plugins/wp-e-commerce/developers/

Hi dni777 and ccolotti,

There is indeed a bug in WP e-Commerce that’s preventing 3.8.9 to work with multisite.

This will be fixed and released in 3.8.9.1, scheduled for next Monday. Stay tuned!

We apologize for the inconvenience this has caused you. Please roll back to 3.8.8.5 and wait for further announcement.

Gary.