Extension:Page Forms/Input types/fr

Cette page couvre les différents types d'entrées possibles pour Page Forms, ainsi que les paramètres et les autres adaptations qu'il est possible de leur appliquer.

text
Type d'entrée par défaut; correspond à l'entrée text de HTML.

Paramètres spéciaux :
 * size - Indique la largeur de la saisie, en nombre de caractères.
 * maximum length - Indique la longueur maximale autorisée pour l'entrée.
 * placeholder text - Indique le texte d'aide affiché à l'entrée jusqu'à ce que l'utilisateur clique dessus.

textarea
Correspond à la balise HTML.

Paramètres spéciaux :
 * num rows - Indique le nombre de rangées.
 * num cols - Indique le nombre de colonnes.
 * maximum length - Indique la longueur maximale autorisée pour l'entrée.
 * - Définit la zone de texte comme redimensionnable automatiquement en hauteur, afin de recevoir le contenu entier sans avoir besoin d'ascenseur.
 * editor type - Ajoute un éditeur basé sur JavaScript à la zone de texte pour faciliter l'édition de son contenu. Les valeurs suivantes sont prises en charge :
 * - utilise l'extension qui doit être installée. Malheureusement, à cause d'une limitation dans l'extension WikiEditor, une seule entrée du formulaire peut être associée à WikiEditor. Si vous voulez ajouter tout  à WikiEditor, vous devez les ajouter dans le JavaScript à , comme ils existent pour.
 * - utilise l'extension qui doit être installée.
 * - utilise l'extension qui doit être installée. Une autre extension  doit aussi être installée. Si vous souhaitez que la barre d'outils s'affiche en haut du champ d'édition plutôt qu'en bas (par défaut), vous devrez également ajouter


 * maximum height - Si VisualEditor est utilisé, cela indique une hauteur maximum (en pixels) pour la zone de texte, car VisualEditor utilise autgrow. Par défaut, cette valeur est de 400.
 * placeholder text - Indique le texte d'aide affiché à l'entrée jusqu'à ce que l'utilisateur clique dessus.

text et textarea avec autocomplétion
Ces deux entrées sont affichées de la même manière que les types d'entrée  et , et ils peuvent être configurés de la même manière, mais ils fournissent aussi l'autocomplétion - aucune ou plusieurs valeurs. Voir les sections sur l' initialisation des paramètres et l' autocomplétion ci-dessous sur la manière de personnaliser l'autocomplétion.

combobox
Le type d'entrée combobox fournit une interface de style liste déroulante : une entrée qui fonctionne comme un champ régulier avec autocomplétion, mais avec une icône supplémentaire de flèche vers le bas, comme celle d'un dérouleur, pour permettre à l'utilisateur de voir d'un seul coup toutes les valeurs possibles. Il est implémenté en utilisant la bibliothèque JavaScript Select2.

Paramètres spéciaux :


 * size - Indique la largeur de la saisie, en nombre de caractères.
 * - Refuse les valeurs arbitraires dans le champ.
 * placeholder text - Indique le texte d'aide affiché à l'entrée jusqu'à ce que l'utilisateur clique dessus.
 * namespace - Préfixe la valeur sélectionnée en ajoutant l'espace de noms spécifié.

tokens
Ce type d'entrée réalise le marquage des valeurs du champ en plaçant chacune d'elles dans un bloc (un token) pour en faire autant d'unités séparées au lieu d'une chaîne de caractères. Ces jetons peuvent ensuite être réarrangés. Comme pour combobox, cette entrée est implémentée en utilisant la bibliothèque JavaScript Select2.

Paramètres spéciaux :


 * size - Indique la largeur de la saisie, en nombre de caractères.
 * max values - Indique le nombre maximum de valeurs autorisées.
 * - Refuse les valeurs arbitraires dans le champ.
 * placeholder text - Indique le texte d'aide affiché à l'entrée jusqu'à ce que l'utilisateur clique dessus.
 * namespace - Préfixe chaque valeur sélectionnée en ajoutant l'espace de noms spécifié.

