I think I would feel more comfortable reinstating the old 'register' code just for MU if that would work. We need Steve for the discussion of checking for admins though.

happy to join the discussion, but frankly not sure where to start… have never even tried to use wpmu, so perhaps a general tutorial is in order?  is admin stuff diff?

love the math required bit for me in this one forum.:???:

Yes, SOME admin stuff is different… WPMU is first, a multi user database, and then second, a blog system…

IF user registrations are enabled in the sub-blog, AND you have a plugin to modify user registrations such as CYC (above) the process is exactly the same as normal WordPress.

I was suggesting, using CYC code simply because it works in both WP and WPMU. It also does a MUCH better job of “Skinning” the login, registration and subscriber profile pages than anything I have ever seen before. Also Because it hooks the wp-login.php page so well, even the built in wp-meta widget keeps the user in the front-end of the blog.

As far as additional profile fields go, I have seen tons of them, some of the more popular ones, ask for info during the registration process and and display their data in the default wp-admin/profile.php…

CYC code and/or Register Plus code could potentially provide SPF users with a single, fully integrated, profile system.

As it stands now, SPFv4 + CYC + MU = a viable Multi-User forum. (including SPF Math Spam Protection on Register)

Unfortunately, this combination is currently very heavy on the admin’s tech knowledge and would not be viable as a “Simple” forum.

Radio,

can you give us (at least me) a brief overview/run down of wpmu?

as I understand it, you get a site admin blog and then a bunch of sub blogs below that for each of the users that sign up or are given a blog. 

where do folks try to set up spf?  at the top level admin blog? or is this for individual sub blogs? or some combination?  who would get access and at what level of access?

okay, I got wpmu running on one of my empty domains.  starting to get a handle on the admin issues.  I will use this topic for posts/questions.

initial look is that it installs fine and runs fine (will let andy deal with registrations/logins) but admins just cant access the admin panels.  wpmu really dorks with the user meta stuff, but have some ideas.  and also something very similar to Radio's suggestion for the site admin

I think I have the site admin stuff up and running… basically God mode… can see all and do all on all the sub blogs…

okay, got site admins and blog admins working on both front end and back end…  doesnt seem to have broken anything in the non wpmu side either – thats a good thing!

I havent committed my changes though because want to think if there is some other way to do this.  It was a lot of code changes to get it working for wpmu just for the site admin.  everywhere we checked for an spf capability, I had to special case it for the wpmu site admin. 

I want to play with writing our own “user_can” routine that does the work of checking wp and wpmu stuff. 

But what I really want to see if I can easily come up with is a way to just grant any site admin that visits the sub blog all the spf capabilities so no special wpmu checks are needed.  The problem here is that its brute force and will run every page load doing the same thing when its only needed the first time.

Could just query the site admins at install/upgrade and grant them spf capabilities at that time, but any added later wont be set up then unless there is some hook/action I can tie into for site_admin creation (I doubt it).  or maybe at user creation see if it is a site admin and grant at that time.

anyways, a bit more work to optimize and make easier to change stuff later.

oh, speaking of install, its going to be crucial that the sub blog admin be the one to install spf on their blog.  If a site admin does it, they will have to take the extra step of granting spf capabilities to the blog admin.

well, its official. for some reason wpmu completely disregards any new capabilities added for the site admin user.  they have this function call promote_site_admin() which essentially wipes out any capabilities added to the site admin by plugins.  well, they dont wipe it out per se, they simply make him have administrator capability.  they dont wipe it out in the database, simply overwrite it in the current_user global variable.  but, that happens to be where the current_user_can() function gets its info from.

No clue why they would think that is a good idea. well, actually, they are trying to make the site admin have administrator capability on sub blogs, but the blatant disregard of other user defined capabilities is very poor.  they made a poor assumption that administrator capability is enough to see any admin page.  Bad assumption given the ability of the wordpress capabilities.

Seems like any wp plugin that adds new capabilities (why else is the ability there?) and actually relies on them, would have the same issues.  seems wpmu is lagging behind base wp in quite a few areas.

this is going to make the fix a bit more messy, inefficient and bloated.

Don't like the sound of 'messy', 'inefficient' or 'bloated'.!

I would almost prefer to just not support MU.

Isn't an alternative to just say – hey – we are running on  MU, this person has admib rights on MU – let them do whatever they want? I could live with that a lot better…

my fix ended up replacing our calls to current_user_can() to sf_current_user_can() and returning true if the original wp function returns true or if wpmu site admin.

so, it adds maybe half a dozen lines of code, most of which only gets executed if its a site admin.

the only drawback is remembering to use the new function if we need to check capabilities.

OMG… NO MATH! YAY!

sorry I have been away in the hospital again. another heart attack.

I’m glad that you have been able to get MU up and running. Most of the language used here after my last post is a bit above my pay grade, but I believe I understand.

wp functions seem to be ignored/overwiten when current_user == is_site_admin() which is unfortunate, even for doncha. This may have been done to push wp2.6.3 into the the blog portion of wpmu, and may continue when wpmu v2.7 comes out, though I don’t expect that change to come for at least 3-6 months after the release of 2.7 final.

To combat the error with site_admin v. current_user_can(), you have created sf_current_user_can() populated once for that user. Where I am confused is, the data for current_user_can() is stored someplace, (wp_usermeta table?) is the same data stored for sf_current_user_can()? (at wp_x_sfusermeta table?)

although a redundant system is not something that is out of line given the complexity of the issue, when would be a good time to check and update that info to keep the two synced… does the info need to be stored?… can the sf_current_user_can() be a dynamic call, rather than relying on stored SF data, actually checking is_site_admin() and if not, then calling the wp_function current_user_can() and populating the results at run time.

I envision a nested IF statement here

if (function_exists(is_site_admin)) {

if (is_site_admin()) { POPULATE sf_current_user_can(everything) }

} ELSE { POPULATE sf_current_user_can(with wp-current_user_can()) } END IF;

Just thinking out loud… my brick didn’t get a lot of use this past week… 😎

I have not downloaded the current trunk code, I’m actually being patient and waiting for Beta2 (this afternoon?)

all the capabilities, levels, etc are stored in a global variable $current_user.  This is where current_user_can() checks for capabilities.  The wpmu guys tried to get slick and during the population of that $current_user var, the call a routine called promote_site_admin() which REPLACES all the users current capabilities with a single one 'administer'.  I understand the thought, but replacing was bad choice in my mind.  Would have been better if they had just appended that new, additional capability to the end of the existing capabilities.

So, whatI have done for site admins, is re-append the spf capabilities back to the end of the capabilitiies array in $current_user.

Another heart attack??  Sure hope you are doing okay!  take care of yourself!

Sorry to hear that news Paul. It's been a bad year hasn't it?

From what I gather I am surprised at the rather cavalier MU use of the current_user object.. but if that is the way it is we have to live with it I guess.

Beta 2 – Am trying hard for today. I was hoping to sort this niggling login problem if possible first…

I dont think anything has been done in beta2 to address the login issue you first reported (though claimed to have solved)…