Bonjours tout l'monde,
Je suis étonné de votre insistance à ne centrer SPIP visiblement pour les
_seuls_ utilisateurs de clônes Altern et d'hébergeurs à la Free.fr
Je ne sais pas comment sont configurées ces machines, mais en l'état actuel
des choses (voir version sur le web du manuel) elles ne permettraient pas
vraiment à un utilisateur lambda de samizdat (par exemple) d'installer le
script et de le faire tourner... du moins sans faire appel à l'intervention
de l'un ou l'autre d'entre nous au niveau de la config.
Exemple 1:
- Dans "récupérer SPIP", j'ai viré la mention "attention à la
compatibilité Mac/PC/Unix", puisqu'à terme, on ne livera que les
versions compactées, adaptées à chaque système (.zip -> Win,
.tar.gz->Linux/BSD, .site->Mac).
Chez nous si quelqu'un fabrique ses gentils fichiers en local sur un Mac et
qu'il les dépose bêtement en FTP sur le serveur, il peu gentillement dire
adieu aux accents et au passage à la langue française...
Le seul moyent, si l'on veut travailler des fichiers à texte accentué (et au
format Mac à l'origine) en "local", sur son Mac ce serait de le faire avec
BBEdit, et de _surtout_ les enregistrer avant mise en ligne avec un codage
Unix...
Et si il sont déjà au format Unix dans l'archive, il faut encore que notre
brave utilisateur pense à décocher l'option "conversion automatique" dans
Stuffit expander s'il veut se retrouver avec autre chose que du charabia
plein de petits carrés et de ÉÈ° etc à la place des caractères accentués.
La nature des versions compactées n'a rien à voir là dedans...
Il s'agit bien de faire comprendre un minimum de chose à l'éventuel futur
utilisateur de SPIP, y compris que les différences et incompatibilité
d'encodage des fichiers textes sont des choses qu'il vaut mieux comprendre
qu'ignorer lorsque l'on veut faire un site Web. Ou, faute de lui faire
comprendre quoi que ce soit, de lui donner des pistes pour résoudre un
éventuel problème.
Exemple 2
- La partie "modifier les droits d'accès" passe à la fin, et est bien
indiquée comme occasionnelle. Là, j'ai ajouté une copie d'écran de
Fetch (Mac), si quelqu'un peut m'envoyer une copie d'écran d'un
client FTP Windows très courant, ça complètera. J'ai réduit au strict
minimum la mension telnet, parce que ça concerne très peu de monde
(et ceux qui savent le faire n'ont pas vraiment besoin de
précisions...).
Sur les serveurs à grand nombre de comptes, il doit sans doute y avoir des
"systèmes" pour éviter à l'utilisateur ce genre de "souci"... Mais au
détriment de la sécurité aussi sans doute.
Sur Free.fr, par exemple, lorsqu'un répertoire est vide on en voit le
contenu grâce à la fonction index automatique d'Apache ce qui n'est pas très
"sécuritaire"... Mais Free.fr s'occupe de la sécu du serveur, pas celle des
sites de ses utilisateurs...
Sur un serveur Unix les droits sont quelque choses de fondamental, et delui
qui veut faire du web a tout intérêt à le savoir un _minimum_, au moins s'il
est sur un serveur qui peut lui demander de s'en préoccuper un minimum.
Revenons à notre utilisateur samizdat, il dépose ses fichier dans son "home
directory", dans un répertoire nommé par exemple "public_html". Il fait quoi
si celà marche pas et qu'on lui a rien expliqué sur les droits et les
propiétaires des fichiers?
Rappel - Dans la version test installée sur samizdat, nous avons justement
un problème de ce type: les fichiers du CACHE sont en "nobody", les fichiers
du script en user "web", la mise à jour ne se fait donc pas automatiquement.
Pour l'instant il faut vider le cache à la main si l'on veut voir les modifs
sur le site :((
Sommes nous des fous pour avoir configuré aussi bizarrement notre serveur?
Je ne sais pas, mais nous avons fait comme des millions d'autres petits
serveurs Unix dans le monde... Avec ce choiux qui nous est propre, de
privillégier la sécurité des services hébergés plutôt que la simplicité de
l'interface.
Sommes nous d'amblée hors du champs visuel de SPIP ?
La position "ceux qui savent le savent, les autres n'en on pas besoin", est
peu courte me semble-t-il, du moins si l'on _partait_ du principe qu'on ne
sait pas sur quelle machine, et dans quelles circonstances, les futurs
utilisateuers de SPIP utiliseront le script.
Cela suppose, biensûr, un guide d'install un peu plus fournit, et organisé
éventuellement autours de divers cas de figures envisagés, y compris les
moins "sexy".
Mais est-ce ce que vous voulez ?
Personnellement lorsque j'installe quelque chose sur le serveur, j'attend du
fichier d'install qu'il soit clair, qu'il anticipe les éventuels problèmes,
qu'il me donne le plus d'indications possible (jusqu'aux commandes à saisir
s'il le faut). Pas qu'il me la joue "simple", "facile", "cool", pour que ce
soit ensuite la galère à installer/configurer.
Pour conclure:
Ce qui m'intéressait au départ dans SPIP c'est sa souplesse de conf des
interface web, son traitement correcte de la typo et la volonté de le faire
tourner sur des config minimalistes type Free.fr.
Mais si ce dernier point signifie l'exclusion de tout serveur "normalement"
configuré (du moins de mon point de vue), c'est que je me suis trompé
Amicalement
Aris
PS- Il me semble que 777 est trop permissif d'un point de vue sécu, je
ferais des test en fin de semaine et je vous dirais ce qu'il en est.
PPS- Pensez à numéroter les version on ne s'y retrouve plus, il y a déjà des
différences en le répertoire et les versions compressées ! Exemple: c'est
quoi le fichier update.php3 dans /ecrire qui n'existe que dans la version du
répertoire ?