This is hard to say without knowing the actual responsibilities of each domain/app/whatever. This is something you have to answer based on the requirements of your project... there is no single strategy one can recommend for every use case.
With that said I think at most you have the makings of two applications - One would serve as frontend and also include the "members" functionality. The reson i think these tow ar probably a sinlge app is because youll want to generate links to one from the other (which is incredibly hard to do if they are seperate applications) - ie. EVERYONE has access to the homepage and say the FAQ, but only members have access to Downloads or something, but still they are the same site.
The other app would be for the backend and hold the admin functionality. Regardless of how many apps you can share the same web dir sinmply make a symlink and then point apache appropriately for example:
cd htdocs
ln -s SF_ROOT_DIR/web frontend
ln -s SF_ROOT_DIR/web backend
Now you can point your cpanel set to htdocs/frontend for domain.com and members.domain.com and point admin.domain.com to htdocs/backend.
Then you could change your .htaccess to look something like this:
Options +FollowSymLinks +ExecCGI
<IfModule mod_rewrite.c>
RewriteEngine On
# we check if the .html version is here (caching)
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f
# no, so we redirect to our front web controller
# if subdomain is admin.* then use backend.php application
RewriteCond %{SERVER_NAME} ^admin\..*$
RewriteRule ^(.*)$ backend.php [QSA,L]
# not admin so we use the frontend app
RewriteRule ^(.*)$ index.php [QSA,L]
</IfModule>
This way you should be able to use no_script_name with both apps.
Another way to do the same thing would be to modify your index.php to something like the following:
require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php');
if(0 === strpos($_SERVER['SERVER_NAME'], 'admin'){
$app = 'backend';
}
else
{
$app = 'frontend';
}
$configuration = ProjectConfiguration::getApplicationConfiguration($app, 'prod', false);
sfContext::createInstance($configuration)->dispatch();
You can modify the app name detection however you like but you get the idea.
With both of the approaches you can do some basic determination based on subdomain, and you can apply this strategy regardless of the number of apps we are talking about whther you only use my recommended 2 or if you use 3.
The alterantive is to make one homegenous application. Assuming each of applications is really just one facet of the overall application i like to go this route. However, I would consider members, non-members, and admin too broad a definition for modules.
If you did it that way you could potentially end up with an insane amount of actions in the controllers. Instead i would make seperate modules for actual concerns. Additionally theres no real reason to use subdomains here - its much easier to just use a segment of the url (ie. /admin or /members) to use specific modules.
For example lets take users... Typically theres going to be an admin area so we can use the admin generator for that functionality and call the module UserAdmin or something similar. Then for the userland stuff we might just have the module User which would handle public profile viewing and listing, profile editing by users and all that stuff. Then for actual login we might have the module UserAuth which strictly handles stuff like login/logout and forgotten password requests and what not. You can route any url to any one of these modules, so your routing might look something like this:
user_login:
url: /login
params: {module: UserAuth, action: login}
user_logout:
url: /logout
params: {module: UserAuth, action: logout}
user_password:
url: /forgot-password
params: {module: UserAuth, action: recoverPassword}
user_reset:
url: /password/reset/:token
params: {module: UserAuth, action: resetPassword}
user_profile:
url: /members/:username
params: {module: user, action: showProfile}
user_index:
url: /members
params: {module: User, action: index}
user_default:
url: /members/:action
params: {module: User}
admin_user:
class: sfDoctrineRouteCollection
options:
Module: UserAdmin
model: User
prefix_path: /admin/user
The last step in doing things this way is to make sure you secure the appropriate modules and actions with the proper credential requirements in security.yml and that you also assign credentials appropriately.
