WPEC creates new users each time I load a page

About WPEC customer profiles.

WPEC customer profiles are nothing more than WordPress users created and used to hold information related to a shoppers experience on a WPEC site. Using WordPress users rather than a special purpose database table makes all of the existing WordPress user functionality available when working with customer profiles.

Additionally, WordPress user functionality makes use of the built in caching capabilities within WordPress, this makes user profile access quick. All of this comes without the costs of additional code to maintain.

WPEC, themes and plug-ins can add information to a customer profile at any time. The functions making up the API are in the wpsc-meta-customer.php. You’ll notice that the API for working with customer profiles mirrors the WordPress API used to work with other types of meta data. Customer meta can be manipulated just as you would manipulate user meta, post meta, or any of the other types of meta available with a WordPress site.

There are a few specifics about customer profiles that you may want to be aware of, but you shouldn’t need to know unless you are contributing to the WPEC functionality.

If you properly use the WPEC meta API, any meta you add to a customer profile will be prefixed with a standard, multi-site safe, prefix. This prefix is automatically removed when you retrieve meta values using the WPEC meta API.

To avoid creating too many profile users, WPEC tries to determine if a specific visit is from a real person or a web bot. If the visit is determined to be from an automata, a special customer profile reserved for automata is used for the visit.

Customer profiles have added to them a meta value ‘last_active’ immediately upon creation. This meta value contains the UNIX timestamp (see php time() function) of the last meaningful change to the profile.
Customer profiles are removed from the database after a period of inactivity. It is normal to have some number of the customer profile users in the database at any one time.

Interesting…

So If I read this correctly, what you are saying is that even though I only have one user defined for my site (admin), the fact that WPEC created another 56 users should not concern me because WPEC will remove these 56 users after a set period of time?

I guess this is some relief but as you can see from the code example above, this new user gets created before my code gets to run. This new user gets created as soon as I load the headers. This means that every time any user uses any function in this script, a new users will be created… 1000 users loggin in per day, checking their login details, the script trying to log them in automatically if “remember me was set” so possibly one call to test the cookie and another to actually log in. Password reset requests will cause new users to be created, password changes will cause new users to be created, updating any personal information will cause new users to be created…

That’s thousands of new bogus users added to the database per day and the more popular my project becomes the bigger that value becomes exponentially.

If you had said that a user gets created for bots and all bots use that user, that I could live with, but a new user being created for every single action any user takes every single time they take any action at all? That is just serious overkill.

Is there a way around this or should I just advertise my kit as being not WPEC friendly?

I repeat the key facts from my first post:
1. I created a new WP site
2. I loaded my plugin and WPEC
3. My code doesn’t make use of WPEC at all
4. Within one day I had nearly 60 users in my database of which only admin was real.

Isn’t there some or other define I could set that would cause WPEC to simply NOT execute whatever gets executed? I noticed something strange while playing with the plugin… When WPEC is active, I get new users added each time I call my script. When WPEC is not active, no new users are added. When I activate wpec, no new user is added but the first time I call my script, 2 new users are added… thereafter only 1 per action.

No idea why but yeah… Knowing that customer profiles are nothing more than WordPress users doesn’t really solve the issue at hand, which is new users being created every time I access my code for whatever reason and NEVER for anything related to WPEC. The only reason I even have WPEC installed is because I personally use it so I like to have it installed on all sites I do exactly for this very reason… to test if there are any issues. This issue, though, I did not expect…

Again, my code does NOTHING with WPEC so is there a define I could set that would cause WPEC to remain dormant for that particular call or something at all I could do to block this excessive user creation?

Thanks for the info so far, by the way. Hope you can give me a solution to my issue also. I really don’t want to have to advertise my kit as not being safe to use with my favorite eCommerce site…

Thx

To avoid creating too many profile users, WPEC tries to determine if a specific visit is from a real person or a web bot. If the visit is determined to be from an automata, a special customer profile reserved for automata is used for the visit.

This, for example, poses a question… HOW does it determine wether a visit is from an automata? If I could somehow make my code always make WPEC see it as an automata then will that cause WPEC to create one bogus user and use that for every single call made by every single user from now into infinity?

Or is this the problem in the first place? WPEC sees my code as being from an automata and then creates a new, bogus user for each visit? From your post it sounded like there is ONE user defined for automata, not one user per visit from an automata… am I understanding you correctly?

I think I might have a solution but need some input, please.

My plugin is meant to run on it’s own, completely independently of any other plugins. In fact, ideally it wouldn’t even trigger any hooks at all ! Unfortunately, it does…

The problem is that my code seems to run before yours does and mine sends a text reply after successful login which means that when your code runs it assumes headers are still open and tries to set a cookie… but since the headers have been sent and closed, it generates a runtime error. As a result, it creates a new user but it never sets any kind of cookies and I am assuming this causes the users to remain indefinitely.

The solution is rather simple, the way I see it, as all I need to do is call remove_all_filters() at the start of my code and thereby bypass your code from running. Unfortunately, wpec is one big project and I have no idea what hook this function calls into…

So if someone could tell me what hook contains the code that checks for automatons and creating users etc, I will be set.

Thanks in advance…

Anyone?

Probably won’t work, the WP e-Commerce hooks happen very early, and are attached to initialization.

