Thank you for responding.
Actually I’m trying to simplify things. Apart from the navigation which isn’t a big issue and is easily handled with about 10 lines of PHP code, there’s still other issues to consider such as the “blog roll”.
The blog roll for the public section will be different than the blog roll for the members section. Though I can control the visibility of posts so that non-members don’t see certain content, there will be content in the public area that the members won’t care about and should be hidden in the members area. Of course some more PHP code and maybe custom fields or categories could filter these.
The public area most likely will use plugins that the member site wouldn’t need. And obviously, the member site will have S2Member, BuddyPress, etc which the public side doesn’t need. So I see a lot of unnecessary overhead on both sides of this.
The public side needs to be indexed in the search engines. The member side won’t be visible to the search engines. Heck, I’d love to just hide the membership side altogether (maybe avoid a few hackers).
I may not want an employee that works on the public side messing around with S2Member, the forum, etc.
Down the road, I may have to take down the member side for some major upgrade but would want to keep the public side up and running (and vise versa).
No matter how you stack it I’ll be conceptually maintaining two sides of this thing – public and member. I was just wondering if splitting the two entities would reduce system load, add flexibility, and keep things a bit cleaner.
Though I’ve been a software developer for 25 years, this is my first membership site. And of course I’m new to S2Member. So I’m definitely open to suggestions.
Bruce,