Re: Syndication vs... Verisign !

impressionnant !

Le mar 30/09/2003 à 19:18, Antoine a écrit :

> Conclusion : utilisez de préférence des .org, et
> demandez à vos hébergeurs et fournisseurs d'accès
> de mettre en place des moyens de blocage de la

pu perso, ca a été mis en place sur L'Autre Net le soir même de
l'installation foireuse de Verisign .

avec intégration dans le paquet alternc, donc tous les hébergeurs
utilisant cet outil sont "protégés".

A+

impressionnant !

Le mar 30/09/2003 à 19:18, Antoine a écrit :

> Conclusion : utilisez de préférence des .org, et
> demandez à vos hébergeurs et fournisseurs d'accès
> de mettre en place des moyens de blocage de la

pu perso, ca a été mis en place sur L'Autre Net le soir même de
l'installation foireuse de Verisign .

avec intégration dans le paquet alternc, donc tous les hébergeurs

Re: Syndication vs... Verisign !

Bon j'ai résolu le problème en arrêtant de m'auto-syndiquer.

C'est dommage, j'avais une rubrique de démonstration pour montrer comment
spip syndique bien, mais bon, là j'avais l'air d'un con avec mes gamble
etc...

Je réessayerai ça plus tard.

Merci pour votre aide.

 <at>  +

BoOz

"DaffyDuke" <daffyduke <at> lautre.net> a écrit dans le message de
news:1064967387.935.172.camel <at> ebola.acme.com...
> impressionnant !
>
> Le mar 30/09/2003 à 19:18, Antoine a écrit :
>
> > Conclusion : utilisez de préférence des .org, et
> > demandez à vos hébergeurs et fournisseurs d'accès
> > de mettre en place des moyens de blocage de la
>
> pu perso, ca a été mis en place sur L'Autre Net le soir même de
> l'installation foireuse de Verisign .
>
> avec intégration dans le paquet alternc, donc tous les hébergeurs
> utilisant cet outil sont "protégés".
>

suggestion recalcul du cache

Pour provoquer un recalcul du cache, je comprends qu'il existe deux options:
ou relcalculer juste la page qu'on vient de modifier, ou une vidange
complète du cache.

Dans la logique d'un site multilingue, où chaque rubrique de niveau
supérieur correspond à une langue différente, serait-il possible de proposer
un recalcul intermédiaire? C.a.dire recalculer toutes les pages dans une
certaine langue (donc appartenantes à la même rubrique supérieure?). Cela
permettrait de mettre à jour les liens de navigation juste pour cette
langue.

