latest stable versions: v150827 (changelog)

Old Forums (READ-ONLY): The community now lives at WP Sharks™. If you have an s2Member® Pro question, please use our new Support System.

Questions about Multisite Installation Setup

Home Forums Community Forum Questions about Multisite Installation Setup

Tagged: ,

This topic contains 7 replies, has 4 voices. Last updated by  Raam Dev 4 years, 3 months ago.

Topic Author Topic
Posted: Thursday Aug 30th, 2012 at 11:37 pm #23631

Hi there,

I’ve been reading some of your documentation and watching videos but there’s something I’m still unclear about regarding a multisite setup. I’m not sure if I should do a regular or a blog farm install.

What I need to do:

This site/network will offer customers monthly paid subscriptions where each customer would get one site of their own. Customers will never need the ability to create more blogs/sites themselves (and we don’t want them to) but, after registration, a new site needs to be created for them. Ideally, new sites would be created automatically after a successful payment.

There will not be multiple levels of access, just one level which gives them acces to their own site, the main site (blog 1) and another “Support” site which will be accessible to all paying customers. The main site will have some documentation on the service my client offers and other protected content. Besides the front page which will have some introductory text and a login form, the main site will contain only protected/non-public pages only accessible to paying users (and network admins of course). On the “Support” site, customers will be able to post tickets and access a knowledgebase (I’ll be using WooThemes’ SupportPress app theme on that site).

Both the main site’s content and the Support site will be accessible to all paying customers. The support site will be entirely protected too with no public content besides a login form if users access it directly without being connected. On either the main or support site, users will not be able to create any content other than posting tickets on the support site (Supportpress needs users to be part of a specific role to do so but I assume I can modify roles with s2Members or Justin Tadlock’s Members plugin to do that?)

On their own site, customers will be able to create pages and posts (and some custom post types) but, other than that, their access will be quite limited (they shouldn’t be real admins on their own site and should not be able to install or modify plugins, themes of modify the site in any way other than adding content (media, pages, posts, custom posts).

So I think that’s the gist of it. I’d appreciate any pointers about how to go with this but, most importantly for now, I need to know if I should setup s2Member as a blog farm in the Multisite Configuration page or not (I’m leaning on no but would like a solid answer ;). After that I’ll probably be able to figure a lot on my own but may have to ask your help again :)

Thank you!

List Of Topic Replies

Viewing 7 replies - 1 through 7 (of 7 total)
Author Replies
Author Replies
Posted: Friday Aug 31st, 2012 at 7:22 pm #23752
Raam Dev
Username: Raam
Staff Member

Hi Stéphane,

You said,

On their own site, customers will be able to create pages and posts (and some custom post types) but, other than that, their access will be quite limited (they shouldn’t be real admins on their own site and should not be able to install or modify plugins, themes of modify the site in any way other than adding content (media, pages, posts, custom posts).

Please see this description from the bottom of the prices page:

If you operate a WordPress® Multisite Network, and your Network DOES make it possible for users/members to create child blogs or sub-sites (in any way), we consider your installation to be a Multisite Blog Farm. Please note, many site owners run a Multisite Network for the purpose of maintaining their OWN child blogs or sub-sites. The term Multisite Blog Farm does NOT apply to a Network that hosts multiple child blogs or sub-sites, all of which are operated by a single site owner. A Multisite Blog Farm (in the eyes of s2Member®), is a Network that makes it possible for its users/members to create child blogs or sub-sites; where one or more of these child blogs or sub-sites is administered by a user/member (e.g. if you offer blogs or sub-sites to your customers, for free or otherwise).

Also, after creating your Multisite network, please navigate to Dashboard -› s2Member® -› Multisite (Config) -> Multisite Registration Configuration. You will see lots of documentation in there, including an option that asks “What Do You Plan to Offer?” .

Posted: Saturday Sep 1st, 2012 at 1:04 am #23759

Hi Raam,

Well, I’m thinking my situation is not a blog farm as, no one but admins (me) or some kind of automated system linked to payment hooks will be able to create sites on the network. Users will basically buy access to a site we’ll create or the system will create for them. At first and until the service gains traction, blog/site creation will be manual and done by me of another network admin. I’m pretty sure that falls outside your definition of a blog farm right?

Thanks!

Posted: Saturday Sep 1st, 2012 at 7:11 am #23765

Hi Stéphane.

Stéphane Bergeron said:
At first and until the service gains traction, blog/site creation will be manual and done by me of another network admin. I’m pretty sure that falls outside your definition of a blog farm right?

No, that’d still be a blog farm, because the users get a blog in the network and are the administrators.

where one or more of these child blogs or sub-sites is administered by a user/member (e.g. if you offer blogs or sub-sites to your customers, for free or otherwise).

I’m emailing Jason to confirm, though. :)

Posted: Friday Sep 7th, 2012 at 1:37 am #24462

Thank you Cristián!

