I requested the same information and have the chance to receive mike´s and fabien´s reply. Here are the details:
For one logic with subdomains: http://trac.symfony-project.org/wiki/HowToDoMultipleSitesWithSingleCore
Multiple Sites Based on Identical Configurations
This may be a strange topic, but I wanted to configure our access into subdomains, all with SSL access. We needed different sites because SSL forces IP based virtual domains, which meant different document roots for us. Such as:
•www.mydomain.com
•admin.mydomain.com
•parents.mydomain.com
However, these were all sites with the same core schema and plugins. The advantage of this configuration is:
•Shared model files: All the XxxPeer classes will be linked across applications
Disadvantage:
•You now have 2-n different caches/logs to monitor.
If you look at a typical Symfony directory structure, it can be broken up to two type groups:
•Common Directories:
◦batch
◦config
◦data
◦doc
◦lib
◦plugins
◦test
•Application Specific Directories:
◦apps
◦cache
◦log
◦web
Here are the steps I took:
•Develop the www.yourdomain.com schema and site. Once this is starting to come together, you can start to develop the additional sites.
•In the new site, symbolic link the Common Directories
•In the new site, create the Application Specific Directories
◦NOTE: In the web directory, you may need to copy some of the original contents (css, js, and .htaccess files come to mind). Keep this in the back of your mind as you start to bring up the new site.
•Run the command symfony fix-perms
◦NOTE: For me, Virtualmin creates these new sites with new usernames. You will have to insure that all the Application Specific Directories are owned by that username, so your clear-cache commands and logging commands work.
•Now, you have a the project configured. You start by doing:
◦symfony app MYAPP
◦symfony module MYAPP MYMODULE
◦...
•You will now find that your apps/MYAPP/modules/MYMODULE has been created, and you have full peer access to the entire database
Here is fabien regarding one logic with different domains names: client1.com client2.com using same apps.
For one logic with different domains:
"You could point them all at the same front controller, and then use a filter or a action parent class to do things like change the site template etc. However, having a front controller per domain may be more efficient, and is a perfectly good way to go.
Each domain could have its own application, but the bulk of the logic should be implemented in plugins, so they can be enabled for each domain/app that needs them, and shared as required. How much code is required per application depends, I guess, on how different the sites actually are. "