the SVN instructions you referred to were really geared towards standard wp and didnt really take multisite into account…

you really should use the forum-plugins and forum-themes created under the blogs.dir so it can be unique to each network site… that said, I doubt your network site admins will have access to the blogs.dir folders to actually upload themes and plugins…

you could centralize them to one fixed location, but the network site admins would be able to change the location in the sp admin, but again, probably couldnt upload to it…

this falls into the category of the tighter integration into multisite (and buddypress) that we have planned for the future…  site wide options, users, and more…  SP was never really designed to work with multisite, but we have managed to keep it working even though there are limitations…

one of the biggest issues is that Andy and I have never really used multisite… I have one test site, but recently trashed that and have loathed trying to install multisite again since its a manual process…

Bill hit the same questions that I was wondering, but didn’t ask yet as I knew you haven’t really begun with multisite in this stage of SPv5.

It’s a can of worms for sure. I’m certain I won’t be allowing admins of sub blogs of my network write access.

I figured once the dust settled that I would see what we have to work with and write a plugin (if possible) for my site that would allow new forums for sub blogs to use the same template and plugin pool (possibly not all), but disable the editor.

tighter integration with multisite and buddypress are the two main items planned for 5.1 currently…

Well, the setup I described seems to work.  When I have more time, I can try creating another test site and activating a different set of plugins.  If SPF is storing the settings on activated plugins in tables for each blog, the code can be centralized. 

I think before you get to site-wide options, it’s just a matter of changing the install routine so that common resources are under wp-content, and blog-specific stuff is under blogs.dir/#/files/sp-resources.

In multisite, I’m not sure I understand what you mean by “network site admins would be able to change the location in the sp admin….”  Network admins can install new plugins.  Site admins can activate and configure them.  There’s no configuration at the network level, since configuration is stored site-by-site.  Site admins can’t install plugins (unless they have FTP access), so there would be no easy way for a site admin to put PHP files in blogs.dir.  For that reason, I think the centralized location makes the most sense, since it is consistent with multisite right now.

I have a number of working multisite installs, so if you need me to try something, just let me know.  Once I have setup another test blog + forum from centralized plugins and themes, I’ll let you know.

the active plugins and theme are stored in each database on each network site…  and one of my points is that there is NO global option or setup… every option and setting is specific to each site the forum is installed on… 

so when each network site installs the forum, it will auto point the configuration stuff to point to blogs.dir… if you centralize it, each network site admin (or you as super admin) will manually have to go in and point the configuration to your centralized location…

But I can open a ticket for 5.0 to look at changing the current install to use a centralized location for plugins and themes for multisite…  I think I agree that would be best…

@ Mr Papa, “the active plugins and theme are stored in each database on each network site…  and one of my points is that there is NO global option or setup… every option and setting is specific to each site the forum is installed on… “

That’s pretty much the way every plugin works on multisite – no global options.  For example, if you install Akismet on a network, you have to configure it on each site or blog.  Even if you network activate it, you still have to configure it site-by-site.  But there is just 1 copy of the Akismet code installed on the network, and only 1 copy is updated. 

The same is true for themes (though there are plugins that change this somewhat).  If I have the Twenty Eleven theme with a certain stylesheet installed on my network, every site on the network with that theme will draw from the same code base and same stylesheet. 

The way SPF is set up at the moment, there would be X copies of a theme for X sites on a network.  While that offers a lot of flexibility, it is a maintenance nightmare. 

Also keep in mind that only network admins can install plugins or themes in multisite, so a site admin won’t have the ability to install in blogs.dir even if he wanted to do that (again, ignoring FTP access).

@ Lee H, I’m not sure what you mean by allowing site admins write access.  Unless the site admins have FTP access, they can only do admin tasks on their individual sites, which means they could change the SPF settings only for the sites for which they are admins.  I found a little more time, and if you follow the SVN instructions and load the plugins and themes in a central location, update the locations site-by-site, SPF handles multisite just fine.  I haven’t found something that doesn’t work yet.

I disagree on no global options…  For example, if there are no global options, like now, then the super admin has no say in whether users can say upload avatars…  in the future, we need some global options that can be applied to all network site installs of simple:press…  same applies to file uploads…  I can certainly seem some super admins wanting to disable file uploading on the network sites…