Par défaut, les tokens apparaissent comme une entrée sur une seule ligne et sont listés verticalement si nécessaire, au fur et à mesure que des valeurs supplémentaires sont ajoutées. Dans certains cas vous voudrez que cette entrée apparaisse plus grande qu'une rangée lorsqu'elle commence, afin qu'elle soit plus évidente pour les utilisateurs qui voudront la dérouler. Pour faire cela avec une entrée unique, ajoutez un paramètre  à la balise du champ, tel que , puis ajoutez à MediaWiki:Common.css quelque chose similaire à :

Si vous voulez que cela s'applique à toutes les entrées tokens du wiki, ajoutez à MediaWiki:Common.css quelque chose similaire à :

radiobutton
L'entrée radiobutton correspond aux boutons radio du HTML. Elle affiche un ensemble de valeurs parmi lesquelles l'utilisateur ne peut en choisir qu'une.

Par défaut, la valeur du premier bouton radio est None, permettant ainsi à l'utilisateur de choisir la valeur vide. Pour empêcher d'afficher « None », vous devez indiquer que le champ est « mandatory », et choisir une des valeurs autorisées en tant que valeur par défaut dans le champ « default= ».

dropdown
L'entrée dropdown correspond à la balise HTML &lt;select&gt;. Elle affiche une liste déroulante de valeurs, parmi lesquelles l'utilisateur ne peut en sélectionner qu'une.

checkboxes
Les entrées checkboxes affichent des cases à cocher permettant à l'utilisateur de choisir tout nombre de valeurs. S'il y a plus qu'un nombre donné de cases à cocher, les liens « Selectionner tous » et « Selectionner aucun » vont automatiquement apparaître au-dessus de l'ensemble des cases, pour permettre automatiquement aux utilisateurs de les cocher toutes ou aucune. Ce nombre est fixé par la variable, dont la valeur par défaut est 10, bien qu'elle puisse être changée dans LocalSettings.php.

Paramètres spéciaux :


 * - masquer les liens « Selectionner tous » et « Selectionner aucun » pour cette entrée, quelque soit le nombre de valeurs
 * - afficher les liens « Selectionner tous » et « Selectionner aucun » pour cette entrée, quelque soit le nombre de valeurs

listbox
L'entrée listbox correspond à la balise HTML &lt;select&gt;, avec l'attribut with the « multiple » ajouté. Cela affiche une liste verticale d'options, dans laquelle l'utilisateur peut faire une sélection multiple.

Paramètres spéciaux :


 * size - Indique la hauteur de la listbox.

tree
Le type d'entrée tree accepte des données hiérarchiques présentées sous forme d'arbre, où toutes les valeurs ont soit des boutons radio soit des cases à cocher à leur côté, en fonction du champ qui est soit multiple, soit mono élément. Les valeurs peuvent provenir d'un arbre des catégories du wiki, ou être déclarées manuellement dans la définition du formulaire.

Comment cette entrée sait-elle qu'elle peut accepter une ou plusieurs valeurs et avoir des boutons radio ou bien des cases à cocher ? Elle regarde simplement si le champ dans le modèle est défini comme supportant une liste de valeurs (en utilisant #arraymap) ou pas. Ce contrôle n'est pas parfait, quoique. Si l'entrée tree affiche des boutons radio au lieu de cases à cocher, ajoutez simplement le paramètre « |list » à la balise du champ dans la définition du formulaire, pour déclarer la liste.

En fonction de la source des valeurs, vous devez spécifier l'un de ces deux paramètres supplémentaires.


 * - définit le nom de la catégorie qui se trouve à la racine de l'arbre.
 * - déclare la structure complète de l'arbre; vous devez utiliser les puces de style wikicode pour définir le niveau de profondeur.