Pour moi ce serait utile, (web estimé à 1000 pages, dont environ 100 en
français, anglais et allemand, et un peu moins dans d'autres langues). Si
cela intéresserait d'autres, je ne sais pas...

Paolo

Pour provoquer un recalcul du cache, je comprends qu'il existe deux options:
ou relcalculer juste la page qu'on vient de modifier, ou une vidange
complète du cache.

Dans la logique d'un site multilingue, où chaque rubrique de niveau
supérieur correspond à une langue différente, serait-il possible de proposer
un recalcul intermédiaire? C.a.dire recalculer toutes les pages dans une
certaine langue (donc appartenantes à la même rubrique supérieure?). Cela
permettrait de mettre à jour les liens de navigation juste pour cette
langue.

Re: [lautre-techos] Re: Problème de charge sur lautre3 (fwd)

Bonjour,

Remarque vue au sujet de spip et de son cache qui ne cacherait pas
assez...

Qu'en pensez-vous ?

	Yannick

PS: Il me semble que BohwaZ (est/a été) abonné à cette liste.

---------- Forwarded message ----------
Date: Wed, 1 Oct 2003 11:51:04 +0200
From: BohwaZ <bohwaz <at> free.fr>
To: techos <at> lautre.net
Subject: Re: [lautre-techos] Re: Problème de charge sur  lautre3

On Wed, 01 Oct 2003 00:38:28 +0200
rocbo <rocbo <at> wanadoo.fr> wrote:

> Salut
>
> Concernant SPIP, par defaut, les delais de rafraichissement des pages
> stockees en cache sont de l'ordre de 24 heures. exemple :
>
> <?php
> $fond = "article";
> $delais = 24 * 3600;
> include ("inc-public.php3");
> ?>

Re: Re: [lautre-techos] Re: Problème de charge sur lautre3 (fwd)

> Hélas si car SPIP n'a pas un "vrai" système de cache hélas. Il ne fait pas que ressortir la page en cache,
il exécute aussi quelques requêtes SQL et une ribambelle de code PHP. Ca n'est pas un vrai cache car on a
des requêtes SQL et plein de code PHP. Personnellement mon système de cache fait ceci:
> 
> Fichier article.php:
> 
> $limite_cache = 24 * 3600;
> $cache_name = "article".$id_article;
> $squelette = "article.html";
> include "inc.php";
> 
> et dans inc.php:
> 
> include "class.cache.php";
> 
> $cache = new cache();
> if($cache->existe($cache_name) && !$cache->expire($cache_name,$limite_cache)) {
> 	include $cache->chemin_cache.$cache_name;
> 	exit;
> }
> 

il manque plus que le source de la classe Cache. Mais bon ca doit
ressemble a qq chose comme ca (pas tres compliqué je presume)

class cache {
   // constructeur ; il ne fait rien puisqu'il n'y a pas de parametres.
   function cache(){
   }

Re: Re: [lautre-techos] Re: Problème de charge sur lautre3 (fwd)

Le Wed 01/10/2003 à 12:21, Yannick Patois a écrit :

> $limite_cache = 24 * 3600;
> $cache_name = "article".$id_article;
  Un peu trop facile : s'il y a d'autres arguments ? si le premier qui
met en cache est admin et insère donc les boutons d'admin ? s'il y a un
formulaire forum à changer selon que l'internaute est logué ou pas ?
  C'est vrai que le cache spip est un beau bordel coté "faut il prendre
la version en cache ou pas", mais tout ce qui y est fait à une raison de
l'être.
  J'ai tenté de simplifier ça une fois, pour remplacer par des
RewriteRule (=> même plus de php du tout pour faire l'include dans ce
cas), mais c'est vraiment tordu à faire, et ça restreint à un minimum
de cas.

À+, Pif.

Le Wed 01/10/2003 à 12:21, Yannick Patois a écrit :

> $limite_cache = 24 * 3600;
> $cache_name = "article".$id_article;
  Un peu trop facile : s'il y a d'autres arguments ? si le premier qui
met en cache est admin et insère donc les boutons d'admin ? s'il y a un
formulaire forum à changer selon que l'internaute est logué ou pas ?
  C'est vrai que le cache spip est un beau bordel coté "faut il prendre
la version en cache ou pas", mais tout ce qui y est fait à une raison de
l'être.
  J'ai tenté de simplifier ça une fois, pour remplacer par des

[modif] squelettes

Salut,

Ci-join une modif des squelettes. 

Bise. 

-------------------------------------------------------------
NetCourrier, votre bureau virtuel sur Internet : Mail, Agenda, Clubs, Toolbar...
Web/Wap : www.netcourrier.com
Téléphone/Fax : 08 92 69 00 21 (0,34 € TTC/min)
Minitel: 3615 NETCOURRIER (0,16 € TTC/min)

diff -u article-dist.html
--- article-dist.html	Thu Sep 04 12:11:14 2003
+++ article-dist.html	Wed Sep 24 19:20:06 2003
 <at>  <at>  -1,4 +1,4  <at>  <at> 
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
 <BOUCLE_article_principal(ARTICLES) {id_article}>

 <html lang="#LANG">
diff -u auteur-dist.html
--- auteur-dist.html	Thu Sep 04 12:11:14 2003
+++ auteur-dist.html	Wed Sep 24 19:20:12 2003
 <at>  <at>  -1,4 +1,4  <at>  <at> 
-<HTML lang="#LANG">
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd"><HTML lang="#LANG">

suggestion recalcul du cache

Pour provoquer un recalcul du cache, je comprends qu'il existe deux options:
ou relcalculer juste la page qu'on vient de modifier, ou une vidange
complète du cache.

Dans la logique d'un site multilingue, où chaque rubrique de niveau
supérieur correspond à une langue différente, serait-il possible de proposer
un recalcul intermédiaire? C.a.dire recalculer toutes les pages dans une
certaine langue (donc appartenantes à la même rubrique supérieure?). Cela
permettrait de mettre à jour les liens de navigation juste pour cette
langue.

Pour moi ce serait utile, (web estimé à 1000 pages, dont environ 100 en
français, anglais et allemand, et un peu moins dans d'autres langues). Si
cela intéresserait d'autres, je ne sais pas...

Paolo

! Re: multilinguisme / sélection du squelette en fonction de la langue

----- Forwarded message from Fil <fil <at> rezo.net> -----

Date: Sun, 27 Jul 2003 23:53:11 +0200
Subject: Re: [spip-trad] multilinguisme

>  <at>  Luis Speciale <speciale <at> club-internet.fr> écrivait :
> > Une question peut être stupide mais assez courte : on pourra utiliser le
> > champ lang pour déterminer un jeu de squelettes (et une cache ?) spécifique
> > à chaque langue ? 
> 
> Le cache non, ça serait inutile. En revanche, le squelette c'est une bonne
> suggestion. Si on décide par exemple que article.es.html est le squelette
> pour les articles en langue 'es', article.html le squelette pour les autres,
> ça peut marcher ; la seule question à résoudre c'est une question de
> priorités entre la résolution du nom du squelette via la langue et via la
> rubrique (article.es.html, article-7.html, article-7.es.html ????)...

Voilà, c'est programmé, et ça permet de faire tout ce qu'on voulait en
matière de multilinguisme :

* une distribution avec des squelettes par défaut dans toutes les langues :
    sommaire-dist.es.html, sommaire-dist.fr.html, etc....

* des squelettes différents selon la langue de l'article, de la rubrique,
  etc. :
    article.es.html, article-7.es.html

Le mécanisme de sélection d'un squelette est désormais le suivant (partons,
par exemple, d'un article 17 dans la rubrique 8, elle-même sous-rubrique de

Petite modif affichage des referers

Salut,

Toute petite modif de la présentation des référers: quand il n'y a qu'une 
lien (pas de regroupement de plusieurs liens d'un même host), l'URL 
présentée pointe entièrement vers la page référer. Dans la version 
précédente, la partie racine de l'URL pointait vers la racine du site. Cela 
rendait l'usage de cette page finalement très peu pratique: en effet, pour 
repérer les liens "nouveaux" (en tout cas, ceux qu'on n'a pas encore 
regardé), seule la fin de l'URL changeait de couleur (vlink, hein). Là, 
visuellement, on a des lignes d'une seule couleur: soit le lien a été 
visité, soit il l'a pas été.

A*

Salut,

Toute petite modif de la présentation des référers: quand il n'y a qu'une 
lien (pas de regroupement de plusieurs liens d'un même host), l'URL 
présentée pointe entièrement vers la page référer. Dans la version 
précédente, la partie racine de l'URL pointait vers la racine du site. Cela 
rendait l'usage de cette page finalement très peu pratique: en effet, pour 
repérer les liens "nouveaux" (en tout cas, ceux qu'on n'a pas encore 
regardé), seule la fin de l'URL changeait de couleur (vlink, hein). Là, 
visuellement, on a des lignes d'une seule couleur: soit le lien a été 
visité, soit il l'a pas été.

A*