Virtualhost pour un projet Symfony 2

Le problème exposé dans ce sujet a été résolu.

Bonsoir à tous,

Dans le cadre des divers développements que je mène professionnellement et personnellement, je me crées moultes vhost pour atteindre les différents projets via un browser. Et je viens de me rendre compte d'une chose somme toute assez gênante. J'ai par habitude de me créer 2 vhost au format projectname.dev pour accéder en environnement de développement et projectname.prod pour avoir un accès en environnement de prod. Dans l'absolu cela fonctionne assez bien mais j'ai juste un problème concernant la homepage des projets, donc l'url /

Si je me trouve sur http://monsuperprojet.dev alors je suis en environnement de prod, pour toutes url descendantes, par exemple http://monsuperprojet.dev/login alors je suis bien dans l'environnement de dev.

Voilà un exemple type de vhost que j'emploie:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<VirtualHost *:80>
    ServerAdmin admin@projectname.dev
    ServerName projectname.dev

    DocumentRoot /home/zazou/public_html/projectname/web

    <Directory />
        Options +FollowSymLinks
        AllowOverride All
    </Directory>

    <Directory /home/isabelle/public_html/projectname/web/>
        Options +Indexes +FollowSymLinks +MultiViews
        AllowOverride All
        Order allow,deny
        allow from all
    </Directory>

    <Location />
        RewriteEngine On
        RewriteBase /
        RewriteCond %{REQUEST_FILENAME} -f
        RewriteRule ^.*$ - [NC,L]
        RewriteRule !\.(js|ico|gif|jpg|png|css|swf|txt) app_dev.php [NC,L]
    </Location>
</VirtualHost>

Si vous aviez une solution à m'apporter, ça serait géniale.

Merci d'avance !

+0 -0

Serait-ce parce que le .htaccess fourni avec Symfony court-circuite ces directives ? Il redirige systématiquement vers app.php, si je ne me trompe. Mais dans la mesure où tu n'en as pas nécessairement besoin sur un serveur de développement et que tu as la main sur la déclaration des hôtes virtuels, tu peux y mettre le contenu (adapté) du .htaccess, non ?

+0 -0

Alors je te confirme que le .htaccess prend la priorité sur mon vhost du coup. Du coup je peux effectivement modifier le fichier pour définir le DirectoryIndex à app_dev.php mais bon c'est un fichier versionné ce .htaccess donc à priori ce n'est pas la vraie bonne solution même si ça peut me dépanner pour un moment.

Dans ce cas, est-ce que tu pourrais quand-même imaginer de modifier ce .htaccess pour y ajouter une condition de redirection selon le nom de domaine utilisé ?

Et si tu te dis "C'est un fichier fourni avec/par Symfony, on ne doit pas y toucher", alors ne change pas non-plus composer.json qui est fourni avec, et pas non-plus parameters.yml… :-°  ;)

Rappelle-moi, un AllowOverride none avec un .htaccess dans l'arborescence ainsi "protégée" déclenche une erreur 500, c'est bien ça ? Il n'y a pas un moyen de changer ce comportement, en redéfinissant le nom des pour les fichiers .htaccess pour tes hôtes virtuels Symfony par exemple ? Je pensais à la directive AccessFileName

+0 -0

Alors je te confirme que le .htaccess prend la priorité sur mon vhost du coup. Du coup je peux effectivement modifier le fichier pour définir le DirectoryIndex à app_dev.php mais bon c'est un fichier versionné ce .htaccess donc à priori ce n'est pas la vraie bonne solution même si ça peut me dépanner pour un moment.

Zazou

La vraie bonne solution serait de ne pas utiliser de .htaccess. Tu n'en as de toute façon pas besoin puisque tu configures ton serveur avec des virtual hosts. En désactivant leur gestion il devrait y avoir un gain de perfs d'Apache plus important qu'on pourrait le croire selon certains benchmarks.

EDIT: un exemple pas trop vieux pour illustrer le propos avec des chiffres.

Rappelle-moi, un AllowOverride none avec un .htaccess dans l'arborescence ainsi "protégée" déclenche une erreur 500, c'est bien ça ?

Ymox

Je ne crois pas, ça ne devrait pas.

Et si tu te dis "C'est un fichier fourni avec/par Symfony, on ne doit pas y toucher", alors ne change pas non-plus composer.json qui est fourni avec, et pas non-plus parameters.yml… :-° ;)

Ymox

Si je ne m'abuse, le problème était plutôt d'avoir un .htaccess pour deux configs, rendant forcément l'une des deux caduque.

+0 -0

Bah le .htaccess est celui fourni par la distrib Symfony directement. Donc la vraie solution est ptète tout simplement de désactiver effectivement le AllowOverride dans mon vhost de développement

Je testerai plus en détail ce soir mais là en 5min j'ai pas l'impression que ça a fonctionné. J'ai remis dans le .htaccess le app.php, j'ai mis les AllowOverride à none dans mon vhost de développement, j'ai restart apache et je me retrouve en env=prod sur la page d'accueil.

Ce qui est fourni avec la distrib n'est pas forcément à garder. Il faut par exemple virer tout ce qui est démo et ne sert à rien dans le projet. Je pense que le .htaccess est juste là pour donner un exemple de config du serveur et n'est pas là pour être utilisé en prod. Pour moi, le seul élément qui doit rester inaltéré est le répertoire vendor.

+1 -0

Rappelle-moi, un AllowOverride none avec un .htaccess dans l'arborescence ainsi "protégée" déclenche une erreur 500, c'est bien ça ?

Ymox

Je ne crois pas, ça ne devrait pas.

Chinoisfurax

D'accord, ce n'est pas le fait de simplement avoir un .htaccess qui pose problème, mais d'y avoir des directives qui ne sont pas surchargeables, alors.

Si je ne m'abuse, le problème était plutôt d'avoir un .htaccess pour deux configs, rendant forcément l'une des deux caduque.

Chinoisfurax

Il n'y a vraiment pas moyen de rediriger vers l'un ou l'autre point d'entrée de l'application en fonction du nom de domaine utilisé ? Je me souviens l'avoir fait avec sf 2.0, mais je sais aussi que le contenu du .htaccess s'est étoffé depuis…

+0 -0

La portabilité dépend là des noms de domaine, non ? Vu qu'en général, on n'a pas les mêmes en dev' et en prod', si on ne fait que rediriger vers l'environnement de développement et qu'on laisse "par défaut" rediriger vers app.php, j'ai l'impression que c'est portable.

+0 -0

Oui toute la demo est effectivement à supprimer, on peut d'ailleurs ne pas l'installer quand on crée le projet avec composer maintenant. Mais je t'avoue que ce .htaccess, je pensais qu'il était utile du coup, je peux rester sur mon .htaccess personnalisé pour ma machine de dev ça ne pose pas de souci.

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte