- Il serait peut-être préférable de déplacer les bugs transférés vers une autre page afin qu'il n'y ait plus ici que les bugs non-transférés, et de mettre les lien direct vers le rapport d'anomalie plutôt que vers le gestionnaire, non ? -- LordFarquaad
Décrivez ici les problèmes rencontrés - Utilisez le gestionnaire d'anomalies !
Certains "bogues" ont pu être réglés par simple réponse sur cette page, ils sont ensuite déplacés vers la page ArchiveRapportsDeBogues.
La page devenait trop longue, j'ai coupé la discussion qui figurait ici et l'ai placée dans la page RapportsDeBoguesUnePageParBugDiscussion afin de conserver une trace. -- LordFarquaad
09/03/2005
priorité : moyenne
difficulté : facile
Les colonnes body et body_r de la base de donnée MySQL sont définies comme TEXT ce qui tronque les grandes pages.
J'ai remplacé les valeurs TEXT par des LONGTEXT et cela fonctionne tres bien.
Plus d'info sur la capacité des colonne : http://dev.mysql.com/doc/mysql/fr/storage-requirements.html
- Ce n'est pas un bogue mais une fonctionnalité. Nous limitons volontairement la taille de ce champ : 1. les pages longues ne sont pas efficace dans un wiki ; 2. la limite des 64 Ko est rarement atteinte ; 3. il est toujours possible de modifier cette limite comme vous l'avez fait. -- CharlesNepote
- Le problème c'est que si la taille est trop longue, on n'en est pas notifié ! Il y a d'ailleurs une discussion à ce sujet, cf TailleMaximumDuTexteDansUnePage -- LordFarquaad
02 Janvier 2005
Priorité: moyenne
Difficulté: variable (plusieurs choses à corriger)
Fichiers concernés: /wakka.php
Description: Divers problèmes d'url plus ou moins liés:
- http://login@MonDomaine.com, http://login:MotDePasse@MonDomaine.com, http://login@MonDomaine.com/, http://login@MonDomaine.com:81/ etc. Tous ces liens sont formattés comme des adresses email, simplement parce que ce sont des liens forcés et qu'ils contiennent un @.
- Les lien interwiki ne vérifient pas l'existance de l'alias: Wikini:BacASable (interwiki), NimporteOu:NimporteQuoi (interwiki inconnu)
- Impossible d'utiliser des carractères spécieaux dans les liens interwiki, même en les forçant: WikiNi:UnePage (interwiki)Étrange, , WikiNi:UnePage (interwiki)%C3%A9trange, WikiNi:UnePage%C3%A9trange
- => impossible de placer des espaces dans la deuxième partie: Google:plusieurs (interwiki)%20mots, Google:plusieurs%20mots, Google:plusieurs (interwiki)+mots, Google:plusieurs+mots
- Vérifier la présence de '://' dans l'adresse avant de vérifier la présence d'un @, ou vérifier la validité de l'adresse mail (NB.: il peut maintenant y avoir des accents dans les adresses mail et les noms de domaines normalement)
- Modifications de GetInterwikiUrl (URI ne serait-il pas plus approprié pour cette méthode ? enfin ça n'a pas une grande importance...): il faudrait afficher un message d'erreur ou retourner la valeur null ou quelque chose du genre quand l'alias n'existe pas.
- Etendre WN_CHAR2 à [^[:space:]] et décider de la forme qu'il faut donner au paramètre:
- peut-on le fournir tel quel, par exemple: Google:UnePageÉtrange, auquel cas il faudra l'urlencoder. Problème: il sera impossible de mettre des espaces: + sera transformé en %2B et %20 sera transformé en %2520 (à moins de faire un remplacement spécial). NB.: urlencode() ou rawurlencode() ? Le deuxième me parait mieux...
- ou alors doit-on le fournir urlencodé, auquel cas il faudra l'urldecoder pour que le texte du lien soit tout de même clair (pour qu'on n'y voit pas les % etc.). Avantage: laisse plus de liberté, inconvéniant: demande plus de responsabilité: l'utilisateur doit savoir urlencoder ou du moins consulter la page qu'il veut lier et copier de l'url le paramètre du lien interwiki... Ceci fait donc perdre une partie de l'avantage des liens interwiki, je pense (écrire simplement un lien vers une page d'un autre site, sans avoir à forcément consulter la page en question)
19 Decembre 2004
Priorité: très élevée
Difficulté: très simple ou à discuter
Description: Les méthodes StartLinkTracking? et StopLinkTracking? de la ClasseWiki ne fonctionnent pas ! En effet, leur rôle consiste à modifier la variable de session linktracking, qui est directement vérifiée dans Link? et ComposeLinkToPage?. Le problème c'est que ces deux méthodes ne vérifient pas la valeur de linktracking, mais seulement si la variable est définie (via isset()), or, mis à part avant le premier appel de Start... ou Stop..., cette variable est toujours définie ! Du coup, le seul élément qui joue un rôle lors du trackin, c'est le dernier argument des méthodes link et composelingtopage... (je m'en suis rendu compte après avoir fait les derniers changements sur la version CVS...)
Voir aussi DevActionsEntetePiedDePageEtLinkTracking.
Solution: il faut modifier la vérification de la valeur de linktracking. La solution simple consiste à remplacer isset par !empty, mais la meilleure solution est à discuter, voici ce que je propose:
- Plutôt que d'utiliser une variable de session, utiliser un attribut de la ClasseWiki. En effet, l'état du linktracking n'a pas besoin d'être transmis de page en page...
- Ajouter une méthode du genre IsTrackingLinks() qui renvoie vrai si le tracking est actif. De la sorte on pourra arrêter temporairement le linktracking, en sachant s'il faut le relancer après ou non (ou l'inverse).
- Modifier les méthodes start et stop, de sorte qu'elles retournent l'ancien état du linktracking; ça permettra de faire d'une pierre deux coup (ex.: l'arrêter, tout en apprenant si oui ou non il faut le relancer après)
- A la place du point deux, on peut peut-être envisager une méthode du genre LinkTracking( [bool $newstatus] ) qui active le linktracking si $newstatus vaut true, le désactive s'il vaut false et ne fait rien s'il n'est pas spécifié (utiliser par exemple null comme valeur par défaut). De plus, elle retournerait l'ancien état. Du coup, sans argument, elle ferait la même chose que le IsTrackingLinks() que j'ai proposé au point 2, mais aurait d'autres fonctionnalités supplémentaires. Il existe déjà des fonctions PhP qui fonctionnent comme cela, par exemple session_id(). Vu son polymorphisme, je propose de garder le nom LinkTracking pour cette fonction qui est en même temps un "get" et un "set" (de même que ce n'est ni get_session_id ou set_session_id mais session_id...)
08 Decembre 2004
Priorité: à déterminer
Difficulté: à déterminer
Description: Le commentaire Comment635? par Nicephore17 est lié à une page qui n'existe plus, ne devrait-il pas avoir été supprimé ? -- LordFarquaad
- D'après le WikiNiChangeLog050, ce bug a été corrigé je pense... -- LordFarquaad
06 Décembre 2004
Priorité: moyenne
Difficulté: ?
Description: waw vous avez déjà essayé les apostrophes dans les noms de pages ? joli hein ? Ou plutôt attroce... allez voir dans le profil de ProgFou et dans le mien, il a testé, j'ai voulu éditer sa page et en fait j'en ai fait une nouvelle... En partant de mon profil ou des DerniersChangements vous arrivez à celle créée par ProgFou. J'ai aussi posté un commentaire dessus et là le nom de la page n'apparait même pas (cf DerniersCommentaires), au moment de poster mon commentaire WikiNi m'a proposé de créer la page parce qu'elle n'existait pas :| Maintenant est-ce qu'il a effectivement été posté ? Mystère...
urls complètes pour accéder aux deux pages concernées:
celle que j'ai faite: http://www.wikini.net/wakka.php?wiki=Est-ce%20qu\'on%20peut%20mettre%20vraiment%20n\'
celle de ProgFou: http://www.wikini.net/wakka.php?wiki=Est-ce%20qu\\\'on%20peut%20mettre%20vraiment%20n\\\'
En fait un des problèmes est que chaque fois qu'on saute d'éditer à aperçu etc. les antislash et les apostrophes sont échappés, donc à chaque coup ça fait 2n+1 antislash (où n est les nombre d'antislash de la fois précédente)... -- LordFarquaad
04 Decembre 2004
Priorité: moyenne
Difficulté: ?
Description: en postant les deux bugs précédents (d'un coup), je suis tombé sur un troisième:
Query failed: insert into wikini_links set from_tag = 'RapportsDeBogues', to_tag = 'Entrepôt' (Duplicate entry 'RapportsDeBogues-Entrepôt' for key 1)
mais la page a été correctement modifiée comme vous pouvez le voir.
Par ailleurs j'ajouterais qu'il n'est pas nécessaire d'arrêter complètement l'exécution du script sur ce genre d'erreur... pour certaines ok mais pas toutes.
-- LordFarquaad (en espérant ne pas reproduire ce bug en cliquant sur "Sauver", ce dont je doute...)
04 Decembre 2004
Priorité: basse-moyenne
Difficulté: ?
Description: Quand on oublie de fermer une balise, WikiNi la laisse ouverte au delà de la fin du message, donc tout ce qui suit conserve la propriété (souligné, gras, italique, barré etc. - autant sous InternetExplorer que sous MoZillaFireFox?): les liens en bas de page, les commentaires... C'est l'horreur ! Et ça ne respecte bien entendu plus le XHTML... J'ai montré un exemple dans le BacASable. On constatera au passage que il y a beaucoup d'autres erreurs mises en avant par l'état actuel du BacASable...
Solution: étant donné que WikiNi sait quand il doit ouvrir ou fermer les balises, il doit savoir les fermer toutes en même temps, le problème c'est qu'il faut les fermer dans l'ordre... Je ne sais pas comment c'est géré pour l'instant, mais ce qu'il faudrait c'est enrégistrer toutes les balises ouvertes sur une pile, de façon à pouvoir toujours s'assurer de fermer les balises dans le bon ordre. J'imagine qu'actuellement ce n'est pas le cas...
Une fois que cela sera fait, on peut envisager de créer une action qui fermerait toutes les balises, mais ça pourrait aussi juste être une fonction appelée automatiquement à la fin de l'affichage de la page.
Je veux bien regarder à tout ça dès lundi.
-- LordFarquaad
30 Novembre 2004
Je viens de découvrir par hasard un bug JavaScript en ouvrant la console JavaScript de Firefox. Dans les formulaires d'édition, on a une erreur à chaque caractère entré ! Voici le rapport d'erreur :
Erreur : event is not defined
Fichier Source : http://www.wikini.net/wakka.php?wiki=PagePrincipale/edit
Ligne : 16
La ligne Html mise en cause est celle du if dans ce JavaScript (d'ailleurs, il sert à quoi ce script, placer des tabs dans les <textarea> des Gecko ?) :
<script type="text/javascript">
function fKeyDown() {
- if (event.keyCode == 9) {
- event.returnValue= false;
- document.selection.createRange().text = String.fromCharCode(9) } }
Ne manquerait-il pas un petit paramètre event quelque part dans l'appel de fonction ?
-- JmPhilippe
C'est bien bugé effectivement, je suis en train d'inverstiguer. Event est facile a corriger,
mais apres c'est document.selection qui pose probleme...
-- FranckExeprod
Pour info:
http://tabinta.mozdev.org/
https://bugzilla.mozilla.org/show_bug.cgi?id=29086
-- FranckExeprod
Quasiment corrigé ???
HackTabulationDansMozilla
-- FranckExeprod
-- Mi Novembre 2004 --
Bonjour,
D'abord un grand merci pour ce developpement.
Bug ?
version 0.4.2
Probleme avec les tableaux si je fais
[|
|cellule1|cellule2|cellule3|
|]
cela ne donne rien alors que j'ai trouve un site en 0.4.1rc http://codedb.delphicenter.com/wiki/wakka.php?wiki=BacASable/edit ou cela fonctionne en standard ?
Du coup j'ai chargé les 2 fichiers modifies sur ce site http://codedb.delphicenter.com/wiki/wakka.php?wiki=WikiTableau que je remercie mais bon ca fait beaucoup de specif tout ca
Les tableaux ne sont pas standard dans WikiNi. Ceux dont tu parle sont un hack du fichier formatters/wakka.php et utilise un fichier à inclure. Pour pouvoir utiliser ces tableaux, il faut modifier le code source du fichier de formatage. Voir le code source pour comprendre quoi et ou mettre les modifications. Attention, le code des tableaux n'a été tester que sur la 0.4.1 (de mémoire)J'espère que tu n'as pas posté sur codedb, je n'y vais jamais, j'utilise ce site pour faire des tests grandeur. --GarfieldFr
Proposition ?
Dans le module usersetting.php j'ai fais une sortie en $this->Redirect($this->config["base_url"]); après le logout ou le login pour revenir a la page d'accueil
Merci de me tenir au courant pour mon pb de tableau
Andy Collard
13 Novembre 2004:
Sur la version CVS actuelle du wiki la syntaxe [[MotWiki Un Mot Wiki]] ne semble pas fonctionner. Certains rencontrent-ils le même problème ? --JeremieCook
9 octobre 2004:
Chez Free, un bogue semble persistant (présent même après une réinstall complète) avec la dernière version, et ne semblait pas être présent avant :
Lors de l'enregistrement d'un nouvel utilisateur ou de l'identification, la validation de la page entraîne l'arrivé sur un charabia, et oblige donc à une réactualisation de la page, qui semble résoudre le problème.
-- loukYss
Priorité : Basse
Difficulté: : Moyenne ?
Description : J'ai un bogue dans le rendu des différences entre deux versions d'un texte qui comprend deux liens entre crochets doubles sur la même ligne, lorsque je fais la différence avec une version dans laquelle il n'y a qu'un seul des deux liens.
A la fin du premier lien, l'affichage devient rouge et barré, jusqu'à la fin de la page.
Version 0.4.1 sur MySQL 3.23.42 et PHP 4.3.3.
Voir le test sur AxlMun.
Peut-être un problème de regexp dans le processeur de diff ?
-- Inconnu
Oui, c'est en effet un problème dans le processeur de diff. C'est assez coton à corriger car le processeur est assez complexe (il s'agit de /handlers/page/diff.php).
Si quelqu'un a du courage pour regarder, c'est formidable. Mais dans le cas contraire le bogue ne sera pas corrigé en priorité car il n'est pas bloquant.
-- CharlesNepote
J'ai jetté un coup d'oeil au moteur de diff, en fait parce que j'aurais voulu un canal RSS qui renvoie vers les diff des pages plutôt que les pages, ça me paraît plus pratique pour savoir ce qu'il y a de neuf lorsqu'on ne connaît pas le contenu des pages par coeur ;-). Il me semble que le problème peut venir de 2 choses :
- le moteur de diff ne coupe les mots que sur les espaces, et non les autres caractères non alpha-numériques, dont la ponctuation
- le moteur de diff compare le texte brut et non le texte affiché (c'est à dire le code Html débarrassé de ses tags), il peut donc ajouter des tags SPAN en plein milieu d'un lien Wikini [[...]] ou d'une action {{...}}, d'où des résultats étranges une fois les [[...]] remplacés
- convertir les deux pages à comparer en Html
- supprimer tous les tags pour ne garder que le texte des pages affiché à l'écran (quid des urls modifiées ?)
- scinder les mots sur tout ce qui n'est pas alpha-numérique
- faire le diff des textes
- rapporter les modifications dans le Html de la page source (c'est là que ça se corse, et là je dois dire que mes compétences de presque débutant PHP ne suffisent pas...)
Oui, le moteur de diff ne traite pas bien les indicateurs de formatage de Wikini. Mais au lieu de transformer une page html en texte avant comparaison, il me semble plus simple de nettoyer une page wikini : ca sera plus rapide en temps de traitement et à mon avis plus simple à mettre en oeuvre. -- DavidDelon
Je n'avais pas pensé à cette option. Cela dit si on nettoie la page en format winkini, il faut "importer" les règles de formatage, alors qu'en Html, une petite expression régulière du style <.*?> devrait faire l'affaire. En plus, s'il y en a (comme moi) qui de temps en temps utilisent du code Html en plein milieu (avec ""...""), ça risque de se corser. Qu'en penses-tu ? -- JmPhilippe
Pour ma part je pense que le diff devrait se faire sur le source de la page et non sur le résultat obtenu après formattage ; ceci pour une raison simple : on utilise le diff pour faire un suivi des modifications et éventuellement les corriger, or toute l'édition se fait au niveau du source et non pas en WYSIWYG. -- ProgFou
Justement je m'étais dit le contraire !!! Comme je voudrais avoir des pages dernières modifications qui renvoient vers le diff des pages plutôt que les pages, il me paraissait plus intéressant de montrer à l'utilisateur la différence par rapport à ce qu'il voit réellement, et non ce que machin a dû taper pour le faire... -- JmPhilippe
Priorité : ??
Difficulté: ?
J'ai installé WiKiNi (version 0.4.1) sur mon serveur Windows XP sous Apache 1.3.29 et php 4.3.4
Je rencontre systématiquement un problème avec cette ligne :
-
if (!$this->tag = trim($tag)) $this->Redirect($this->href("", $this->config["root_page"]));
J'ai fait plein de tests et mis des traces petit à petit dans le code pour voir d'où venait cette erreur et je suis tombé sur cette ligne.
Peut être parce que mon installation serveur ne gère pas les doubles redirections ? (header() depuis index.php puis header() dans le Redirect() de wakka.php ?)
En tout cas quand je transforme la ligne en :
-
if (!$this->tag = trim($tag)) $this->tag = $this->config["root_page"];
tout remarche bien !!
Priorité :Nouvel Hebergeur testé ?
Difficulté: : ?
Installation chez http://www.phpnet.org : hébergeur commercial ; propose PHP et MySQL.
Pt'ete que mon cas va vous interesser puisque visiblement je suis le 1er a teste Wikini chez cet hébergeur !
- J'ai fait une install de wikini chez Free.fr ... tt est OK
- J'ai ensuite installé un autre wikini chez PHPnet.org
Les étapes de l'installation ce passent normalement; aucun message d'erreur.
Mais lorsque ensuite je tente d'aller sur le wikini que je viens de creer...(lien a la fin de l'install, ou meme entapant l'url)...
...Je retombe irrémediablement sur la page du début de l'installation (ou sont demandés les parametres SQL etc...) !!!!
Comprend PÔ :-(
NB: J'ai essayer avec & sans les spécificitées de l'install chez Free.fr (sessions & .htaccess pré-créer ou non)
merci de votre reponse.
cyril@sonanbul.org
A part un problème de droit d'écriture, je ne vois pas. Vérifis que le serveur Apache a les droit d'écriture dans le répertoire de l'installation de WikiNi. Ce que tu peux faire, c'est de mettre les droits en écriture pour le groupe quitte à remettre les droits d'origine après installation --GarfieldFr
Priorité :Basse.
Description : J'inscris dans une page un NomWiki dont le nombre de caractères dépasse le maximum autorisé par défault (50).
Je clique ensuite sur le "?" situé à la fin de ce NomWiki, et j'arrive sur la page d'édition. J'écris ce qu'il me plait, et puis valide par "Sauver". On me demande alors : "Cette page n'existe pas encore, voulez vous la créer ?". Je réponds oui, et tombe sur cette erreur :
Query failed: insert into wikini_acls set list = '+', page_tag = 'CeciEstUnTestdunNomWikidePlusDeCinquantesCaracteresPourFaireUnRapportDeBug', privilege = 'write' (Duplicate entry 'CeciEstUnTestdunNomWikidePlusDeCinquantesCaractere-write' for key 1)
J'ai fini par comprendre que c'était à cause du NomWiki trop long, mais je ne trouve pas l'erreur très explicite. Voilà :)
Jérémie
Priorité : Haute
Difficulté: : ?
Description : Sur la version de www.wikini.net, il y a un problème avec les listes. Voir par exemple la page ActionWantedPages ou le rendu de la liste n'est pas correct sous Firefox et IE6. Il est à noter qu'il y a des problème de rendu aussi sur la page ActionAttach et ActionAttach sur /dev --GarfieldFr
Priorité : Moyenne
Difficulté: : Facile
Description : Problème error reporting avec E_ALL
Solution :
- ajouter error_reporting(E_ALL ^ E_NOTICE); au debut
- OU corriger tous les messages NOTICE
Priorité : Haute
Difficulté: : ????
Description :J'utilise Wikini depuis quelques temps sur mon serveur sans problème (version 0.4.1rc). J'ai installe aussi cette meme version dans mon entreprise et la j'ai un probleme. Les actions faisant appel à la fonction Format de la classe wiki ne s'affiche pas (erreur de page). Apres avoir regardé un peu le code il semble que le problème se passe dans le fichier formatters/wakka.php dans la fonction "preg_replace_callback". Je butte sur ce probleme depuis quelques heures et je ne vois pas de solution surtout que sur mon site perso tout va bien. Je suppose que c'est des différences au niveau de php.ini qui conduisent à cette différence de fonctionnement mais lesquelles ! (j'ai fait l'essai de reduire la fonction wakka2callback à sa plus simple expression mais le probleme reste le même des que l'initialisateur de la fonction Format est une action comme recentlycommented.php par exemple)
- Bonjour Christian, pourrais-tu nous montrer le message d'erreur obtenu, ça nous aiderait probablement. -- ProgFou
- Ce n'est pas un message d'erreur php mais "Impossible de trouver la page" retourné par le navigateur. --GoubS
- On continue le dialogue sur ta page perso stp, elle est moins longue à charger... ;-) -- ProgFou
-- GoubS 27 04 2004
Priorité : Basse
Difficulté: : ?
Description : Mauvaise restitution du diff mot à mot quand il y a des puces.
Par exemple :
Test test. -test -test
Test test. - test - test
Priorité : Basse
Difficulté: : backport WackoWiki
Description :l'utilisation de %% génère une boîte avec des ascenseurs horizontaux et verticaux, et quand je scrolle avec la souris, le scroll s'arrête sur cette boîte, ce qui n'est pas le cas avec WackoWiki
Bon c'est surtout gênant, mais ça vient ajouter au fait que cette fonctionnalité d'affichage "tel quel" est sympathique (évol' vers formatage Delphi voire autre, /var/log/messages pour moi) mais contraignante et moche pour l'internaute. Il ne manque pourtant pas grand chose : voir BacASable pour mes remarques. En gros : je souhaite un paramètres ligne_max (si pas précisé, le texte s'étend sans scroll bar), il n'y a que si je clique dans cette "fenêtre" que la scroll bar devient active (surtout pour déplacement avec souris).
-- BenoitAudouard 20031213
Priorité : Basse ?
Difficulté : ?
Description : Problème de perte de formatage du cadre de texte avec certains
J'ai du mal à diagnostiquer d'où ça vient : je l'ai laissé dans BacASable (deux versions successives, deux bugs différents).
Du texte passe hors du cadre au-dessus des boutons Sauver / Aperçu / Annulation (dans tous les cas), éventuellement la puce passe dans la ligne verticale du cadre (2ème cas). J'ai l'impression que c'est dû à ma signature précédée de -- en début de ligne (le premier - est transformé en puce).
Ce n'est pas très grave, en Aperçu permet de s'en rendre compte très vite et de corriger le texte (en plusieurs fois éventuellement).
Voici le texte à copier en bas de page pour le reproduire (avec tous les espaces conservés en début de ligne) :
- Une évolution que je vois c'est une navigation à deux niveaux :
- supposons que j'ai une toc avec liste des chapitres et des sous-chapitres, sur une page
- je verrais bien affiché : tous les sous-chapitres du chapitre en cours (pas simplement suivant/précédent qui est trop linéaire) + chapitre précédent / chapitre suivant (voire la liste de tous les chapitres)
=> tout de suite la navigation n'est plus un labyrinthe mais elle est à plat
=> si on le met à gauche, ça permet d'avoir comme certains menus en java : tous les sous-chapitres du chapitre en cours sont visibles, tout le niveau au-dessus est directement accessible...)
-- BenoitAudouard 20031118 (enfin ce que je veux en premier, c'est les tableaux !)
- ça te convient comme descriptif d'évol ? Je l'ai quand ? ;-)) -- BenoitAudouard 20031120
Question tout de même
Priorité : Basse ?
Difficulté : Aucune
Description : Les erreurs connues liées à une surcharge du serveur
Faire une page de doc' pour WikiNi, listant ces erreurs dans la doc' de l'administrateur WikiNi. La conduite à tenir est de prévenir un administrateur de TuxFamily (mail, irc...) ou de l'hébergeur retenu pour qu'il regarde ce qui se passe à ce moment là et intervienne. L'ajouter aussi à la FaqTuxFamily?
-- BenoitAudouard 20031121
Dans la page : http://www.wikini.net/wakka.php?wiki=FonctionnalitesDetaillees
le lien wikiNiSyndication ->
Query failed: select * from wikini_pages where tag = 'WakkaFr' and latest = 'Y' limit 1 (Lost connection to MySQL server during query)
- ça c'est pas un bogue, c'est un serveur de tuxfamily surchargé, ce soir j'ai eu droit à ça aussi :
- 20h30
- http://faq.tuxfamily.org/wakka.php?wiki=DerniersChangements
- Query failed: select * from wikini_acls where page_tag = 'DerniersChangements' and privilege = 'read' limit 1 (Lost connection to MySQL server during query)
- 20h35 et un début d'affichage de page
- http://faq.tuxfamily.org/wakka.php?wiki=DerniersChangements
- PagePrincipale :: Query failed: select * from wikini_pages where tag = 'DerniersCommentaires' and latest = 'Y' limit 1 (Lost connection to MySQL server during query)
- Plus quelques pages blanches, Server made a boo boo, la page DerniersCommentaires étant particulièrement fragile (toute la présentation est perdue, seul s'affiche le contenu avec les liens) -- BenoitAudouard 20031121
Priorité : Bassejav
Version : WikiNi 0.1.1.0.3 et inférieurs
Difficulté : Normale.
Description : La suppression d'une page orpheline ne supprime pas les commentaires associés à cette page.
Bug pas très urgent, car la suppression de page est surtout faite pour de nouvelles pages crées par erreur, il n'y a souvent pas de commentaire associés.
Ces commentaires non supprimés offrent notamment un affichage disgracieux dans les DerniersCommentaires.
-- DavidDelon et CharlesNepote
Description : Le handler /deletepage, ou plus exactement la fonction DeleteOrphanedPage($tag), ne supprime pas les commentaires associés à la page ! Pour corriger ce problème, il suffit d'ajouter à cette fonction, dans le fichier wakka.php, la ligne suivante : $this->Query("delete from ".$this->config["table_prefix"]."pages where comment_on='".mysql_escape_string($tag)."' ");.
-- ProgFou 20031214
Je crois me rapeler que lorsqu'une page est supprimée, les données de la page restent en base (pour éviter tout problème de suppression intempestive)... doit-il en être ainsi des commentaires ? -- CharlesNepote
Attention : le code présent dans le CVS ne reflète pas cette position ! Le handler /deletepage appelle la méthode DeleteOrphanedPage? qui fait toute une série de DELETE : les révisions de la page et les liens, acls et referers associées, mais pas les commentaires en l'occurence. Donc il faudrait préciser ce qui est souhaité : purger le tout au moment du delete (dangereux ÀMHA), ou bien "marquer" l'effacement et ne l'effectuer que lors de la purge (préférable ÀMHA). -- ProgFou
Priorité : Basse
Difficulté : Normale.
Description : Le caractère euro : "€" ne s'affiche pas bien à l'édition à cause de l'encodage actuellement en vigueur dans les pages de WikiNi : ISO-8859-1. Il faudrait choisir ISO-8859-15 pour résoudre le problème mais il faut alors étudier l'impact de ce changement. Ce n'est pas très urgent. Je m'en charge.
L'idéal serait encore d'adopter l'unicode (UTF-8), mais MySQL 3.x et 4.0.x ne gèrent pas cet encodage. -- CharlesNepote
En attendant, utiliser ""€"", qui donne bien €.
Une première étape pourrait être d'ajouter une colonne encoding à la table wikini_pages. Ainsi l'encodage actuel d'une page serait connu et il serait donc plus facile de gérer les transitions. De même, on pourrait imaginer que cela permette d'avoir des pages dans différents encodages sur un même site. Le but final étant bien entendu d'arriver à l'UTF-8... -- ProgFou
Priorité : Basse
Version : au moins la version CVS après WikiNi 0.1.1.0.3
Difficulté : Normale.
Description : La fonction d'insertion d'image ne fonctionne pas lorsque l'image n'a pas d'extension. Par exemple, les icônes RDF proposées par le W3C n'ont pas d'extension :
http://www.w3.org/RDF/icons/rdf_w3c_icon.128 et s'affichent pourtant correctement dans les navigateurs (grâce au type Mime je suppose). Ce bogue s'explique du fait que l'image est affichée en fonction du fait qu'elle a une extention "gif", "jpeg" ou "png" (cf. ce diff ligne 238). Il paraît difficile de faire tester chaque lien à WikiNi pour connaître son type Mime. Aussi la solution à ce bogue semble passer par la création d'une action qui pourrait avoir la forme suivante : {{img src="http://xxx.yyy.com/image" alt="Texte alternatif"}}. Cette fonction offrirait aussi la possibilité de spécifier l'élément "alt".
-- CharlesNepote
Priorité moyenne
Priorité : Moyenne
Difficulté : Normale.
Description : L'action "mychanges" lors du tri par dates affiche plusieurs fois le même jour. C'est peut être un fonctionnement normal mais alors c'est pas trés intuitif... Un petit texte explicatif serait bienvenu. -- JeanPascalMilcent
- ErwanPigneul la requete appelée pour formatter la page mychange n'est pas correcte. je propose plutôt d'utiliser celle ci dessous (ligne 15 normalement):
<?php
if ($pages = $this->LoadAll("SELECT tag, max(time) as time FROM ".$this->config["table_prefix"]."pages WHERE user = '".mysql_escape_string($this->UserName())."' AND tag NOT LIKE 'Comment%' GROUP BY tag ORDER BY time ASC, tag ASC"))
?>
Priorité : Moyenne
Difficulté : Normale.
Description : Mauvaise restitution des diffs lors d'ajout/suppressions de liens. -- DavidDelon
Priorité : Moyenne
Difficulté : difficile
Description : Internet Explorer sous Macintosh ne permet pas d'éditer des documents de taille > 30k (environ). -- DavidDelon
Internet Explorer sur mac n'est plus supporté par Microsoft. Le navigateur par defaut sur Mac devient Safari. IE mac va peu à peu devenir comme Netscape 4.x, cad utilisé par 0.5% des internautes.
Haute priorité
Priorité : Haute
Difficulté : normale
Description : Le rendu sous Netscape Navigator 4.x n'est pas vraiment acceptable. Par exemple sous NN 4.7 Win98? :
- la fenêtre d'édition est trop petite,
- celle des commentaires aussi,
- si une page contient juste un mot par exemple, le cadre entoure complètement ce mot,
- les indications de bas de page ne sont pas alignées,
- le word diff n'est pas toujours affiché correctement.
(cadre autour du mot).Ces problèmes n'apparaissent pas avec Netscape 7.x. (Ils ne devraient pas non plus survenir sur Netscape 6.x.)
Il paraît intéressant d'améliorer cette situation, même si Netscape 4.x est en voie de disparition. (Travail en cours, presque terminé, par CharlesNepote.)
-- DavidDelon, PatrickPaul, CharlesNepote
Envoyez chier NS4 !! Aucun respect pour cette antiquité qui casse les couilles de tout les webdesigners vivants sur terre. Respectez les standards, c'est tout !
-- Francois
Je suis assez d'accord avec François ;-) En plus, NS4 est un dinosaure en voie de disparition. Tant pis si les pages apparaissent en noir et blanc. Si le code xhtml respecte bien la sémantique, la page sera lisible. C'est tout ce qu'il y a d'important.
Vouloir faire une jolie page sous NS4 va poser beaucoup de problèmes, faire perdre du temps pour peu de résultats.
La vérité est ailleurs ;-D
-- Pascale
Priorité : ???
Difficulté : difficile
Description : a bug in the handlers/page/diff.php, display of deletion (not changing) of words is in false order, eg. look at ErusUmbrae and the last change: deletions of "now" and "first" are placed after another unchanged word, which would normally go first
-- ErusUmbrae
Ok, see what you mean ... Thanks for this report.
-- DavidDelon
Would be very happy if you could solve this. ;>
-- ErusUmbrae
Priorité: Basse
Difficulté:?
Description : Il semble impossible d'afficher deux caractères " consécutifs dans une page Wiki
-- PaulToth
Oui. C'est assez pénible dans certains cas. Il est possible de les afficher correctement entre deux balises %% (correspondant à la balise <pre> HTML) mais une boite est alors créée. Il est aussi possible d'utiliser leur codage HTML : "" ou "" (voir la source), mais c'est une solution un peu lourde. Je vais réfléchir au problème. -- CharlesNepote
Priorité: Basse
Difficulté:?
Description : Le caractère œ s'affiche correctement dans du texte normal, mais non lorsqu'inséré dans un lien wiki mon œuvre?
-- EuLer
Peux-tu préciser la façon dont tu procèdes. Il n'y a aucun problème de mon côté : tu peux voir l'exemple que j'ai créé dans le BacASable et ici même avec beaucoup de cœur. -- CharlesNepote
Au niveau de mon navigateur (Firebird !!!) le cœur qui est tout juste avant le --CharlesNepote ci-haut, je le vois avec le c&_#_339ur (J'ajoute les barres de soulignement au cas où vous verriez vraiment le "oe" correctement). En fait, ce problème est seulement lorsque le "oe" se trouve dans un lien : [[lien cœur]] --EuLer
Priorité : Basse
Difficulté : Facile
Description : « Sauver » m'apparaît comme un anglicisme (Save...). Il faudrait lui préférer ENREGISTRER. Il suffit de modifier le fichier edit.php dans handlers/page.
-- EuLer
Totalement d'accord ; heureusement que nos cousins Quebecquois veillent ! Je vais corriger (AFaireMoinsDe10Minutes) -- CharlesNepote
Je me demande également si on ne peut pas remplacer le "Editer cette page" par "Modifier cette page"
- Pour :
- "Modifier" est plus général que "Editer" qui a un côté "informaticien".
- Contre :
- La documentation existante fait référence à "Editer cette page" ;-)
- Modifier a peut-être un côté moins précis qu'éditer. (Éditer est même rentré dans les moeurs et se trouve dans de nombreux logiciels bureautiques sous la forme du menu "Édition") (CharlesNepote)
Moi je ne suis pas contre, mais il faut alors aussi "modifier" la chaîne "Éditer permissions" pour "Modifier permissions". Je suggère d'aller voir sur les autres wikis avant toute chose. -- CharlesNepote
Les changements proposés n'apportent rien en terme de fonctionnalité. Pire: enregistrer est plus long que sauver. -- GerdAmi.
En terme de fonctionnalité, la modification n'apporte rien, en effet. Mais pour ma part je pense que la diversité culturelle mérite autant d'attention qu'un bogue fonctionnel. D'autant que le mot "enregistrer" est celui qui est généralement utilisé dans nos traitements de texte, navigateurs, tableurs et autres. L'argument de la longueur me paraît de peu de poids : 11 lettre au lieu de 6, à un endroit où on a toute la place, ce n'est vraiment pas génant. Sauf opposition en masse, je pense qu'il faut donc le corriger. -- CharlesNepote
Priorité : Basse
Difficulté : Solution proposée
Version testé : 0.4.1rc
Description : Lorsque on affiche une page avec le paramètre /raw la page n'est pas affichée correctement sous IE qui la considère comme une page HTML (?). Les espaces et les retours à la ligne sont donc retirés lors de l'affichage. Pour avoir le texte de la page tel qu'il a été tappé, il faut indiquer au navigateur le type mime à utiliser, à savoir text/plain. La correction est assez simple :
<?php
if ($this->HasAccess("read"))
{
if (!$this->page)
{
return;
}
else
{
header("Content-type: text/plain"); //correction pour afficher le texte réel
// display raw page
echo $this->page["body"] ;
}
}
else
{
return;
}
?>
Si vous n'êtes pas contre, je me propose de mettre le CVS à jour le 19/10/2003 avec cette correction.
--GarfieldFr
Ok, verifier qu'il n'y ait pas d'impact lors de la syndication (inclusion inter-wikini) -- DavidDelon
Complètement OK pour moi. David peux-tu confirmer qu'il ne va pas y avoir d'interférence avec la syndication ? [on a eu la même idée mais avec un conflit d'édition pour moi ;] -- CharlesNepote
Je viens de tester, pas de problème avec la syndication -- DavidDelon
Au passage, cette correction nous permet de générer la page dans un format compatible avec le processus d'installation que je propose dans GestionDeLaDocumentationWikiNiInstallee. Il suffirait de rajouter un paramètre à la méthode pour enregistrer la page directement sur le serveur. Un truc du genre http://www.wikini.net/wakka.php?wiki=RapportsDeBogues/edit&save=1. Je regarde si ca marche....
Je viens de faire un essai concluant, une telle syntaxe permet bien de générer un fichier texte avec le contenu de la page. Voici le code modifié :
fichier handlers/page/raw.php
<?php
if ($this->HasAccess("read"))
{
if (!$this->page)
{
return;
}
else
{
header("Content-type: text/plain");
// display raw page
echo $this->page["body"] ;
if ($_GET["save"]) {
$filename = "setup/doc/".$this->GetPageTag().".txt";
if (!$fp = fopen($filename, 'w')) {
echo $this->Format("//Impossible de créer le fichier ($filename)//");
exit;
}
if (!fwrite($fp, $this->page["body"])) {
echo $this->Format("//Impossible d'écrire dans le fichier ($filename)//");
exit;
}
fclose($fp);
}
}
}
else
{
return;
}
?>
Le fichier est généré dans le répertoire setup/doc qui doit exister et accessible en écriture.
--GarfieldFr
Au passage je pressent un bogue sur la syndication (/formatters/wakka.php) :
<?php
// raw inclusion from another wiki
else if (preg_match("/^\[\[\|(\S*)(\s+(.+))?\]\]$/", $thing, $matches))
{
list (,$url,,$text) = $matches;
if (!$text) $text = "404";
if ($url)
{
$url.="/wakka.php?wiki=".$text."/raw";
return $wiki->Format($wiki->Format($url, "raw"),"wakka");
}
else
{
return "";
}
}
?>
Si le wiki duquel on fait l'inclusion gère la ReecritureDURL, la chaîne "/wakka.php?wiki=" est inutile, non ? -- CharlesNepote
Oui est elle est inutile mais comme on ne sait pas à l'avance si le site dont on fait l'inclusion fait de la réecriture ... De toute façon les deux syntaxe sont valides, ainsi http://www.wakkawiki.com/RecentChanges et http://www.wakkawiki.com/wakka.php?wakka=RecentChanges donnent le même résultat. -- DavidDelon
Priorité : ?
Difficulté : ?
version testée : 0.1.1.0.3
Description : Dans le Wiki que je prépare sur la coopération (snif, je voulais le proposer à tous...) http://jmichelcornu.free.fr/WikiCooperation/wakka.php?wiki=PagePrincipale
il se passe un truc bizare dès que l'on modifie la PagePrincipale.
Lorsque l'on sauve après édition il met un message : "Query failed: update cooperation_pages set latest = 'N' where tag = 'PagePrincipale' (Got error 134 from table handler)"
et la pagePrincipale n'est plus accessible. Il faut alors aller dans la base de donnée : la modif n'y est pas mais il n'y a plus de pagePrincipale dont le champ "latest" soit à Y.
Il faut donc reprendre la dernière version (en fait l'avant dernière puisque la dernière n'a pas été entrée dans la base) et remettre le champ latest à Y à la main pour pouvoir de nouveau accéder à la PagePrincipale
Cela ne se produit pas sur les autres pages.
Je ne comprends pas si c'est dans le code Wiki entré que cela plante ? Pourtant même sans modification de la page actuelle ("Editer cette page" puis sauver sans rien toucher) il se passe la même chose, ou si c'est un bogue Wikini ou Free ???
Cela a commencé à planter après que la modif (qui n'a pas été prise en compte) était d'ajouter un "-" dans un mot Wiki : VosCorrections2?-1. Est-ce que cela pourrait y être pour quelque chose ?
--JeanMichelCornu
Il semblerait que la table cooperation_pages soit corrompue : difficile de déterminer la raison mais je ne pense pas que Wikini soit directement responsable. La seule solution que je vois, puisque tu n'a pas accès aux outils d'administration de la base de donnees chez free, c'est de detruire la table et de la recréer, à partir de phpmyadmin pour la destruction et en relancant l'installation pour la création (sauvegardes auparavant !). Free est souvent surchargé, victime de son succès, du coup ce genre d'incident arrive de temps en temps. -- DavidDelon
Priorité : Basse
Difficulté : Simple
Version testé : 0.4.1rc
Description : Un lien wiki sur un mot comportant un accent propose un lien http://lemotenqestion.
Un exemple vaut mieux qu'un long discours :
Elephant?
--Twidi 20031219
J'ai un patch à proposer pour que les mots wiki puissent comporter des accents.
4 lignes à modifier : 2 dans wakka.php et 2 dans formatters/wakka.php
Je l'enverrais dans quelques jours.
Si vous voulez le patch directement, contactez-moi par mail : dolmen à bigfoot point com.
-- OlivierMengu?é 2004-02-13
Priorité : Moyenne (peut poser des problèmes dans certaines conditions)
Difficulté : Simple (genre AFaireMoinsDe10Minutes ;-))
Description : Le calcul automatique de l'option de configuration base_url est incorrect. Ceci pourrait avoir des conséquences importantes dans le cas de la non spécification explicite de cette option dans le fichier de configuration. Je propose la correction suivante : dans wakka.php, dans la définition du tableau $wakkaDefaultConfig, définir "base_url" comme ($_SERVER["HTTPS"] ? "https" : "http")."://".$_SERVER["HTTP_HOST"].($_SERVER["SERVER_PORT"] != 80 ? ":".$_SERVER["SERVER_PORT"] : '').preg_replace("/\/".preg_quote("wakka.php").".*$/", "/", $PHP_SELF).(preg_match("/\/".preg_quote("wakka.php")."($|\?)/", $_SERVER["REQUEST_URI"]) ? "wakka.php?wiki=" : ''). Cette expression pourrait aussi être simplifiée si rewrite_mode était calculé avant. J'ai testé le fonctionnement de cette correction à la fois en mode standard et en mode rewrite. Au passage, personnellement j'utilise un define(WAKKA_ENGINE, "wakka.php") pour éviter de mettre cette valeur en dur dans le script.
-- ProgFou 20040103
Priorité : Basse
Difficulté : Moyenne (?)
Description : L'édition d'un commentaire le détache de sa page associée. La première question est de savoir s'il est normal de pouvoir éditer un commentaire en l'appelant directement par son NomWiki, par exemple ainsi : Comment149?. Si oui, alors il faudrait vérifier pourquoi on perd l'information du comment_on après l'édition, sinon il faudrait bloquer l'édition des commentaires.
-- ProgFou 20040103
Priorité : Moyenne
Difficulté : Simple (genre AFaireMoinsDe10Minutes ;-))
Description : Il est impossible d'enregistrer un commentaire si on a pas le droit d'écriture sur une page. Ceci est du à une erreur dans la fonction SavePage du fichier wakka.php : il faut remplacer HasAccess("write", $tag) par HasAccess($comment_on?"comment":"write", $tag). On peut alors au passage supprimer la ligne "TODO:" juste au dessus. ;-)
-- ProgFou 20040110
Je ne comprend pas le bogue. Il est parfaitement possible de publier un commentaire dans le cas que tu décris, non ? Peux-tu préciser ? -- CharlesNepote
En premier lieu, sur le principe même du test des droits d'accès, on devrait tester le droit comment et non write pour autoriser l'ajout d'un commentaire. Ou à la rigueur les deux ? Mais pour moi commenter n'est pas modifier la page ! En second lieu, le test actuel empêche quelqu'un d'ajouter un commentaire à une page s'il n'a pas les droits d'écriture sur celle-ci (est-ce le choix de WikiNi ?), sauf s'il est propriétaire de la page vu que ce dernier à tous les droits sur une page ! Encore une preuve des risques de confusions, voir bugs, en faisant ce genre d'exception. -- ProgFou
Priorité : Basse
Difficulté: : Simple
Description : Index de tableaux non initialisés ou proprement testés (entre autres remarques cosmétiques)
Par exemple, en arrivant sur la page d'accueil, j'ai les "notices" suivants :
Notice: Undefined index: message in d:\sites web\_local\wikini\wakka.php on line 229 Notice: Undefined index: linktracking in d:\sites web\_local\wikini\wakka.php on line 290 Notice: Undefined index: linktracking in d:\sites web\_local\wikini\wakka.php on line 283 Notice: Undefined index: linktracking in d:\sites web\_local\wikini\wakka.php on line 283 Notice: Undefined index: linktracking in d:\sites web\_local\wikini\wakka.php on line 283
Par exemple, si je prend la ligne 229 incriminée dans le premier notice, je vois :
<?php
function GetMessage() { $message = $_SESSION["message"]; $_SESSION["message"] = ""; return $message; }
?>
Outre le fait qu'écrire des fonctions sur une ligne n'est pas le meilleur moyen de rendre un code lisible par les contributeurs, et qu'utiliser des chaînes délimitées par des simples quotes doit être favorisé, il faut toujours tester l'existance d'un élément avant d'en utiliser la valeur.
J'écrirais donc plutôt ici :
<?php
function GetMessage()
{
if (isset($_SESSION['message'])) {
$message = $_SESSION['message'];
}
$_SESSION['message'] = '';
return $message;
}
?>
- NicolasHoizey
Il est clair qu'il faudrait faire le ménage dans le code de WikiNi pour éviter ce genre de chose. Manque de temp hélas ! Mais cela sera fait un jour. En attendant, il suffit de modifier le php.ini pour qu'il ne renvois pas les "NOTICE", ce qui est en général la configuration des hébergeurs. --GarfieldFr
Priorité : ?
Difficulté: : ?
Version testée: WikiNi 0.1.1.0.3
Description : Ayant modifié (dans le fichier de configuration) les liens qui apparaissent en entête de page (entre PagePrincipale et "Vous êtes xxx.yyy.zzz.ttt"), j'ai un problème qui intervient à chaque modification de page. Les liens que j'ai placé en entête sont insérés dans la base (liens en provenance de la page éditée et en direction des liens de l'entête). C'est à dire que le lien TableauDeBordDeCeWiki que j'ai placé en haut apparait dans toutes les branches du PlanDuSite (ce qui rend ce dernier illisible).
Précision, les liens sont sous la forme [[ParametresUtilisateur Profil utilisateur]]. -- OlivierPoncin
- Où les as-tu changé exactement (quel nom de fichier) ? Ce comportement est normal si tu as fait cette modification directement dans l'action {{header}} et que tu n'y as pas indiqué que tu ne souhaitais pas que ces liens soient "suivis" (c'est appelé LinkTracking? dans le code). J'attends ta réponse pour te donner plus de précisions. -- ProgFou
- J'ai simplement édité la ligne "navigation_links" du fichier de config wakka.config.php. Je ne connaissais pas le principe de LinkTracking? donc désolé d'avoir signalé un bug qui n'en est pas un! Il me semble pourtant étrange d'avoir choisi ce comportement par défaut, je vais chercher comment le désactiver. -- OlivierPoncin
- Ok. Je viens de regarder comment est utilisé cette variable navigation_links et elle subit effectivement le suivi des liens, lors de son affichage dans l'action {{header}}. Si ça te gène vraiment, tu peux essayer ceci : dans le fichier actions/headers, chercher le code PHP permettant l'affichage de navigation_links, le précéder d'un appel à $this->StopLinkTracking() et le faire suivre d'un appel à $this->StartLinkTracking(). Pour ma part j'en ai profité pour étudier une fonction SetLinkTracking qui renvoit l'état en cours puis fixe le nouvel état. Je verrai à l'usage si ça vaut le coup de l'intégrer dans les prochaines versions de WikiNi. :) -- ProgFou
- Merci bien, mon problème est effectivement résolu de cette manière. Je me demande toutefois l'intérêt de tracker les liens du header! -- OlivierPoncin
- Je pense que la cause est tout simplement historique et que ça fait partie des choses que nous devons nettoyer un peu... -- ProgFou
Priorité : très haute !!! ;-)
Difficulté: : immédiate
Je reviens à la charge ;-) mais je n'arrive pas à maintenir mon inscription sur wikini.net uniquement très longtemps. Et à voir la page des derniers changements, je ne suis pas le seul. Mystère, une histoire de cookie ? --FidelioEspoir
Priorité : basse
Difficulté: : immédiat
Version testée: WikiNi 0.4.1rc
Description : dans la regex de la mort du formatteur, il y a des virgules qui trainent dans des crochets, pour repérer les liens wiki : [A-Z,0-9]
Du coup, Ab,z est reconnu par le preg_replace_callback et par le if correspondant de wakka2callback, mais la méthode Link ne le comprend pas comme un lien wiki et le change en http://ab,z/
Solution : dégager toutes les virgules :-)
Priorité : basse
Difficulté: : moyenne (nécessite une recherche dans le code)
Version testée: WikiNi 0.4.1rc
Description : On peut utiliser absolument n'importe quel nom (avec n'importe quel caractère) pour une page de WikiNi, du moment qu'on le place directement dans l'URL.
Solution : Il vaudrait mieux effectuer un contrôle du nom de page fourni avant de proposer de créer cette page. Ce bug fait aussi ressortir le manque d'appel à la fonction stripslashes (ou bien désactiver la fonction d'échappement des caractères) pour nettoyer les variables reçues via CGI.
--ProgFou
Priorité : haute ?
Difficulté: : ?????
Version testée: WikiNi 0.4.1
Description : Lorsque l'on souhaite afficher une ligne horizontale non pas avec le formateur ---- mais afficher une ligne de ____ (regardez la source, j'ai inséré cette ligne)
_
tout le wiki Bug sur l'affichage de la page ...regardez en bas la ligne de copyright et le reste. De plus un caractere "bizarre s'affiche".
Solution : ???? Respecter la syntaxe Wiki ? Il m'est arrivé de bugger un wiki entier avec impossibilité de l 'afficher sans avoir modifié la BDD..mais cela était dut à du html inséré. Dans le cas de notre ligne horizontale c est la syntaxe Wiki qui bug c est beaucoup plus grave.
Je crois pas que ce soit la syntaxe WikiNi qui bug, simplement tu ne l'utilise pas correctement, quant tu insère une "ligne" faites avec des _ tu genère une suite de balise souligné et donc si tu génère le mauvais nombre de balise, tu va avoir la suite du texte souligné jusqu'a la fin de la page. Par dessus tu ajoute une erreur d'interprétation du HTML par le navigateur et tu obtiens un résultat bizarre. Regarde le HTML généré par ton "bug" et tu veras qu'il est correct --GarfieldFr
Note : j'insère le même symbole ci-dessous pour éviter de souligner tout le reste de la page --ViNz
_
Priorité : basse
Difficulté: : ?????
Je suis sur Internet Explorer (...) et il semble impossible d'afficher la source d'une page WikiNi.
Vous avez été confrontés au pb?
--SimonGB?
Je n'arrive pas à reproduire le bogue ; pas de problème avec Internet Explorer 5.0. Pouvez-vous détailler SVP ? -- CharlesNepote
- Sous Internet Explorer 6.0.2800.1106, sur deux machines différentes (98 et XP), la demande d'affichage de la source reste muette
- J'ai entre temps contourné le pb en demandant une actualisation de la page. Suite à cette manip, la source apparaît normalement...
- Ce n'est pas bloquant, mais plutôt curieux... -- SimonGB?
J'arrive à afficher la source... par contre dès que je tape un caractère j'ai une fenêtre "Erreur" qui apparait avec le message suivant:
-
Une erreur est survenue
Souhaitez-vous effectuer un déboggage?
Ligne: 144
Erreur: objet attendu
Oui|Non
-
Est-ce que cela peut vous éclaircir? StephaneCvr
Priorité : basse
Difficulté : si je savais ;)
J'ai utilisé l'action include avec les paramètres de style sur un wiki (WikiNi 0.4.1rc) de façon tout à fait normale.
Je constate qu'ici ça marche aussi (voir ActionInclude) alors que sur mon wiki (WikiNi 0.1.1.0.3) l'action include en elle-même fonctionne, mais pas le style.
Ne connaissant rien au PHP, j'ai simplement demandé à ce qu'on me donne une copie du fichier Include.php provenant du wiki où ça marchait (WikiNi 0.4.1rc) pour remplacer l'include.php de mon site, mais ça ne marche pas plus.
Y a-til d'autres modifs à faire ?
(Note : les deux pages ayant l'action include sur les deux sites différents dont je parle sont des copies conformes).
--StaifanY
Priorité : basse
Difficulté : semble très facile
Certains nous disent que la gestion des sessions est défaillante sur wikini.net. Mais je n'arrive pas à reproduire le bogue...
GarfieldFr nous a fait remarqué cependant, en effet, une chose anormale : la présence de "" dans le chemin de session (cookie path). Si le problème (lequel) vient de là, le code incriminé est le suivant (dans /wakka.php) :
- determine le chemin pour le cookie
- $a = parse_url($this->GetConfigValue?('base_url'));
- $this->CookiePath? = dirname($a['path']).'/';
Il faut supprimer le .'/' à la fin.
Suite à confirmation du bogue, le premier qui met à jour le CVS à gagné ;)
-- CharlesNepote
Priorité : haute
Version : 0.4.1rc
Type: Faille XSS
Description :
http://www.domaine.tld/wakka.php?wiki='"><h1>ARGHHHH
Grave docteur ?
Remède :
Dans la dernière version de wikini (CVS du 28 sept 2004), si on installe wikini dans un répertoire pas à la racine du site (disons /wiki par ex.), l'install se déroule bien (hébergement free.fr), mais au moment de revenir sur la page principale, il y a plein de gros mots qui s'affichent parce que le répertoire sessions n'a pas été trouvé pour placer le cookie. En effet, il semble que le répertoire sessions doive être placé à la racine du site, et non dans le répertoire /wiki. C'est y pas un bug ça ?
- La position du répertoire de sessions est fonction de l'hébergeur et non pas de WikiNi. Ce n'est pas WikiNi lui-même qui gère la sauvegarde des sessions, mais le moteur PHP installé par l'hébergeur. Il faut donc se conformer aux directives de l'hébergeur pour l'emplacement du répertoire de sauvegarde des sessions. -- ProgFou
Priorité : Moyenne
Difficulté: : Moyenne ?
Version : 0.4.2
Description : Si un utilisateur s'est connecté sans demander "se souvenir de moi", et si il est encore en train d'éditer une page lorsque son cookie d'identification devient périmé, quand il clique sur "Sauver", il se voit répondre "Vous n'avez pas accès en écriture à cette page !" et il perd ce qu'il vient d'éditer.
Une solution serait peut-être de mettre un champ hidden dans le formulaire <form> d'édition, et de tester ce champ dans edit.php. Si l'utilisateur n'existe pas, mais que ce champ existe, on peut envoyer à l'utilisateur un message d'alerte (comme en lignes 52-54 de edit.php, lorsque quelqu'un d'autre a sauvegardé la même page), mais cette fois pour lui dire "copiez vos modifications, reconnectez vous et collez vos modifs avant de sauver à nouveau."
-- YvesGrenier
- Il me semble que le cookie d'identification est relativement long... il faut en outre que la page soit protégée pour les seuls utilisateurs enregistrés : ce qui fait que ce cas doit être assez rare. Cela dit, il s'agit tout de même d'un problème. Si vous avez le courage de pondre un peu de code il est le bienvenu ; sinon je regarderai à l'occasion. -- CharlesNepote
Priorité : Moyenne
Difficulté: : ?
Version : 0.1.1.0.3 (interwiki)
Je viens d'installer une WikiNi et contraitrement aux deux premières 1 et 2, j'ai plusieurs soucis :
- Afficher/commenter ouvre une page en création qui porte le titre TitrePage??show_comments=1
- si l'on veut consulter l'historique d'une page, cela ouvre la page principale
ArnoLagrange 22/01/2005
- Tout d'abord, la version 0.1.1.0.3 contient des failles de sécurité et n'est plus maintenue : vous devriez changer de version au plus vite. Par ailleurs, n'avez-vous pas justement "personnalisé" cette version, expliquant ainsi les dysfonctions ? Pour l'option d'aperçu voir la DocumentationFichierDeConfiguration. -- CharlesNepote