You might be trying to fix a problem that doesn’t need to be fixed. The issue with WPEC not keeping the WordPress user table neatly is going to be resolved very shortly. Why not wait for the beta of the point release and see if it fixes the problem.

If you must implement something you should google conditional loading of plugins and look at that technique. Definitely not for the faint of heart, will require a lot of debugging. But if you don’t want WPEC to load on all pages why not do it that way.

Or you could think about putting your store on a sub-domain, and only have the commerce functionality load with that web site?

-jeff

I was actually just busy reading the thread about how they want to move the users into some other place so they are not as “in your face” as they are now. That all sounds good and well, but as I said, the problem is that my plugin ends the headers and wpec assumes (probably because it happens to early on) that the headers are still available for use. This makes it clear that my code runs first…

This actually returns an HTML error string to my app. Something along the lines of :

<br />
<b>Warning</b>:  Cannot modify header information - headers already sent'

Problem is, MY data gets sent as base64 encoded text but this error is appended as normal text which means it breaks my code when I try to decode non-base64 text.

I agree with Robin’s post:

I must be missing something BUT why do you need to generate an anonymous user for every visitor? I don’t see the point or need. If the visitor buys something then I get their details. If the visitor does not buy anything then the anonymous data is of no use to me

I would also say that a temporary user should be created if the visitor interacts with my store in any way at all, not simply for entering my url into his browser. The fact that “everybody does it” hardly sounds like a good enough reason to do so… Why not be the first to do it right, then?

My intention is to distribute this code so I need to work around this issue. like I said, I don’t need any hooks to fire at all… My code just runs, logs the user in and returns the login cookie together with a “All went well” text string and some basic account info then ends. If I am going to give this code to others I cannot tell them to go create sub domains and change their website(s) around just so my plugin will work with their site…

I need a way to prevent WPEC from writing cookies when a user logs in. That seems to be my main concern. The cookies cause their function to fail and thus break my code in the process due to the error message being returned. When a user logs in they create a new user which causes an error that results in a new user in my database, no cookies being set on the server and my code breaking back in my app.

Just to be clear here, to make sure it doesn’t sound like I’m changing the focus of my query, yes, I do want the excessive user creation to stop but if they will get cleared eventually then I suppose I could live with it if I have to… BUT… the fact that new users get created every single time I call my script means that when I call the login function, WPEC actually BREAKS my entire application. That is the far worse crime in my books! So I definitely need a way around the user creating function…

Why exactly a new user needs to be created in the first place is beyond me… Again, if they interact with my store in any way, shape or form, sure, go ahead, do what you must do… but to create a new user just because someone wants to read my rss feed? A new user just to REQUEST a password change? A new user when logging in with the temporary password? Another user created for changing your username and yet another one for logging back in with your new password? Serious overkill there… notice how I now have 5 new users and not once did the user even glance at the store section of my website… How could this possibly be justifiable even with “well everyone else does it so why can’t we?” ?

If the WPEC update is going to NOT automatically write cookies upon login then my issue will be resolved. If they still do then I will be stuck in the same boat even after they hide the new users that get created…

But I will definitely give it a try! Nothing to loose by trying! ??

Conditional loading of plugins… sounds great! Not for the feint of heart? Not so much. ?? All my issues could be avoided by me simply clearing the hook they use to create the new users through…

One line of code and I would be good to go… I already know the code… I just need the first param to go with it… Just one little word… all I need… ??

When a user is logged in WP e-Commerce does not write any cookies. If a user is not logged in, then logs in, any existing WP-e-Commerce cookie is deleted.

When a visitor to a web site is logged in WP e-Commerce uses the existing current WordPress user information, it does not create a temporary user.

– jeff

This is the error I get:
/wp-content/plugins/wp-e-commerce/wpsc-core/wpsc-functions.php</b> on line <b>1642</b>

…and this is what is there:

function _wpsc_merge_customer_data() {
...
	setcookie( WPSC_CUSTOMER_COOKIE, '', time() - 3600, WPSC_CUSTOMER_COOKIE_PATH, COOKIE_DOMAIN, is_ssl(), true );
	unset( $_COOKIE[WPSC_CUSTOMER_COOKIE] );
}

The error occurs on setcookie…

That’s WPEC making sure there isn’t a cookie set because the user is logged in.

Set a breakpoint on it and you’ll see that it’s probably happening somewhere near near the ‘init’ action.

That should be well before content is being sent.

What error are you getting?

Well, I finally got it working without throwing out the error. Just had to add
remove_all_filters('shutdown');

Strange, I thought the after_setup_theme hook would be the culprit but nope… turns out shutdown was the one I was looking for…

Just looked at all add_filter and all add_action statements in the script, added them all to my script and applied a process of elimination. Now I just need to go test if this solves the user generation issue or not, but at least it solves the error that breaks my code and if it doesn’t solve the issue, their update will so I am good either way now.

Thanks for the assist.

mybadstudios,

Can you do us all a favor and try a change. If it works I’ll submit the patch to the WPEC core.

Wrap the setcookie call with a headers sent test, the should look something like this.

if ( ! headers_sent() ) {
  setcookie( WPSC_CUSTOMER_COOKIE, '', time() - 3600, WPSC_CUSTOMER_COOKIE_PATH, COOKIE_DOMAIN, is_ssl(), true );
}

That worked just beautifully, yes ??

I submitted the patch!