Le paramètre structure vous permet d'obtenir l'équivalent de ceci :

Vous pouvez également initialiser les paramètres facultatifs suivants :


 * - définit la hauteur de la boîte en pixels, dans laquelle l'arborescence est affichée
 * - définit la largeur de la boîte en pixels, dans laquelle l'arborescence est affichée
 * - définit le délimiteur utilisé quand le champ contient une liste de valeurs. Par défaut une virgule ','.
 * - cache le nom de la catégorie de la racine.
 * - définit le nombre de niveaux de l'arborescence affichés au début. Par défaut 10.

Vous pouvez voir un formulaire d'exemple utilisant ce type d'entrée ici.

Pour les noms de catégorie
Si vous utilisez le type d'entrée « tree » pour afficher une arborescence de catégorie, notez que cette entrée va afficher uniquement les noms des catégories sélectionnées mais sans le préfixe de l'espace de noms Category: ; donc si vous voulez qu'il s'affiche aussi sur la page, le modèle devra l'ajouter.

Si le champ spécifie plusieurs catégories, et que le modèle utilise #arraymap pour le proposer, l'appel à #arraymap devrait ressembler à :

...en d'autres termes, vous devez spécifier le paramètre « delimiter » final pour #arraymap, et en faire un espace, un blanc ou quelque chose de similaire, pour éviter d'imprimer, les virgules entre les balises des catégories.

checkbox
Une case à cocher unique, utilisée pour les valeurs booléennes.

Paramètres spéciaux :


 * - permet d'attribuer un libellé à la checkbox, qui sera placé dans une balise &lt;label&gt;.

date
Cette entrée contient trois éléments séparés, pour l'année, le mois et le jour.

datetime
L'entrée « datetime » est similaire à l'entrée « date » mais inclut des entrées supplémentaires pour les heures, les minutes, les secondes et l'indication AM/PM.

Paramètres spéciaux :


 * - indique qu'une entrée de fuseau horaire doit aussi être incluse.

year
year est le texte qui représente seulement l'année dans le champ d'une date.

datepicker
« datepicker » permet à l'utilisateur de choisir une date avec l'aide d'une fenêtre séparée comportant un calendrier basé sur JavaScript. Cette entrée possède plusieurs paramètres optionnels; voir la liste complète ici.

datetimepicker
« datetimepicker » est un type d'entrée basé sur Javascript très similaire à « datepicker » et contenant des fenêtres pour sélectionner à la fois la date et l'heure. Par défaut. Ses paramètres sont tous ceux de « datepicker » plus les suivants :


 * - heure minimale autorisée
 * - heure maximale autorisée
 * - intervalle (en minutes) entre les options affichées à l'utilisateur

rating
Le type d'entrée « rating » affiche un ensemble d'étoiles pour permettre à l'utilisateur de formuler une évaluation.

Paramètres spéciaux :


 * - indique la largeur (et la hauteur) de chaque étoile. Par défaut 24 pixels.
 * - indique le nombre d'étoiles à afficher. Par défaut 5.
 * - permet aux utilisateurs de sélectionner une demi-étoile. Par défaut false ; fixer à   (ou tout autre valeur) pour le mettre à true.

googlemaps, leaflet, openlayers
Les types d'entrée « googlemaps » « leaflet » et « openlayers » vous permettent d'afficher une carte pour obtenir la valeur des coordonnées en utilisant respectivement les services Google Maps, Leaflet ou OpenLayers.

Si vous utilisez l'entrée googlemaps, vous aurez probablement besoin d'avoir une clé d'accès à l'API Google Maps, et la déclarer dans LocalSettings.php via le paramètre , pour que l'entrée puisse s'afficher.

