Extension:Page Forms/Problèmes communs

This page is a translated version of the page Extension:Page Forms/Common problems and the translation is 100% complete.

Vous trouverez ci-dessous les questions communes et les problèmes rencontrés lors de l'utilisation de Page Forms . Cette page ne contient pas les bogues connus de Page Forms - voir pour cela Bogues connus et fonctionnalités planifiées.

Problèmes MediaWiki

Si un modèle contient des titres de section (comme == Section 1 ==), lorsque le modèle est affiché sur une page, chaque titre de section aura son propre lien « Modifier ». De tels liens ne sont pas souhaitables, car ils conduiront l'utilisateur à modifier le modèle plutôt que la page actuelle en question. La façon la plus simple d'éviter ce problème est de placer la chaîne __NOEDITSECTION__ n'importe où dans ce modèle; cela supprimera tous les liens de modification de section de toute page qui contiendra ce modèle. Une autre option qui vous permet de supprimer sélectivement les liens de section (mais toujours pas recommandée) est d'utiliser les balises ‎<h2>, ‎<h3>, etc. au lieu de ==, ===, etc.

Problèmes liés à Page Forms

Vous pouvez modifier la façon dont les dates sont entrées et sorties par les formulaires en ajoutant la ligne $wgAmericanDates = true; au fichier MediaWiki principal LocalSettings.php . Par défaut, les dates sont imprimées sous la forme 2007/06/20; en faisant ce changement, les dates seront alors imprimées sous le format « Juin 20, 2007 » (avec le nom du mois fonction de la langue du wiki).

Vous pouvez également définir manuellement le format d'affichage des dates en utilisant la fonction d'analyseur #time définie par l'extension ParserFunctions. Pour un format européen de style de date par exemple, vous pouvez avoir quelque chose comme ceci dans le modèle :

