Manual:Tag extensions/fr

Les projets individuels trouveront souvent utile d' étendre le marquage embarqué du wiki avec des possibilités supplémentaires, que ce soit un simple traitement de chaîne de caractères, ou la récupération complète d'informations. Les extensions de balise permettent aux utilisateurs de créer de nouvelles balises personnalisées qui font justement cela. Par exemple, on pourrait utiliser une extension de balise pour présenter une simple balise, qui injecte un formulaire de donation dans la page. Les extensions, ainsi que les fonctions Parser et les accroches sont la manière la plus efficace de modifier ou d'étendre les fonctionalités de MediaWiki. Vous devriez toujours vérifier la matrice avant de commencer un travail sur une extension pour vous assurer que quelqu'un d'autre n'a pas déja fait exactement ce que vous essayez de faire.

A simple tag extension consists of a callback function, which is hooked to the parser so that, when the parser runs, it will find and replace all instances of a specific tag, calling the corresponding callback function to render the actual HTML.

Exemple
Cet exemple enregistre une fonction de callback pour la balise. When a user adds this tag to a page like this:, the parser will call the   function, passing in four arguments:


 * $input : Input between the  and   tags, or null if the tag is "closed", i.e.
 * $args : Tag arguments, which are entered like HTML tag attributes; this is an associative array indexed by attribute name.
 * $parser : The parent parser (a Parser object); more advanced extensions use this to obtain the contextual Title, parse wiki text, expand braces, register link relationships and dependencies, etc.
 * $frame : Le cadre parent (un objet PPFrame). Ceci est utilisé avec $parser pour fournir à l'analyseur des informations plus complètes sur le contexte dans lequel l'extension a été appelée.

Pour un exemple plus élaboré, voir Exemple d'extension de balise

Attributs
Voyons un autre exemple :

This example dumps the attributes passed to the tag, along with their values. It's quite evident that this allows for flexible specification of new, custom tags. You might, for example, define a tag extension that allows a user to inject a contact form on their user page, using something like.

There is a veritable plethora of tag extensions available for MediaWiki, some of which are listed on this site; others can be found via a quick web search. While a number of these are quite specialised for their use case, there are a great deal of well-loved and well-used extensions providing varying degrees of functionality.

Conventions
Voir pour la présentation générale et la configuration d'une extension.

Publier vos extensions

 * 1) Create a new page on this wiki named Extension: with information on your extension, how to install it, and screenshots of it in use. A convenient template has been created to hold this information called . Voir la page du modèle pour plus d'informations. You should also add as much detail as possible to the body of the page, and it is wise to check back fairly regularly to respond to user questions on the associated talk page. Assurez-vous également que la page appartient à.
 * 2) Extensions that create new hooks within the extension code should register them on extension hook registry.
 * 3) Avertissez la liste de diffusion mediawiki-l.

Voir aussi publier votre extension.

Problèmes de sécurité
You'll notice above that the input in the examples above is escaped using  before being returned. It is vital that all user input is treated in this manner before echoing it back to the clients, to avoid introducing vectors for arbitrary HTML injection, which can lead to cross-site scripting vulnerabilities.

Charger des modules
The right way to add modules for your extension is to attach them to the ParserOutput rather than to $wgOut. The module list will then be automatically taken from the ParserOutput object and added to $wgOut even when the page rendering is pre-cached. If you are directly adding the modules to $wgOut they might not be cached in the parser output.

Chronologie et extensions
If you change the code for an extension, all pages that use the extension will, theoretically, immediately reflect the results of new code. Technically speaking, this means your code is executed each and every time a page containing the extension is rendered.

In practice, this is often not the case, due to page caching - either by the MediaWiki software, the browser or by an intermediary proxy or firewall.

To bypass MediaWiki's parser cache and ensure a new version of the page is generated, click on edit, replace "action=edit" in the URL shown in the address bar of your browser by "action=purge" and submit the new URL. The page and all templates it references will be regenerated, ignoring all cached data. The purge action is needed if the main page itself is not modified, but the way it must be rendered has changed (the extension was modified, or only a referenced template was modified).

If this is not sufficient to get you a fresh copy of the page, you can normally bypass intermediary caches by adding '&rand=somerandomtext' to the end of the above URL. Assurez-vous que 'somerandomtext' est différent à chaque fois.

Comment désactiver la mise en cache des pages en utilisant mon extension ?
Depuis MediaWiki 1.5, l'analyseur est passé dans le troisième paramètre de l'extension. Cet analyseur peut être utilisé pour invalider le cache ainsi :

Regénérer la page quand une autre page est modifiée
Maybe you don't want to disable caching entirely, you just want the page to be regenerated whenever another page is edited, similar to the way that template transclusions are handled. This can be done using the parser object that is passed to your hook function. The following method was lifted from and appears to work for this purpose.

Fine grained adjustment of caching behavior
You can use fine grained caching for your extension by using cache keys to differentiate between different versions of your extension output. While rendering you can add cache keys for every feature by adding an addExtraKey method to your hook function, e.g.:

However, modifying $parser->getOptions during parse means that the extra option keys aren't included when trying to get a cached page, only when rendering a page to go into cache, so you can use the PageRenderingHash hook to set extra options. PageRenderingHash is run both when putting a page into cache, and getting it out, so its important to only add new keys to the hash if they're not already there. par exemple :

Quelques notes importantes sur le sujet :


 * Using "!setting1=$value" instead of just "!$value" in the confstr ensures that the parser cache does not become messed up if different extensions are installed or their load order changes. ! est utilisé comme séparateur pour différentes options de rendu
 * Some people use  instead of  . Be warned that addExtraKey does not tell the parser cache that the extra key is in use, and thus can easily result in breaking the cache if you are not careful.

Depuis la version 1.16
Parser hook functions are passed a reference to the parser object and a frame object; these should be used to parse wikitext.

a été diffusé depuis la version 1.8. Its advantages include simplicity (it takes just one argument and returns a string) and the fact that it parses extension tags in, so you can nest extension tags.

The second parameter to recursiveTagParse,, is an optional argument introduced in MW 1.16 alpha (r55682).


 * If  is provided (using the value of   passed to your extension), then any template parameters in   will be expanded.  In other words, content such as   will be recognized and converted into the appropriate value.
 * If  is not provided (e.g.,  ), or if   is set to false, then template parameters will not be expanded;   will not be altered.  Although this unlikely to be the desired behavior, this was the only option available before MW 1.16.

However, one step of parsing that is still skipped for tags, even when using recursiveTagParse, is Parser::preSaveTransform. preSaveTransform is the first step of parsing, responsible for making permanent changes to the about-to-be saved wikitext, such as:

The original call to preSaveTransform intentionally skips such conversions within all extension tags. If you need pre save transform to be done, you should consider using a parser function instead. All tag extensions can also be called as a parser function using  which will have pre save transform applied.
 * Converting signatures (, ~ ,  )
 * Expanding link labels, also known as the pipe-trick (e.g., changing Help:Contents into Contents ). Without this step, shorthand links such as Help:Contents are considered to be invalid, and are left in their wikitext form when parsed.
 * Développement des modèles.

Depuis la version 1.5
Depuis MediaWiki 1.5, les paramètres de style XML (attributs des balises) sont pris en charge. Les paramètres sont passés dans le deuxième paramètre de la fonction de l'accroche, en tant que tableau associatif. The value strings have already had HTML character entities decoded for you, so if you emit them back to HTML, don't forget to use, to avoid the risk of HTML injection.

Comment empêcher la modification de la sortie HTML de mon extension ?
The return value of a tag extension is considered almost parsed text, which means its not treated as pure html, but still modified slightly. There are two main things that are done to the output of a tag extension (Along with a couple other minor things):


 * Replace strip markers. Strip markers are certain items which are inserted at various stages of processing wikitext to act as a marker to re-insert removed content at a later time. Ceci n'est pas quelque chose dont les extensions ont habituellement besoin de s'inquiéter.
 * which turns *'s into lists, and turns any line starting with a leading space into a &lt;pre&gt; among other things. Cela peut quelques fois être un problème dans certaines extensions.

Tag extensions also support returning an array instead of just a string (Much like parser functions) in order to change how the return value is interpreted. La valeur en position 0 du tableau doit être le HTML. La clé du « markerType » peut être initialisée à   pour empêcher d'autres analyses. En écrivant quelque chose comme  vous assurerez que la valeur $html ne sera plus modifiée et sera traitée comme du simple texte html.

Comment faire apparaître mon extension sur Special:Version ?
In order for your extension to be displayed on the MediaWiki Special:Version page, you must assign extension credits within the PHP code.

To do this, add a  variable as the first executable line of code before the hook line or function definition.

An example extension credit is:

Replace  with one of the following (unless your extension falls under multiple classes&mdash;then create a credit for each class):


 * 'specialpage'&mdash;reserved for additions to MediaWiki Special Pages;
 * 'parserhook'&mdash;used if your extension modifies, complements, or replaces the parser functions in MediaWiki;
 * 'variable'&mdash;extension that add multiple functionality to MediaWiki;
 * 'media'&mdash;used if your extension is a media handler of some sort
 * 'other'&mdash;all other extensions.

The  is the name of an interface/i18n message that describes your extension that will need to be defined in your extension's i18n.php file. If you omit this field, the  field will be used instead.

Retrieving the tag name inside of the callback
Suppose you have several tags  and   that share the same callback, and inside the callback function, you want to obtain the name of the tag that invoked the callback.

The short answer is: the tag name ( or  ) is not present in any of the callback's arguments. But you can work around this by dynamically constructing a separate callback for each tag:

Voir aussi

 * – List of special tag/variables like,  , ...
 * – Liste des balises de l'analyseur utilisées sur les wikis Wikimedia.
 * Project:Extension requests
 * Project:Extension requests
 * Project:Extension requests
 * Project:Extension requests
 * Project:Extension requests