Un simple fichier server-config.php cela évite de mélanger les choses

<?php
define('DOC_ROOT', '/var/www/paamayim-nekudotayim/');
define('HTTP_ROOT', 'http://www.paamayim-nekudotayim.com/');

Dans une application il y a la vue, les contrôleurs, le modèle, la configuration. Seule la partie "configuration" devrait être éditée lors d'un changement de serveur. Inclure un "base href" c'est modifier la vue, et mixer la partie vue et configuration. Je suis pas fan

Oui en fait c'est une erreur de ma part, j'utilise cette balise pour remédier à certains bugs quand j'utilise l'URL rewriting et des liens relatifs

Bonjour bonjour

Je voulais juste commenter les méthodes que vous utilisez.

La méthode <base href="root"> : ce serait une bonne idée de ne pas l'utiliser pour plusieurs raisons. Déjà comme l'a souligné Naholyr, on doit modifier la vue, et normalement, la vue n'a pas à être modifier pour ce genre de "détails". De plus, la balise <base /> a été mise en service à partir de HTML 3.2 (sauf erreur), et sera disponible en HTML 5 (d'après les drafts actuelles), mais pas en XHTML 2.0 ! Alors attention.
Les drafts sont susceptibles de changées, mais la draft sur ce sujet est déjà stable, alors il y a peu de risque que ça change (mais ne vendons pas la peau de l'ours avant de ...).

La méthode PHP avec define et cie. C'est à mon avis, la meilleure solution. C'est peut être un brin plus ch***t pour écrire tes liens, mais tu gagnes en maintenance une fois de plus. Et cette méthode est plus légère que la précédente.

Pour Hubert Roksor, quand un URL n'est pas relatif, il est absolu. Les RFCs disent path-absolute dans ce cas, c'est assez explicite je pense

Il y a aussi la méthode des environnements d'exécution, façon Symfony et autres, qui est assez facile à mettre en place (puisque finalement c'est la même que ce que je disais précédemment, à ceci près qu'au lieu de ne pas écraser le fichier de config sur le serveur de prod, on utilise plusieurs fichiers de conf et plusieurs bootstraps) :

- Tout le code "commun" à tout environnement est placé dans un fichier autre que l'index.php (par exemple "runtime.php") et index.php se réduit à sa plus simple expression :
1. La config
2. Le runtime (qui dépend de la config)

<?php

// Options dépendantes de l'environnement d'exécution (bdd, chemins, etc...)
require 'config/config.inc.php';

// Exécution de l'application
require 'includes/runtime.php';

- On crée un fichier "config-dev.inc.php" qui détermine la config en environnement de dév (localhost), et un fichier "config-prod.inc.php" qui détermine la config en environnement de production. Rien n'empêche d'en créer d'autres

- On crée autant de points d'entrée qu'on a d'environnements :
index.php

<?php

require 'config/config-prod.inc.php';
require 'includes/runtime.php';

index-dev.php

<?php

require 'config/config-dev.inc.php';
require 'includes/runtime.php';

On n'a alors plus du tout à se soucier de l'environnement : quand je bosse en local j'appelle http://localhost/index-dev.php et sur le serveur de prod je me contente de supprimer l'accès au fichier "index-dev.php" (en ne l'uploadant pas, c'est le plus simple).

Et la règle d'or c'est que la seule différence entre mon serveur de prod et mon serveur de dév, c'est le fichier de conf utilisé. Tout le reste doit être rigoureusement identique.
On peut se créer autant d'environnements qu'on veut, le fichier de config devrait permettre de régler le niveau de débuggage, les chemins, l'activation ou non des benchmarks, etc...