StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>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.</p> <p>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. </p> <p>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:</p> <pre><code>cd htdocs ln -s SF_ROOT_DIR/web frontend ln -s SF_ROOT_DIR/web backend </code></pre> <p>Now you can point your cpanel set to <code>htdocs/frontend</code> for <code>domain.com</code> and members.domain.com and point <code>admin.domain.com</code> to <code>htdocs/backend</code>.</p> <p>Then you could change your .htaccess to look something like this:</p> <pre><code>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> </code></pre> <p>This way you should be able to use <code>no_script_name</code> with both apps.</p> <p>Another way to do the same thing would be to modify your index.php to something like the following:</p> <pre><code>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(); </code></pre> <p>You can modify the app name detection however you like but you get the idea.</p> <p>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.</p> <p>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. </p> <p>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.</p> <p>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 <code>UserAdmin</code> or something similar. Then for the userland stuff we might just have the module <code>User</code> 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 <code>UserAuth</code> 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:</p> <pre><code>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 </code></pre> <p>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.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload