I've been trying to come up with a solid plan for moving forward with this file sharing portal for the company I work for.
I already have a skeleton in place that we use for sharing files with product dealers and collaborators, as well as receiving files from those with permission to upload to us. The site works rather well and I have permissions broken down into roles and specific users per file group.
Now what I need to do is take this and make it work for the dealer portals for some of our brands. The permissions already in place allow me to filter files appropriately but the trick here is that the portal MUST look like the parent brand site so that the dealers don't realize they're not on the parent site, which isn't Drupal, anymore.
Some files need to be restricted to only those who have access to them through the dealer portal and others should be available between sites.
So what I'm looking at right now is:
files.domain.com = current default install
dealers.brand1.com = dealer portal for brand 1
dealers.brand2.com = dealer portal for brand 2
dealers.brand1.com will link to dealers.brand1.com and have an identical look, and the same goes for brand2. Both of which will be using the same code base and database as files.domain.com.
dealers1 and dealers2 will be group logins with roles of brand1 and brand2 respectively. There needs to be a login page for dealers.brand1.com and dealers.brand2.com.
My thoughts were to have the dealer portal pages be something like files.domain.com/brand1/file and Rewrite the urls to dealers.brand1.com/file
But I'm not sure that would be possible. I'm thinking after the url was rewritten it wouldn't function.
I stopped after that idea because I had a feeling I was starting the "small problem, big solution" route. I did some searches and haven't found anyone with the same problem but have been similar.
Right now I'm thinking multisite install with sites/default being files.domain.com, then sites/dealers.brand1.com and sites/dealers.brand2.com setup using the same settings.php file from files.domain.com but changing the $conf to set a different theme and site name but leaving the db info the same so it gets all of the rest of the site info for files.domain.com.
I think that's probably the easiest solution, and maybe the proper one, but I'm not sure that is true.
So what I'd like to know is if I'm thinking right or, if that's not going to work, what the right way would be to do this.
To sum up my needs:
1 database with all content, modules, etc (have)
multiple sites with different looks using the database (need)
content access controlled by roles (have)
themes for each site setup to only access content flagged for access by associated role (have/need, 50/50)
I realize that I'll have to make sure each theme filters traffic properly so that there's no bleed over between brand1 and brand2. But before I deal with that problem I gotta get the plan set in stone.
Any ideas?
Comments
Try Organic Groups or Domain Access
I'm not really sure what you meant by this sentence:
dealers.brand1.com will link to dealers.brand1.com and have an identical look, and the same goes for brand2. Both of which will be using the same code base and database as files.domain.com.
Was it a mistake that you said "dealers.brand1.com" and "dealers.brand1.com" will have an identical look?
Either way, since you said you want one database, shared code base, and possibly shared users? I think you should try Organic Groups. It nicely partitions groups and themes.
And if you're dead set on using subdomains, you might want to use Domain Access instead. I would stay away from a Multisite installation here.
Also, I've monkeyed with your idea of rewriting URLs before. You get into ALL kinds of problems, I would stay very far away from doing that, especially if you use Pathauto.
Not sure if that helps, but those are my friendly suggestions.
Sorry about the confusion, I
Sorry about the confusion, I meant to say that www.brand1.com will have a link on the site to dealers.brand1.com.
I'll look into Domain Access. I've been avoiding it mainly because I didn't know if I wanted to dive into figuring it out or not.