Simple Press works, or at least has worked, fine with custom user and user meta tables. We have multiple users running in this configuration. None have reported any issues in some time (have to assume they are still active) and thus we haven’t tested directly. You can actually see some code for it in our startup.

And to be honest, don’t remember exactly what the other users were doing with the custom tables.

But keep in mind that simple press will need to be installed in each site.

Maybe you can provide more details and specifics as to what you are doing.

I was about to say yes we support this as I know it is coded to look for them but then thought I would search the code just in case and I think we might actually be missing it in the actual installation code and I am going to assume it is during the install and the failure to populate sfmembers that you have encountered this.

I will go off now and double check this and if I am right and there is a loose end I will get it fixed up for the next update which – if WP3.5 gets released today as promised, will be immediately afterwards.

Thanks for both replies!  The issue on my end might be in the sequencing – here is what happened:

1. ‘Site A’ was setup with a SP and a bunch of user accounts
2. Site A was then duplicated to create a new site (‘Site B’)
3. Removed all user accounts from ‘Site B’
4. Changed the wp-config files on both Sites A & B to utilize the user database from Site A 

This process worked fine from the WordPress end – but as I mentioned the sfmembers table did not get linked between Sites A & B after making that config change.  SP is creating entries in the sfmembers table on Site B as people update their profiles, but it’s creating them with the incorrect ID’s.  For example, if when user ID 2198 updated their profile on Site B, SP created an entry in sfmembers but tagged it with ID 78, which is probably just an auto increment number. Unfortunately, then that person’s SP account info is improperly associated with the WordPress user ID 78 account.

Hopefully that helps – chances are this is an edge case that probably not many folks will run into.  

We don’t perform an auto-increment on the user_id – we just take whatever WordPress sends to use as the user_id. So there should be something else going on we need to discover.

Go back to step 3 – removing all of the user accounts. Did this include removing the sfmembers data? because that would have been best left alone…

Yes – the sfmembers table was wiped out as well. At this point, if I bring over the sfmember table data from Site A to Site B, will the shared user tables functionality work?  For example, if someone updates their account info on Site A, will that be reflected in the Site B sfmembers table simply by having the CUSTOM_USER_TABLE setting enabled in the admin?  It seems like this setting would actually tell Site B to use the sfmember table from Site A, meaning that no data would need to be in sfmembers on Site B.  Unless I am unclear about hot it works, and it’s actually replicating the data in the sfmembers table on both sites and for any updates it’s updating both tables. 

Also, how do shared user tables work for avatars?  If someone on Site A uploads an avatar, that file gets stored on Site A, but in theory the user should now have the same avatar on Site B.  Will Site B know where to find the avatar?

Good questions and I think you guessed the right answer. SP was not itself constructed to work on shared tables other than the shared WP users/usermeta tables.

We will need to ponder this one…