Vous pouvez aussi définir (facultatif) ces paramètres pour les types d'entrées suivants :


 * - définit la hauteur de la carte en pixels.
 * - définit la largeur de la carte en pixels.
 * - utilise une paire de coordonnées pour délimiter les limites de la carte à afficher ; ce paramètre ne s'applique seulement si l'entrée n'a pas de valeur; exemple de valeur pour ce paramètre : "-20,-15;50,55".

Le type d'entrée leaflet permet un paramètre supplémentaire :


 * - définit l'image spécifiée (qui doit avoir été téléversée sur le wiki) en tant qu'image de fond de la carte, plutôt qu'une carte géographique.

Le type d'entrée googlemaps vous permet d'entrer une addresse pour localiser les coordonnées plus facilement. Mais si le formulaire contient déjà un ou plusieurs champs pour entrer l'addresse, alors il est possible que l'utilisateur doive la rentrer deux fois - une fois pour enregistrer les données actuellement, et une seconde fois pour les localiser. Pour éviter que les utilisateurs aient à faire ce double travail, il est possible de faire en sorte que tous les champs d'addresse fournissent leur valeur directement à la carte lorsque le point est recherché. Vous pouvez faire cela en utilisant le paramètre  - voir ici.

Tous ces formats par défaut, dépendent du code JavaScript externe. Néanmoins, simplement en installant l'extension OpenLayers, il est possible de faire que le format openlayers utilise du code JavaScript local.

Désactivation
Notez bien que tous ces types d'entrée envoient les données de votre wiki (c'est à dire les données qui sont le résultat des requêtes), aux services externes. Ce sont les seules parties de code de Page Forms qui envoient les données à l'extérieur, autres que l'autocomplétion sur des valeurs externes, bien que cette dernière demande une configuration supplémentaire pour fonctionner. Si vous avez un wiki privé et que vous êtes très préoccupé de ne pas voir vos données s'extérioriser, vous pouvez ajouter le code suivant dans LocalSettings.php :

Ceci va bloquer l'utilisation de tout service externe par Page Forms - ce qui à cet instant signifie interdire ces trois types d'entrée.

regexp
Le type d'entrée regexp n'est pas réellement un type d'entrée, mais plutôt la possiblité d'afficher l'entrée réelle (le plus souvent de type text) en appliquant une validation supplémentaire basée sur une expression régulière. Voir ici l'explication plus détaillée de ce type d'entrée et de ses paramètres.

Types d'entrée autorisés selon le type de données
Lorsque vous utilisez Cargo ou Semantic MediaWiki, chaque type de données défini possède un type d'entrée par défaut et également selon le cas, une longueur d'entrée par défaut. En plus, certains types de données sont gérés d'une manière particulière quand le champ contient une liste de valeurs délimitées au lieu d'une seule valeur.

Voici les types par défaut et les autres types d'entrée permis pour chaque type de données, et cela pour des valeurs seules :

Voici les types d'entrée par défaut et les autres types d'entrée autorisés pour les listes délimitées d'un type de donnée particulier :

Setting values and mappings
Some input types provide the user with pre-defined values. These can be values that the user is required to choose among (like with the  input type), or values that are only meant to serve as a guide to the user (like with , although there too these options can be made mandatory, if you add the   parameter).

For both cases, the set of parameters for specifying the values shown to the user is nearly the same. Here are the parameters for the "field" tag that can be used in all cases:
 * +  – If you have Cargo installed on the wiki, this set of parameters will be automatically used if the input type uses autocompletion, like   does. The code will find the Cargo table and field that this template/form field corresponds to, and use all the values that have been set for that field. Or you can use these parameters to specify any combination of table and field you want.
 * – If you have Semantic MediaWiki installed, this parameter will be automatically used if the input type uses autocompletion. The code will find the relevant property and use all of its values, or you can use this parameter to specify a different property.
 * – Functionally, this parameter works the same as, above, though it lacks some of the side effects:   can also impact the size and even input type of the field.
 * – Gets its values from the names of all pages belonging to a specific category.
 * – Gets its values from the names of all pages belonging to one or more specific namespaces. To get values from more than one namespace, separate the names with commas. To get values from the main namespace, use "Main", or just leave it blank.
 * – Gets its values from the names of all pages belonging to a specific SMW concept.
 * – Finally, you can simply manually specify the set of values shown to the user; an example would be . This set of values should be separated by commas by default, but the delimiter can be modified using the   parameter.

