How to structure this Symfony web project?

Question

I am new to Symfony and am not sure how to best structure my web project. The solution must accommodate 3 use cases:

1. Public access to www.mydomain.com for general use
2. Member only access to member.mydomain.com
3. Administrator access to admin.mydomain.com

All three virtual hosts point to the Symfony /web directory

Questions:

Is this 3 separate applications in my Symfony project (e.g. "frontend", "backend" and "admin" or "public", "member", "admin")?

• Is this a good approach if there is to be some duplicate code (e.g. generating a member list would be common across all 3 applications, but presented differently)?
• How would I route to the various applications based on the subdomain when a user accesses *.mydomain.com? Where in Symfony should this routing logic be placed?

Or, is this one application with modules for each of the above use cases?

EDIT: I do not have access to httpd.conf in apache to specify a default page for virtual hosts. I can only specify a directory for each subdomain using the hostin provider's cPanel.

Answer 1

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.

Answer 2

I think you should separate your applications in public, member and admin. The routing would be done by apache: you can use 3 document roots pointing to separate folders. Mutualizing your code can be done through the use of plugins. You can override a plugin's code : for a specific application if you need to. If the public and member access have very many things in common, you could consider using the same application for both accesses.