[Spip] Premier essai avec SPIP (suite)

Dev
1

Bonjour tout l'monde,

Bon, après quelques heures je me suis bien habitué à SPIP et cela fonctionne
plutôt bien... dans un environnement plaisant. Un autre copain de samizdat
s'y met, comme ça on aura aussi un autre avis d'administrateur.

La première impression générale est celle d'une assez grande souplesse de
configuration et d'organisation de la partie visible.

Il faut dire que grâce au fichier .zip d'Antoine j'ai récupéré les images
qui aident à la navigation dans la partie édition :))

Par contre je n'ai pas réussi à utiliser ses fichiers de config qui sont
visiblement (?) au format DOS et je perd tous les accents sur mon Mac tant
sous MacOs que sous Linux. Pour moi perso 8)) un tarball (.tar.gz) ou un
fichier stuffit (.sit) serai mieux

Quelques questions:

- Est-il possible de désactiver temporairement le recours aux fichiers
"cache": lorsque l'on fait des essais de "mise en page" sur le HTML il faut
à chaque fois aller les détruire pour voir l'effet des modifs.

- Où (ou comment) se règle le nombre d'articles et de brèves qui sont
affichés en "une" par exemple ? il me semble que c'est un paramàtre dans le
fichier sommaire.html, mais comme je n'ai pas encore plongé en détail dans
le code je n'en suis pas certains.

- Est-ce qu'il y a (ou est prévu) la création d'un fichier "backend" qui
permettrait d'afficher les titres de son site sur un autre site.

Une remarque en passant:

Pour moi le bouton pour "recharger" la page (en bas à gauche) ne fonctionne
pas: il me renvoi sur test.com (!) vu que SPIP est installé dans un
répertoire test... ce doit être une erreur de lien

Enfin, à propos de la doc:

- Ma proposition de travailler à la rédaction d'un README tient toujours, je
m'y mettrais dès que j'ai terminer l'install.

- Sur le fichier .pdf c'étais une remarque en passant. Pour l'instant cela
suffit et en plus c'est très bien fait. Je pense qu'ensuite nous pouvons
effectivement envisager d'en faire une version HTML et une version TXT.

Amitiés

Aris

PS- Il serait peut-être pas mal de commencer à numéroter les différentes
versions de SPIP qui circulent pour s'y retrouver en utilisant un système
qui puisse différencier les versions contenant des modifications proposée et
celles contenant des modifications adoptées. Sinon cela rique d'être vite le
bordel. en quelques jours il y a déjà eu pas mal de modifs et j'avoue ne pas
toujours avoir compris de quoi il ressort.

PPS- Pourquoi ne pas s'ouvrir un compte sur sourceforge pour gérer
collectivement le développement des différentes parties de SPIP sous la
bienveillance d'Arno.

2

Hello Aris,

- Où (ou comment) se règle le nombre d'articles et de brèves qui sont
affichés en "une" par exemple ? il me semble que c'est un paramàtre dans le
fichier sommaire.html, mais comme je n'ai pas encore plongé en détail dans
le code je n'en suis pas certains.

Ca fait partie des squelettes (.html) de la partie publique : la syntaxe
des boucles sur brèves et articles est expliquée dans la doc d'Arno
(grosso modo il y a un paramètre de type {par date}{0, 3} qui dit
qu'il faut classer les documents par date et prendre les trois premiers
à partir du rang zéro).

Pour moi le bouton pour "recharger" la page (en bas à gauche) ne fonctionne
pas: il me renvoi sur test.com (!) vu que SPIP est installé dans un
répertoire test... ce doit être une erreur de lien

Heu, dommage, le bouton sert justement à recalculer les pages du cache ;))....
C'est à cause des variables d'environnement utilisées. Je l'ai configuré
pour utiliser $SERVER_NAME qui d'après ce que j'ai trouvé est une variable
standard CGI donnant l'adresse du serveur. Malheureusement ça marche pas
partout (pas chez Free par exemple). Avant, ça utilisait uniquement $REQUEST_URI,
mais là aussi ça ne marchait pas partout (chez Free mais pas les clones Altern ;-)).
Malheureusement il n'y a pas de variables permettant de donner l'adresse du serveur
qui marchent à la fois sur les deux hébergeurs que je teste. Faudrait une
heuristique pour décider si le $REQUEST_URI contient effectivement le nom
du serveur, sinon rajouter le $SERVER_NAME devant.

En attendant, les durées d'expiration des documents dans le cache sont dans
les rubrique/breve/article/index.php3 de la partie publique (en secondes :
mets 5 ou 10 pour tester).

Sinon cela rique d'être vite le
bordel. en quelques jours il y a déjà eu pas mal de modifs et j'avoue ne pas
toujours avoir compris de quoi il ressort.

J'avoue que c'est ma faute, j'ai déboulé ici avec la finesse d'un rhino
dans un magasin de faïences, mais n'ayant pas d'accès en écriture au FTP
du scarabée, et ayant malgré tout besoin (et envie) d'un SPIP qui marche,
j'ai communiqué mes modifs comme j'ai pu.

