I am using something similar to the solutions bellow and as I am not
afraid of server admin I really agree it is a good solution. Though, as
Lukas mentioned it was not obvious for everybody but I think all
developers know how to manupulate the "hosts" file of their computer in
order to developer whatever websites they work on.
I think it is not unusual for people for do something like domain.com ->
domain.local, right? So simply use one front controller and have inside:
if ($_SERVER['HTTP_HOST'] == 'www.staging.com')
{
define('SF_ROOT_DIR', realpath(dirname(__FILE__).'/..'));
define('SF_APP', 'frontend');
define('SF_ENVIRONMENT', 'staging');
define('SF_DEBUG', false);
}
else if ($_SERVER['HTTP_HOST'] == 'www.domain.local')
{
define('SF_ROOT_DIR', realpath(dirname(__FILE__).'/..'));
define('SF_APP', 'frontend');
define('SF_ENVIRONMENT', 'dev');
define('SF_DEBUG', true);
}
else
{
define('SF_ROOT_DIR', realpath(dirname(__FILE__).'/..'));
define('SF_APP', 'frontend');
define('SF_ENVIRONMENT', 'prod');
define('SF_DEBUG', false);
}
This has worked a charm for me as I want to be able to access both
production and development at the same time. If there is interest I can
make this a wiki page or Lukas while you are at it, you can do both?
Good/Bad?
Kupo
Kris Wallsmith wrote:
> Hi Lukas,
>
> I typically use the following front controller. This allows me to
> define the bootstrap settings from w/i my Apache configuration,
> preventing people from accessing the site in an alternate environment.
>
> Hope that helps!
> Kris
>
> <pre><code>
> <?php
>
> /** @version SVN: $Id$ **/
>
> define('SF_ROOT_DIR', realpath(dirname(__FILE__).'/..'));
> define('SF_APP', isset($_SERVER['SF_APP']) ?
> $_SERVER['SF_APP'] : 'frontend'));
> define('SF_ENVIRONMENT', isset($_SERVER['SF_ENVIRONMENT']) ?
> $_SERVER['SF_ENVIRONMENT'] : 'prod');
> define('SF_DEBUG', isset($_SERVER['SF_DEBUG']) ? (bool)
> $_SERVER['SF_DEBUG'] : false);
>
> require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.'apps'.DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.'config'.DIRECTORY_SEPARATOR.'config.php');
>
> sfContext::getInstance()->getController()->dispatch();
>
> </code></pre>
>
> On Oct 8, 5:08 am, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>>
>> I have tried many approaches in order to be able to keep my
>> development frontend files in a separate directory than the
>> production frontends. This has the advantage that you can more easily
>> prevent/secure access to the development frontend while still being
>> able to keep the development frontends in svn without the danger of
>> forgetting to remove these files when doing a checkout on the
>> production machines. More importantly by making this separate
>> directory with the development frontends available form the web, but
>> with additional security precautions, its possible to use the
>> development frontends on your production machines. The process to get
>> there is unfortunately quite hacky. I am open for suggestions on how
>> to improve the approach as its described below:
>>
>> In order to prevent end users from accessing development front
>> controllers or other administrative tools, these files should be
>> moved to a directory "admin" inside the root symfony directory. This
>> will however break any assets from loading properly. The solution is
>> to change the AssetHelper to use a different relative url in that
>> case. The following steps are necessary for this:
>>
>> 1) Add a constant in the given front controllers that enables the
>> host rewriting:
>>
>> define('SF_REWRITE_ASSET_HOST', true);
>>
>> 2) Add a filter that rewrites the location (for most applications
>> there will be a need to initialize the session, making sure that non
>> authenticated users are directed at the right page, that the language/
>> country cookie is set properly etc., which seems like a goof location
>> for this code):
>>
>> class initSessionFilter extends sfFilter
>> {
>> /**
>> * Execute filter
>> *
>> * @param FilterChain $filterChain The symfony filter chain
>> */
>> public function execute($filterChain)
>> {
>> if ($this->isFirstCall()) {
>> $context = $this->getContext();
>> $request = $context->getRequest();
>> $user = $context->getUser();
>> $action = $context->getActionStack()->getLastEntry()-
>> >getActionInstance();
>>
>> if (defined('SF_REWRITE_ASSET_HOST') && SF_REWRITE_ASSET_HOST) {
>> $asset_host = sfConfig::get('app_config_rewrite_asset_host');
>> if (substr($asset_host, 0, 4) === 'http') {
>> $request->setRelativeUrlRoot($asset_host);
>> } elseif (preg_match('/s(\/.+\/)(.*)/', $asset_host,
>> $matches)) {
>> $request->setRelativeUrlRoot(preg_replace($matches[1],
>> $matches[2], $request->getRelativeUrlRoot()));
>> } else {
>> $request->setRelativeUrlRoot($request->getRelativeUrlRoot
>> ().$asset_host);
>> }
>> }
>> ..
>> }
>> }
>>
>> }
>>
>> 3) Add 'app_config_rewrite_asset_host' to your app.yml file
>>
>> all:
>> config:
>> # rewrite_asset_host: 'http://foo.bar'
>> # rewrite_asset_host: 's/admin\./'
>> rewrite_asset_host: '/../web'
>>
>> Remember that you can have different configuration settings per
>> environment and per server (following the above guidelines).
>>
>> There is a problem with this solution however if the no_script_tag
>> feature is disabled, since in that case the url helpers will use the
>> $request->getRelativeUrlRoot() to construct the url. In that case you
>> also need to do some further hacking:
>>
>> 4) First you need to store the original relative url root in a
>> constant before modifying the value in your filter. Then you need to
>> open up and store lib/symfony/controller/sfWebController.class.php in
>> your application lib directory and modify the genUrl() method. Look
>> for the call to getRelativeUrlRoot() and change the section of the
>> code as follows:
>>
>> $url = '';
>> if (!sfConfig::get('sf_no_script_name'))
>> {
>> $url = $this->getContext()->getRequest()->getScriptName();}
>>
>> else if ($sf_relative_url_root = $this->getContext()->getRequest()-
>> >getRelativeUrlRoot())
>> {
>> $url = (defined('RELATIVE_ROOT_URL')) ? RELATIVE_ROOT_URL :
>> $sf_relative_url_root;
>>
>> }
>>
>> regards,
>> Lukas
>>
>
>
> >
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~----------~----~----~----~------~----~------~--~---
