Membership simplification approach

Hey Folks:

I was just wondering your thoughts on Membership Site simplification/best practice on this...

Is it a good idea to just have the following for either a subdomain or subfolder (does not matter which):

...Say there is 4 Levels of Membership for the sake of argument...

1. Subscriber Free (all access to the main domain):

2. Level 1 Paid Subscriber (all access everything above plus or Here is the part of the "simplification" for each level (hopefully if I am understanding it right)...just lock down and require Level 1 Paid Subscribers (or higher if applicable) ONLY to see anything at all that is "behind" every single piece of information after the path or

2. Same idea with Level 2 Paid Subscriber

3. Same idea with Level 3 Paid Subscriber

...this way there is no need to be picking and choosing all over the site what is protected and what is not...pretty straight forward in my mind (I hope)...

I know there is several ways to approach but I really want to adopt a minimalist approach.

So, am I thinking correctly with this method?

All input very welcomed!!!

P.S. The subdomain or subfolder could be the same theme or totally separate themes to give the section and different look and feel (or not) and also the subdomain or subfolder could, additionally, be domain name mapped to actually be a totally separate domain name than #1 above (the hub or core site) if that is expected and told to the subscriber upfront for whatever reason.

Thanks guys/gals!



  • Jack Kitterhing
    • Code Norris

    Hi there Greg,

    I hope you are well today and thank you for your question.

    I think that this would work well, but only on a multisite basis with global tables defined.

    This would mean that the logins and access levels would be shared between each sub site.

    So you'd have, etc, Is that what you was going to do a multisite, or did you want to keep them completely separate?

    Thank you!

    Kind Regards

  • Greg
    • The Exporter

    Hey @Jack:

    Well..."yes" and "no".

    I am using multisite.

    But, I was wanting to have the core or primary site to have it's own membership area and levels. So, in that sense, yes.

    However, having a multisite and wanting to keep as much as possible in the multisite enviroment to manage every easily I want to additionally the following:

    ---Instance 1>>Have other multiple sites that I will use domain mapping. They will have their own independent domain names and totally and completely separate businesses (unrelated to the core or primary site) as well. I would also consider having Membership sites in the same exact way as the core or primary site above too.In this instance, these will be my own sites (not others).


    ---Instance 2>>I would also like to have the ability to create other (additional) domain mapped sites that will be fore other folks websites who them "may" also have the option to add there own Membership levels too like the core or primary site). I would do this when I feel client would not need or want CPanel access or control of the domain DNS etc.

    So, I can not (of course) have members from the core/primary site access domain mapped sites in Instance 1 or Instance 2 sites and subscribers should not be the same across domain mapped sites that are completely separate.

    How does that work? That seems like it would defeat the purpose and reason for having a multisite installation. I know it is single database in multisite but I thought the users/subscribers etc were separated by tables etc so they are isolated from one intended separate site to another? How should I tackle? Will it still be feasible?

    Also, if I ever need to peel off one of my own domain mapped sites or a client domain mapped sites in the above setup can it be done easily (do you have links explaining)...

    That being said, whenever I feel a client would need access to a Cpanel (or similar) and domain DNS, then I would just to do development in a single installation and be done with it. But a lot of folks just want the basics and don't care about (or even want to deal with that stuff)...hence the above approach to keep most in the multisite domain mapped environment (isn't that how edublogs does it too)?

    Thanks a bunch for your insight...all the info you can supply on this is much appreciated!

    Another alternative was having:
    1. One Multisite Installation for a core/hub site and many other domain mapped sites for separate businesses that I run directly (some may or may not have membership level needs).

    2. One Multisite Installation for a core/hub site to promote (for example hosting/design) and have many other domain mapped sites that would be separate clients with their own businesses (some may or may not have membership level needs).

    3. Then, clients with CPanel and DNS control needs I would install single WP installations (not multisite) and design/develop/build one off sites.

    I am sure I am missing is late where I am...2:30 AM EST in the

    Thanks a lot @Jack...I really have to get a solid handle on it as far as the best approach for me (I am sure there are several way to look at it)...I am after simplicity and a minimalist type of approach where I can produce and scale quickly and efficiently without a lot of headaches and hassle so the foundation has to be right for me on this ya!

    hehehe...I am sure you have gotten this a lot around here...

    I have been through some of the tutorial but need a really good practical path.


  • Jack Kitterhing
    • Code Norris

    Hi there @Greg

    I hope you are well today and sorry about the extreme delay here.

    Thanks for the additional information.

    Out of the box even when networked activated on a multisite install, membership will work on a per site basis.

    So each site would have it's own members, contents, and protected pages, which is what you need correct?

    Alternatively, you can active global tables in membership to allow the plugin to work on a network basis.

    This means that membership would work across all sites and you'd control access to the sites on a overall basis, i.e, content and members are protected on a global basis.

    It wouldn't be possible to domain map without giving your client access to DNS, as for the registered domain they'd need to add a A record, though you could use the inbuilt enom domain reseller included in the new domain mapping :slight_smile:

    So personally, I'd go with the multisite > domain mapping with enom reseller with membership network activated but not on a global table basis.

    Thank you!

    Kind Regards

  • Greg
    • The Exporter

    Hi @Jack

    Thanks for the follow up. Ok, if I did do:

    "So personally, I'd go with the multisite > domain mapping with enom reseller with membership network activated but not on a global table basis.", what steps would need to be taken in order to (if ever needed) peel off/move a website along with its database to another host or location later? Can that be done and relatively easily if I create a website for a client using multisite with domain mapping initially(as a example) and need to move it later to another host...OR, if a website of mine needs to be moved for whatever reason to a separate host etc?


  • Jack Kitterhing
    • Code Norris

    Hi there Greg,

    I hope you are well today.

    If you want to move it (the website), you'd have to export your database, would you be moving domains or would you just be moving hosts?

    If your moving domains, you need to run a find and a replace and replace the serialized values, using a script like this :slight_smile:

    Thank you!

    Kind Regards

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.