How to set up a "mother site" application so the code is only in one place?

chatmasta

New member
Jan 7, 2007
2,613
68
0
NYC
Hey,

I am developing an application for restaurants to build their own website (similar to LetsEat.at | The Free Restaurant Website Builder). The websites will be pretty cookie cutter, and all restaurant-specific data will be stored in one database. Each restaurant will have its own domain and be hosted on my server. My question is this:

What is the best way to set everything up (domains, file system, templating) so that the main application code is only in one place on the main server? The only differentiation between restaurants will be layout and data.

Hopefully you understand what I am asking - I am really struggling with this.

Thanks,
Miles
 


Put the codebase 1 level above the webroot, then have the individual sites use an include or require(server path) for that folder.

For the database, you could follow the wordpress model and use a unique table prefix for each site, keeping them all in the same database but if there are gonna be a lot of sites, this method may not be practical.
 
  • Like
Reactions: chatmasta
Hmm that is pretty simple, I like it. So creating a new site is just a matter of uploading the template files and a config file to a folder.

Anyone else have ways of doing this?
 
I've done it. Have a domains table in your db, and in all other tables, have a column for domain id. On each request, parse out the requested root domain, look that up in the domains table, then scope your queries according to the domain id as well.

As for templates, you can extrapolate all of that into a database as well with some creative thinking. If it's simple css differences, create different stylesheets, upload them into a style folder, then populate a settings drop down for each restaurant site that allows you to select the appropriate stylesheet. If you want to get really fancy, make it so you can edit the stylesheet in the backend.

If you plan things out well in the beginning, you shouldn't ever have to touch the database once the system is live. I have a setup where I can launch a whole new site in under a minute using the system I just wrote out.
 

This. Don't bother setting up a new set of files for every site, that will get old really fast. Have all customer domains point to a single app, and then show a specific site depending on the domain of the request coming in. Will make it a lot easier to automate this way as well.
 
I would run seperate mysqls for each site, but that is me. I like failsafes.

There are several ways to do Wordpress like this. I think you could take the code from one of those Wordpress master installs and wrap it around your app.
 
I would run seperate mysqls for each site, but that is me. I like failsafes.
Yah, ok, but if any of your mysql installs are failing regularly enough for this to be a concern, [insert doing-it-wrong.jpg here]

I agree with what everyone else said re: domain table. The complexity of what you want to do differently on each site will determine how you want to setup the layouts -- As some have mentioned, if the page content and types of pages are often the same, most the design changes from site to site can be done with clever CSS and a little inginuity. If you're trying to do unique modules or stuff that requires "code logic" for sites (e.g. SpecialtyPizzas.php only on BobsPizza.com+JanesPizza.com and not on WomensUnderwear.com), save yourself some time and find a good templating engine, learn template inheritance for that engine, and abuse the crap out of it. You'll thank me later. If you're coding in python, I recommend the excellent Jinja library for that, but if you're stuck with PHP, you're stuck with Smarty, which sucks, or one of the many imitators, which suck even harder (TBH I don't use templating very often in PHP, because the libraries are so bad. So really, this is just another plug for python, sponsored in part by the Python Fanbois Club. Python -- it's a mother fucking snake.)
 
I do have this "mothersite" setup sharing codebase and databases off a certain CMS.

One thing that bothers me about this though is this sort of setup makes the sites less "flippable". If you want to sell a site and have no easy way to rip it out, package it up and ship it off, you are screwed even if someone is willing to pay to get it off your hands!

Have any of you had experience flipping sites and running into the problem of packaging and transferring them?
 
I do pretty much what you do for some portal sites,

I use a few tables in the db to store configs for each domain, and use php to detect the domain and then the rest follows from there, it's really very easy once you start making use of includes functions and classes. I can now launch a new portal site in under an hour, and to the end user it looks pretty customised. I aim to literally have 1000s of portals running off this.


Have any of you had experience flipping sites and running into the problem of packaging and transferring them?

This is a problem I have pondered on, so I literally have coded with that in mind, and the admin interface uses one simple function to determine the site its working on, so if i did decide to break one off wether it be to sell or host else where, i can simply just copy the db and scripts, and change that function to work with the sole domain :)
 
I do have this "mothersite" setup sharing codebase and databases off a certain CMS.

One thing that bothers me about this though is this sort of setup makes the sites less "flippable". If you want to sell a site and have no easy way to rip it out, package it up and ship it off, you are screwed even if someone is willing to pay to get it off your hands!

Have any of you had experience flipping sites and running into the problem of packaging and transferring them?

A simple, probably shitty solution, would be to rip a flat file version of the site to sell.
 
Give the buyer all the files and empty out a copy of your DB all entries except those for the site he bought? No different from a custom CMS really.