Bill Murray said:

“As it is now, a admin from another blog on the network can edit the paths to the main blogs forum install and use or modify whatever is there.”
I’m not sure that’s the case.  An admin from Blog A is only editing the SPF settings for Blog A.  Unless that person is also an admin on the main blog and logs into the main blog, the settings are completely independent.

Still a misunderstanding I think. I’m not talking about blog.2’s forum being able to edit options on blog.1’s forum.

I’m saying that blog.2’s forum can set the storage locations path to blog.1’s forum storage locations. Then in the backend of blog.2’s forum, the admin can delete any or all smilies, badges, avatars, icon etc, that are in blog.1’s storage location. And the SP backend will happily do it without complaint. Of course these files can be uploaded as well. Imagine your surprise if your wholesome forum icons where replaced with something XXX?

I do believe there should be global options for the Super Admin. I don’t really see any way around it. Even if it has to be a flat file that is read to save a database call.

I believe those options should also cover plugins that the Super Admin would like to allow sub blog forums to use. The plugins that are currently for SP v5 were actually part of the core of all versions of SP before v5. And personally I don’t know how anyone can run a great forum without at least a handful of them.

You have a valid point on how most Super Admin’s won’t allow sub blogs access to themes and plugins. But this is not a rule either. I do allow sub blog admins to use alternate themes and plugins from a pool. They just can’t add (literally) additional ones. All plugins and themes I introduce have been gone through with a fine toothed comb by me. I strip out the scary stuff or edit as I feel fit.

I wasn’t petitioning for sub blog forum admins to have write access either, but as things are right now, unless I hand place the theme or plugin files in their storage location folders (ain’t gonna happen), they would have a bare bones forum unless they had the ability to move files there themselves (again, ain’t gonna happen).

@ Mr Papa, new install.  I updated the code, created a new site, activated the plugin on that site, and then continued on.  I figured I’d mention the SVN documentation thing because keeping that updated provides a strong foundation for doing the documentation for the ultimate release.

@ Lee H,

“I’m saying that blog.2’s forum can set the storage locations path to blog.1’s forum storage locations. Then in the backend of blog.2’s forum, the admin can delete any or all smilies, badges, avatars, icon etc, that are in blog.1’s storage location. And the SP backend will happily do it without complaint. Of course these files can be uploaded as well. Imagine your surprise if your wholesome forum icons where replaced with something XXX?”

Ok, light dawns on my marble head, and I see your point, which might be valid.  I tested and I could change Blog 2’s custom badges folder to that of Blog 3, and then proceed to do what you suggested but I was logged in as a network admin.  Then I tried creating a site admin for Blog 2 and could still change locations to Blog 3.

SPF reported that I had write access to Blog 3 folders while on the backend of Blog 2.  Is SPF’s write access test faulty?  Or is this a multisite issue where multisite isn’t controlling write access in blogs.dir?  I’ll do some more investigating on the WP side and see what I can find. 

One workaround could be for SPF to check if the install is multisite, and if so, only let a blogs.dir folder location be saved if it contains the current blog ID.

Interestingly, when I went to add a new site admin, I got this error:

Warning: Cannot modify header information – headers already sent by (output started at /problem-with-post-edit-buttonome/qbg/qbgarage.com/wp-content/plugins/simple-press/sp-api/sp-api-primitives.php:763) in /problem-with-post-edit-buttonome/qbg/qbgarage.com/wp-includes/pluggable.php on line 934

The user was created, however.  Hopefully, the SPF team catches that.

I may not have communicated effectively on the issue of access to themes and plugins.  Network admins do exactly what you do because that is the way multisite works.  I was referring to the creation of new blogs rather than new themes or plugins.  There are web services offering the ability to create for a new user to create a site, much like wordpress.com.  I don’t see these services as a big target initially, because I think most multisite installs are where the network admins create the sites themselves.

I raised this question on the WP multisite forums and got 2 replies from well-known multisite gurus.

