Le déploiement d'un serveur de mise à jour

From Joomla! Documentation

This page is a translated version of the page Deploying an Update Server and the translation is 65% complete.

Other languages:
English • ‎español • ‎français


Ce didacticiel a pour vocation d'aider les développeurs à créer un serveur de mise à jour pour une intégration avec le système de mise à jour implémenté dans Joomla. En ajoutant une liste de serveurs de mise à jour dans le fichier manifest de leurs extensions, les développeurs vont permettre aux utilisateurs de mettre à jour leurs extensions via le gestionnaire des mises à jour des extensions (voir l'écran d'aide Mise à Jour de Joomla 3.x) en un clic seulement.

Définition d'un serveur de mise à jour

Pour pouvoir utiliser cette fonction, un serveur de mise à jour doit être défini dans le fichier "manifest" de votre extension. Cette définition peut être utilisée pour toutes les extensions compatibles avec les versions 2.5 et plus récentes de Joomla! mais n'est pas disponible pour les templates. Vous pouvez utiliser deux options pour votre type de serveur: collection ou extension. Celles-ci seront expliquées en détail par la suite. Ce code doit être ajouté au fichier "manifest" de l'extension, à l'intérieur de la balise pour l'élément "extension". Le serveur de mise à jour est définie comme suit pour chaque type :

    <server type="collection">https://example.com/list.xml</server>
    <server type="extension" priority="2" name="My Extension's Updates">http://example.com/extension.xml</server>

Plusieurs serveurs peuvent être définis à l'aide de balises <updateservers>.

Types de serveur


Le serveur de type "collection" permet aux développeurs de définir un fichier "manifest" pour une extension afin de charger des mises à jour à partir d'une collection. Ce type de serveur peut être utilisé par les développeurs qui souhaitent définir les mises à jour pour leurs extensions dans un seul fichier (non recommandé) ou si leurs extensions disposent de plusieurs sous-extensions qui ne sont pas distribués ou mises à jour toutes en même temps (comme un type pack d'extension). L'exemple ci-dessous est la définition de collection utilisée par le programme de mise à jour du noyau Joomla :

 <extensionset name="Joomla Core" description="Joomla! Core">
    <extension name="Joomla" element="joomla" type="file" version="1.7.0" detailsurl="https://update.joomla.org/core/extension.xml"/>

Toutes les définitions doivent être présentes entre les balises <extensionset> dans votre "manifest" collection. La balise <extensionset> peut avoir deux paramètres facultatifs : name et description. Pour chaque extension que cette collection références, une balise <extension> est nécessaire. La balise <extension> présente les paramètres suivants, qui sont tous requis pour que le processus de mise à jour se déroule correctement :

  • name (nom) - le nom de l'extension
  • element (élément) - le nom non traduit de l'extension c'est à dire mod_custom
  • type - le type d'extension (composant, module, plugin, etc.)
  • version - la dernière version de l'extension
  • detailsurl - L'URL du fichier XML qui contient les définitions indivielles de mises à jour de l'extension


The extension server type allows developers to define an extension's manifest to pull updates from a single extension's manifest. All collection manifests eventually point to this XML file. All updates in this file must be defined after an <updates> tag at the beginning of the file. The below example is the update definition for the Joomla! 3.6.5 release:

		<name>Joomla! 3.6</name>
		<description>Joomla! 3.6 CMS</description>
		<infourl title="Joomla!">https://www.joomla.org/announcements/release-news/5693-joomla-3-6-5-released.html</infourl>
			<downloadurl type="full" format="zip">https://downloads.joomla.org/cms/joomla3/3-6-5/Joomla_3.6.5-Stable-Update_Package.zip</downloadurl>
		<maintainer>Joomla! PLT</maintainer>
		<targetplatform name="joomla" version="3.[234567]" />

