spam users in wp_users after wpsc upgrade

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.

Will the cleanup also be fixed? The add-in to wp-config.php does not seem to be reducing the count. Hiding them is one thing, but removing them from the DB cleanly over time is still a good idea.

@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.

@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.

@gary Cao thanks for the reply and the through explanation.

I confirmed a couple things with further testing in my local dev environment to confirm why there were so many user sessions created with a local dev environment.

1) 2 anonymous sessions are created when a web visitor adds a product to the checkout. (You just confirmed that lol)
2) since I test on multiple browsers (new cookies) it is creating 2 new anonymous sessions each time and I test with a handful making it appear there is a new web visitor each time, thus causing two new anonymous sessions to be created each time.

I was in the mix of typing out why the heck non-real web visitors that are NOT adding items to the checkout (THUS BOTS etc..) are getting 2 user accounts/sessions associated to them, but you guys already appear to be working on a solution to that. And from experience know its no easy task trying to resolve a development fix like this especially when original code causes some limitations.

I am also affected by this bug- only thing is that I haven’t yet upgraded my version so that means that it is also in 3.7

I have 2 sites with WPEC and one is on latest and the other hadn’t been upgraded & both have this anonymous user issue.

Nothing has been getting purged.

Hoping for a solution.

Thanks

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..

Thanks for the efforts above Gary,

Can I ask when the official release of the actual update fixing the problem will be.

Days, Weeks or Months will do, I need to plan at this end, thanks

@bob Baker – My understanding is that we’re talking day/s. Can you confirm that the beta linked directly works?

@gary Cao – Thank you for the explaination. Taking over somebody elses project is alway tricky, even more so when the original design has some ‘excentric’ ideas.

I look forward to the new release.

@gary cao, does this just ‘hide’ the anonymous users or remove them?

It looks like it is just hiding the anonymous users. I have been using a plugin, “No Posts User Delete Plugin v2.0” to remove the anonymous users, and after installing the beta the anonymous users do not show up under “users” in the admin panel, but still show up like they did without the new beta on the plugin when I search for subscribers without any posts. I installed the beta early this morning and it hasn’t purged them. Had over 900 new users over a period of a few hours, just deleted them again.

@kscott29 – it removes them every hour (or two hours – I can’t remember which). I read that last night on one of Gary’s updates in github.

@dan Milward, I understand that it’s supposed to purge the users every few hours, but it isn’t in my case. Even with the beta.

Edit:
Unless it is set for over 3.5 hours, because that is how long I allowed it to build up before deleting the users manually again.

@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?