Choualbox/m/settings (Que signifie le M ?)

@Wig0: J'ai un session_start dans un header sans affichage (1&1 aime pas les affichages :/)
Du coup j'ai une session : PHPSESSID avec une id spécifique à la personne mais je crée la session lorsqu'il arrive sur le site, pas lorsqu'il est connecté

@Ezazhel: tu peux associer n'importe quel paramètre à le session donc y stocker des informations pratiques. Regarde ici http://www.w3schools.com/php/php_sessions.asp

@Wig0: Je sais comment fonctionne les sessions ^^ J'ai qu'à créer une session lors de la connexion. J'aurai plus besoin de faire la requête sql après pour récupérer le login. Par contre je le passe en sha1 pour éviter que la personne le modifie après ?)

@Ezazhel: Ce qui est stocké coté client dans le cookie PHPSESSID est un identifiant unique. Tout ce qui est stocké dans ta $_SESSION coté serveur est protégé et le client n'y a pas accés.

@Appineos: Han ! ça par contre je ne savais pas que les $_SESSION n'était pas accessible, enfin j'aurai pu m'en douté sachant que c'était côté serveur ! (Mais du coup comment savoir que $_SESSION existe ? si on ne peut pas avoir de "retour")

@Appineos: Je n'ai jamais rien pigé aux .htaccess :/ Un jour peut-être.
Je vais me renseigner sur les routes. Là à la limite c'est pas grave, j'ai récupéré le login_user par rapport à son id. Donc je m'en resservirai pour afficher les infos du compte.

PS : Je suis sur bootstrap

@Ezazhel: je vais essayer d'être clair bien que je n'ai pas la science infuse.

Dans un cas général, un site (ainsi que sa navigation) s'effectue avec une arborescence type (client étant ce que t'as dans ta barre d'adresse, serveur étant ce qui est appelé sur le disque dur du serveur):

client = site.com/ (ou /index.php) || serveur = /dossier/index.php
client = site.com/login.php || serveur = /dossier/login.php
client = site.com/membre/profil.php || serveur = /dossier/membre/profil.php
...

Souvent, la plupart des sites masques le .php grace à de l'url rewriting (.htaccess pour apache et ses dérivés)
client = site.com/ || serveur = /dossier/index.php (pas de changement ici)
client = site.com/login | serveur = /dossier/login.php
client = site.com/membre/profil || serveur = /dossier/membre/profil.php

Jusque là, apache (ou le serveur web) s'occupait des "routes" pour faire pointer fichier.php -> fichier.php même pour les cas ou fichier -> fichier.php, étant donné qu'il savait que même si .php pas présent, c'était quand même pour appeler le .php sur le disque du serveur.

dans des contextes un peu plus "spécialisé", souvent utilisé par des frameworks (la plupart du temps hein, c'est possible de le faire soit même)
Apache ne s'occupe plus vraiment des routes, je n'ai pas été vérifié (je taff pas avec php en ce moment) mais je suis presque sûre que quelque soit ce que le client appel, celui-ci appellera un seul et même fichier (php) et c'est ce fichier qui va s'occuper de lire l'url du client. Des exemples:

client = site.com/ || serveur = /dossier/noyau.php
client = site.com/login || serveur = /dossier/noyau.php
client = site.com/membre/profil || serveur = /dossier/noyau.php

Pour les exemples, noyau.php va traiter l'url, voir ce que le client demande, et charger tel ou tel fichier (ou module, widget, bundle (les termes diffères) plus souvent). C'est dans ce contexte qu'on parle de "route php" ou alors "router". Tu as différent contexte pour les routers, mais là n'est pas la question (chargement d'un fichiers avec les différentes route possible du site, mais je vais pas rentrer dans les détails).

En soit c'est pas une pratique qui date de hier, c'est aujourd'hui courant comme méthode. Mais s'applique le plus souvent pour des projets établi avec le pattern MVC et donc le plus souvent (je radote non ?) sur des projets orienté objet.

Je sais que si un expert passe par là, il me tirera les cheveux, car le contexte est beaucoup plus complexe que ce que j'ai pu cité. Mais l'idée est là.

J'espère que tu as réussi à lire jusque là.

@Appineos: Juste pour ton info, nginx n'a pas d'équivalence native au .htaccess, ça se passe dans les fichiers de configuration du VHosts pour faire la même chose (beaucoup plus opti, l'optique de nginx étant d'être le plus léger possible, mais beaucoup moins pratique pour l'hébergement mutualisé).

@Nell: et pour ajouter un détail à cette explication qui tient la route (sans mauvais jeu de mot), j'ai cru détecter de l'affichage d'exception avec un affichage à la silex/symfony sur cb. Pour moi, il y a bien un router php sur choualbox.

@Nell: J'ai tout lu ! Merci bien :)