Bon sinon, pour le problème soulevé par Nicolas, je suis en train
d'écrire un contournement, en déplaçant le répertoire IMG (qui contient
les images importées par les rédacteurs dans les articles) à l'intérieur
du répertoire ecrire. Inconvénient : à cause du .htaccess, il y a un petit
script supplémentaire dans le répertoire public pour appeler les images
des articles. Si quelqu'un a une meilleure solution...

PPS- Pourquoi ne pas s'ouvrir un compte sur sourceforge pour gérer
collectivement le développement des différentes parties de SPIP sous la
bienveillance d'Arno.

Personnellement je ne connais rien à sourceforge, mais pourquoi pas ?

a+

Antoine.

3

Antoine Pitrou wrote:

Bon sinon, pour le problème soulevé par Nicolas, je suis en train
d'écrire un contournement [...]

C'est fait :

http://pitrou.free.fr/spip.zip
http://pitrou.free.fr/spip.tar.gz

Il faut donc maintenant créer le sous-répertoire IMG à l'intérieur
du répertoire ecrire.

Pour les fichiers au format DOS, normalement c'est réglé.

4

Il faut donc maintenant créer le sous-répertoire IMG à l'intérieur
du répertoire ecrire.

Ouh là... alors celle-là, elle me plait pas du tout... :slight_smile:

Deux raisons pour ne pas faire comme ça:

(1) L'appel des fichiers graphiques via un script avec un header, si on commence avec ce genre de finasseries, on n'est pas sortis de l'auberge. Ca fait des fichiers graphiques appelés avec un nom exotique (merci pour les sauvegardes d'images via le Web! le type qui monte un galerie de photos va se flinguer...), un contrôle totalement imbitable pour le webmestre qui aurait le goût de faire des modifs directement par ftp (puisqu'il ne sait plus où sont les images d'une manière "instinctive").

(2) Par ailleurs, le site se trouve directement lié au dossier "ecrire" à partir du moment où des éléments du site (les images) y sont stockées. Or, quand y'a un pépin, une config qui foire, un problème avec les mots de passe des admins, le plus simple, c'est de prendre le dossier "ecrire" et de le mettre à la poubelle; puis d'en installer un propre. Ca pourrait même être une façon de faire les mise-à-jour majeures (genre: gros gros changements dans SPIP) sans difficulté (on jette "ecrire v1" et on le remplace par "ecrire v2"). Là, on ne peut plus, sinon on risque de dégager les images avec.

Et puis ça risque de compliquer des développements futurs. En particulier, l'intégration de fichiers multimédia (quickime, mp3, flash, n'importe quel format) dans des articles. Si on commence à gérer nous-mêmes les headers, on court au massacre, parce qu'il faudra prévoir tous les formats possibles et imaginables.

Non, vraiment, c'est se lancer dans des complications extrêmes. Il faut trouver une solution plus simple. Et avec AUCUN élément du contenu du site dans le dossier /ecrire (qu'on doit pouvoir virer et remplacer d'un coup de baguette magique).

De ce que j'ai pigé, c'est la commande opendir qui est refusée. J'ai découvert ça récemment chez certains gratuits: ils refusent les opendir (lire un directory) qui remontent dans la hiérarchie des dossiers. Mais je crois que les file_exists(../..), eux, fonctionnent toujours, non? Dans ce cas, on peut tenter le coup autrement.

Sinon, j'ai aussi le problème avec les fichiers d'Antoine: les accents déconnent sur Mac (même tar.gz).

Du coup, j'ai modifié l'accès anonyme au FTP:
ftp://www.scarabee.com
l'upload est désormais accepté (bon, ben, faut faire un peu plus attention aux manipulations). Antoine, est-ce que tu peux charger tes fichiers modifiés (de préférence, la version avant la bidouille avec image.php3 qui ne me plait pas du tout)? J'espère que tes accents passeront correctement. Dans ce cas, tu peux aussi installer ton spip.zip, spip.tar.gz, et moi j'installerai un spip.sit pour Mac.

Pour une numérotation, je propose de commencer à 0.5, parce que c'est déjà bien avancé, mais que le site public n'est pas terminé. A priori, dès que le système de boucles est terminé, on pourra lancer une version 1.0beta (beta, histoire d'indiquer que c'est pas testé sur beaucoup de serveurs). On n'a qu'à numéroter les versions compressées: spip_0_5.zip, etc.

Aris, si tu veux commencer à bosser sur un install.txt, n'hésite pas (merci du coup de main). Tu peux l'intaller directement à la racine du ftp (quand on arrive sur le ftp, directement, comme ça il sera bien en évidence). Ah oui: on doit modifier les autorisations d'accès aux dossiers /ecrire, /CACHE et /IMG; j'ai pas creusé la question: est-ce que ça peut poser des problèmes de sécurité?