There are several more options for the autocompletion-based inputs; see "Autocompletion", below.

Mapping
You can have the set of values displayed to the user be different from the set of values that actually show up in the page's wikitext. If the values are page names, and those pages have a "display title" set that is different from their real page name, then by default the form will display the display title instead of the page name. If you want, you can have the page name itself displayed, by adding the following to LocalSettings.php:

You can enable other such mappings using the following parameters:


 * template name - Takes in the name of a "mapping template" (a template that takes in a single, unnamed parameter, i.e., and displays a "mapped" string as a result), and uses that template to map every potential value, so that the values' "aliases" appear on the screen, and not the values themselves.
 * property name - Used for fields that select pages with 'combobox', 'tokens', 'listbox', and 'dropdown' input types. For each possible value, displays a SMW property from that page rather than the title of the page, but saves the title of the selected page(s) as the field value. Used in conjunction with the  parameters to get the list of possible values.
 * table name/ field name - Similar to  except it is used for Cargo fields. Used in conjunction with ,  ,  , and  /.
 * - If the Translate extension is installed, calls Translate's magic word on each value to get the mapped value.

For example, a form could contain a field tag like this:

The template at Template:StatusLabel could then contain something like:

You could then use that same "mapping template" to display the label of the value on regular, non-form pages. Within the template that contains the field "status", you could have the following:

Autocomplétion
Quatre des types d'entrée (, ,   et  ) utilisent l'autocompletion — dès que l'utilisateur commence à taper, l'entrée affiche une liste déroulante des completions possibles.

Si un champ représente une propriété de Semantic Mediawiki, ou un champ Cargo, de type «  », l'autocomplétion sera activée par défaut — le champ se complétera automatiquement avec le nom de toutes les pages qui utilisent déjà cette propriété ou ce champ. Pour tous les autres types, il n'existe pas d'autocomplétion par défaut, mais vous pouvez réaliser cela simplement en déclarant ce type d'entrée comme étant l'un des quatre possèdant l'autcomplétion.

Vous pouvez manuellement activer l'autocomplétion d'un champ sur l'ensemble des valeurs à partir d'une propriété SMW, un champ Cargo, une catégorie, un espace de noms, un concept, ou en définissant une liste manuelle, en utilisant un des paramètres « values ... » - voir ci-dessus.

Vous pouvez aussi appliquer l'autocomplétion basée sur des valeurs hors du wiki, contenues dans des pages web, des bases de données, des fichiers, etc.; voir ci-après pour les différentes manières de réaliser cela.

Si un champ est désigné comme contenant des valeurs multiples, l'autocomplétion prendra en charge par défaut les valeurs multiples : après avoir saisi une valeur et placé le délimiteur, une nouvelle autocomplétion va recommencer avec la valeur suivante. Vous pouvez spécifier manuellement qu'un champ possède l'autocomplétion sur les valeurs multiples, en ajoutant le paramètre « list » à la définition du champ. Vous pouvez également spécifier le délimiteur de cette liste de valeurs, en utilisant le paramètre « delimiter=... » (par défaut une virgule ',').

Par défaut, le nombre maximum de possibilités d'autocomplétion qu'un champ peut offrir est 1000 ; cela pour des raisons de performance. Pour modifier ce nombre, changer la valeur de  en LocalSettings.php.

Désactivation
Vous pouvez désactiver l'autocomplétion si elle a été déclarée par défaut sur un champ, en indiquant que le type d'entrée est simplement « text » ou « textarea ».