To me these users would not technically be admins as they won’t be do anything besides create posts. They won’t have access to themes or plugins or even page creation. But if this is a blog farm to you then I’ll get the client to pay for the price difference between the Unlimited-Site License I got and the Network Support License.

Now as for installation, should I activate the plugin network-wide? The main site will be the only one accepting registration and payments. On the other sites, I only need to control login access to the backend. Any pointers on how best to proceed?

Thank you very much again!

Posted: Sunday Sep 9th, 2012 at 7:18 pm #24702
Staff Member

Thanks for the heads up on this thread.

Yes, the scenario you’ve described would still be considered a blog farm (in the eyes of s2Member), because members of the Main Site, will in one way or another, have access to a blog of their own within your Network.

Now as for installation, should I activate the plugin network-wide? The main site will be the only one accepting registration and payments. On the other sites, I only need to control login access to the backend. Any pointers on how best to proceed?

There’s no need to activate s2Member Network-wide in this case. Simply activate s2Member on the Main Site of your Network, and then allow each member to register/pay for access to their account on the Main Site. From the Main Site (once they’ve logged in), you can provide members with a link to /wp-signup.php on the Main Site, where they can create as many blogs as you might allow them to. If you’re going to handle this manually, simply tell s2Member that all Membership Levels are allowed to create 0 blogs. This way members can’t create their own blogs, only the Super Administrator could accomplish that, via access to the Network Administration menu in WP.

Posted: Tuesday Sep 11th, 2012 at 11:44 pm #24961

Thank you very much for responding Jason.

Moving beyond licensing, if you don’t mind, I have just a couple more questions for you about the best way to install and run s2Member on this network for our need. So here’s a few more clarifications on our use case then a couple questions :

I thought that it would be necessary to activate s2Member network wide in order for it to control access to the sites so that only paying members can get in. We’d want to automate as much of that as possible like, for example, if a recurring membership lapses for payment failure for example, I’d want s2Member to prevent access to the protected pay areas of not only the main site but a second support site as well as a member’s private site.

The main site will not only have the s2Member signup forms and payment process but also documentation pages as well as pages with links to special offers to purchase equipment at 3rd party vendors and all that content needs to only be accessible to paying customers (with memberships in good standing… the service is based on recurring monthly payments). There would also be a second “support” site that all paying customers need to be able to access that will be used to provide a ticketing system, a knowledgebase and a private blog (this is powered by WooThemes’ SupportPress application theme). That site will be completely closed to public visitors.

If we could prevent ourselves from having to manually turn access to the main and support site on or off depending if a customer’s account is paid or if it’s unpaid or they cancel it would be great. Same with their private site once it’s created by an admin.

I though we’d have to activate s2Member network-wide to be able to do this. Is that the case?

When s2Member is installed network-wide, is it “network aware” in that, even if payment is processed only on the main site, is the user account’s status (paid/unpaid/cancelled) available to other sites on the network so access can be controlled?

If you could point me to specific documentation about these things I’d really appreciate it. Once I have a better grasp of these issues I can move forward with the project.

What we really do not need in our case is give the ability to any paid customer to create any site. That is not the nature of the the business or the service the site’s offering.

Thank you very much for your help!

  • This reply was modified 4 years, 3 months ago by  Stéphane Bergeron. Reason: Typos & other corrections
Posted: Thursday Sep 13th, 2012 at 12:29 am #25103
Raam Dev
Username: Raam
Staff Member

When s2Member is installed network-wide, is it “network aware” in that, even if payment is processed only on the main site, is the user account’s status (paid/unpaid/cancelled) available to other sites on the network so access can be controlled?

No. While s2Member is compatible with WordPress Multisite Networking, the sites within a WordPress network are separate and not interconnected. That means you cannot share users, logins, or other data across the sites (including access control).

Please see the following from WordPress.org:

The sites in a multisite network are separate, very like the separate blogs at WordPress.com. They are not interconnected like things in other kinds of networks (even though plugins can create various kinds of interconnections between the sites). If you plan on creating sites that are strongly interconnected, that share data, or share users, then a multisite network might not be the best solution.

The s2Member Multisite feature allows you to offer the s2Member plugin to sub-sites, giving your sub-sites the ability to setup and use s2Member on their own. When you upgrade s2Member on the primary site, the s2Member plugin is automatically updated for all your sub-sites. However, things like access restrictions on one WP installation are not shared across WP installations (again, the WordPress Multisite feature itself isn’t designed to work like that).

There are plugins that allow you to get around these WordPress Multisite limitations, however they may or may not work with s2Member.

Viewing 7 replies - 1 through 7 (of 7 total)

This topic is closed to new replies. Topics with no replies for 2 weeks are closed automatically.

Old Forums (READ-ONLY): The community now lives at WP Sharks™. If you have an s2Member® Pro question, please use our new Support System.

Contacting s2Member: Please use our Support Center for bug reports, pre-sale questions & technical assistance.