Re-bjr,
Voici un récapitualif des conventions de traitement des textes pour SPIP
fait pour mes petits camarades de samizdat... cela peut servir à d'autres.
Aris
Typographie
Yo,
j'ai mis le zip et le tar.gz de la version 0.99b à
l'adresse de téléchargement. Beaucoup de nouveautés
(je risque d'en oublier quelques-unes).
- Une aide en ligne concotée par Arno, pour un certain
nombre de tâches quotidiennes sous spip.
- Un système permettant de personnaliser les URLs des pages
publiques (articles, rubriques, brèves, forums). A cet effet,
vous pouvez changer le mode de génération des URLs dans
inc-urls.php3 à la racine de SPIP. Les deux méthodes prédéfinies
sont "standard" et "html" et correspondent respectivement
à des URLs du type "article.php3?id_article=123" et
"article123.html". Vous pouvez également choisir vos
propres formats d'URL. Par exemple créer un fichier
inc-urls-samizdat.php3 (pour commencer, il est conseillé de
recopier le contenu d'inc-urls-standard.php3), et y
modifier les fonctions de générations d'URL (dont la
syntaxe vous apparaîtra à peu près évidente). Ensuite,
dans inc-urls.php3, sélectionner le type "samizdat".
Evidemment, c'est à vous d'écrire les fichiers de
configuration Apache correspondants (.htaccess ou
httpd.conf) : ceux-ci étant fortement dépendants
du serveur sur lequel vous travaillez, il nous est
impossible de vous fournir des exemples qui marchent
à coup sûr.
- De nouveaux champs #URL_ARTICLE, #URL_RUBRIQUE, #URL_BREVE
et #URL_FORUM correspondent à l'application dans les
squelettes des fonctionnalités ci-dessus. Ainsi tous les
liens du sites sont générés automatiquement, et en
changeant une variable dans inc-urls.php3 vous changez
le type d'urls internes sur l'ensemble des liens générés
par les squelettes (n'oubliez pas de recalculer les pages
pour voir le résultat). Les squelettes par défaut ont
été mis à jour en conséquence.
- La gestion du cache a été adaptée pour tenir compte de
cette nouvelle fonctionnalité.
- Une nouvelle table est créée dans la base MySQL, nommée
spip_forum_cache : elle permet de gérer les dépendances
des pages mises en cache vis-à-vis des forums, et de supprimer
automatiquement les pages concernées quand une intervention
est ajoutée dans un forum (ainsi ces pages sont recalculées
à la prochaine visite).
- Un nouveau champ #PARAMETRES_FORUM, permettant d'ajouter
les paramètres CGI nécessaires si jamais vous décidez d'inclure
le formulaire de réponse dans une page spécifique.
(exemple d'utilisation dans une boucle forums :
<A HREF="repondre_forum.php3?#PARAMETRES_FORUM">Répondre à ce message</A>
repondre_forum.php3 étant une nouvelle page que vous avez
créée qui appelle un squelette contenant un #FORMULAIRE_FORUM)
- Une nouvelle fonctionnalité : ajouter un logo à un
article, et les champs correspondants dans les squelettes :
#LOGO_ARTICLE et #LOGO_ARTICLE_RUBRIQUE. Arno pourra
éventuellement vous donner des détails.
- Un numéro de version est inclus (sans l'indication de version
mineure, donc par exemple 0.99 au lieu de 0.99b) afin de tester
s'il est nécessaire de relancer l'installation pour mettre à
jour la base de données.
- ...
a+
Antoine.
Salut,
Je viens d'installer la version 0.99b pour Macintosh (donc au format Stuffit: ".sit").
Rappel, les versions sont stockées à l'adresse:
http://www.minirezo.net/archives
Procédure de mise à jour
hello
juste une petite question avant d'y aller :
pour updater de la version 98 à 99b SANS PERDRE les données et la
présentation que l'on a mis en place sur son site :
1) il faut mettre tous les fichiers de la 99b SAUF les squelettes html sur
le site en écrasant les précédents ?
2) puis refaire une installation ce qui ajouterait les tables et champs
supplémentaires, SANS mettre en l'air ce qui existe déjà ?
Aucun risque pour l'existant c'est bien cela , C'EST BIEN SUR ?
amts
richard
-----Message d'origine-----
hello
juste une petite question avant d'y aller :
pour updater de la version 98 à 99b SANS PERDRE les données et la
présentation que l'on a mis en place sur son site :1) il faut mettre tous les fichiers de la 99b SAUF les squelettes html sur
le site en écrasant les précédents ?
C'est ça.
Au passage, un ch'ti conseil: travailler ses propres squelettes dans un autre dossier sur son ordinateur perso. Comme ça, le risque d'écraser n'est pas grave: il suffit de réinstaller ses propres "article.html", etc.
2) puis refaire une installation ce qui ajouterait les tables et champs
supplémentaires, SANS mettre en l'air ce qui existe déjà ?Aucun risque pour l'existant c'est bien cela , C'EST BIEN SUR ?
C'est le principe: la mise à jour ajoute les tables et les champs nécessaires, et dans le cas présent bidouille les champs des forums déjà existants.
"Aucun risque": ben c'est une bêta, tout de même :-))
Cela dit, ça a bien fonctionné jusqu'à maintenant.
ARNO*
Hello
j'ai mis les fichiers 99b où il fallait (sans écraser les squelettes HTML)
j'ai réinitialisé en enlevant le inc-connect
la procédure s'est bien passée avec un couac seulement à la fin
Warning: Unable to access current working directory in /inc.php3 on line 2
Warning: Failed opening 'inc_connect.php3' for inclusion (include_path='')
in /inc.php3 on line 2
Attention : un problème technique (serveur MySQL) empêche l'accès à cette
partie du site. Merci de votre compréhension.
L'identification a échoué.
Vous pouvez réessayer ou retourner au sommaire
la partie publique du site est tjrs accessible (donc à priori la base est
bien là et peut être travaillée) mais la partie après tentative
d'identification remet le texte warning ci dessus
C'est un couac que j'avais déjà eu avec la mise en place de la 98e
et qu'il m'a semblé résoudre avec la modification du paramètre localhost
Mais là NIET cela ne marche pas
Un rapport avec le .httaccess du répertoire "ecrire" ???
je ne sais plus trop quoi faire à quelque jour du lancement officiel de ce
site
please help
richard wild
-----Message d'origine-----
Hello Richard,
Warning: Unable to access current working directory in /inc.php3 on line 2
Warning: Failed opening 'inc_connect.php3' for inclusion (include_path='')
in /inc.php3 on line 2
Attention : un problème technique (serveur MySQL) empêche l'accès à cette
partie du site. Merci de votre compréhension.
L'identification a échoué.
Vous pouvez réessayer ou retourner au sommaire
Heu.... pas d'autres symptômes pendant la phase d'installation ?
Tu pourrais réessayer pour voir (resupprimer .htaccess et inc_connect.php3) ?
a+
HELLO SUITE (suis pas sur ma machine - mais cela devrait vous parvenir)
sous toutes réserves - une tentative d'explication puisqu'au bout de
quelques heures après moultes réinstallation cela marche (le même scénario à
peu de chose près qu'avec l'installation de la 98e)
1) sans doute un pb avec le fichier ".httaccess" figurant au niveau
"/ecrire/data" -
- lors de l'installation brute avec écrasement des fichiers etc (brute mais
conforme aux indications) j'ai pu noter à un instant que le fichier
".httaccess" ne contenait qu'un "deny for all" par la suite le fichier
".httaccess" était plus étoffé et valide (de mémoire cela se termine par un
truc du genre LIMIT à présent)
- toujours ce truc bizarre que l'on peut mettre plusieurs possibilités dans
le champ spip localhost et que le logiciel spip accède quand meme a la base
(bon là je ne vais pas me plaindre mais je signale)
- pouvez vous vérifier que votre fichier ".httaccess" généré au niveau
"/ecrire/data" est bien le bon et au bon endroit ? (j'ai meme retrouvé à un
moment un ".httaccess" figurant au niveau "/ecrire" au lieu de l'étage
inférieur "/ecrire/data")
2) une autre élément c'est que les delays d'origine (3 x 3600) sont trop
longs car des modifs peuvent ne pas avoir été pris en compte et les novices
(dont je suis) peuvent avoir un élément de plus pour pédaler dans la
choucroute (euh pardon dans le yaourt - Il vaudrait mieux mettre les taquets
à 10 et demander quand cela fonctionne au novice de remonter à plus long -
amts
rw
-----Message d'origine-----
hello
maintenant que j'ai accès à l'administration de mon site :
1) très sympa les rajouts
2) le mode d'emploi en ligne permet de peaufiner (en tout cas à partir des
étapes ont mené jusque là)
3) Effacer la base de données SPIP : amha - trop dangereux - seul un
superadministrateur ayant accès à phpadmin devrait avoir le droit d'appuyer
sur le bouton - idem pour la sauvegarde de la base (avec les codes etc)
HELLO SUITE (suis pas sur ma machine - mais cela devrait vous parvenir)
sous toutes réserves - une tentative d'explication puisqu'au bout de
quelques heures après moultes réinstallation cela marche (le même scénario à
peu de chose près qu'avec l'installation de la 98e)1) sans doute un pb avec le fichier ".httaccess" figurant au niveau
"/ecrire/data" -
- lors de l'installation brute avec écrasement des fichiers etc (brute mais
conforme aux indications) j'ai pu noter à un instant que le fichier
".httaccess" ne contenait qu'un "deny for all" par la suite le fichier
".httaccess" était plus étoffé et valide (de mémoire cela se termine par un
truc du genre LIMIT à présent)- pouvez vous vérifier que votre fichier ".httaccess" généré au niveau
"/ecrire/data" est bien le bon et au bon endroit ? (j'ai meme retrouvé à un
moment un ".httaccess" figurant au niveau "/ecrire" au lieu de l'étage
inférieur "/ecrire/data")
Bon, je pige pas trop, m'enfin quelques trucs: le .htaccess sert à limiter l'accès aux dossiers. Il y en a donc deux:
/ecrire/.htaccess
est celui qui vérifie l'identification par mot de passe des utilisateurs et admins;
/ecrire/data/.htaccess
contient carrément un "deny for all", c'est-à-dire que ce dossier "data" est carrément inaccessible, même aux admins, via le Web. En effet, c'est lui qui contient les fichiers "sensibles" (liste des mots de passe, sauvegardes du site).
A priori, je ne vois aucun rapport entre l'accès à la base de données et le .htaccess qui ne sert à l'identification via le Web.
- toujours ce truc bizarre que l'on peut mettre plusieurs possibilités dans
le champ spip localhost et que le logiciel spip accède quand meme a la base
(bon là je ne vais pas me plaindre mais je signale)
Ca, ça dépend des serveurs. Certains acceptent à la fois un "localhost", ou une adresse fixe du genre "www.monsite.com"... Voir avec l'hébergeur lequel utiliser.
2) une autre élément c'est que les delays d'origine (3 x 3600) sont trop
longs car des modifs peuvent ne pas avoir été pris en compte et les novices
(dont je suis) peuvent avoir un élément de plus pour pédaler dans la
choucroute (euh pardon dans le yaourt - Il vaudrait mieux mettre les taquets
à 10 et demander quand cela fonctionne au novice de remonter à plus long -
Non. Parce que c'est ce délais qui justifie l'existence du système de cache. Avec un délais de 10 (secondes), les pages seront recalculées carrément à chaque visite, et au revoir les enfants (visites ralenties à l'extrême, et serveur surchargé).
Faudra peut-être mieux le préciser dans la doc, mais c'est à cela que sert le cookie que l'on peut poser dans /ecrire: ajouter un bouton "recalculer" en bas de toutes les pages pour forcer la remise à jour de ces pages.
Amicalement,
ARNO*
3) Effacer la base de données SPIP : amha - trop dangereux - seul un
superadministrateur ayant accès à phpadmin devrait avoir le droit d'appuyer
sur le bouton - idem pour la sauvegarde de la base (avec les codes etc)****************
Effacer la base de données SPIP :
Cette option efface tout le contenu de la base de données, y compris tous
les accès rédacteurs et administrateurs. Après l'avoir exécuté, vous devrez
lancer la réinstallation de SPIP pour recréer une nouvelle base ainsi qu'un
premier accès administrateur.Attention, la suppression des données est irréversible !
****************
Justement: la procédure installée par Antoine est volontairement lourde: il faut créer un dossier via FTP dans /ecrire/data pour pouvoir effectuer ces opérations (sauvegarde, réinstallation, effacement). Donc, de fait, c'est équivalent à un superadmin, puisque seul celui qui détient l'accès FTP sur le site peut effectuer ces manoeuvres.
Amicalement,
ARNO*
ok merci pour les précisions
les couacs d'update sur certains sites resteront donc un mystère , pas trop
grave si cela fini par marcher.
encore un petit "abus de votre patience"
la boucle ci dessous marchait avec la 97 et ne marche plus avec la 99b
(boucle inspirée de la doc initiale)
<B1><UL>
<BOUCLE1(rubriques){id_parent}>
[<LI><A HREF="rubrique.php3?id_rubrique=#ID_RUBRIQUE">(#TITRE)</A>]
<B2><UL>
<BOUCLE2(articles){id_rubrique}>
[<LI>(#TITRE)]
</BOUCLE2>
</UL></B2>
<BOUCLE3(boucle1)></BOUCLE3>
</BOUCLE1>
</UL></B1>
apparaît à l'écran :
BOUCLE1 SELECT * FROM spip_rubriques WHERE id_parent= AND id_rubrique IN
(13,22,14,12,21,19,28,5,3,18,2) BOUCLE1
puis plus rien...
Une idée ?
rw
-----Message d'origine-----
Essaie d'englober le tout dans une boucle supplémentaire :
<B_Racine><UL>
<BOUCLE_Racine(rubriques){racine}>
[<LI><A HREF="#URL_RUBRIQUE">(#TITRE)</A>]
<B1><UL>
<BOUCLE1(rubriques){id_parent}>
[<LI><A HREF="rubrique.php3?id_rubrique=#ID_RUBRIQUE">(#TITRE)</A>]
<B2><UL>
<BOUCLE2(articles){id_rubrique}>
[<LI>(#TITRE)]
</BOUCLE2>
</UL></B2>
<BOUCLE3(boucle1)></BOUCLE3>
</BOUCLE1>
</UL></B1>
</BOUCLE_Racine>
</UL></B_Racine>
ce qui sélectionne toutes les rubriques à la racine du site,
puis exécute la BOUCLE1 de façon récursive sur toutes les
sous-rubriques (avec, à chaque parcours, exécution de la BOUCLE2
pour récupérer les articles).
Ca marche ?
wild medito wrote:
Bravo Antoine cela marche (pensez à modifier la formule magique dans la doc)
il me vient une autre remarque :
on avait dit : la mise à jour c'est grosso modo tout sauf les squelettes
mais en fait les boucles des squelettes ne sont pas épargnées si on veut par
exemple garder le "système permettant de personnaliser les URLs des pages
publiques"
il faut donc ligne par ligne voir quoi modifier dans ces boucles squelettes
(ligne par ligne si on a introduit des modif perso dans les boucles) - c'est
bien cela ?
-----Message d'origine-----
wild medito wrote:
il me vient une autre remarque :
on avait dit : la mise à jour c'est grosso modo tout sauf les squelettes
mais en fait les boucles des squelettes ne sont pas épargnées si on veut par
exemple garder le "système permettant de personnaliser les URLs des pages
publiques"
Oui, effectivement ;)) Dans le cas que tu cites, cela revient simplement à
faire la chasse aux liens HREF="squelette.php3?id_squelette=#ID_SQUELETTE"
et à les remplacer par HREF="#URL_SQUELETTE" (ceci pour squelette=rubrique,
article, breve, forum).
Mais sinon les boucles écrites avec une version devraient tout de même
marcher avec les versions suivantes, même si elles ne tirent pas parti
des nouvelles fonctionnalités. La boucle que tu as dû modifier est
une exception, mais le couac devrait être résolu dans la version suivante.
a+
Je peux me tromper mais il me semble que vous avez laissé un
HREF="article.php3?id_article=#ID_ARTICLE" dans le fichier "auteurs.html"
;))
RW
(Read Write)
-----Message d'origine-----
Non, c'est vrai, mais a priori c'est un fichier de test,
vu qu'il n'est pas lié aux autres ;-))
wild medito wrote:
Salut tout le monde,
Je viens d'installer une version 0.99c. Toujours à l'adresse:
http://www.minirezo.net/archives/
Pour l'instant, c'est la version Mac (.sit). Les versions PC suivront dès qu'Antoine aura 5 minutes.
Encore une fois, il faut procéder à une réinstallation complète (c'est-à-dire effacer le fichier inc-connect.php3 après l'installation des nouveaux fichiers pour déclencher une nouvelle phase d'installation). En effet, il y a deux nouvelles tables mySQL dans SPIP...
La nouveauté, c'est un système de syndication: on peut désormais afficher sur son site les nouveautés d'un ou plusieurs nouveaux sites, et cela entièrement automatiquement. Y'a pas encore de documentation à ce sujet, mais ça viendra...
De quoi s'agit-il?
- Les sites réalisés à partir d'une base de données peuvent très facilement fabriquer une page contenant la liste de leurs dernières mises à jour. Ces fichiers sont dans un format standard en XML. C'est le cas des sites réalisés sous SPIP (le fichier "backend.php3") et sous phpNuke. Par exemple, le fichier des nouveautés de Vakooler se trouve à l'adresse:
http://www.vakooler.com/backend.php3
Une source très pratique de fichiers "backend", c'est le service fourni par le Portail des copains, qui fabrique de tels fichiers pour tous les sites qu'il répertorie:
http://www.rezo.net/backend
- Ces fichiers étant automatisés et dans un format standart, il est très facile pour un autre site d'aller récupérer ces pages, de "lire" les informations délimitées par des balises XML (indiquant, pour chaque article, le titre et l'adresse de l'article, et dans le cas des site SPIP, la date et le nom des auteurs). Ainsi, à chaque mise à jour du site (dans SPIP, par le système de cache intégré), le site va chercher sur le site référencé la liste de ses dernières mises à jour et les affiche dans sa propre mise en page. Avec le système de squelettes de SPIP, on peut en plus configurer très précisément cette mise en page graphique.
Cette fonction existe dans phpNuke. Voyez par exemple sur la page d'accueil de Davduf.net:
http://www.davduf.net/
En bas de la colonne de droite, il y a un encadré "L'autre Portail", référençant les dernières mises à jour de ce site. C'est ce que permet cette nouvelle fonctionnalité de SPIP.
La différence: on associe ces sites "syndiqués" aux rubriques de son propre site SPIP, et on peut mettre autant de sites syndiqués que l'on veut. De cette façon, on peut avoir ces listes de "quoi de neuf" dans des rubriques précises, et même plusieurs sites liés dans une même rubrique. Ca devient très pratique: si vous avez un site avec un classment thématique, vous pouvez indiquer dans chaque rubrique thématique les nouveautés d'autres sites traitant des mêmes thèmes (par exemple, dans la rubrique "Nouvelle économie" d'uZine, signaler les dernières infos de Vakooler, dans la rubrique traitant de privacy signaler les infos de Kitetoa. Ou carrément: faire un "Portail des Copains" bis... :-))
De cette façon, on a une première "passerelle" entre phpNuke et SPIP: des sites sous SPIP peuvent s'interconnecter avec des sites Nuke, histoire d'afficher leurs nouveautés, et inversement. Ca n'est pas encore l'échange de fichiers pur et simple, mais c'est déjà une première étape pour que SPIP s'intègre dans des réseaux de sites...
- Ajouter ces "liens" dans SPIP. Très facile: dans la colonne de gauche, lorsque vous "naviguez" dans les rubriques, apparaît un encadré "Sites syndiqués". Il y a un formulaire d'une seule case: dans cette case vous indiquez l'URL de la page de syndication du site visé (par exemple: http://www.vakooler.com/backend.php3). Ca vous mène à une page qui vous permet de vérifier que ça fonctionne: si ça fonctionne, la liste des nouveautés ainsi que le titre du site visé apparaissent. Juste en dessous, un second formulaire est déjà rempli automatiquement à partir des infos récupérées: le titre du site visé, l'URL de sa page d'accueil et son descriptif; vous pouvez si nécessaire modifier ces informations (surtout si le webmestre de ce site a mal configuré son fichier backend). Validez, ça revient à la page de la rubrique SPIP, et le site apparaît dans la colonne de gauche (vous pouvez le supprimer d'un clic).
Pour les boucles, faudra l'ajouter à la documentation, mais en voici une très simple à recopier dans un squelette de rubrique:
<BOUCLE_syndic(SYNDICATION){id_rubrique}>
<LI><B><A HREF="#URL_SITE">#NOM_SITE</A></B>
<BR>#DESCRIPTIF
<UL>
<BOUCLE_syndic_articles(SYNDIC_ARTICLES){id_syndic}{0,5}{par date}{inverse}>
<LI><A HREF='#URL'>#TITRE</A> [par (#LESAUTEURS), ] [(#DATE|affdate)]
</BOUCLE_syndic_articles>
</UL>
</BOUCLE_syndic>
La boucle "BOUCLE_syndic" est d'un type nouveau: SYNDICATION. Une telle boucle affiche la liste des sites liés. Ici, la sélection se fait selon l'id_rubrique de la rubrique dans laquelle on se trouve. On peut aussi mettre "id_secteur" (récupérer toutes les syndications de ce secteur), ou "tout" (pour toutes les syndications du site). On peut bien entendu mettre un classement (par nom_site), et une limite d'affichage {0,5}. Notez bien: la boucle SYNDICATION récupère le nom, l'URL et la description des sites syndiqués, et non de leurs brèves.
Pour récupérer la liste des "brèves" (items du "quoi de neuf" de ces sites), il faut une seconde boucle, cette fois du type SYNDIC_ARTICLES. Cette boucle récupère la liste des articles eux-mêmes, et non plus le nom des sites syndiqués. Ici, on l'a installée à l'intérieure de la première boucle, ce qui permet une présentation selon les sites syndiqués (on affiche le nom d'un site, puis la liste de ses nouveautés, puis on recommence avec un autre site syndiqué). D'où la sélection par {id_syndic}. On pourrait se passer de la première boucle, et attaquer directement avec la liste des brèves, en sélectionnant ainsi:
<BOUCLE_nouveautes(SYNDIC_ARTICLES){id_rubrique}{0,5}{par date}{inverse}>
(comprendre: sélectionner les 5 brèves les plus récentes des sites liés à cette rubrique). Par rapport à la première méthode en deux boucles imbriquées, ici on récupère une seule liste dans laquelle les brèves de plusieurs sites sont mélangées).
ATTENTION: le fonctionnement de la syndication implique que votre site fasse des appels à d'autres sites. Cela peut s'avérer impossible sur certains serveurs (protection). On a déjà choisi une méthode qui permet de contourner la limitation la plus répandue sur les serveurs grand public, mais on ne peut garantir que ça fonctionne partout. Et là, on n'y peut vraiment rien. Mais bon, ça ne doit pas bloquer le fonctionnement de votre site: au pire, vous ne pourrez simplement pas ajouter de sites syndiqués dans votre machin.
ATTENTION 2: qui dit appels vers l'extérieur dit: "vous dépendez de l'extérieur". Si un serveur syndiqué déconne, ça peut poser des problèmes (pages difficiles à calculer?). Bon, à priori, avec la méthode qu'on a choisie, ce genre de gel desvrait être limité, m'enfin faut en être conscient: si vous appelez 200 sites sur toutes les pages de votre site, ça risque de ne pas très bien se passer.
Ah oui, autre chose: par rapport à phpNuke, le système de syndication de SPIP intègre la date de publication et le nom des auteurs. Si un site sans date de publication est syndiqué (phpNuke), votre site ajoutera aux articles récupérés la date à laquel il les a récupérés pour la première fois. Du coup, au moment de la mise en route d'une syndication, ces dates seront "fausses", c'est-à-dire fixées toutes au jour de cette syndication; mais au fur et à mesure, ça redeviendra cohérent (puisque les articles suivants seront datés du moment de leur apparition en ligne). De plus, SPIP conserve dans sa base toutes les références des articles syndiqués: vous n'êtes donc pas limités aux 10 ou 15 articles affichés "en ce moment" dans le fichier backend du site syndiqué, vous pouvez afficher ceux que vous avez stockés sur votre site (si au bout d'un an, vous voulez afficher 500 liens "quoi de neuf", libre à vous...).
Dernière chose: les fichiers backend sont récupérés à chaque mise à jour des pages (quand SPIP va chercher une page en cache, rien n'est recalculé). Donc si vous faites une page rubrique remise à jour toutes les 2 semaines, un site syndiqué ayant des mise à jour toutes les heures ne sera pas correctement référencé! A l'inverse, si vous fixer un délais du cache très court (genre 10 secondes comme le préconisait Richard), vous faites un appel vers les sites syndiqués toutes les 10 secondes: votre site risque de ramer sévère.
Amicalement,
ARNO*
-----Message d'origine-----
1) Arno : "A l'inverse, si vous
fixer un délais du cache très court (genre 10 secondes comme le
préconisait Richard), vous faites un appel vers les sites syndiqués
toutes les 10 secondes: votre site risque de ramer sévère."
meuh non ! il s'agissait de durées courtes uniquement lors de la mise en
place initiale du site pour permettre les mises en place... pas pour le long
terme
2) les gars hier je me suis farci le passage de 97 à 99b - alors que la
suite était sous le coude - faudrait nous dire le projets de sortie pour que
l'on s'organise pour les mises z'à jour - cela serait vraiment sympa -
surtout pour les galériens de l'installation comme nous
amts
rw