Autocomplétion distante
L'ensemble des valeurs possibles d'autocomplétion d'un champ est par défaut contenu directement dans la page HTML du formulaire, dans une déclaration JavaScript. Par soucis de performance, il y existe une limite sur le nombre de valeurs placées sur la page; par défaut la limite est fixée à 100. Après que ce nombre est atteint, l'autocomplétion distante est réalisée là où elle s'applique, via un appel Ajax vers le serveur, en fonction de ce que l'utilisateur a entré. Ce type d'autocomplétion est plus lent, mais il permet beaucoup plus de résultats d'autocomplétion.

Vous pouvez changer la valeur par défaut en ajoutant à LocalSettings.php un code similaire à :

Correspondance de chaque caractère
Par défaut, l'autocomplétion dans Page Forms détecte le début de chaque mot de l'ensemble des valeurs possibles. Vous pouvez par contre modifier l'autocomplétion afin qu'elle coïncide avec chaque caractère, en ajoutant la ligne suivante à LocalSettings.php : Cette fonctionnalité est particulièrement importante pour les wikis qui ont des valeurs avec des caractères non ASCII, tels que les wikis avec des alphabets non romain, parce que l'autocomplétion par défaut basée sur les mots, ne fonctionne pas encore avec des caractères non ASCII.

Autocomplétion avec des caractères accentués
L'autocomplétion des inflexions pour les caractères avec accents, est prise en charge pour les types d'entrée combobox et tokens.

Le repli d'accents a ses limites mais il peut aider à ce que certaines interactions importantes quoique négligées, avec l'utilisateur fonctionnent mieux. Une fonction réalisant le repli d'accents associe essentiellement les caractères Unicode à leur équivalent ASCI. Avec le repli d'accents, il n'est pas important de savoir si vous cherchez cafe, café ou çåFé; le résultat sera le même.

Autocomplétion sur des valeurs externes
Il y a deux manières pour qu'un champ ait l'autocomplétion en utilisant des données externes au wiki - la première est, à partir d'une URL récupérer une sous-chaîne et retourner les données au format JSON similaires au JSON fourni par l'API MediaWiki, et la seconde est d'utiliser l'extension External Data pour récupérer les données à partir de source quelconque externe/interne.

A partir d'une URL externe
Vous pouvez obtenir l'autocomplétion d'un champ sur des valeurs venant de l'extérieur du wiki, en utilisant le paramètre suivant :
 * URL identifier

Pour réaliser cela, veuillez suivre les étapes suivantes :


 * 1) Create a page/web service that takes in a substring via the query string, and displays a set of completion values. Page Forms expects to get a JSON format response with a toplevel key of "pfautocomplete" and an array of objects with the "title" key marking the values of possible completions.  You can see a brief example of this from this API call on semantic-mediawiki.org.
 * For example, if you had a list of three countries -- Uruguay, Germany, and Japan -- and were asked for a list of possible completions for "an", you would return:
 * This also makes it easy to autocomplete on the values from another wiki.
 * 1) Decide on a short string to represent this URL.
 * For example, the service providing lookups in our list of countries could be called " ".
 * 1) Add the short string to the array in   in your LocalSettings.php to configure Page Forms to use your URL when it sees the string.  Put " " where you want the user's input will go.
 * In our example, if we want Page Forms to feed the user's keystrokes to the url  via the url parameter " ", we'd put:
 * 1) Add the parameter "values from url=URL-identifier-string" to the relevant field in the form definition.
 * For our country example, we might have a field that looks like
 * 1) Add the parameter "values from url=URL-identifier-string" to the relevant field in the form definition.
 * For our country example, we might have a field that looks like

Using the External Data extension


The External Data extension (ED) supports retrieving data from a number of sources which include external URLs, regular wiki pages, uploaded files, files on the local server, databases and LDAP directories.

