Re-hello,
Je viens juste d'installer une beta4 (sans problèmes aucun, moins de 10
minutes). Après coup d'oeil rapide sur la nouvelle interface graphique je
trouve cela plutôt fonctionnel, en particulier le coup du mémo :))
Je ferais donc juste 2 remarques :
1) Il me semble que c'est plus lent à l'affichage que la précédente.
2) On fait comment désormais pour administrer les rubriques genre en
supprimer une ou en renomer une ?
Aris
Salut,
Je viens de modifier la page "Afficher tout le site", du coup, nouveaux fichiers:
/ecrire/inc.php3
/ecrire/articles_tous.php3
/ecrire/articles_class.php3
(pour le dernier, c'est pas important, c'est juste pour unifier la présentation).
Dans inc.php3, modif de la fonction "afficher_articles", avec plus de paramètres. Et bien entendu, l'essentiel est dans "articles_tous.php3.
Bon, quelques détails graphiques à modifier (les triangles sur le mauvais fond, beurk!), mais ça fonctionne.
-> Désormais, on déplie les rubriques une par une, ce qui est pratique pour les très gros sites (sinon, l'affichage de cette page sera monstrueux); on peut tout de même afficher l'intégralité d'un coup si on veut ("tout déplier" - je ferai un icône).
-> On retrouve surtout la fonction qui avait disparu: "supprimer" les rubriques vides.
Bon, sous Netscape, y'a un ch'tit bug graphique avec la colonne de droite, mais ça m'a semblé acceptable.
1) Il me semble que c'est plus lent à l'affichage que la précédente.
Yop, forcément: avant on avait une seule image qui ne contenait que quelques couleurs (et en plus, totalement uniformes), maintenant on a une tripotée de petits logos avec survol et effets de relief.
Je proposerai une version où le "survol" des boutons des désactivés, et du coup je pourrai aussi limiter le nombre de fichiers graphiques.
De plus, je systématise l'usage de tableaux pour la présentation de listes, ce qui ralentit un poil l'affichage.
2) On fait comment désormais pour administrer les rubriques genre en
supprimer une ou en renomer une ?
Pour l'administration des rubriques, voir le nouvel article "articles_tous.php3. La page spécifique "Les rubriques" de la version précédente faisait double-emploi, on a donc fusionné avec celle-ci, ça devient plus cohérent. (Et pour créer des sous-rubriques, on passe par "naviguer dans le site" - peut-être que je pourrai ajouter des petits boutons dans cette nouvelle version de "tous le site").
Amicalement,
ARNO*
Yo,
Bon, quelques détails graphiques à modifier (les triangles sur le
mauvais fond, beurk!), mais ça fonctionne.
Dans le même style, les nouvelles puces sont moins jolies qu'avant !
-> Désormais, on déplie les rubriques une par une, ce qui est
pratique pour les très gros sites (sinon, l'affichage de cette page
sera monstrueux); on peut tout de même afficher l'intégralité d'un
coup si on veut ("tout déplier" - je ferai un icône).
Mmmmh, y a un problème : une URL ne doit pas faire plus de 256 caractères.
Ca risque de les dépasser avec ton système (sur un site avec bcp de
rubriques).
Plus prudent : "tout déplier" déclenche une variable deplie=oui,
et tu rajoutes juste la liste des rubriques repliées.
-> On retrouve surtout la fonction qui avait disparu: "supprimer" les
rubriques vides.
Par contre, c'est pas très raisonnable de pouvoir supprimer une rubrique
qui contient des articles en cours de rédaction ;))
Bon, sous Netscape, y'a un ch'tit bug graphique avec la colonne de
droite, mais ça m'a semblé acceptable.
Mouaiss.....
De plus, je systématise l'usage de tableaux pour la présentation de
listes, ce qui ralentit un poil l'affichage.
Justement, pourquoi systématiser cet usage même lorsqu'il n'est
pas très utile (et qu'il ralentit l'affichage, comme tu le dis si
bien) ?
a+
@ Arno* (arno@scarabee.com) :
Il s'agit d'indiquer le nom du site. Ce qui correspond, dans les
squelettes, à un nouveau pseudo-tag: #NOM_SITE_SPIP.De plus, l'URL du site est calculée automatiquement, et correspond à
un pseudo-tag: #URL_SITE_SPIP.
Hum?? J'ai un spip qui a deux URLs différents, comment marchera ton
"automatique" ??? Je crois que tu devrais mettre l'URL dans un champ
éditable comme le nom, et tu peux t'autoriser à le remplir "automatiquement"
seulement s'il est vide.
Du coup, je l'utilise pour créer automatiquement un back-end.php3 qui
n'a plus besoin d'aucune configuration manuelle (inutile désormais
d'entrer à la main dans backend.html).
(Excellente idée cela dit)
Je viens de modifier la page "Afficher tout le site", du coup,
Excccccelllllent ! (Sur mes deux spip-diplo cette page assurait le plantage
d'explorer)
PS: toujours pas de 'descriptif' dans ecrire/articles.php3, ou c'est moi qui
hallucine ?
-- Fil
Re-salut,
Bon, encore quelques modifs.
- Nouvelles petites icones pour l'état (le "statut") des articles:
/ecrire/IMG2/puce-blanche.gif
/ecrire/IMG2/puce-orange.gif
/ecrire/IMG2/puce-verte.gif
/ecrire/IMG2/puce-rouge.gif
/ecrire/IMG2/puce-poubelle.gif
du coup, histoire de les utiliser, modifs sur:
/ecrire/inc.php3
/ecrire/articles.php3
- Présentation et options dans "Tous le site":
/ecrire/IMG2/triangle-bleu.gif
/ecrire/IMG2/triangle-bleu-bas.gif
(pour les triangles sur fond bleu)
/ecrire/articles_tous.php3
Désormais on a la possibilité de sélectionner quels statuts d'articles on veut afficher (uniquement "en cours de rédaction", pour les admins qui aiment zieuter le travail des autres, ou n'importe quelle autre combinaison). Et correction du bug signalé par Antoine: désormais on ne peut plus effacer une rubrique contenant des articles en cours de rédaction ou proposés à validation (j'avais repris bêtement le "coll_actives" de inc-calcul.php3...).
Fil:
Hum?? J'ai un spip qui a deux URLs différents, comment marchera ton
"automatique" ??? Je crois que tu devrais mettre l'URL dans un champ
éditable comme le nom, et tu peux t'autoriser à le remplir "automatiquement"
seulement s'il est vide.
C'est ce que j'avais fait au début, mais ça pose le problème des gens qui saisissent leurs adresse n'importe comment. Et ensuite, bon courage pour faire le tri entre:
www.rezo.net/~arno
www.rezo.net/~arno/
www.rezo.net/~arno/index.html
(sachant que ce que je veux récupérer, c'est le second...) En faisant le truc automatique, je me contente de récupérer www.rezo.net/~arno/ecrire/blah-blah-blah, et de sucrer ce qu'il y a avant "/ecrire"...
UN spip sur deux URLS différents? Ouh là... Bon: le calcul automatique ne se fait qu'une fois: quand la ligne "adresse_site" de "spip_meta" est vide. Si tu fixes toi-même (phpMyAdmin!) cette valeur, elle n'est plus remplacée.
PS: toujours pas de 'descriptif' dans ecrire/articles.php3, ou c'est moi qui
hallucine ?
Si si, mais seulement quand il y a un descriptif... (C'est un zoli pavé verdâtre juste jous le titre.) Au fait, en interface simplifiée, le champ "descriptif" n'apparaît pas dans le formulaire (sauf s'il y a déjà du texte dans le descriptif).
Antoine:
Mmmmh, y a un problème : une URL ne doit pas faire plus de 256 caractères.
Ca risque de les dépasser avec ton système (sur un site avec bcp de
rubriques).
Plus prudent : "tout déplier" déclenche une variable deplie=oui,
et tu rajoutes juste la liste des rubriques repliées.
Aïe, c'est chiant, ça...
Le problème, c'est que "tout déplier", ensuite il faut pouvoir "replier" rubrique par rubrique (ce qui fait qu'alors ça revient au même problème).
T'as une idée? (Comment ils font, les autres qui font la même chose? :-))
Amicalement,
ARNO*
Re-re-re-salut,
Minuscule changement sur:
/ecrire/rubriques_edit.php3
En effet, quand on vient du site public (modifier cet article à partir du bouton provoqué par le cookie), la validation de "rubriques_edit" menait à la page "toutes les rubriques" désormais inutile... Maintenant ça renvoie vers "naviguer.php3", ce qui est plus cohérent (c'est là que se trouve le bouton "voir en ligne").
ARNO*
ARNO* wrote:
/ecrire/IMG2/puce-blanche.gif
/ecrire/IMG2/puce-orange.gif
/ecrire/IMG2/puce-verte.gif
/ecrire/IMG2/puce-rouge.gif
/ecrire/IMG2/puce-poubelle.gif
Les anciennes étaient plus jolies, tu veux pas les remettre ?
>Mmmmh, y a un problème : une URL ne doit pas faire plus de 256 caractères.
>Ca risque de les dépasser avec ton système (sur un site avec bcp de
>rubriques).
>Plus prudent : "tout déplier" déclenche une variable deplie=oui,
>et tu rajoutes juste la liste des rubriques repliées.Aïe, c'est chiant, ça...
Le problème, c'est que "tout déplier", ensuite il faut pouvoir
"replier" rubrique par rubrique (ce qui fait qu'alors ça revient au
même problème).
Non : tu deplies/replies rarement bcp de rubriques individuellement
(en tout cas moins des qqes dizaines qu'il faudrait pour provoquer
le bug).
Tout replié :
articles_tous.php3
Tout replié avec qqes rubriques dépliées :
articles_tous.php3?liste=13,45,118
Tout déplié :
articles_tous.php3?deplier=oui
Tout déplié avec qqes rubriques repliées :
articles_tous.php3?deplier=oui&liste=65,12,97
Sinon, toujours le problème de la taille des tables : ça déborde
sur la droite pour les sous-rubriques (explorer et netscape) :
y a pas moyen de mettre un width=100% qqe part ?
Enfin, l'affichage est pas très fluide.
a+
Antoine.
Fil:
>Hum?? J'ai un spip qui a deux URLs différents, comment marchera ton
>"automatique" ??? Je crois que tu devrais mettre l'URL dans un champ
>éditable comme le nom, et tu peux t'autoriser à le remplir "automatiquement"
>seulement s'il est vide.
@ Arno* (arno@scarabee.com) :
C'est ce que j'avais fait au début, mais ça pose le problème des gens
qui saisissent leurs adresse n'importe comment. Et ensuite, bon
courage pour faire le tri entre:
www.rezo.net/~arno
www.rezo.net/~arno/
www.rezo.net/~arno/index.html(sachant que ce que je veux récupérer, c'est le second...) En faisant
le truc automatique, je me contente de récupérer
www.rezo.net/~arno/ecrire/blah-blah-blah, et de sucrer ce qu'il y a
avant "/ecrire"...UN spip sur deux URLS différents? Ouh là... Bon: le calcul
automatique ne se fait qu'une fois: quand la ligne "adresse_site" de
"spip_meta" est vide. Si tu fixes toi-même (phpMyAdmin!) cette
valeur, elle n'est plus remplacée.
Après essais, ce que je proposais continue à me paraître la bonne solution :
tu le proposes dans le formulaire, mais s'il est vide tu proposes ton calcul
automatique. Etre obligé de passer sous phpMyAdmin c'est mauvais.
Pour ta crainte de voir des www.rezo.net/~arno/index.html il suffit de
vérifier que le dernier caractère est /, sinon tu tronques.
-- Fil
Fil wrote:
Après essais, ce que je proposais continue à me paraître la bonne solution :
tu le proposes dans le formulaire, mais s'il est vide tu proposes ton calcul
automatique. Etre obligé de passer sous phpMyAdmin c'est mauvais.
Je suis du même avis. En plus, il est impossible de déterminer
automatiquement et à coup sûr l'URL du site.
Arno:
>Coucou, beta5 :
>
>- des modifs graphiquesQuelles modifs graphiques? (Quand modifs, ce serait bien de lister
complètement les modifs.)
Présentation des auteurs et des mots-clés dans l'article ; ajout
de la fonction recherche dans les auteurs ; présentation de la
liste des mots-clés (fonte plus petite, bandeaux plus clairs,
bouton supprimer pour tous).
Sinon, j'ai enlevé la possibilité de modifier un "groupe" de
mots-clés : ça rend les squelettes invalides ;))
a+
Sinon, j'ai enlevé la possibilité de modifier un "groupe" de
mots-clés : ça rend les squelettes invalides ;))
Comment ça?
Tu as tout de même remarqué que la gestion des "groupes" est
volontairement très simple et très basique. Pour sélectionner
les mots du groupe "pays", il faut faire :
<BOUCLE_machin(MOTS){type=pays}>
ce qui est ultra-facile à retenir et à comprendre.
Si un admin pas au courant décide que "pays" n'est pas joli
et qu'"entité géographique" convient mieux, le squelette ne
marche plus et le webmestre est bien marri s'il n'a pas été
prévenu par l'admin.
a+
ARNO* wrote:
Ah oui, mais dans ce cas, on ne change plus rien. On peut si on veut faire des sélections de rubriques avec {titre=mon oeil}, ou même avec une expression régulière si j'ai bien suivi.
Là, si le webmestre principale veut faire dans la maquette ultra-rigoureuse, de toute façon il n'a pas d'autre choix que de très bien briefer ses troupes d'admins. Par exemple: les admins peuvent installer eux-mêmes des logos de rubriques. Je te dis pas l'horreur s'ils envoient des trucs qui ne correspondent pas à la charte graphique. Ou encore: sur la page d'accueil, pour faire un chouette encadré (dans Vacarme, par exemple), je fais une boucle (RUBRIQUE){id_rubrique=5}: si les admins décident de déplacer leurs textes de cette rubrique, la maquette est ruinée.
Donc, pour moi c'est clair, on ne peut pas faire ce genre de limitations: si un type veut se faire des squelettes ultra-rigoureux, dans ce cas il explique aux admins qu'il faut être rigoureux.
Amicalement,
ARNO*
Salut,
Je suis en train de télécharger une version beta 6 (si j'y arrive, rezo.net tourne au ralenti). Cette version nécessite une mise à jour de la base (bravo Antoine pour la nouvelle formule de mise à jour!).
Le but de cette mise à jour est d'introduire un moteur de recherche dans SPIP (puisque cette fonction existe dans uZine). Ce moteur fournit (pour l'instant?) une pertinence moins importante que celle d'uZine, mais c'est déjà pas mal.
Le principe:
- nouvelle table: spip_index
- à chaque recalcul d'une page article, rubrique, etc., un fichier spip-index.php3 se met en route et récupère tous les mots de l'article en question, qu'il place dans cette table, en pondérant ("poids") en fonction de sa situation (si un mot est dans le titre, il gagne 8 points, sinon 1 point dans le texte...)
- dans les squelettes, c'est très simple à utiliser, car on utilise les boucles déjà existantes (il n'y a pas de nouveau type de boucle). Par exemple, pour obtenir une liste d'articles (répondant à la recherche), on fait:
<BOUCLE...(ARTICLES){recherche}{par poids}{inverse}{0,10}>
mais aussi
<BOUCLE...(BREVES){recherche}{par date}{0,10}>
Comme vous le constatez, ainsi on utilise directement les boucles classiques, ce qui signifie qu'on fabrique sa présentation comme on le ferait pour une liste habituelle d'articles, de brèves, de rubriques, etc.
- pour fabriquer le formulaire de recherche, je me suis pas cassé, y'en a un tout simple dans "sommaire.html". Le tout est de passer une variable "recherche=...".
- modifs dans inc-public, de façon à ce qu'une page de recherche n'utilise pas de cache (on aurait l'air fins).
Salut,
Désolé, mais j'ai pas réussi à télécharger complètement la beta 6. rezo.net déconne trop, le ftp est trop lent et s'interromp au milieu. Donc -> ne pas l'utiliser avant que tout soit disponible.
J'essaierai à nouveau cet après-midi
ARNO*
ARNO* wrote:
- à chaque recalcul d'une page article, rubrique, etc., un fichier
spip-index.php3 se met en route et récupère tous les mots de
l'article en question, qu'il place dans cette table, en pondérant
("poids") en fonction de sa situation (si un mot est dans le titre,
il gagne 8 points, sinon 1 point dans le texte...)
Glurps....
Sinon, toujours le même jeu de chat et la souris avec Antoine: chaque
fois que je supprime le lien "Se déconnecter", il le remet dans la
version suivante. Bon, ce coup-ci je l'ai juste décalé dans la
colonne de gauche, mais je soutiens mordicus que c'est du pur jargon
de technicien,
Pourtant c'est une fonction qui sert. Reste à trouver un nom adéquat,
alors.
a+
Salut,
Ca y est, je viens de télécharger la beta 6 complète.
Ca donne:
http://rezo.net/~arno/index.php3
(pas vraiment travaillé l'interface, hein...).
Ce qui m'inquiétait dans un tel système de moteur, c'est la vitesse. Sur rezo.net, c'est très très rapide (faut dire aussi que rezo.net est particulièrement performant quand il fonctionne).
- l'indexation prend environ 1 seconde sur un article très long, et devient imperceptible sur un article court; sur les brèves, je peux pas vraiment chronométrer. IMPORTANT: l'indexation se fait lorsqu'une page est recalculée, donc l'indexation est très largement répartie dans le temps (ça n'est pas comme htdig - moteur libre utilisé par le diplo par exemple -, qui effectue une indexation _complète_ du site à chaque fois qu'on lui demande). La charge sur le serveur est donc très supportable.
- la recherche, elle, basée désormais sur le système d'indexation, est ultra-rapide, et n'utilise qu'une seule requête mySQL.
Ah oui, j'oublais... je vous ai dit que la recherche s'effectuait directement dans les boucles déjà existantes. Il suffit de remplacer {id_rubrique}, {id_breve}, etc. par {recherche} dans des boucles (ARTICLES), (RUBRIQUES)... En réalité, on peut utiliser la recherche dans les boucles:
- (ARTICLES){recherche}
- (RUBRIQUES){recherche}
- (AUTEURS){recherche}
- (MOTS){recherche}
- (BREVES){recherche}
Bien entendu, si vous n'avez pas de pages spécifiques "mots.html" ou "auteurs.html" (par exemple), il semblerait y avoir un problème si vous effectuez des recherches sur de telles boucles ("MOTS", "AUTEURS"), avec risque de renvoyer vers des pages qui n'existent pas. Mais puisque l'indexation est provoquée par les visites (recalcul) des pages, une page qui n'est pas visitée (ici, tout simplement parce qu'elles n'existent pas), une boucle "(AUTEURS){recherche}" sur un site sans page "auteurs.php3" ne donnerait tout simplement aucun résultat.
Ah oui, dans mon squelette d'exemple ("recherche.html"), j'ai pas traité le cas "il n'y a pas de réponse". Ben c'est très très simple, il suffit d'utiliser le codage classique de la boucle:
<B_article>
<BOUCLE_article(ARTICLES){recherche}{par points}{inverse}{0,10}>
<LI>#POINTS - #TITRE
</BOUCLE_article>
Il n'y a pas de réponse.
<//BOUCLE_article>
Amicalement,
ARNO*
ARNO* wrote:
Ce qui m'inquiétait dans un tel système de moteur, c'est la vitesse.
Sur rezo.net, c'est très très rapide (faut dire aussi que rezo.net
est particulièrement performant quand il fonctionne).
Quelques chiffres à propos : l'indexation de tout ton site (via une
aspiration) donne une table de 90000 lignes, pour 100 articles. Une
ligne de la table faisant plus d'une centaine d'octets, ça fait
donc au minimum 10 Mo. Pour un site de la taille d'uzine avec 200 ou
300 articles, compter plus de 20 Mo. D'autre part, l'indexation risque
d'être de plus en plus lente au fur et à mesure que la taille de la
table augmente.
Rien que l'utilisation de la fonction propre() lors de l'indexation
risque de bouffer du temps, vu que ça fait deux propre() au lieu
d'un seul sur l'article (à replacer dans le contexte des discussions
d'il y a qqes semaines à propos du poids de la dite fonction, et
des tentatives d'allègement...). Quant à l'ereg() utilisée, peut-être
essayer de la remplacer par un split() (cf. doc PHP) afin d'éviter
les substr à gogo (900 mots par article - un peu moins car de petits
objets sont indexés à côté - donc 900 passages de boucle...).
Pour les questions de taille, éventuellement exporter les mots vers
une autre table (spip_index_dico) et remplacer les références dans
spip_index par un id_dico ? En plus, ce sera certainement plus rapide
(indexation et recherche), car le nombre de mots distincts devrait être
très inférieur au nombre d'entrées d'indexation.
Enfin, pour les clés de la table, je ne pense pas que rassembler
id_article, id_rubrique, etc., dans une seule clé soit très
intéressant : voir la doc mysql, mais à mon avis vaut mieux faire
N clés différentes.
A tester sur d'autres hébergeurs moins costauds que rezo.net... ?
IMPORTANT: l'indexation se fait lorsqu'une
page est recalculée,
Suggestion : indexer lors des modifs sur l'espace privé. Dans
l'espace public, indexer uniquement lorsque l'article n'est pas
déjà indexé : ainsi l'espace public n'est pratiquement jamais
mis à contribution (sauf au début quand on met l'indexation
en marche et qu'il y a un paquet d'articles).
Ah oui : si la nomenclature des fichiers include pouvait
rester homogène (ecrire/enlettres.php3, ecrire/spip_index.php3...)
a+
Antoine.
Salut,
Quelques modifs dans la beta 6 (oui, déjà).
J'ai ajouté une configuration précise qui commence à devenir réellement précise.
- possibilité d'activer/désactiver les brèves. En effet, un site comme Vacarme, pour l'instant, n'utilise pas les brèves; autant que les rédacteurs ne soient pas tentés d'en mettre alors que les squelettes ne les prennent pas en compte. Notez: quand on désactive les brèves, ça se contente de supprimer le logo dans la barre de navigation. (Peut-être prévoir petite modif dans inc-calcul.php3 qui désactive carrément leur affichage - suffit d'ajouter une requête "AND 1=2"...)
- surtout, possibilité de déterminer finement quels éléments optionnels sont utilisés dans les articles. De cette façon, on peut désactiver la date de rédaction, les mots-clés, les surtitres, soustitres, descriptif, chapeau, postscriptum. Dans le cas où l'on désactive les mots-clés, le logo correspondant vers la gestion des mots-clés disparaît.
Les fichiers modifiés sont:
/ecrire/inc.php3
/ecrire/configuration.php3
/ecrire/articles.php3
/ecrire/articles_edit.php3
Histoire de gérer l'affichage/masquage des logos:
/ecrire/IMG2/cles-non.gif
/ecrire/IMG2/cles-on.gif
/ecrire/IMG2/cles-off.gif
/ecrire/IMG2/breves-non.gif
/ecrire/IMG2/breves-off.gif
/ecrire//IMG2/breves-on.gif
(les logos "on/off" existaient déjà, mais ils sont légèrement modifiés, les anciens provoquant une petite "bavure" quand les logos d'à côté son masqués).
Amicalement,
ARNO*
Quelques chiffres à propos : l'indexation de tout ton site (via une
aspiration) donne une table de 90000 lignes, pour 100 articles. Une
ligne de la table faisant plus d'une centaine d'octets, ça fait
donc au minimum 10 Mo. Pour un site de la taille d'uzine avec 200 ou
300 articles, compter plus de 20 Mo. D'autre part, l'indexation risque
d'être de plus en plus lente au fur et à mesure que la taille de la
table augmente.
Oui oui, je suis conscient des limites. C'est pour cela que l'on peut désactiver le moteur. Je pense même qu'il faudra préciser qu'on ne doit utiliser le moteur intégré à SPIP que dans un site de taille modeste, et que sinon il faut s'orienter vers un système plus professionnel (tel htdig).
Pour l'optimisation de l'indexation, j'avoue que j'atteints mes limites. Si tu veux bidouiller, n'hésite pas. (Tiens, marrant: comme je suis moyennement compétent en PHP, j'ai beaucoup moins de chances d'utiliser des codes incompatibles avec PHP3... :-))
Amicalement,
ARNO*
ARNO* wrote:
Oui oui, je suis conscient des limites. C'est pour cela que l'on peut
désactiver le moteur. Je pense même qu'il faudra préciser qu'on ne
doit utiliser le moteur intégré à SPIP que dans un site de taille
modeste, et que sinon il faut s'orienter vers un système plus
professionnel (tel htdig).Pour l'optimisation de l'indexation, j'avoue que j'atteints mes
limites. Si tu veux bidouiller, n'hésite pas. (Tiens, marrant: comme
je suis moyennement compétent en PHP, j'ai beaucoup moins de chances
d'utiliser des codes incompatibles avec PHP3... :-))
Je sais, mais ce que je voulais dire c'est que ç'aurait été sympa
que ce soit toi qui fasses les tests. Si ça passe mal chez la plupart
des hébergeurs, il vaudra mieux le désactiver par défaut (ou l'optimiser,
mais c'est une autre question....).
a+