{{#time:d.m.Y|{{{start date}}}}}

De même, vous pouvez modifier la façon dont les heures sont saisies et affichées. Si vous avez un champ de formulaire dont le type d'entrée est datetime, par défaut il utilisera le format sur 12 heures, avec AM (pour le matin) et PM (pour l'après-midi). Vous pouvez le changer en format 24 heures en ajoutant dans votre fichier LocalSettings.php la ligne :

$wgPageForms24HourTime = true;

Si une page (que nous appellerons Page A) est transcluse dans une autre page (que nous appellerons Page B), et que la page A appartient à une catégorie associée à un formulaire, elle peut avoir l'effet secondaire malheureux de rendre la Page B membre aussi de cette catégorie, donnant ainsi à Page B un onglet Editer avec formulaire en haut, même si un tel onglet n'est pas approprié. Vous pouvez résoudre ce problème en plaçant la déclaration de la catégorie dans la page A dans un bloc ‎<noinclude>, ce qui fera de la page A un membre de cette catégorie, mais pas la page B.
Si, lorsque vous allez aux pages spéciales Special:CreateProperty ou Special:CreateTemplate, vous voyez un message d'erreur concernant l'accès refusé à la base de données ressemblant à "Access denied for user...", cela signifie que votre compte de base de données n'a pas l'autorisation de créer de tables temporaires.
Si vous rencontrez des problèmes JavaScript en utilisant Page Forms (comme la fenêtre de téléversement de fichier qui n'apparait pas correctement), le problème peut venir d'un bogue JavaScript généré par une autre extension ou de l'habillage. Pour déboguer le problème, ajouter ?debug=true ou &debug=true à la chaîne de l'URL concernée. Ensuite, inspectez la page à l'aide du navigateur, puis cliquez sur Console pour voir s'il y a des messages d'erreur JavaScript.
Plusieurs actions de Page Forms sont effectuées à l'aide de la file d'attente des travaux de MediaWiki, comme la création des modèles et des propriétés en utilisant Special:CreateClass, et en générant automatiquement les pages. Si ces actions ne semblent pas être effectuées, il se peut que la valeur de $wgMaxShellMemory ne soit pas assez grande. Par défaut, il est de 300 Mo (avant MW 1.22, 100 Mo); pour l'augmenter, ajoutez quelque chose comme ceci à LocalSettings.php :

$wgMaxShellMemory = 512000;

Si un formulaire contient un grand nombre de champs - par exemple avec l'utilisation de modèles à instances multiples - et que tous ne sont pas enregistrés, cela pourrait être dû à une limitation de PHP. Augmenter la valeur de la définition de max_input_vars dans php.ini peut aider.
Si vous avez des problèmes avec WikiEditor dans les formulaires, assurez-vous que la ligne suivante n'est pas dans LocalSettings.php:

$wgDefaultUserOptions['wikieditor-publish'] = 1;

Si VisualEditor n'apparaît pas dans les zones de texte, il peut être utile d'ajouter la ligne suivante à LocalSettings.php :

$wgDefaultUserOptions['visualeditor-enable'] = 1;

Si vous souhaitez effectuer un traitement sur une liste de valeurs avant d'appeler #arraymap sur elle, comme pour trier, ou la diviser ou l'imprimer, il peut être utile d'utiliser l'extension Array .
Page Forms ne traite que les formulaires pour ajouter et modifier les données des pages wiki. Vous pouvez souhaiter utiliser les formulaires à d'autres fins : heureusement, il existe quelques autres extensions de formulaires utilisables. Par exemple, EmailForm vous permet de créer des formulaires pour envoyer des données par courriel. Voir aussi le manuel des formulaires MediaWiki pour d'autres extensions de ce type.

Les tables wiki standard ne sont pas autorisées comme valeurs de champ. Vous pouvez surmonter cette limitation en utilisant {{!}} au lieu de | dans la syntaxe de la table wiki. Si vous utilisez VisualEditor dans les champs de formulaire (avec l'extension VEForAll ), il échappera heureusement les caractères '|' présents dans les tableaux. Ou vous pouvez simplement utiliser des balises standard HTML pour créer des tables.

Problèmes avec les autres extensions

Si vous utilisez Semantic MediaWiki pour l'autocomplétion, par exemple en utilisant values from property, vous pouvez constater que certaines valeurs sont tronquées et à la place, se terminent par une série aléatoire de nombres et de caractères.

Problèmes liés à l'architecture des données

Un problème général est l'utilisation des catégories. L'approche Wikipédia consiste à avoir de nombreuses catégories sur chaque page, afin d'identifier tous les aspects du sujet de la page. L'approche générale de Page Forms est cependant d'avoir une seule catégorie par page, et de faire définir cette catégorie par le modèle principal de la page : en d'autres termes, il est recommandé aux utilisateurs de ne pas entrer directement les déclarations de catégorie. L'exception à cette règle est lorsqu'il est nécessaire de marquer hiérarchiquement la page, c'est-à-dire d'être capable de l'ajouter à différents niveaux d'un arbre de catégories. Le type d'entrée 'tree' peut être utilisé à cette fin.
Lorsque vous définissez une relation entre deux classes, vous ne savez peut-être pas quelle classe devrait enregistrer cette relation. Habituellement, ces relations seront du type de un vers plusieurs, également appelée relation parent-enfant, dans laquelle chaque page de type A a une relation avec un certain nombre de pages de type B, tandis que chaque page de type B a toujours une relation avec exactement une page de type A. Un exemple concerne les pays et les villes : un pays peut avoir plusieurs villes, mais une ville appartient toujours à un pays donné. Dans ce cas, vous ne pouvez pas savoir si ce sont les pages Pays qui doivent avoir un champ Ville, ou les pages Ville qui doivent avoir un domaine Pays, ou même si les deux champs doivent coexister. Dans cette situation, il est recommandé de spécifier la relation seulement de l'enfant vers le parent, c'est-à-dire d'utiliser un champ "Pays" pour les villes et non l'inverse. Cela pour deux raisons: d'abord, cela vous permet d'appliquer la règle selon laquelle chaque enfant a exactement un parent; et deuxièmement, cela rend l'auto-complétion du formulaire plus fiable, puisque les pages des parents sont généralement créées avant les pages de leurs enfants.
Vous ne savez peut-être pas si vous devez créer un formulaire ou plusieurs pour un ensemble correspondant de types de pages. Par exemple, dans un wiki sur les restaurants, devrait-on avoir un formulaire / modèle / catégorie séparé pour les restaurants ordinaires, les restaurants de restauration rapide, les brasseries, etc., ou un formulaire unique appelé « Restaurant », avec un seul modèle et une catégorie correspondante, qui utilise simplement un champ pour indiquer de quel type de restaurant qu'il s'agit ? Une bonne méthode est de regarder l'ensemble de données que vous voulez entrer et être affichées pour chaque type de page. Si c'est la même chose pour tous les types, alors vous devriez probablement utiliser un seul ensemble de formulaire, modèle, ou catégorie pour tous. Si vous ne trouvez que quelques différences, vous pourrez peut-être utiliser la fonction Afficher sur sélection pour gérer les différents cas d'un même formulaire. Toutefois, s'il existe des différences suffisamment importantes dans l'ensemble des champs affichés, il est probablement plus logique de donner à un tel type de page son formulaire, son modèle et sa catégorie propres.
Il est possible de créer un espace de noms différent pour chaque type de page. Wikisource le fait par exemple avec un espace de noms Author:, et certains wikis utilisant Page Forms ont un ou plusieurs espaces de noms en fonction du type de page. Si vous faites cela sur votre wiki, c'est à vous de le faire, mais il n'est pas recommandé de le faire à moins qu'il n'y ait une vraie possibilité de nommer l'ambiguïté autrement. Un wiki important comme Wikipedia aura beaucoup de pages nécessitant de lever l'ambiguïté, mais la plupart des petits wikis n'en auront guère, et donc avoir des espaces de noms séparés sera probablement une complication inutile. (Actuellement, les exemples les plus courants d'ambiguïté dans les petits wikis sont causés parce qu'ils ont des pages pour les villes et les États des États-Unis : « New York » et « Washington » s'inscrivent dans les deux catégories. Il existe diverses solutions à ce problème, mais la plus simple peut être de que chaque état soit référencé par son abréviation sur deux lettres, par exemple "NY" et "WA".)