WP e-commerce 3.8.13.2
@misulicus, Thanks for the clarify!
Yes I checked in every 3 hours interval it removes and creates new users again.
In Backend Users-> ALL field is not populated,
It is understandable of how the plugin works in relation to customer meta information.
I guess on this process when old users are removed and new users are created again the Query /loading time hits little higher.
Just my hunch, I could be totally wrong. Query/loading can hit higher due to many other problems too…
I checked error log, no error output.
Even tried to debug..still no error.
Pls note this is my test site with only 2 registered users. Hope some one with many users can debug and help.
Thanking you!
Am I correct that 3.5 * 3600 = 3.5 hours?
Four and a half days since reporting a major bug that brings my site down and not even an acknowledgement?
The “fix” for the users bug is simply to hide them? Again, my issue of wp not deleting them automatically again ignored.
This is very poor support and I am not a happy customer. Wish I had not paid money for this software and I shall not be wasting any more time with wp-e-commerce.
The wp_users table is being purges with the config file fix however I am currently running the most current release – 3.8.13.3 and there are other database accumulation issues that this fix does not resolve. The users are purged but all the associated data in the wp_usermeta table remains.
Additionally the wp_options table is slowly filling up with data assoicated with an option_name value that includes “_transient_wpsc_customer_meta” and “_transient_timeout_wpsc_customer_meta”.
Please let me know if there is a reasonable fix for this issue as soon as possible. Our databases are growing too fast.
So if understand correctly all fixes untill now are still a little hacky? No real sight on a genuine update / bug fix? My client site has been down because of this. It looks like I’ll have to move on and transfer to another commerce tool fo Worpdress if this isn’t solved soon.
@rcswm
The transient flooding of your database seemed odd because I couldn’t recall a place in the current implementation where WPEC uses the WordPress transient function to do the data storage.
I vaguely recall that transients were used in the past to store the information. It may have been one of the motivations to go to the current meta data like implementation.
My guess is that it should be safe to delete the transients you identified. In fact, because WordPRess only deletes these expired transients when they are requested, they will never go away on their own.
As a side note, WordPress only stores transients in the options table as a last resort. That means your configuration doesn’t include one of the other more efficient caching mechanisms used for transients. If your hosting situation permits it, enabling one of these caching tools is a good idea. In my case, the performance difference is at least 3 times better when I turn on memcached compared to when I turn it off. Defiantely worth a look.
@jeff@pyebrook.com
I’ve checked my cPanel options very thoroughly. There is no obvious method by which to even enable memcached which SuperCacher for WordPress requires. Not sure where to go from here to resolve the issue in the long term. If my database tables fill up with bloat from data that is unnecessary this presents a serious problem. Any additional advise is welcome.
Update
I am trying a plug-in that appears to be working very nicely. Optimize Database after Deleting Revisions by CAGE Web Design. This appears to be working perfectly for anyone that doesn’t have the ability to handle the issues I have mentioned using plug-ins that require you to be able to enable memcached, which in my case was not an option.
RCSWM,
You shouldn’t see the number of transients in the option table increase from version 3.8.12 onward.
If you see these you have something wrong in your configuration.
There are other caching mechanisms other than memcached. Reach out to your hosting provider and ask them about what they offer and recommend. It might be that wp disk based caching is the best you can do on your host, and that works well also.
Don
(@d_random)
I have spam 35,000 users!!!!!!!!!!!!
Hi d_random,
With the current release you shouldn’t be seeing the number of users grow this large unless there is a problem or unless you have a busy site. On average does your website regularly get more than 200 unique visitors per hour?
So a small number of ‘wpec anonymous user records’ is normal and healthy. But yhey should get cleaned up periodically. Obviously something isn’t right. I can think of the two likely causes for the number to grow beyond what is reasonable.
#1 Is the WPEC hourly scheduled to run? If not this is definitely a problem. If you don’t have a tool to check the scheduled cron events I can recommend WP Crontrol.
#2 When the cron runs is it encountering some type of error, most likely an out of memory condition? You can confirm this by checking your server error.log. You might also want to enable the WP debug log and check for errors there. If it turns out to be an out of memory condition slightly increasing the available PHP memory will probably get things working again.
FYI, There are finished enhancements in the queue that will make this process more robust. These enhancements are currently being reviewed for inclusion in the next point release.
Last of all these aren’t spam users, WPEC leverages WordPress user profiles to hold information about the shoppers as they progress through your site. Too many of these hanging around is definitely an issue, but SPAM implies something nefarious rather than something that is not working as intended.
Post back so we can get your problem resolved.
Jeff
WPEC dev team, I understand everything you have posted in this thread about the new Customer API, and I thank you for trying to come up with a workable solution to what is a mess of a technical problem. Please add high up on your to-do list thinking through exactly what happens to a customer when their anonymous user record is pruned by the cron task but they still have the cookie referencing a deleted user ID. I’m finding a mixed bag of unexpected results for our non-logged-in users who haven’t interacted with the cart in days but have remained constantly active on the site. One outcome is that while the cart gets emptied as I would expect due to inactivity, items can still be added to it under the same deleted user ID, and orphan records are created in wp_usermeta referencing the deleted user ID. Correct me if I’m wrong, but shouldn’t it do a sanity check of user ID presented in the customer cookie (e.g. does the user exist?) and recycle to a fresh customer cookie if the user ID was pruned? If you agree, this should occur on every request which involves WPEC, including AJAX calls to add an item to the cart. (I’m thinking in particular of the case of a visitor who has had a product page window open for days with items in the cart, and who eventually comes back to it after ages of inactivity expecting to maybe add another item and checkout but is surprised to find the cart emptied during the item add.)
Don
(@d_random)
Thanks for your help Pye Brook.
Anyone…is there a way to delete the users in MYPHP?
A bulk delete for example?
Not knowing your WordPRess configuration I would recommend against doing a bulk delete. I can’t say for certain if it would make other things go out of sync.
If you want to try to cleanup the database one thing to try would be temporarily setting up a cron that would fire off the cleanup routine more than once per hour.
If you have something like the the wp crontrol plugin you can set this up very easily by duplicating the wpsc_hourly_cron_task event with a different time interval.
Let us know how it works.
-Jeff
