modif à faire dans .htaccess

[sly]

si vous ne le faites pas, votre version ne marchera plus :

Il faut appliquer manuellement ce commit sur votre fichier .htaccess juste après votre prochain "pull" (je l'ai fais sur www)
https://github.com/sletuffe/www.refuges ... 38a2ff9b77

[sly]

***P.S. qui n'a rien à voir*** Pourquoi ne mets tu pas ton .htaccess directement comme ça dans le GIT ? ça passe très bien.

J'ai besoin de faire passer un paramètre spécifique au dév que je veux surtout éviter de voir débarquer en prod
php_value display_errors 1
Si je pouvais mettre ça dans un .htaccess2 (actif en sus) alors je ferais que le .htaccess soit dans git

[sly]

note : j'ai cherché un truc genre :
include .htaccess2
qui nous permettrait d'avoir nos spécificités, mais ça n'existe pas avec apache

[Dominique]

J'ai besoin de faire passer un paramètre spécifique au dév que je veux surtout éviter de voir débarquer en prod
php_value display_errors 1
Si je pouvais mettre ça dans un .htaccess2 (actif en sus) alors je ferais que le .htaccess soit dans git

Beu..ha ? Bon. J'aurais bien mis le .htaccess de prod dans le git et demerd si tu veux les traces quand tu testes (perso, je n'utilise pas)

note : j'ai cherché un truc genre :
include .htaccess2
qui nous permettrait d'avoir nos spécificités, mais ça n'existe pas avec apache

Beu..ark

Make it simple

[sly]

Beu..ha ? Bon. J'aurais bien mis le .htaccess de prod dans le git et demerd si tu veux les traces quand tu testes (perso, je n'utilise pas) :satan:

comme ça, au prochain "git push" avec oubli de remettre, ça fini en prod : glups.
et à chaque fois qu'on pull, ça écrase notre .htaccess !

Tu codes sans ??? balaise... parce que "page blanche" ça ne m'aide pas des masses pour trouver qu'il manque un ; à la ligne 135 !

Beu..ark :avocat:

Make it simple

Toute la philosophie debian des mises à jour !
le fichier général, on y touche pas, et toute la customisation va dans un fichier local propre à son installation.
Ce qui est fait pour le config.php et le config_prive.php quoi.

ça me semble plus simple car tu le fais une fois pour toute que de faire ta modif à chaque fois que tu testes !

[Dominique]

comme ça, au prochain "git push" avec oubli de remettre, ça fini en prod : glups.
et à chaque fois qu'on pull, ça écrase notre .htaccess !

glups pas pensé à ça.

Tu codes sans ??? balaise... parce que "page blanche" ça ne m'aide pas des masses pour trouver qu'il manque un ; à la ligne 135 !

Ben oui je me suis bien demandé pourquoi j'étais dans le blanc mais je n'ai pas cherché.
Merci pour le truc. (ça me servira aussi dans un autre contexte)

[Dominique]

Toute la philosophie debian des mises à jour !
le fichier général, on y touche pas, et toute la customisation va dans un fichier local propre à son installation.
Ce qui est fait pour le config.php et le config_prive.php quoi.

ça me semble plus simple car tu le fais une fois pour toute que de faire ta modif à chaque fois que tu testes !

Bon, je me rend.
Mais pourquoi tu ne mets pas le config_prive.php à la racine ? Dans l'include, ça me parait être "packagé". Et ça aurait un sens à côté du htaccess.modele
Je verrais un config.php + son modèle à la racine pour les paramètres locaux et un includes/define.php pour les constantes du package (d'ailleurs, elle seraient plus logique en define qu'en $config[])
Mais bon, c'est du cosmétique

[sly]

Sans importance pour moi tant que c'est documenté et que ça ne fini pas en prod !

Mettre les config ensemble et les htaccess ensemble ou mettre les custom ensemble et les mettre à la racine ou dans un dossier custom, je ne vois pas un rangement plus logique qu'un autre.

Tout me va, je te laisse faire comme tu préfères et mettre à jour le README.md en conséquence