Les pages wikini sont limitées à 65000 caractères car elles sont stockées dans un champ de type text. Le problème est que si on rédige une page comprenant plus de 65000 caractères ils sont supprimés lors de la sauvegarde.
Aprés échange de mails avec DavidDelon, plusieurs solutions :

• limiter la taille du champ de saisie à 65000 caractères.
• prévenir avant sauvegarde
• utiliser le longtext pour stocker les pages (2^32 octets dispo ...).

-- JeanPascalMilcent

• Moi je suis en faveur d'une augmentation de la taille du champ. -- PatrickPaul

• Attention : à propos du "longtext", la documentation mentionne : "Note that because the server/client protocol and MyISAM? tables has currently a limit of 16M per communication packet / table row, you can't yet use this the whole range of this type. See section 6.2.3.2 The BLOB and TEXT Types". Dans le cas où on décide de changer le type du champ, le type "mediumtext", limité (sic) à 16 Mo devrait peut-être suffire non ?
• Est-ce que la limite de 65000 caractères est vraiment pénalisante ? Avez vous des exemples de cas fréquents où la limite est problématique (je pense par exemple à la publication de textes d'auteur comme ceux proposés par l'ABU) ?
• Augmentation de la taille du champ :
  • question : est-ce que cela ne grève pas les performance et l'espace utilisé (à taille de contenus égales) ? la mise à jour des bases existantes est-elle facile ?
  • avantages : répond simplement au problème
  • inconvénients : danger pour la pérénité des sites (de nombreux Wikis sont montés sur des serveurs mutualisés avec une limite de taille de la base MySQL (souvent 20-50 Mo) ; cela veut dire qu'un individu mal intentionné peut saturer la base en quelques clics) [on peut peut-être limiter en plus la taille du champ de saisie ?]
• . -- CharlesNepote

• Sur le site de Tela Botanica, nous avons installé plusieurs Wikini. Nous sommes une dizaine à les utiliser régulièrement. Ce problème de page trop longue est apparu deux fois. Dans les deux cas, nous utilisions des tableaux en html (le code html encombre la page). Je pense qu'en passant le champ en mediumtext et en limitant le nombre de caractères dans le champ de saisie cela devrait marcher. N'est il pas possible de décider de la taille du champ texte avec une variable du fichier de config ?
• . -- JeanPascalMilcent

• Pour répondre à la question "la limite des 65 000 caractères est-elle vraiment pénalisante ?" j'apporte l'information suivante : cela représente environ 20 à 30 pages de texte (ceci n'est qu'une estimation). Je pense que cela peut être insuffisant notamment pour les sites de publication de textes ou encore l'édition colaborative de livres.

-- PatrickPaul White Knight Casino

• Dans le cadre d'une édition colaborative d'un livre ou d'un gros document, ces documents sont en général découpés en sections (chapitres, sous chapitres...etc). Avec l'action {{include}}, la limite de taille pour une page permet dans une certaine mesure de dépasser la taille de 65000 caractères, il suffit d'avoir une page par section et d'inclure toutes ces page dans le document final. L'avantage est la possibilité d'éditer simultanément des parties différentes d'un même document (puisque physiquement dans des pages différentes).

Ceci dit, il se peut que pour certaine très grosse section la limite de 65000 soit une limite. Alors pourquoi ne pas proposer lors de l'installation le choix de la taille maximum de chaque page avec un choix entre "page de taille mormale" et "page de très grande taille", la taille normale étant de 65000 caractères (type text) tandis que la grande taille serait la taille au dessus dans MySQL ( mediumtext je crois). Russia tours
-- GarfieldFr

Une autre chose, à quoi sert le champ body_r dans la table pages ? -- GarfieldFr
casino online slots
A ma connaissance le champ body_r n'a pas d'utilité. Il est apparu à la version 0.1. -- PatrickPaul

Alors, autand le supprimer non ? --GarfieldFr

Non, parce qu'elle pourrait servir : on pourrait par exemple l'utiliser pour ajouter le résumé de modification (et d'ailleurs body_r sonne bien dans ce cas). -- CharlesNepote
Encore un fossile ;-) --FidelioEspoir payment gateway

Ou en êtes vous de ce problème ? Il me parait urgent d'ajouter au moins une alerte en cas de dépassement sans quoi on écrase le contenu sans le savoir et on peut s'en rendre compte que plusieurs modifications plus tard ! -- cumulus

Pareil, la page http://rezal404.org/wikini/wakka.php?wiki=Mp3Legal arrive a saturation, et pourtant elle ne fait pas 30 pages je crois. Y'a t'il un risque de changer le type de table "a la volé" ?

• Théoriquement, je pense que ça ne présente pas de risque (sans garantie), mais je conseillerais tout de même de faire un backup d'abord (il suffit de copier la table sous un autre nom...) -- LordFarquaadfootball betting sites

Je vous ferais tout de même remarqué que 65535 carractères non seulement ça fait 65ko dans la bdd, mais cela en fait encore plus lors du rendu de la page, avec l'entête, le pied de page, les balises html et les actions... Une page web de 65ko c'est déjà pas mal, et en général je pense qu'on conseille vraiment de ne pas dépasser les 100ko... Permettre des champs mediumtext implique des pages qui peuvent dépasser les 16mo, vous imaginez ??? Je pense vraiment que text est une valeur tout à fait convenable, et qu'il vaut mieux apprendre à l'utilisateur à être raisonnable, notemment en lui affichant un avertissement. S'il y a vraiment besoin de dépasser cette valeur de 16ko, je pense que le mieux c'est l'include (un seul devrait suffir). Il ne faut pas oublier non plus qu'il est difficile de naviguer dans de trop longues pages...
Pour les cas où ça serait vraiment absolument totalement inévitable de faire une seule page de plus de 16ko, alors je pense que c'est à l'administrateur de faire ce changement. Je pense même qu'il ne serait pas bon de proposer un choix à l'installation, car cela risque de perturber les gens pour une option qui serait destinée seulement à de rares cas qui, a priori, ne sont pas prévisibles. -- LordFarquaad

---

---