Chemin root erroné en SPIP 4.4 ou SPIP 5.x avec un répertoire vendor/ en lien symbolique

Chez N*t il y a un bazar de liens symboliques sur les sites pour charger SPIP.

En l’occurrence, on a

  • config/matrice/xxx/spip/vendor
  • vendor (lien symbolique vers le précédent)

Note: config/matrice/xxx est déjà un lien symbolique avec un répertoire spip/ complet dedans

En SPIP 4.4 & 5.x le kernel rempli le chemin racine à partir du chemin (realpath) donné dans vendor/composer/installed.php dans la clé 'root/install_path' (qui contient __DIR__ . '/../../')

https://git.spip.net/spip-league/kernel/-/blob/5d4d24f1cb164be6c340c273ce486e0b0d529c33/src/InstallationDetector.php#L35

On se retrouve avec un chemin root qui vaut par exemple /var/www/site/config/matrice/xxx/spip/ au lieu de /var/www/site/ (et c’est déjà du à la présence de __DIR__ qui résout tout lien symbolique) et du coup, tous les appels à la fonction app()->get*Dir() deviennent erronés dans ce cas.

Par exemple dans Adminer, on avait ajouté pour SPIP 4.4+

			if (function_exists('\SpipLeague\Component\Kernel\app')) {
				$dir_base = app()->getEtcDir() . 'bases/';

Mais cela ne retourne en fait pas le chemin réel de la BDD (contrairement à _ROOT_* en SPIP 4.4 qui n’a pas été modifié — mais ces constantes sont aussi bien modifiées en 5.0 par contre)


Notons que pour parer au même problème avec les constantes _ROOT_* on ne pouvait pas lier ecrire/ entièrement notamment non plus.

On liait chaque répertoire de ecrire/* et copiait le répertoire ecrire/inc_version.php qui contient la déclaration de _ROOT_RACINE

Quelque chose comme

  • config/matrice/xxx/spip/ecrire/inc
  • ecrire/inc (lien symbolique vers le précédent)
  • ...
  • config/matrice/xxx/spip/ecrire/inc_version.php
  • ecrire/inc_version.php (copie du précédent)

Ce fonctionnement (hack on peut dire) ne fonctionne plus en SPIP 5.0 je crois bien (déjà car des définitions de ces constantes sont parties dans ecrire/bootstrap/)

Bref, je ne sais pas s’il faut changer quelque chose en 5.0 (disons que c’est un peu un problème concomitant avec la structure de mutualisation chez N*t, et mutualiser vendor/ a ses limites par ailleurs).

Il n’empêche que le root pourrait peut être être calculé avec une autre méthode qui éviterait ce désagrément ?