maybe its too early in the morning here, but not following this yet…

If a user is not assigned as a subscriber of the blog with SPF at the time they sign up, they are forever locked out of the forums.

could you explain this better please? subscriber with spf?  locked out of the forums? are you saying that they cant view a forum???

do you mean the user was never created in the sfmembers table?  Is wpmu doing nonstandard things when creating users?  is it not firing the wp hook for creating users?  does it have an alternate way from wp for creating users? thats about the only way something like that could happen.  if they do, they shouuld have an alternate hook that gets fired.

mabye be speaking too soon here since I am not sure I understand the issue yet, but in 4.1 we are now hooking into user wp profile updates. wouldnt be too hard to ensure the user exists at this point and create if they dont.  BUT more important to understand what wpmu is doing differently when creating users.

Frankly, I dont think there is a tenable way to not have different tables for users and permissions.  Keep in mind that the permissions stuff is done in many tables (and not sfmembes anyways).  I think modifying core wp tables and adding stuff would be a mistake.  Besides, if we arent properly creating the sfmembers data, we wouldnt make the modifications necessary to the users table and the same issue would exist.  We just need to understand the wpmu method(s) of creating users.

Mr Papa said:

maybe its too early in the morning here, but not following this yet…

If a user is not assigned as a subscriber of the blog with SPF at the time they sign up, they are forever locked out of the forums.

could you explain this better please? subscriber with spf?  locked out of the forums? are you saying that they cant view a forum???

do you mean the user was never created in the sfmembers table?  Is wpmu doing nonstandard things when creating users?  is it not firing the wp hook for creating users?  does it have an alternate way from wp for creating users? thats about the only way something like that could happen.  if they do, they shouuld have an alternate hook that gets fired.

mabye be speaking too soon here since I am not sure I understand the issue yet, but in 4.1 we are now hooking into user wp profile updates. wouldnt be too hard to ensure the user exists at this point and create if they dont.  BUT more important to understand what wpmu is doing differently when creating users.

Frankly, I dont think there is a tenable way to not have different tables for users and permissions.  Keep in mind that the permissions stuff is done in many tables (and not sfmembes anyways).  I think modifying core wp tables and adding stuff would be a mistake.  Besides, if we arent properly creating the sfmembers data, we wouldnt make the modifications necessary to the users table and the same issue would exist.  We just need to understand the wpmu method(s) of creating users.

I will try to explain better:

If the User is (-No role for this blog-) of (wpmu sub-blog with SPF forum installed) at the time they are entered into the wp_users table, there is no way to add him to wp_x_sfmembers (wpmu sub-blog with SPF forum installed).

Yes, they are locked out of the forums. Even if they are added as Site-Admin, they are perpetually being directed to their own SPF profile.

The way the user is created is the same as wp, however, SPF may or may not be loaded in that particular sub-blog when that occurs. When a user joins a new blog however, a user role change is all that occurs. Most commonly, -no-role-for-this-blog- is updated to -Subscriber- (could be higher afterward, however subscriber is generally the first step.)

Hooking into the profile update would seem to be a good way to resolve the issue, as directing the user to their profile seems to be the default action being taken. I would think that hooking into a user role change would also be a good way.

I know this may sound like a broken record, and just thinking about what I want to say sounds so, childish, but in programming it actually does make co-operative sence.

Other plugins store user data and options in standard WP Options tables, and in wpmu each can account for data under different sub-blogs.

While saving Group, Forum, Topic, post and even PM and Threading data and options in SPF specific tables makes the most sence; saving extra user profile data, user options and SPF roles, would best be modled after existing, and very popular WP plugins. i.e. Register Plus and Role Manager respectivly, both of which are WPMU cross compatable.

At the same time, having different SPF profiles and WP profiles is making less and less sense, and bringing the wp-login.php and wp-profile.php page to the front of the blog is handled quite well under 'Customising Your Community', even in MU.

Lastly, saving user avatars/gravatars to be used blog wide is also handled very well inside wp-profile.php with the wp/wpmu plugin 'User Photo'

I bring there points up because, although SPF v4.0.1 is VERY GOOD… using the methods detailed in these third party plugins, would make SPF the PERFECT Forums plugin.

