en fin d’installation, ce serait pratique, à mon avis, que l’utilisateur n’ait pas à créer plugins/auto (et lib).
J’y vois plusieurs avantages :
il n’a pas besoin de se connecter via ftp pou manipuler les dossiers
il n’a pas à manipuler les droits des fichiers créés
on n’a pas besoin que /plugins/auto soit en 777 vu que le dossier est créé par php
(tout comme config/ IMG/ local/ et tmp/)
Ce côté “j’installe et je peux directement utiliser SPIP” de spip_loader serait mieux. Car créer un répertoire dont le nom est “plugins/auto” n’est pas si trivial pour tout le monde (où ? C’est quoi ce nom ? etc…). Le fait qu’on soit bloqué après une installation “cliquodrome”, très adaptée à ceux qui n’y connaissent pas grand chose au ftp, est à mon avis très perturbant.
en fin d'installation, ce serait pratique, à mon avis, que l'utilisateur
n'ait pas à créer plugins/auto (et lib).
J'y vois plusieurs avantages :
- il n'a pas besoin de se connecter via ftp pou manipuler les dossiers
- il n'a pas à manipuler les droits des fichiers créés
- on n'a pas besoin que /plugins/auto soit en 777 vu que le dossier est
créé par php
(tout comme config/ IMG/ local/ et tmp/)
On a déjà causé de la mise à dispo de ce dossier, mais c'est vrai que c'était dans SPIP directement. Au final, on avait préféré ne pas l'inclure directement dans le core.
Pour le cas d'une installation par spip_loader (mode clic and play), je pense que ça serait pas bête de le créer. Mais il faudrait bien faire attention à le créer uniquement lors d'une installation et non lors d'une mise à jour (car il ne serait pas bon d'imposer ce dossier aux webmestres qui n'en veulent pas).
Oui c'est ce que je pense aussi : le code source versionné du noyau ne doit pas le contenir mais les outils d'installation proposés par la communauté doivent savoir les ajouter (loader et spip-cli, notamment).
Pour une installation par ce biais (par un outil), je pense que le cas par défaut est de le faire, et en option (define, interface, arguments, peu importe) pouvoir le débrailler.