anyways, I have committed some changes to the install/upgrade to segment the stuff the user has no chance to upload things to… this would be plugins, themes and languages…  these will be in wp-content by default… for things we provide an uploader, such as smileys and avatars, the storage location remains in the blogs.dir area because it needs to be site specific…

I have tested with multisite install only…  I dont have any multisites from 4.4.x that I can try an upgrade on…

I would appreciate if Bill Murray and Lee could give the new installer/upgrader a run and see if it works for yall too…

Mr Papa said:

I would appreciate if Bill Murray and Lee could give the new installer/upgrader a run and see if it works for yall too…

Hmmmm…  It’ll take some doing. But I’ll see what I can do 🙂

@Bill…

What I meant about write access to admins. Currently it appears that any networked blogs would need write access to add new or any additional themes/plugins to their selection.

If the storage locations pointed to a common pool of themes, plugins, language files etc it could work.

Whatever the case… the theme editor freaks me out completely. Letting someone you probably don’t know personally have free reign to place any kind of code on your server is like handing them a bunch of loaded guns. I’m not even comfortable with them having the ability to edit storage location paths. 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.

But…  I know none of this is written in stone, and this is pretty much the first discussion (that I know of) on the topic outside of Steve and Andy.

oh, lots of discussion to occur on this when we begin…

but I agree Lee… think there will be some sort of global options enabling or disabling features and options on the individual network sites…

but not sure what you mean… an admin on network site 2 shouldnt be able to edit options on network site 3, unless you gave them access… unless they are a super admin, they only have access to their site options…

Not sure I said they could edit options on other sites, sorry if I implied that.

But by changing paths couldn’t they overwrite images, or use the template editor to modify any theme as long as they knew what blogs.dir to enter?

I can make a new forum on a blog, logged in as the proper admin for the blog (not super). The default storage locations are blogs.dir according to blog number. There is one theme, default. I can modify the themes path to the main install and use whatever themes are there and modify them.

@ Mr Papa, I tested the latest installation changes on a new site under 1 of my networks, and it works perfectly.

However, it creates 3 folders under sp-resources, which is fine, but this isn’t consistent with the description for the SVN setup, so I’d just modify that description. 

After installing a new site, I went back and edited the locations of my existing site, and it works fine.

I have to think more about your comments on “global options” before I can comment intelligently.  There aren’t a lot of WP plugins that have global options (I can think of just 1 off the top of my head, NextGen Gallery).  As for feature control of things like file uploading, if that is in a plugin, and a network admin doesn’t want to allow that, he can not install or delete that plugin.  I see your point about network admins wanting to control how site admins configure SPF, but I think those are features that only impact networks where users can create their own sites.  Most of the multisite installs I see are where the network admin is controlling the site setups, where that concern is a non-issue.  I think you’d be best served to devote resources to have SPF first work with multisite the way most plugins do, and then tackle the global settings issue.

@ Lee H, you wrote:

“What I meant about write access to admins. Currently it appears that any networked blogs would need write access to add new or any additional themes/plugins to their selection.”

Sites cannot add themes or plugins in a standard multisite install, and I’d recommend that they not be allowed to add SPF themes or plugins as that is not consistent with the way multisite works.  Network admins can only perform these functions.  Adding a new plugin is separate from activating, so a site admin could activate any 1 of the installed plugins.

“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.  I haven’t tested every element of that, but I have made changes to the settings on 2 forums on 2 sites of the same multisite installation, and the settings are independent.  That is just the way multisite works with just about every plugin out there. 

@ Lee H, the template editor is an issue.  In a normal multisite install, a site can’t edit templates from the WP back end, so I’d say this should be turned off when SPF is installed in multisite if SPF has a template editor.

If there is no template editor, the only way a site admin could reach the templates or plugins would be via http://FTP.  Site admins could change their site settings at will, but they’d only be impacting a single site on the network.

Bill Murray thanks for the feedback on the new installation… was this fresh install or an upgrade from 4.4.x?

yeah, the svn instructions and other pinned topics were really for the group of folks that jumped in at the start of the alpha back in July. wouldnt hurt to bring them back up to date…