Integrating these methods would not only improve performance but would also show a marked decrease in user issues such as plugin incompatability. In Fact you will see a range of cross plugin compatability on a level not previously available.

As for the original issue, being locked out of the forums, I believe the tack being taken is grounds for a report that the issue is being addressed in future versions, however users will want a fix quite soon.

on business travel for next week… will review when I get back..

Steve, Andy

I located something that MAY help in this instance:

http//codex.wordpress.org/WPMU_Functions

Although this function is undocumented

is_user_member_of_blog ( $user_id, $blog_id = 0 )

This function MAY help when examining a user who is loggin in for the first time and is shown his profile (as a normal first time user is)

If this returns a true event, and the user does not have group or membership assigned, SPF could kick over it's own Registration event to register the member as if they had just registered on the blog. (in effect they may have just registered on the site, but on a different blog)

this registration event should kick over even if blog registrations are turned off, as the site admin may want all users to register using the WPMU specific wp-signup.php routines, which is where we are getting most of the errors we are encountering.

you would have to condition the routine with an 'if function exists()' first as we would not want this to cause an error in a standard wp install.

as i said, this function is undocumented, so you would have to experiment with it on a local WPMU install.

if you like, you may contact me with a test routine in e-mail, and specify the conditions to test. (I'm good at breaking things like this… not so good at actually coding it.)

Haven’t been ignoring this and I have raised a ticket. When Steve gets back we can discuss the best way to deal with it.

okay, have read through this 3 or 4 times now and still confused…  must be my thick head…

a couple of questions…

what the heck is “no role for this blog”??  Is that a wpmu specific role? what is its function? and is that the default role for new users on wpmu instead of subscriber?

where is spf installed?  in the main blog?  or in sub blog? or multiple sub blogs?  is the issue with sub blog users accessing the spf on the main blog?

If a user is not assigned as a subscriber of the blog with SPF at the time they sign up, they are forever locked out of the forums.

If a user is not assigned as a subscriber of the blog??  This is the same blog spf is on?  If they dont get subscriber do they get any role? Is that what this “no role for this blog” is?  why wouldnt wpmu still fire the new user hook which is what spf latches on to?  does register = sign up in wpmu?  are the registrations taking place on the blog (main or sub) that spf is installed in?  or on another blog?

perhaps a pictorial block diagram or flow would help here… sorry to be dense, but this wpmu is all new to me…

if a user has “no role for this blog” should they be able to access spf?  how does a user get a “real” role in wpmu?  is it a profile update like in wp?  Which profile update does it? main blog or sub blog?  is it the one that has spf loaded?  If so, in 4.1 I already latch onto that hook for some other stuff.  Even though I am not sure I understand the whole sequence yet,  if a profile update is done to make them a subscriber or higher, and the normal wp profile update hook is fired, I could provide a quick and dirty patch to catch that, check if user exists and create them if needed.

The problem with MU is that it adds 2 different user roles to the blogs that are not in regular WP

Site Admin (aka god mode)

and

No Role (aka ghost mode)

When a user registers on a MU blog, they get the role assigned to them on the blog they register on… but in all other blogs, they get “No Role” esentally ghosts with no way to effect the blog, or, in the case of forums, no way to access the posts

take site xyz.com: Obviously www xyz.com is the main blog… but sub blogs xxx.xyz.com and yyy.xyz.xom are also built on this imaginary domain.

when a user signs up on http://www.xyz.com he's given the wp-role of subscriber and if the main blog also has SPF, the SPF role as Member

but on sub-blogs xxx and yyy, the user is also registered, but assigned the role of “No Role”

What's more, because those two blogs were not active in the registration process, no registration event was sent to any SPF installation on those two sub-blogs.

Now, when the user goes to blog xxx forums, he can not re-register, because he's already registered, and changing the WP-role from “No Role” to “Subscriber”, has no effect on SPF… it's looking for a registration event. You get a Ghost user who is trapped with no access to xxx forums.

What happens is SPF recognises that the user is logged in and, because he's visiting the forum, it shows him his profile…

editing his profile has no effect and any attempt to view the rest of the forum is treated like his first visit again and he is taken to his profile, again.

logging out simply leaves the user as a logged out user/guest and whatever privlages Guests have.

Who can change the role from “no role” to “subscriber”?  the user or only the admin? and its updated in the main blog where spf resides?   if he has “no role”, fair to assume he should not be able to access spf on the main blog?

Assuming “no role” should not be able to access spf and someone must change his role to “subscriber” or higher on the main blog that contains spfr, in the next day or two, I will create a 4.0.1 patch (actually some modded files) for you to try something and see if it helps this situation.

Mr Papa said:

Who can change the role from “no role” to “subscriber”? the user or only the admin?

** all three; the Site admin, the sub-blog admin and the user themselves.

and its updated in the main blog where spf resides?

** no this is a sub-blog specific setting.

if he has “no role”, fair to assume he should not be able to access spf on the main blog?

** access in any blog with SPF is limited to just viewing their own profile. (forever stuck on profile)

Assuming “no role” should not be able to access spf and someone must change his role to “subscriber” or higher on the main blog that contains spfr, in the next day or two, I will create a 4.0.1 patch (actually some modded files) for you to try something and see if it helps this situation.

That would be fantastic.

and its updated in the main blog where spf resides?

** no this is a sub-blog specific setting.

I wanted to elaborate a bit on this.

SPF exists inside a blog. blogs exist inside wpmu. if an action takes place in WPMU it occurs in a singular blog. the rest of the blogs are uneffected.

if a user registers in www (main blog with SPF) then the user has access to spf inside that blog and inside that SPF.

that user however does not have access to sub-blog xxx or yyy (although that may change later)

spf can be in either or both of the sub-blogs as well, and because they are not involved in a registration on www, they have no way to hook the registration routines.

when the www user visits the spf on the sub blogs, that's where the “forever stuck” error occurs.

Also… a user may register on zzz sub-blog with no SPF install… this user is now “forever stuck” on all of the SPF installs, even on the main www blog.

hooking wp-role changes also exists inside each sub-blog, If each install of SPF could watch the existing role of a user inside their own sub-blog, then they could effectively allow (or even disallow) access acording to the role-assigned, no mater how it's altered.

lol… this didnt help…  confused me a bit more…  BUT, you said fantastic to my suggested fix, so I will go with that as a starting point…  maybe tonight, tomorrow for sure…

well the fix worked… if I visit the user's wp-profile and adjust user role… and save… then the user shows correctly in that blog and on that spf.

now… multiply that by 5,000 users… and the potental for 5,000+ blogs, all with a copy of SPF…

In WPMU there is a plugin called PowerTools which advanced users can use for global house keeping.

PowerTools allows SiteAdmin to make PHP calls which they can run for every blog.

Is there a PHP call that can be fired to trigger your code, besides the hook for updating the profile?

Since I still code with a brick, would you provide me with the PHP code, to run down the wp_user database, and fire your code to 'update' each user who is role 'subscriber' – some logic like:

with PowerTools the single php string could be run on every sub-blog and used as a housekeeping tool for siteadmins.

yes, there is a function call. assuming using 4.0.1

sf_create_member_data($userid)

please verify that is proper name in sf-database.php, but it should do the trick…

my patch added an action on the profile update hook, checked if the user existed and then created the user if it did not… I will add this my other login in the action routine.

I also want to play with detecting the situation when we go to the profile page and get stuck so no real user interaction is reqd. Of course, this wont help the admin blank users portion of this though that might be detectable too. or perhaps a housekeeping routine could be provided with link on members page.

I am somewhat lost on this discussion and don't really have a clue what you two are up to!!!

I am starting to like it that way when it cmes to this MU stuff (Just kidding)

I can't work out if you both now WHY when it goes to the profile you can't escape it… because if you don't know I can tell you. So… if you don't know, I think it is because we check to see if a user has NULL posts accredited to them in his sfmember data. If it is NULL we direct them to the profile page and then change that data to a zero. This way if they make no posts they wont be doirected here next time because the column is no longer null. If, of course, they have no sfmembers data then it wil always be NULL.

Sorry if you knew that already but as I say… I am lost on how far you have been…