Manuel:Développement d'extensions

Extensions:

Développement

Extension "Tag"

Manuel:Fonctions d'analyse

Points d’accroche

Pages spéciales

Manuel:Habillage

Manuel:Mots magiques

API

Content models

Chaque extension se compose de trois parties :

1. Installeur
2. Exécution
3. Emplacement

Une extension minimale se compose de trois fichiers, une pour chaque partie :

MyExtension/extension.json

Stocke les instructions de l'installateur. Le nom du fichier doit être "extension.json". (Pour les versions antérieures à MédiaWiki 1.25 les instructions d'installation se trouvent dans un fichier MyExtension/MyExtension.php nommé d'après l'extension. Beaucoup d'extensions ont encore des fonctionnalités rétro-compatibles dans ce fichier PHP.)

MyExtension/MyExtension_body.php

Stocke le code d'exécution pour l'extension. Le nom de fichier "MonExtension_body.php" est conventionnel mais non requis. Si votre extension est complexe et implique plusieurs fichiers PHP, vous devez suivre la convention de placer son code d'implémentation dans un sous-répertoire nommé MyExtension/includes (bien que l'extension Exemple ne suive pas cette convention). Par exemple, regardez l'extension SemanticMediaWiki

MyExtension/i18n/*.json

Stocke l'information d'emplacement de l'extension.

Lorsque vous développez une extension, remplacez "MyExtension" ci-dessus par le nom de votre extension. Utilisez les noms UpperCamelCase pour son répertoire et son/ses fichiers PHP; ce sont les conventions générales de nommage des fichiers . (l'extension BoilerPlate est un bon point d'entrée pour commencer les entensions. Vous pouvez aussi prendre en compte l'utilisation de MWStew pour le génération de votre extension boilerplate. Voir aussi le modèle cookiecutter pour les extensions MediaWiki sur GitHub).

Les trois parties d'une extension, la configuration, l'exécution, et l'internationalisation tout comme les types d'extensions, la licence et la publication de votre extension sont décrits dans les sections suivantes de cette page.

Pendant votre développement, vous pouvez vouloir désactiver le cache en configurant $wgMainCacheType = CACHE_NONE et $wgCacheDirectory = false, sinon les messages système et les autres modifications peuvent ne pas apparaître.

Configuration

Votre but en écrivant la partie de configuration est de consolider l'initialisation des paramètres pour que les utilisateurs qui installent votre extension n'aient rien à faire d'autre que d'inclure le fichier de configuration dans leur fichier LocalSettings.php , comme cela :

wfLoadExtension( 'MyExtension' );

Si vous voulez rendre votre extension configurable par l'utilisateur, vous devez définir et documenter certains paramètres de configuration et le setup utilisateur devrait ressembler à ceci :

wfLoadExtension( 'MyExtension' );
$wgMyExtensionConfigThis = 1;
$wgMyExtensionConfigThat = false;

Pour atteindre cette simplicité, votre fichier setup doit effectuer un certain nombre de tâches (décrites en détails dans les sections suivantes) :

• enregistrer tout pilote de média, fonction d'analyseur, page spéciale, balise XML personnalisée, et la variable utilisée par votre extension.
• définir et/ou valider toutes les variables de configuration que vous avez définies pour votre extension.
• préparer les classes utilisées par votre extension pour l'auto-chargement
• déterminer quelles parties de votre installation doivent être faites immédiatement et quelles autres doivent être reportées après que le coeur de MediaWiki ait été initialisé et configuré.
• définir toutes les accroches supplémentaires nécessaires à votre extension
• créer ou vérifier toutes les nouvelles tables de la base de données, nécessaires à votre extension.
• configurer l'internationalisation de votre extension

Enregistrement des fonctionalités avec MediaWiki

MediaWiki liste toutes les extensions qui ont été installées sur sa page de Special:Version. A titre d'exemple, vous pouvez voir toutes les extensions installées sur ce wiki en Special:Version. Il est de bon ton de vérifier que votre extension est aussi affichée sur cette page. Pour faire cela, vous devrez ajouter une entrée à $wgExtensionCredits pour chaque pilote de média, fonction d'analyseur, page spéciale, balise XML personnalisée, et variable utilisée par votre extension. L'entrée ressemblera à quelque chose comme ceci :

{
	"name": "Example",
	"author": "John Doe",
	"url": "https://www.mediawiki.org/wiki/Extension:Example",
	"description": "This extension is an example and performs no discernible function",
	"version": "1.5",
	"license-name": "GPL-2.0+",
	"type": "validextensionclass",
	"manifest_version": 1
}

Voir Manual:$wgExtensionCredits pour les détails complets de la signification de ces champs. Beaucoup de ces champs sont optionnels, mais il est encore bon de les remplir. La manifest_version fait référence à la version du schéma pour lequel le fichier extension.json est écrit. Jusqu'à présent (janvier 2018) les versions disponibles sont la 1 et la 2. Voir ici pour la documentation concernant cette fonction.

En plus de l'enregistrement ci-dessus, vous devez également définir les accroches de votre fonction dans MediaWiki. Ce qui figure ci-dessus ne configure que la page Special:Version . La manière dont vous faites cela dépend du type de votre extension. Pour les détails, voyez la documentation de chaque type d'extension :

Extensions:

Développement

Extension "Tag"

Manuel:Fonctions d'analyse

Points d’accroche

Pages spéciales

Manuel:Habillage

Manuel:Mots magiques

API

Content models

Rendre votre extension configurable par l'utilisateur

Si vous voulez que l'utilisateur puisse configurer votre extension, vous devrez fournir une ou plusieurs variables de configuration. C'est une bonne idée que de donner à ces variables un nom unique. Elles devront aussi suivre les conventions de nommage de MediaWiki (par exemple les variables globales doivent commencer par $wg).

Par exemple, si votre extension s'appelle "Very silly extension that does nothing", vous pourriez vouloir que le nom de vos variables de configuration commence par $wgVsetdn ou $wgVSETDN. Ce que vous choisissez n'a réellement pas d'importance tant que personne du coeur de MediaWiki ne commence ses variables de cette manière et vous avez fait un travail raisonnable en vérifiant que personne parmi les extensions publiées n'avait fait commencer ses variables de la sorte. Les utilisateurs n'hésiteront pas à choisir entre votre extension et d'autres extensions car vous avez choisi des noms de variables qui se chevauchent.

Une bonne idée aussi est d'inclure la documentation détaillée de toutes les variables de configuration dans vos informations d'installation.

Avertissement :

Pour éviter les vulnérabilités de register_globals , initialisez TOUJOURS explicitement toutes les variables de configuration de votre extension dans le fichier setup de l'extension. Les structures telles que if ( !isset( $wgMyLeetOption ) ) $wgMyLeetOption = somevalue; ne procurent AUCUNE GARANTIE contre les register_globals!

Voici un exemple de boiler plate qui peut être utilisé pour commencer :

{
	"name": "BoilerPlate",
	"version": "0.0.0",
	"author": [
		"Your Name"
	],
	"url": "https://www.mediawiki.org/wiki/Extension:BoilerPlate",
	"descriptionmsg": "boilerplate-desc",
	"license-name": "MIT",
	"type": "other",
	"AutoloadClasses": {
		"BoilerPlateHooks": "BoilerPlate.hooks.php",
		"SpecialHelloWorld": "specials/SpecialHelloWorld.php"
	},
	"config": {
		"BoilerPlateEnableFoo": true
	},
	"callback": "BoilerPlateHooks::onExtensionLoad",
	"ExtensionMessagesFiles": {
		"BoilerPlateAlias": "BoilerPlate.i18n.alias.php"
	},
	"Hooks": {
		"NameOfHook": [
			"BoilerPlateHooks::onNameOfHook"
		]
	},
	"MessagesDirs": {
		"BoilerPlate": [
			"i18n"
		]
	},
	"ResourceModules": {
		"ext.boilerPlate.foo": {
			"scripts": [
				"modules/ext.boilerPlate.js",
				"modules/ext.boilerPlate.foo.js"
			],
			"styles": [
				"modules/ext.boilerPlate.foo.css"
			]
		}
	},
	"ResourceFileModulePaths": {
		"localBasePath": "",
		"remoteExtPath": "BoilerPlate"
	},
	"SpecialPages": {
		"HelloWorld": "SpecialHelloWorld"
	},
	"manifest_version": 1
}

Remarquez que après l'appel à wfLoadExtension( 'Silly extension that does nothing' ); la variable globale $wfBoilerPlateEnableFoo n'existe pas. Si vous initialisez la variable, par exemple dans LocalSettings.php alors la valeur donnée dans

	"config": {
		"BoilerPlateEnableFoo": true
	},

ne sera pas utilisée.

Préparer des classes pour l'auto-chargement

Si vous choisissez des classes pour implémenter votre extension, Mediawiki fournit un mécanisme simplifié pour aider PHP à trouver le fichier source dans lequel se trouve votre classe. Dans la plupart des cas cela évite d'écrire votre propore méthode d' __autoload($classname) .

Pour utiliser le mécanisme d'auto-chargement de MediaWiki, ajoutez les entrées dan sle champ AutoloadClasses . La clé de chaque entrée est le nom de la classe; la valeur est le fichier qui héberge la définition de la classe. Pour une extension simple ne comportant qu'une seule classe, on donne souvent à la classe le nom de l'extension et donc la section d'auto-chargement pourrait ressembler à ceci (avec une extension appelée MyExtension):

{
	"AutoloadClasses": {
		"MyExtension": "MyExtension_body.php"
	}
}

Le nom de fichier est relatif au répertoire dans lequel se trouve le fichier extension.json .

Définir des accroches supplémentaires

Voir Manuel:Hooks .

Ajouter des tables dans la base de données

Avertissement :

Si votre extension est utilisée sur un produit de production quelconque hébergé par la WMF, veuillez suivre le guide de changement de schema.

Si votre extension a besoin d'ajouter ses propres tables de base de données, utilisez l'accroche LoadExtensionSchemaUpdates . Voir la page du manuel pour davantage d'informations sur l'utilisation.

Configurer l'internationalisation

Voir:

• Internationalisation (sommaire)
• Internationalisation (détaillé)
• Namespaces

Ajouter des journaux

Sur MediaWiki, toutes les actions des utilisateurs sur le wiki sont tracées pour la transparence et la collaboration. Voir Manual:Logging to Special:Log pour savoir comment le faire.

Execution

La technique pour l'écriture de la portion d'implémentation dépend de la partie du système Mediawiki que vous souhaitez étendre :

• Balisage Wiki : Les extensions qui étendent le marquage du wiki contiendront typiquement du code qui definit et implémente les balises XML personnalisées, les fonctions d'analyseur et les variables.
• Rapports et administration : Les extensions qui ajoutent des rapports et des possibilités administratives habituellement le font en ajoutant des pages spéciales. Pour davantage d'informations, voir Manuel : Pages spéciales .
• Automatisation des articles et intégrité : Les extensions qui améliorent l'intégration entre MediaWiki et sa base de données arrière, ou qui vérifient les acticles pour les fonctions d'intégrité, vont typiquement ajouter des fonctions à l'une des multiples accroches qui concernent les processus de création, de modification, de renommage, et de la supression des articles. Pour plus d'informations concernant ces accroches et sur la manière d'y attacher votre code, veuillez voir Manuel:Hooks .
• Habillage et convivialité : Les extensions qui apportent un nouvel aspect et comportement à MediaWiki sont embarquées dans les skins. Pour davantage d'information sur la manière d'écrire vos propres habillages, voir Manual:Skin et Manual:Skinning .
• Sécurité: Les extensions qui limitent leur utilisation à certains utilisateurs doivent s'intégrer au système des droits propre à MediaWiki. Pour en connaître plus sur ce système, veuillez voir Manual:Preventing access . Certaines extensions aussi laissent Mediawiki utiliser des mécanismes d'autentification externes. Pour davantage d'informations, voir AuthPlugin . De plus, si votre extension tente de limiter le nombre de lecteurs de certains articles, veuillez consulter les pièges décrits dans Security issues with authorization extensions .

Voir aussi Extensions FAQ , Pôle des développeurs

Localisation

En cours de développement vous pourriez vouloir désactiver les deux caches en initialisant $wgMainCacheType = CACHE_NONE et $wgCacheDirectory = false, sinon vos modifications des messages système ne seraient pas affichées.

Si vous voulez que votre extension soit utilisable sur les wikis qui ont des lecteurs en plusieurs langues, vous devez ajouter une prise en charge de l'internationalisation à votre extension.

Enregistrer les messages dans <clé-de-langue>.json

Enregistrer les définitions de messages dans un fichier d'internationalisation JSON, un par clé de langue dans laquelle votre extension a été traduite. Les messages sont enregistrés avec une clé de message et le message lui-même, en utilisant le format standard JSON. Chaque identifiant de message doit être en minuscules et ne doit pas contenir d'espaces. Un exemple que vous pouvez trouver par exemple dans l'extension MobileFrontend. Voici un exemple de fichier JSON minimal (dans ce cas en.json:

en.json

{
	"myextension-desc": "Adds the MyExtension great functionality.",
	"myextension-action-message": "This is a test message"
}

Enregistrer la documentation des messages dans qqq.json

La documentation concernant les clés des messages peut être mise dans le fichier JSON pour le pseudo language avec le code qqq. Une documentation de l'exemple ci-dessus peut-être :

qqq.json:

{
	"myextension-desc": "The description of MyExtension used in Extension credits.",
	"myextension-action-message": "Adds 'message' after 'action' triggered by user."
}

Definir des messages

• Attribuez à chaque message un identificateur de message unique, en minuscules, et sans espaces ; par exemple :uploadwizard-desc
• Pour toute chaîne de caractères à afficher à l'utilisateur, veuillez définir un message.
• MediaWiki supporte les messages paramètrés et cette fonction doit être utilisée quand un message dépend des informations générées au moment de l'exécution. Les paramètres de substitution sont spécifiés par $n, où n représente l'index du paramètre; par exemple

"mwe-upwiz-api-warning-was-deleted": "There was a file by this name, '$1', but it was deleted and you can not reupload the file. If your file is different, try renaming it."

Définir la documentation du message

Chaque message que vous définissez doit avoir une entrée de documentation du message associée Message documentation; dans qqq.json par exemple

"uploadwizard-desc": "Description of extension. It refers to [//blog.wikimedia.org/blog/2009/07/02/ford-foundation-awards-300k-grant-for-wikimedia-commons/ this event], i.e. the development was paid with this $300,000 grant."

Charger le fichier d'internationalisation

Dans votre routine d'installation, définissez l'emplacement de vos fichiers de messages (par exemple dans le répertoire i18n/):

{
	"MessagesDirs": {
		"MyExtension": [
			"i18n"
		]
	}
}

Utilisation de wfMessage dans PHP

Dans votre code d'installation et d'implémentation, remplacez chaque utilisation littérale du message par un appel à wfMessage( $msgID, $param1, $param2, ... ). Dans les classes qui implémentent IContextSource (tout comme dans quelques autres telles que les sous-classes de SpecialPage), vous pouvez utiliser $this->msg( $msgID, $param1, $param2, ... ) à la place. Exemple:

wfMessage( 'myextension-addition', '1', '2', '3' )->parse()

Utiliser mw.message sous JavaScript

Il est aussi possible d'utiliser les fonctions i18n dans JavaScript. Voir Manual:Messages API pour les détails.

Types d'extensions

Extensions:

Développement

Extension "Tag"

Manuel:Fonctions d'analyse

Points d’accroche

Pages spéciales

Manuel:Habillage

Manuel:Mots magiques

API

Content models

Les extensions peuvent être catégorisées sur la base des techniques de programmation utilisées pour implémenter leurs actions. Les extensions les plus complexes utilisent plus d'une des techniques suivantes :

• Sous-classement: MediaWiki s'attend à ce que certains types d'extensions soient implémentés en tant que sous-classes d'une classe de base fournie par MediaWiki:
  • Manuel : Pages spéciales – Les sous-classes de la classe SpecialPage sont utilisées pour construire des pages dont le contenu est généré dynamiquement en utilisant une combinaison de l'état actuel du système, des paramètres d'entrée de l'utilisateur, et des requêtes à la base de données. A la fois, des rapports et des formulaires de saisie de données peuvent être générés. Ils sont utilisés à la fois pour des raisons statistiques et administratives.
  • Manuel:Habillage – Les habillages modifient l'aspect et le comportement de Mediawiki en modifiant le code qui génère les pages en sous-classant la classe Mediawiki SkinTemplate .
• Manuel:Hooks – Une technique pout injecter du code php personnalisé aux points-clés du traitement MediaWiki. Elles sont largement utilisées par l'analyseur de MediaWiki, son moteur d'internationalisation, son système de gestion des extensions, et son système de maintenance des pages.
• Associations balise-fonction – Balises de style XML qui sont associées à une fonction PHP génèrant du code HTML. Vous n'avez pas besoin de vous limiter au formatage du texte à l'intérieur des balises. Vous n'avez même pas besoin de l'afficher. Plusieurs extensions de balises utilisent le texte comme paramètre ce qui guide la génération du HTML pour inclure les objets Google, les formulaires d'entrée de données, les flux RSS, et les extraits des articles wiki sélectionnés.
• Manuel:Mots magiques – Une technique pour faire correspondre une variété de chaînes de caractères wiki à un ID unique qui est lié à une fonction. A la fois les variables et les fonctions analyseur utilisent cette technique. Tout texte associé à cet identifiant sera remplacé par la valeur retournée par la fonction. La correspondance entre les chaînes de texte et l'identifiant est stockée dans le tableau $magicWords. L'interprétation de l'identifiant est un processus un peu plus complexe – voir Manuel:Mots magiques pour plus d'information.
  • Manuel:Variable – Les variables sont quelque part comme un abus de langage. Il existe des morceaux de texte wiki qui ressemblent à des modèles mais qui n'ont pas de paramètre et qui ont reçu des valeurs en dur. Le marquage standard de wiki tel que {{PAGENAME}} ou {{SITENAME}} sont des exemples de variables. ils tirent leur nom du source de leur valeur: une variable PHP ou quelque chose qui pourrait être assigné à une variable, par exemple une chaîne, un nombre, une expression, ou la valeur de retour d'une fonction.
  • Manuel:Fonctions d'analyse – {{functionname: argument 1 | argument 2 | argument 3...}}. De même manière que les extensions de balises, les fonctions d'analyseur traitent les paramètres et retournent une valeur. A l'inverse des extensions de balises, le résultat des fonctions d'analyseur est du texte wiki.
• Modules API – vous pouvez ajouter des modules personnalisés à l'API d'action de MediaWiki, appelables par JavaScript, les robots ou les clients tiers.
• Page content models – If you need to store data in formats other than wikitext, JSON, etc. then you can create a new ContentHandler.

Support des autres versions du coeur

Il existe deux conventions largement répandues pour supporter les versions plus anciennes du coeur MediaWiki :

• Maître: la branche maître (master branch) de l'extension est compatible avec autant d'anciennnes versions du coeur que possible. Ceci résulte en un fardeau de maintenance (les développements à compatibilité ascendante doivent être conservés longtemps, et les modifications de l'extension doivent être testées avec plusieurs versions de MediaWiki), mais les sites qui utilisent les anciennes versions de MediaWiki bénéficient des fonctions ajoutées récemment par l'extension.
• Branches de version: les branches de version (release branches) de l'extension sont compatibles avec les branches correspondantes du coeur, c'est à dire que les sites qui utilisent MediaWiki 1.32 doivent utiliser la branche REL1_32 de l'extension. (Pour les extensions hébergées sous gerrit, ces branches sont automatiquement créées quand les nouvelles versions de MediaWiki sont diffusées.) Ceci résulte dans un code plus propre et un développement plus rapide mais les utilisateurs sur les versions anciennes des coeurs ne bénéficient pas des correstions de bogues et des nouvelles fonctions à moins qu'elles ne soient rétro-reportées manuellement.

La maintenance de l'extension doit déclarer avec le paramètre de politique de compatibilité du modèle de l'{{extension}} quelle convention elle suit.

Licence

MediaWiki is an open-source project and users are encouraged to make any MediaWiki extensions under an Open Source Initiative (OSI) approved license compatible with GPL-2.0-or-later (Wikimedia's standard software license).

We recommend adopting one of the following compatible licenses for your projects in Gerrit:

• GNU General Public License, version 2 or later (GPL-2.0-or-later)
• MIT License (MIT)
• BSD License (BSD-3-Clause)
• Apache License 2.0 (Apache-2.0)

For extensions that have a compatible license, you can request developer access to the MediaWiki source repositories for extensions. To specify the licence in code and with "license-name" a key should be used to provide it's short name, e.g. "GPL-2.0-or-later" or "MIT" adhering to the list of identifiers at spdx.org.

Publication

Pour autocatégoriser et pour standardiser la documentation de votre extension existante, veuillez voir Modèle:Extension . Pour ajouter votre nouvelle extension à ce Wiki:

A developer sharing their code in the MediaWiki code repository should expect:

Feedback / Criticism / Code reviews

Review and comments by other developers on things like framework use, security, efficiency and usability.

Developer tweaking

Other developers modifying your submission to improve or clean-up your code to meet new framework classes and methods, coding conventions and translations.

Improved access for wiki sysadmins

If you do decide to put your code on the wiki, another developer may decide to move it to the MediaWiki code repository for easier maintenance. You may then request commit access to continue maintaining it.

Future versions by other developers

New branches of your code being created automatically as new versions of MediaWiki are released. You should backport to these branches if you want to support older versions.

Incorporation of your code into other extensions with duplicate or similar purposes — incorporating the best features from each extension.

Credit

Credit for your work being preserved in future versions — including any merged extensions.

Similarly, you should credit the developers of any extensions whose code you borrow from — especially when performing a merger.

Any developer who is uncomfortable with any of these actions occurring should not host in the code repository. You are still encouraged to create a summary page for your extension on the wiki to let people know about the extension, and where to download it.

Deploiement et enregistrement

Si vous pensez déployer votre extension sur les sites Wikimedia (en incluant éventuellement Wikipedia), un examen supplémentaire est justifié en termes de performances et de sécurité. Consulter Review queue .

Si votre extension ajoute des espaces de noms, vous pouvez enregistrer ses espaces de noms par défaut; de manière équivalente, si elle ajoute des tables de bases de données ou des champs, vous pouvez les enregistrer sur database table and field registration .

Veuillez être conscient que la relecture et le déploiement des nouvelles extensions sur les sites Wikimedia peuvent être extrêmement lents, et dans certains cas ont pris plus de deux ans.

Documentation d'aide

Vous devez fournir la documentation d'aide dans le domaine publique pour les fonctions offertes par votre extension. Aide:CirrusSearch est un bon exemple. Vous devez donner aux utilisateurs un lien vers la documentation à l'aide de la fonction addHelpLink() .

Fournir du support / collaborer

Les développeurs d'extensions doivent ouvrir un compte sur Phabricator de Wikimedia, et demander un nouveau projet pour l'extension. Cela fournit un espace public où les utilisateurs peuvent soumettre les problèmes et les suggestions, et vous pouvez collaborer avec les utilisateurs et les autres développeurs pour trier les bogues et planifier les fonctionnalités de votre extension.

Voir aussi

• Extension:Example – implémente quelques exemples de fonctionnalités avec une documentation en ligne complète
  • exemples de dépôt Git avec cela et autres exemples de code
• Extension:BoilerPlate – une extension Boilerplate fonctionnelle, utile comme point de départ pour votre propre extension (dépôt git)
  • Lisez l'extension Example, basez votre propre code sur l'extension BoilerPlate.
• cookiecutter-mediawiki-extension – un modèle pour l'outil python cookiecutter pour générer une extension standard (avec variables, etc.)
  • Vous permet d'avancer rapidement avec votre propre extension. Peut aussi générer l'extension BoilerPlate.
• List of simple extensions - copier le code spécifique à partir d'eux
• API:Extensions – explique comment votre extension peut fournir une API aux clients
• Extending wiki markup
• Project:WikiProject Extensions
• Manuel:Conventions de codage
• Meilleures pratiques pour les extensions
• ResourceLoader