To autocomplete using ED, you need to first call any of ED's "#get_..._data" parser functions within the form definition (preferably at the bottom of the form definition, to avoid unnecessary line breaks). This will fetch data that can then be used in the field tags. (See the External Data documentation for how to call these.) The field tag may then use these parameters:
 * ED variable name (mandatory)
 * ED variable name (optional)
 * ED variable name (optional)

Here is a sample call to #get_web_data to fetch data from some URL:

Assuming a form definition contains a call like that, a field tag can then use the values retrieved for autocompletion - not just to set the autocomplete values themselves, but also, if the input type is "combobox" or "tokens", to set a corresponding thumbnail image and description for each one.

Assuming our External Data call retrieved three "columns" of values, as the one above does, the field tag using this data could look like:

Dependent autocompletion
You can set a field's autocompletion values to be based on the value a user has already set of another field in the form. This is done with the parameter, which has this syntax:

{{{field ... |values dependent on= template name [ field name ]

It specifies that the current set of allowed values for this field are all the values taken by this same field from pages where 'field name' is equal to the value selected for 'field name' in the current form.

Is that confusing?

Well, this example may help: if a template is called "Restaurant" and it has template fields (not properties) named "Country" and "City", and you want the set of cities that are used for autocompletion to be only those cities in the country that the user selected, then the field tag for the City field should look something like:.

Uploading files
If a field in the form is meant to hold the name of an uploaded file (say, an image), you can allow users to upload this file directly through the form. This is done simply by adding the parameter "uploadable" to that field's declaration in the form definition. This will add a link reading "Upload file" next to this field in the form; if the user clicks on this link, it will pop up a "lightbox"-style window (using the FancyBox JavaScript library) that lets the user upload a file. Once the user has done so, the window will close, and the field will contain the name of the uploaded file. If the field is configured to contain a list of values, the new file name will be appended to whatever was there before; otherwise, the file name will overwrite whatever the field contained before.

Note that the "uploadable" parameter can only be used in fields of type "text", "text with autocomplete", "combobox" or "tokens".

For uploadable fields, you can also set the default filename of the uploaded files, by setting the "default filename=" parameter in the field definition. The value of this parameter can include parser functions, magic words and the like. It can also include the variable "&lt;page name>", which gets substituted with the name of the page being added or edited. So adding to the field definition the parameter "default filename=Image for &lt;page name>", for instance, for a page called "Abc", would set the default name of any uploaded file to "Image for Abc". Note that if you simply want to specify a default file to use such as "Imageneeded.png" the regular "default=Imageneeded.png" parameter will do.

You can see a demonstration of file uploading here.

Note that the upload window will not work if  is set to   in your LocalSettings.php.

You can also set uploadable fields to use the operating system's own uploading directly, instead of using MediaWiki's uploading system - this gives the user fewer options, but it is a simpler process, and on mobile devices it can present some interesting options, like uploading photos right after they are taken. To do this, add the following line to LocalSettings.php:

The special parameters for uploadable fields are:
 * - Specifies that this is an uploadable field.
 * - Specifies that a thumbnail of the uploaded image should be placed under the field in the form.
 * filename - Specifies the default filename for files uploaded with this field.

"show on select"
For inputs of type 'checkbox', 'checkboxes', 'radiobutton', 'dropdown' and 'listbox', the parameter  specifies that one or more elements on the page should only be displayed if and when certain value(s) are selected within that input.

The syntax for this parameter is:
 * value 1 element ID 1;value 2 element ID 2;value 3 element ID 3;etc.

A value can be provided with more than one element-id:
 * value A element ID 1;value B element ID 1;value B element ID 2;value C element ID 3;etc.

For inputs of type 'checkbox', simply " element ID" should be used. Note that the element IDs cannot contain spaces and/or multibyte characters and cannot start with a number.

For an example of this feature in use, see this form, and observe what happens when you select different values for the "Publication type" dropdown. You can see how that was implemented in this form definition.