La section suivante décrit les éléments d'une mise à jour unique.

  • name - le nom de l'extension, ce nom apparaîtra dans la colonne "Nom" de la vue de mise à jour du gestionnaire d'extension (obligatoire).
  • description - une courte description de l'extension (facultatif) -- si vous choisissez d'utiliser <![CDATA[]]>, les guillemets doubles vont briser le formatage HTML. Utilisez des guillemets simples avec vos entités HTML.
  • element - le nom de l'extension installée (obligatoire). Pour les plugins, ce doit être le même que la valeur de l'attribut du plugin dans le manifest du fichier principal du plugin. Pour <filename plugin="nomduplugin">nomduplugin.php</filename>, la valeur de l'élément doit être nomduplugin.
  • type - le type de l'extension (composant, module, plugin, etc.) (obligatoire).
  • folder (dossier) - spécifique aux plugins, cette balise décrit le type du plugin mis à jour (contenu, système, etc.) (obligatoire pour les plugins).
  • client - Required for modules and templates as of 3.2.0. - The client ID of the extension, which can be found by looking inside the #__extensions table. To date, use 0 for "site" and 1 for "administrator". Warning! Plugins and front-end modules are automatically installed with a client of 0 (site), but you will need to specify the client in an update or it will default to 1 (administrator) and then found update would not be shown because it would not match any extension. Components are automatically installed with a client of 1, which is currently the default.
    • Attention : le nom de la balise est <client> pour Joomla! 2.5 et <client_id> pour les versions 1.6 et 1.7. Si vous utilisez <client_id> plutôt que de <client> sur un site de 2.5, la balise sera ignorée.
  • version'- les références de la version (obligatoire)
  • infourl - l'URL pour diriger les utilisateurs vers des informations complémentaires concernant la mise à jour (facultatif).
  • downloads - la section qui liste tous les emplacements pour le téléchargement.
    • downloadurl - l'URL à partir de laquelle il est possible de télécharger l'extension. La balise <downloadurl> doit contenir deux paramètres obligatoires :
      • type - le type du package (complète ou mise à jour).
      • format - Le format de l'archive (zip, tar, etc.).
    • NB - there must be no newline before or after the URL; it needs to all be on one line or you will get Error connecting to the server: malformed when the update is run
  • tags - A list of tags relevant to this version. Joomla! 3.4 and later uses this to determine the stability level of the update. The valid tags are:
    • dev : versions de développement, très instables et pré-alpha (par exemple, les nightly builds).
    • alpha: Alpha quality software (features not implemented, show-stopper bugs)
    • beta: Beta quality software (all features implemented, show-stopper bugs possible, minor bugs almost certain)
    • rc: Release Candidate quality software (no show-stopper bugs, minor bugs may still be present)
    • stable: Production quality software All other tags are currently ignored. If you provide more than one tag containing one of the aforementioned stability keywords only the LAST tag will be taken into account. If you do not provide any tags Joomla! will assume it is a stable version.
  • maintainer - The name of the extension maintainer (similar to the <author> tag in a manifest) (optional)
  • maintainerurl - The website of the extension maintainer (similar to the <authorUrl> tag in a manifest) (optional)
  • section - Facultatif (utilisation inconnue)
  • targetplatform - A tag to define platform requirements, requires the following elementsː
    • name - The name of the platform dependency; as of this writing, it should ONLY be "joomla"
    • version - La version de Joomla! prenant en charge l'extension.
    • min_dev_level and max_dev_level - These attributes were added in 3.0.1 to allow you to select a target platform based on the developer level ("z" in x.y.z). They are optional. You can specify either one or both. If omitted, all developer levels are matched. For example, the following matches versions 4.0.0 and 4.0.1. <targetplatform name="joomla" version="4.0" min_dev_level="0" max_dev_level="1"/>
      • Note: If your extension is Joomla! 2.5 and/or 3.1 compatible, you will be required to have separate <update> definitions for each version due to the manner in which the updater checks the version if you specify a number. However to show your extension on all Joomla versions that support automatic updates add <targetplatform name="joomla" version=".*"/>. If you want your extension to show on all Joomla 3.x versions then rather than specifying a version in the version tag add in <targetplatform name="joomla" version="3.[012345]"/>. This will show the update to all 3.x versions.
  • php_minimum - Beginning with 3.2.2, a minimum supported PHP version can be supplied in the update stream. If the server does not meet the minimum, a message is displayed to the user advising that an update is available but cannot be installed due to unsupported requirements.
  • supported_databases - Beginning with 3.7, a minimum supported Databases + version can be supplied in the update stream. If the server does not meet the minimum, a message is displayed to the user advising that an update is available but cannot be installed due to unsupported requirements.
    • An example could look like this: <supported_databases mysql="5.5.3" postgresql="9.2" mssql="10.50.1600.1" />

A separate <update> definition will be required for each version of your extension you release.

The values of element, type, client_id and folder should match those in the table #__extensions.

Important pour les plugins : les plugins doivent intégrer les éléments <folder> et <client> pour fonctionner correctement.

Résolution de problèmes

  • SQL update script is not executed during update.
If the SQL update script (for example, in the folder sql/updates/mysql) does not get executed during the update process, it could be because there is no version number in the #__schemas table for this extension prior to the update. This value is determined by the last script name in the SQL updates folder. If this value is blank, no SQL scripts will be executed during that update cycle. To make sure this value is set correctly, make sure you have a SQL script in this folder with its name as the version number (for example, 1.2.3.sql if the version is 1.2.3). The file can be empty or just have a SQL comment line. This should be done in the old version -- the one before the update. Alternatively, you can add this value to the #__schemas using a SQL query.

Outils de support