Amicalement,
ARNO*

5

Salut,

ARNO* wrote:

Ouh là... alors celle-là, elle me plait pas du tout... :slight_smile:

Je suis d'accord, c'est très crade.... Tant pis :wink:

A ce que j'ai lu dans la doc php, la restriction
open_basedir affecte toutes les opérations sur les fichiers
(http://fr.php.net/manual/configuration.php) - y compris,
j'imagine, include() et autres. La config chez pas mal
d'hébergeurs est probablement de restreindre l'accès au
répertoire du script et ses descendants. Une solution
est donc d'avoir deux répertoires IMG synchronisés
ensemble : un à la racine, un dans ecrire. Ca laisse
juste le problème de bien recopier les fichiers si on
fait une réinstallation.

Sinon, j'ai aussi le problème avec les fichiers d'Antoine: les
accents déconnent sur Mac (même tar.gz).

Justement, il vaut mieux utiliser le .zip... je viens de me rendre
compte que tar.exe (versions DJGPP et Cygwin) est une belle daube
qui transforme les fichiers textes format Unix en format Dos
(oui, oui, un programme d'archivage qui ne te restitue pas les
données exactes....). Le dernier .zip devrait aller : j'ai pris
soin de laisser tous les fichiers en Unix (en tout cas c'est que
me dit UltraEdit). Sinon, faudra que je passe les accents en
entités HTML....

Antoine, est-ce que tu peux charger tes
fichiers modifiés (de préférence, la version avant la bidouille avec
image.php3 qui ne me plait pas du tout)?

Bon, je fais ça demain (enfin tout à l'heure) : défaire la bidouille,
vérifier, et télécharger les fichiers.

Ah oui: on doit modifier les autorisations d'accès
aux dossiers /ecrire, /CACHE et /IMG; j'ai pas creusé la question:
est-ce que ça peut poser des problèmes de sécurité?

En lecture : pour cache et img, l'enjeu n'est pas énorme ;)).
Pour ecrire, étant donné que le .htaccess n'est pas forcément
utilisé, il faut que tous les scripts php fassent appel au minimum
à inc_connect.php3 et inc_auth.php3, pour filtrer l'utilisation.
Il faut aussi qu'il ne contienne pas de données sensibles
(coll_act.txt n'a pas l'air très sensible :-).

En écriture : je ne vois pas comment exploiter la possibilité
d'écrire dans ces répertoires si on n'a pas la possibilité d'écrire
des scripts pour y accéder. La restriction open_basedir mentionnée
plus haut est là justement pour éviter ce genre de problèmes
(accéder à un compte chez un hébergeur depuis un autre compte
en contournant les restrictions FTP et HTTP).

a+

Antoine.

6

(coll_act.txt n'a pas l'air très sensible :-).

Un petit mot sur coll_act.txt, qui semble laissé tout le monde dubitatif...

Il est généré lorsqu'on modifie la structure du site et qu'on publie des articles. Il s'agit d'un fichier texte contenant la liste des numéros des "rubriques actives" (qu'au début j'appelais "collections"). Sous la forme:
"21,32,16,12,7,1"

C'est fait pour faciliter (accélérer, notamment) la construction des pages publiques. Cette liste est donc générée par la partie privée, mais utilisée uniquement dans la partie publique.

Les rubriques "actives" sont les rubriques qui:
- contiennent au moins un article publié;
- contiennent une rubrique active (c'est-à-dire une rubrique contenant un article publié, ou une rubrique contenant une rubrique contenant ... contenant un article publié).

En effet, dans le site public, il ne faut pas afficher _toute_ la rubrique du site créée par les admins, mais uniquement les rubriques actives. En effet, pour "travailler", on fabrique souvent une structure avant de faire les articles, certaines rubriques étant vides, en attendant qu'on y publie des articles. Pour le visiteur, on ne doit pas afficher ces rubriques, faute de quoi il visiterait des rubriques vides (culs de sac), ce qui ferait très mauvais effet.

Donc "coll_act" est la liste des rubriques à afficher (exclusivement).

Le calcul est un peu lourd (surtout sur un site qui contient de très nombreuses rubriques): il faut en effet tester les rubriques de manière récursive. Donc de nombreux appels mySQL.

Comme c'est utilisé très souvent (en fait, chaque fois qu'on appel des boucles de rubriques - genre "afficher les rubriques dans cette rubrique", etc.), cette liste est précalculée dans le site privé. Ensuite c'est stocké dans le fichier, placé dans une variable $coll_actives, puis utilisé tel quel dans les requêtes mySQL:

... AND FIND_IN_SET(id_rubrique,\"$coll_actives\")>0

(c'est-à-dire sélectionner uniquement les rubriques dont l'id_rubrique est compris dans la liste $coll_actives).
Bref, c'est fait pour accélérer les calculs et alléger le serveur mySQL (quelques dizaines de requêtes mySQL évitées à chaque fois).

Amicalement,
ARNO*