I'm working on a project to allow a number of mini-sites within a WordPress multisite installation. Here's how it's supposed to function:
The client has a large number of individual locations, each of which has their own website. All of these websites are sites within a large WordPress network to allow for centralized user and site maintenance. This part is working already.
But each location has any number of clients and wants each client to have their own "mini-site" within the network. Essentially a new WordPress site, but housed underneath the location's site, URL, and administrator list.
Users of the mini-site should only be able to use that mini-site, not the parent site, and not any other site on the network.
As I've been working on this, I've come across two different ways to set this up. Both are somewhat complex:
WordPress allows you to install several standalone networks with one codebase. It's like multisite, but on steroids. My first attempt at solving the above problem was to bury a bunch of multi-network functionality in the system. When you added a new client mini-site, you were actually adding a new site to a network "owned" by the parent site.
This half-worked. You could create the sites just fine, but without deeper control over the server (my client asked for a plugin, something they can drop on the server without needing to give me SSH access) it was difficult to get the routing to work in Apache. Some of the new mini-sites would load, others would 404, others would redirect back to the parent site.
The other problem was management. Though you could create as many mini-sites as you wanted (and could verify through phpMyAdmin that they existed), I had difficulty reading back out a list of the sites that were available.
The other problem was database management. Every time you create a new site, you create 10+ new tables in the database. If the site will only ever have 1 or 2 posts/pages, this is overkill.
Custom Post Type with Theme Override
My new approach is to set up the clients as a custom post type. Then, users of the parent site can write new posts and check a field in a meta box to associate the content with a client (using a post-to-post relationship scheme).
When you visit the page for the custom post type, WordPress overrides the display and presents a custom theme (a mod of P2) displaying posts associated with the custom post type.
Not as many problems with scalability here, just in content management. I haven't quite figured out a way to allow filtering of content from one client to another (remember, content is associated with a CPT based on a meta field, so unless I build out another post management screen, it's hard to view "all posts for client-x").
My question: Which of these approaches is the best? Is there another approach I should consider that might be easier for the end user to work with?