Basically, on multisite, SPF should either a) not allow the folder locations to be edited or b) change the base from /wp-content/ to just /files/ (WP will then use /wp-content/blogs.dir/3/files/ for blog ID 3) or perform some other validation that prevents a user from entering a path to a blogs.dir folder over which he doesn’t have control.

I think #3 is the hardest to achieve and the most vulnerable (because someone might find a way around the validation routine). 

I’m not sure I see the need for these locations to be managed on multisite, but if there is a desire to allow people to manage them, I think #2 is a secure choice.  #2 insures that any file is in a folder for that blog ID.  It’s clean and simple.

Hope that helps.

reasons like this are exactly why we plan to tighten up the integration in 5.1… SP was never really designed to work with multisite but folks have had success with some limitations…

Nothing has changed in 5.0 in regards to how the blogs.dir directories are handled…

Did you see this error in my previous post?

Warning: Cannot modify header information – headers already sent by (output started at /problem-with-post-edit-buttonome/qbg/qbgarage.com/wp-content/plugins/simple-press/sp-api/sp-api-primitives.php:763) in /problem-with-post-edit-buttonome/qbg/qbgarage.com/wp-includes/pluggable.php on line 934

nope, missed it… will log a ticket…

can you explain a bit further the steps you did?  a quick try and I didnt get the error, but not sure I did what you did…

I was logged in as a network admin for a site on multisite.  I wondered if the fact that SPF was showing I had write permissions to the folder of another site was because I was logged in as a network rather than a site admin.

So I was adding a new user (Users->Add New).  I entered a username and email and set the role to administrator.  I also checked the box to skip the confirmation email.  Then I clicked the Add New User button.  That’s when the error appeared.  As I said in a previous post, the user was created even though the error was displayed.

so… just to verify…

you logged in as the super admin (ie network administrator)…  went to a network site…  and in that network site dashboard, tried adding a user with the details you specified?  correct?

I dont seem to get an error message doing that…

is it repeatable for you?  do you have any other plugins that could be conflicting?

Yes, your list of my steps is correct.  It is repeatable.  I just grabbed the latest code and re-ran the same test, and the error occurs.  One note: the error only occurs if WP will actually create the user.  If I attempt to re-use an email address, so that WP won’t create the user, I don’t see the PHP error. And despite the error, WP does create the user.

Other than SPF, I only have 5 plugins on the test site, all network activated: Akismet, Bad Behavior, Google Analytics for WordPress, Google XML Sitemaps, and Ozh’ Admin Drop Down Menu.

is this a test site? none of those should be an issue, but wondering if you can try disabling them and trying again?

I will try some variations tomorrow to see if I can duplicate…

I network deactivated all of them, so that my only active plugin was SPF, tested, and still got the error.  As a further test, I also switched themes, from the WP Twenty Eleven to the standard Genesis child theme, and got the same error, so I don’t think it is plugin or theme related.

On an unrelated note, the WP admin bar shows up for me at the top of this forum, but all of the links I tried take me the forum home page, so I can’t turn off displaying the admin bar.  Is there a way for me to do that or can you do it for me?

lol.  good point…  users are blocked from our admin…  and of course, wp has made the only direct way to disable a user’s wp admin bar is in their profile…  guess we can add a plugin to globally disable it since Andy and I dont use it…

Mr Papa said:

lol.  good point…  users are blocked from our admin…  and of course, wp has made the only direct way to disable a user’s wp admin bar is in their profile…  guess we can add a plugin to globally disable it since Andy and I dont use it…

Yeay! Stupid bar… GONE! Didn’t know how to properly bitch about that one.

very simple plugin to remove for all… since they cant get to admin anyways, might as well remove…

Bill Murray… havent forgotten about you… still cant seem to replicate the error message…  still trying… might be on back burner for day or two as we try to get 5.0 live on our site tomorrow…  but will revisit…