Manifest files/fr

2022-09-04T07:09:41Z

Lorangerart:

<noinclude><languages /></noinclude>
<noinclude>
{{Joomla version|version=4.x}} {{Joomla version|version=3.x}} {{Joomla version|version=2.5|status=eos}}
</noinclude>
Avec Joomla, toutes les extensions proposent des fichiers manifestes. Ces fichiers recouvrent les informations générales concernant l'installation, ainsi que des paramètres pour la configuration de l'[[S:MyLanguage/extension|extension]] elle-même. Depuis Joomla! 2.5, il existe très peu de différences entre les différents formats de fichiers manifestes en fonction des différents [[S:MyLanguage/Extension types (technical definitions)|types d'extensions]] permettant ainsi à chaque type de bénéficier de la puissance de l'installateur Joomla.

==Conventions de nommage==
Le fichier doit être nommé <tt>manifest.xml</tt> (pour les versions de Joomlaǃ 2.5 et 3) ou <tt><extension_name>.xml</tt> (pour les versions de Joomlaǃ 2.5, 3 et 4) et situé dans le répertoire racine du package d'installation.

Joomla 4.x : la correspondance automatique du namespace va échouer si un nom de fichier tel que <tt>manifest.xml</tt> est utilisé. Voir https://github.com/joomla/joomla-cms/issues/37750

==Syntaxe==

===Élément à la racine===
{{notice|La nouvelle balise <code><extension></code> remplace l'ancienne <code><install></install></code> de la version Joomla {{JVer|1.5}}}}

La balise principale du fichier d'installation est :
<source lang=xml><extension></extension></source>

La balise ouvrante et fermante est la même pour toutes les extensions. Les attributs suivants sont autorisés à l'intérieur de la balise :

{|class="wikitable"
|-
! style="width: 150px" | Attribut || style="width: 150px" | Valeurs || Applicable à || Description
|-
| type || <code>component</code><br /><code>file</code><br /><code>language</code><br /><code>library</code><br /><code>module</code><br /><code>package</code><br /><code>plugin</code><br /><code>template</code><br/><code>element</code> || Toutes les extensions
| Cet attribut décrit à l'installateur le type de l'extension. En fonction de ce type, d'autres d'exigences supplémentaires s'appliqueront aux sous-balises.
|-
| version
| <code>2.5</code><br /><code>3.0</code> || Toutes les extensions
| Chaîne de caractères qui identifie la version de Joomla! pour laquelle cette extension est développée. Ceci n'est pas utilisé dans le version {{JVer|3.x}} et a été retiré de la version {{JVer|4.0}} et des versions ultérieures.
|-
| method
| <code>install</code><br /><code>upgrade</code> || Toutes les extensions
| La valeur par défaut <code>install</code> sera également utilisée si l'attribut <tt>method</tt> n'est pas utilisé. La valeur <code>install</code> signifie que l'installateur va s'arrêter s'il trouve un fichier/dossier de la nouvelle extension.
|-
| client
| <code>site</code><br /><code>administrator</code> || Modules
| L'attribut <tt>client</tt> permet de préciser pour quel type de client d'application le nouveau module est disponible.
|-
| group
| ''string'' || Plugins
| Le nom du groupe indique pour quels groupes de plugins le nouveau plugin est disponible. Les groupes existants sont les noms de dossier du répertoire <tt>/plugins</tt>. Le programme d'installation va créer de nouveaux noms de dossier pour les noms de groupe qui n'existent pas encore.
|}

===Métadonnées===

Les éléments suivants peuvent être utilisés pour insérer des métadonnées. Aucun de ces éléments n'est obligatoire et s'ils sont présents, ils doivent être un enfant de l'élément racine.

<pre>
<name> – raw component name (e.g. com_banners).
<author> – author's name (e.g. Joomla! Project)
<creationDate> – date of creation or release (e.g. April 2006)
<copyright> – a copyright statement (e.g. (C) 2005 - 2011 Open Source Matters. All rights reserved.)
<license> – a license statement (e.g. NU General Public License version 2 or later; see LICENSE.txt)
<authorEmail> – author's email address (e.g. admin@joomla.org)
<authorUrl> – URL to the author's website (e.g. www.joomla.org)
<version> – the version number of the extension (e.g. 1.6.0)
<description> – the description of the component. This is a translatable field. (e.g. COM_BANNERS_XML_DESCRIPTION)
<element> – the internal name of the component. If omitted, name will be cleaned and used
</pre>

Remarque : les balises <name> et <description> sont des champs traduisibles de sorte que le nom et la description de l'extension pourront être présents dans la langue maternelle de l'utilisateur.

=== Fichiers de frontend ===

<source lang="xml">
<files folder="from-folder">
<filename>example.php</filename>
<folder>examples</folder>
</files>
</source>

Les fichiers à copier dans le répertoire de frontend doivent être placés dans les balises <code><files></code>. Vous pouvez utiliser l'attribut <code>folder</code> en option pour spécifier un répertoire '''du package ZIP'''. Chaque fichier à copier doit être nommé par l'élément <code><filename></code>. Si vous souhaitez copier un dossier entier à la fois, vous pouvez le définir comme un <code><folder></code>.

Pour les '''plugins''', le nom brut du plugin doit être placé dans l'attribut <code>plugin</code> de l'élément <code><filename></code> qui pointe vers le fichier contenant la classe du plugin. Par exemple, dans le cas d'un système de plugin appelé "exemple" (nom complet : <code>plg_system_exemple</code>), il faudra utiliser <code><filename plugin="exemple">exemple.php</filename></code>.

===Fichiers multimédias===

<source lang="xml>
<media folder="media" destination="com_example">
<filename>com_example_logo.png</filename>
<folder>css</folder>
<folder>js</folder>
</media>
</source>

Cet exemple permet de copier le fichier (<tt>/media/com_example_logo.png</tt>) et les dossiers ( <tt>/media/css/</tt> et <tt>/media/js/</tt> ) listés vers <tt>/media/com_example/</tt>, ainsi que la création du dossier <tt>com_example</tt> si nécessaire. Vous pouvez utiliser en option l'attribut <code>folder</code> pour spécifier un répertoire '''dans le package ZIP''' à partir duquel réaliser la (dans ce cas, <tt>media</tt>).

Les extensions doivent stocker les éléments, dont elles ont besoin pour être accessible sur le web (JS, CSS, images, etc), dans <code>media</code>. Cette fonctionnalité a été ajoutée dans le cadre du projet de développement d'une interface multi-site et du placement éventuel de fichiers de code (PHP) en dehors des espaces web serveurs accessibles.<br />Remarque: la section médias n'est pas analysé pour les extensions de type 'package'.

Ref:
* [https://groups.google.com/forum/#!msg/joomla-dev-cms/4CAASJqFY-k/PvPj14gP29EJ Google Groups - joomla-dev-cms thread]
* [https://groups.google.com/forum/#!msg/joomla-dev-cms/uNmhX98sKbE/p8p68Jke680J Google Groups - joomla-dev-cms thread]

===Section de l'administration===

<source lang="xml">
<administration>

</administration>
</source>

La section d'administration est définie par l'élément <code><administration></code>. Puisque seuls les [[S:MyLanguage/Component|composants]] concernent à la fois l'espace [[S:MyLanguage/Site (Application)|site]] et celui d'[[S:MyLanguage/Administrator (Application)|administration]], '''seuls les manifests pour composants doivent intégrer ces éléments'''.

====Fichiers de backend====

Les fichiers à copier dans le répertoire de backend doivent être placés dans l'élément <code><files></code> sous <code><administration></code>. Vous pouvez utiliser l'attribut optionnel <code>folder</code> pour spécifier un répertoire à copier depuis le '''pack ZIP'''. Voir les ''fichiers frontend'' pour plus d'informations.

====Liens de menu et sous-menus====
{{dablink|'''Note de version :''' avant Joomla! 3.4, le fait de ne pas avoir de balise <code><nowiki><menu></nowiki></code> dans votre fichier XML avait pour conséquence l création d'un élément de menu. Cette anomalie a été corrigée dans Joomla! 3.4 et ainsi, si aucune balise <code><nowiki><menu></nowiki></code> n'est présente dans votre fichier manifest, aucun menu d'administration ne sera créé pour le composant.}}

<source lang="xml">
<menu>COM_EXAMPLE</menu>
<submenu>

<menu link="anoption=avalue&anoption1=avalue1">COM_EXAMPLE_SUBMENU_ANOPTION</menu>
<menu view="viewname">COM_EXAMPLE_SUBMENU_VIEWNAME</menu>
</submenu>
</source>

Le texte pour l'élément du menu principal pour le composant est défini dans la balise <code><menu></code>, enfant de de la balise <code><administration></code>. Une balise <code><submenu></code> peut être présente (également comme enfant de <code><administration></code>), qui pourra contenir d'autres éléments de menu définis par <code><menu></code>.

En outre, chaque élément <code><menu></code> permet de définir les attributs suivants :

{| class="wikitable"
! style="width: 150px" | Attribut || Description
|-
| link || Un lien vers lequel renvoyer l'utilisateur lorsque l'élément de menu est cliqué. Vous pouvez utiliser "view" à la place.
|-
| img || Le chemin (relatif) à une image (16x16 pixels) qui apparait à côté de l'élément de menu.
<u>Doit être url compatible (par exemple sans espaces).</u>
|-
| alt ||
|-
| view || Un paramètre URL à ajouter au lien. Par exemple, <code><menu view="cpanel">COM_EXAMPLE</menu></code> dans le manifest XML com_example générerait l'URL de l'élément de menu <tt>index.php?option=com_example&view=cpanel</tt>. Vous pouvez utiliser "link" à la place.
|-
|}

La valeur à l'intérieur de la balise est le nom du menu. À La différence de ce qui se faisait pour Joomla! 1.5, vous ne pouvez pas utiliser une chaîne de caractère dans votre langue naturelle. Par exemple, si vous renseignez "Composant d'exemple" au lieu de COM_EXAMPLE, votre nom de composant qui s'afficherait en titre serait "composant-d-exemple" et vous seriez dans l'impossibilité de le traduire. Pour réaliser une traduction, vous devez créer un fichier nommé <tt>fr-FR.com_example.sys.ini</tt> '''(NDT : avant de pouvoir créer le fichier fr-FR, il convient de créer le fichier d'origine en-GB)''' dans <tt>administrator/languages/fr-FR</tt> (vous pouvez utiliser la balise manifest <code><languages></code> pour qu'il soit copié lors de l'installation) ou dans <tt>administrator/components/com_example/language/fr-FR</tt>. Dans ce dernier cas, vous ne devez pas inclure le fichier de traduction dans la balise <code><languages></code> balise. Tant que vous aurez placé le répertoire de langue dans vos balises <code><files></code>, il sera copié lors de l'installation du composant.

Le contenu de ce fichier devrait être :

<source lang="ini">
COM_EXAMPLE="Example Component"
COM_EXAMPLE_SUBMENU_ANOPTION="Another Option"
COM_EXAMPLE_SUBMENU_VIEWNAME="Another View"
</source>

Please note that the language string must be enclosed in double quotes, as per Joomla!'s translation standards.

{{note|Joomla! 1.6 and later sorts the Component menu items based on the actual translation of the key you supply in your XML manifest. This means that the sorting order is correct no matter what you call your translation key and no matter which language the site is being displayed in. Essentially, Joomla! 1.6 fixed the wrong sorting of the Components menu experienced under Joomla! 1.5 for the majority (non-English speaking!) of Joomla! users.}}

=== Dashboards ===
{{notice|This code only works in {{JVer|4.0}} and later}}

Specifies the details for displaying a dashboard for the component in the Administrator area for the site.
* It will make a dashboard icon appear next to the administrator menu item for the component
* The dashboard icon will click through to display modules assigned to the cpanel-example administrator module position
* The title and icon defined in the XML file will be used as the header and icon at the top of the component's dashboard page.

<source lang="xml">
<dashboards>
<dashboard title="COM_EXAMPLE_DASHBOARD_TITLE" icon="icon-lock">example</dashboard>
</dashboards>
</source>

===Configuration===
{{warning|<div class="mw-translate-fuzzy">
Les composants '''ne prennent pas en charge''' les définitions de configuration '''dans le manifeste'''. Ceci avait été mis en œuvre dans Joomla! 1.5. Ils est possible de définir les options de configuration pour différents niveaux à l'aide des [[S:MyLanguage/Component configuration metadata|métadonnées de configuration de composant]].
</div>}}
<div class="mw-translate-fuzzy">
La balise <code><config></code>, enfant de la racine, décrit les options de configuration de l'extension. En cas de besoin, les options seront affichées par le gestionnaire concerné (gestionnaire de plugins, gestionnaire de modules ou gestionnaire de templates). '''Les options de configuration peuvent également être définies dans un fichier séparé nommé <code>config.xml</code>. Son élément racine doit être <code><config></code>.'''
</div>

Chaque groupe de champs <code><fieldset></code> peut contenir un ou plusieurs éléments <code><field></code> (champ), chacun représentant un seul [[S:MyLanguage/form field|champ de formulaire]] avec une étiquette. Consultez les [[S:MyLanguage/Standard form field types|types de champs pour formulaires standards]] pour une liste des types de champs autorisés et un exemple de définitions de champs de formulaire XML.

=== Namespace ===
{{notice|This code only works in {{JVer|4.0}} and later}}

Specify the namespace to be used for autoloading the plugin. The given namespace will autoload to the root directory of your extension by default however you can optionally add a "path" attribute to the namespace element to specify a subpath within your extensions root directory.

===SQL===

<source lang="xml">
<install>
<sql>
<file driver="mysql" charset="utf8">sql/example.install.sql</file>
</sql>
</install>
<uninstall>
<sql>
<file driver="mysql" charset="utf8">sql/example.uninstall.sql</file>
</sql>
</uninstall>
</source>

Dans l'exemple ci-dessus, nous avons placé les fichiers SQL dans le répertoire <tt>admin/sql</tt> du paquet d'installation. Vous devez inclure le dossier <tt>sql</tt> dans les fichiers d'administration (tel que décrit dans "les fichiers backend").

Vous pouvez exécuter SQL lors de l'installation et/ou la désinstallation à l'aide des éléments <code><install></code> et <code><uninstall></code>. Une balise <code><sql></code> doit apparaître comme un enfant de ces éléments. <code><sql></code> peut contenir n'importe quel nombre d'éléments <code><file></code>, chacun devant définir un seul fichier SQL à exécuter. Leurs types de pilote de base de données sont décrits par l'attribut <code>driver</code>, leurs jeux de caractères par l'attribut <code>charset</code>.

<div class="mw-translate-fuzzy">
==== Mise à jour du schéma SQL====
</div>

Depuis la version 1.6, une balise <code><update></code> est disponible et vous permet de fournir une série de fichiers SQL pour mettre à jour le schéma actuel.

<source lang="xml">
<update>
<schemas>
<schemapath type="mysql">sql/updates/mysql</schemapath>
<schemapath type="sqlsrv">sql/updates/sqlsrv</schemapath>
</schemas>
</update>
</source>

Par exemple, pour passer de la version <code>1.0.0</code> à la version <code>1.0.1</code> dans une base de données '''MySQL''', un fichier <code>1.0.1.sql</code> doit être créé dans le dossier <code>sql/updates/mysql</code> et la balise <code><version></code> du manifest doit être mis à jour :
<source lang="xml">
<version>1.0.1</version></source>

La structure finale du dossier sql ressemblera à ceci (dans l'hypothèse d'une base de données '''MySQL''')
<source lang="xml">
sql
|-->example.install.sql
|-->example.uninstall.sql
|-->updates
|-->mysql
|-->1.0.1.sql</source>

Des fichiers similaires doivent être créés pour les versions suivantes.

<div class="mw-translate-fuzzy">
===Fichiers langue===
</div>
<div class="mw-translate-fuzzy">
Dans Joomla! 1.5, les développeurs d'extensions devaient placer les fichiers de langue dans le dossier général des langues de Joomla! à l'aide des balises <languages>...</languages> comme indiqué ci-dessous. '''Cette méthode peut toujours être utilisée avec la version''' {{JVer|3.x}}.
</div>

<source lang="xml">

<languages folder="langfiles">
<language tag="en-GB">en-GB.com_example.ini</language>
</languages>
</source>

<div class="mw-translate-fuzzy">
Depuis Joomla! 1.6, il vous est conseillé de placer les fichiers langue de votre extension dans le dossier même de votre extension. Joomla! chargera alors automatiquement les fichiers de langue depuis votre extension.
</div>

En plaçant les fichiers de langue dans le dossier de l'extension, vous permettez ainsi de les isoler et donc de les protéger. Par exemple, dans le cas ou un administrateur supprimerait une langue de son installation Joomlaǃ. Dans ce cas, les fichiers de langue de l'extension ne seront pas supprimés. Ils resteront alors en place et ne seront accessibles que si la langue est installée à nouveau.

La structure du dossier de langue pour le frontend et le backend est identique. Il convient de les placer dans la balise <code><languages></code> (par exemple '''en-GB''') pour chaque langue et dans le dossier comme suit : '''language/en-GB/'''. Vous devez aussi spécifier ces dossiers pour le frontend et le backend.

Dans votre manifest, il suffit simplement d'inclure votre dossier <tt><language></tt> dans la section fichiers. Les sous-répertoires pour chaque langue seront alors automatiquement copiés. À l'intérieur des groupes <code><files></code>, il vous suffit d'ajouter une balise <code><folder></code> à côté des éléments dans le groupe <tt><files></tt>, comme indiqué dans cet exemple :

<source lang="xml">
<files>
<filename plugin="alpha">alpha.php</filename>
<folder>sql</folder>
<folder>language</folder>
</files>
</source>

Notez que les deux techniques peuvent fonctionner ensemble. Voici un exemple du noyau :

<source lang="xml">
<files>
<filename plugin="languagecode">languagecode.php</filename>
<filename>index.html</filename>
<folder>language</folder>
</files>
<languages>
<language tag="en-GB">language/en-GB/en-GB.plg_system_languagecode.ini</language>
<language tag="en-GB">language/en-GB/en-GB.plg_system_languagecode.sys.ini</language>
</languages>
</source>

Les avantages pour cette solution sont les suivants :

Tous les fichiers ''.ini'' présents dans le dossier du noyau ont la priorité sur les fichiers dans les dossiers langue des extensions.
Par exemple, s'il existe, un fichier <tt>sys.ini</tt> d'un dossier du noyau sera toujours chargé dans le backend, sauf lors de l'installation d'une extension qui contient son propre fichier <tt>sys.ini</tt> dans un dossier de langue. Dans ce cas et uniquement ce cas, le fichier <tt>sys.ini</tt> dans le dossier de l'extension affichera son contenu traduit au moment de l'installation. C'est très pratique car un développeur peut avoir deux fichiers <tt>sys.ini</tt> avec un contenu différent.

Il est également beaucoup plus facile pour un utilisateur ayant besoin de trouver le fichier <tt>.ini</tt> d'une extension qui n'est pas disponible dans sa langue de l'ajouter dans le dossier principal. Il n'y a aucun risque qu'il ne soit supprimé en cas de désinstallation par erreur de l'extension.

Veuillez consulter également :
*[[S:MyLanguage/J2.5:Making non-core language packs|Créer un pack langue hors du noyau]]
*[[S:MyLanguage/Creating language packs for extensions in Joomla 2.5|Créer un pack langue pour une extension Joomla! 2.5]]

Au cours du développement, vous pouvez activer le système de débogage de langue dans la configuration globale de Joomlaǃ. Vous pourrez découvrir si un problème est levé. Depuis {{JVer|3.2}}, cela est nécessaire afin d'aider à déboguer le en-GB qui est '''toujours''' chargé en premier lorsque l'on est pas en mode de débogage et ainsi empêcher l'affichage des constantes.

===Fichier de script===

<source lang="xml">
<scriptfile>example.script.php</scriptfile>
</source>

<div class="mw-translate-fuzzy">
Un '''fichier de script''' (code PHP qui est exécuté avant, pendant et/ou après l'installation, la désinstallation ou la mise à jour) peut, en option, être défini à l'aide d'une balise <code><scriptfile></code>. Ce fichier doit contenir une classe nommée '<tt><element_name>InstallerScript''</tt> où <tt><element_name></tt> est le nom de votre extension (par exemple : com_nomducomposant, mod_nomdumodule, etc.). Pour les plugins, il convient de nommer également le groupe (par exemple : plgsystemnomduplugin). Les packages de bibliothèque ne prennent pas en charge les fichiers scripts. La structure de la classe sera comme suit :
</div>

This file should contain a class named "<element_name>InstallerScript" where <element_name> is the name of your extension (e.g. com_componentname, mod_modulename, etc.). Plugins must state the group (e.g. plgsystempluginname).

In {{JVer|4.0}} and later the structure of the class is as follows:

<source lang="php">

<?php

use Joomla\CMS\Installer\InstallerAdapter;

class com_componentnameInstallerScript
{
/**
* Constructor
*
* @param InstallerAdapter $adapter The object responsible for running this script
*/
public function __construct(InstallerAdapter $adapter)
{
}

/**
* Called before any type of action
*
* @param string $route Which action is happening (install|uninstall|discover_install|update)
* @param InstallerAdapter $adapter The object responsible for running this script
*
* @return boolean True on success
*/
public function preflight($route, InstallerAdapter $adapter)
{
return true;
}

/**
* Called after any type of action
*
* @param string $route Which action is happening (install|uninstall|discover_install|update)
* @param InstallerAdapter $adapter The object responsible for running this script
*
* @return boolean True on success
*/
public function postflight($route, $adapter)
{
return true;
}

/**
* Called on installation
*
* @param InstallerAdapter $adapter The object responsible for running this script
*
* @return boolean True on success
*/
public function install(InstallerAdapter $adapter)
{
return true;
}

/**
* Called on update
*
* @param InstallerAdapter $adapter The object responsible for running this script
*
* @return boolean True on success
*/
public function update(InstallerAdapter $adapter)
{
return true;
}

/**
* Called on uninstallation
*
* @param InstallerAdapter $adapter The object responsible for running this script
*/
public function uninstall(InstallerAdapter $adapter)
{
return true;
}
}

?>
</source>

Note that since Joomla 3.6 Joomla has shipped a basic script that you can use instead of shipping your own from scratch '''JInstallerScript''' which contains various helper methods commonly used through the community.

=== Library Manifests ===
{{notice|The section is based on {{JVer|4.0}} and later}}

A simple library manifest might look like this:
<source lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<extension type="library" method="upgrade" version="4.0">
<name>My Test library.</name>
<libraryname>mytest</libraryname>
<files>
<folder>Classes</folder>
<folder>language</folder>
<filename>mytest.php</filename>
</files>
</extension></source>

This will install the library into the <tt>JPATH_SITE/libraries/mytest</tt> folder.

What if your company has several libraries and you want to group them together under folder <tt>JPATH_SITE/libraries/mycompany</tt>?

Simple - include your company name in the <tt>libraryname</tt> property of each library like this:

<source lang="xml">
<libraryname>mycompany/mylibrary1</libraryname>
</source>

<source lang="xml">
<libraryname>mycompany/mylibrary2</libraryname>
</source>

These libraries will then be installed in the <tt>JPATH_SITE/libraries/mycompany/mylibrary1</tt> and <tt>JPATH_SITE/libraries/mycompany/mylibrary2</tt> folders.

Uninstalling <tt>mylibrary1</tt> will still leave <tt>mylibrary2</tt> installed on your site.

When using <tt>script files</tt> with such company libraries the installer class name should look like this:
<source lang="php">
class mycompanymylibrary1InstallerScript
</source>
<source lang="php">
class mycompanymylibrary2InstallerScript
</source>

<div class="mw-translate-fuzzy">
=== Serveurs de mise à jour ===
</div>

<source lang="xml">
<updateservers>
<server type="extension" priority="1" name="Extension Update Site">http://example.com/extension.xml</server>
<server type="collection" priority="2" name="Collection Update Site">http://example.com/collection.xml</server>
</updateservers>
</source>

Les serveurs de mise à jour peuvent être définis dans les balises <code><updateservers></code> comme enfant de la racine. Cet élément peut contenir une ou plusieurs balises <code><server></code> chacune avec la description depuis laquelle chercher les mises à jour. Chaque rubrique <code><server></code> permet de définir les attributs suivants :

{| class="wikitable"
! style="width: 150px" | Attribut || style="width: 150px" | Valeurs || Description
|-
| type || <code>extension</code><br /><code>collection</code> || Le type de serveur de mise à jour.
|-
| priority || ''integer'' || La priorité du serveur de mise à jour.
|-
| name || ''string'' || Le nom du serveur de mise à jour.
|}

<div class="mw-translate-fuzzy">
Pour plus d'informations :
* [[S:MyLanguage/J2.5:Developing a MVC Component/Adding an update server|Création d'une extension Joomla! - Ajout d'un serveur de mise à jour]]
* [[S:MyLanguage/J2.5:Managing Component Updates|Gestion des mises à jour de composants pour Joomla! 2.5]]
</div>

=== Supporting Download Keys ===

As of Joomla 4.0.0 users can enter their download keys in the Update Sites list. This gives them a single place to manage the download keys. When a user is going to update an extension, Joomla will check if there is a download key. If there is a download key, Joomla will add the download key to the update URL.

To support download keys you must include the <tt>dlid</tt> tag in the manifest file. The <tt>dlid</tt> tag takes 2 arguments:
* prefix
* suffix

The <tt>dlid</tt> tag will look like this in your manifest file:
<source lang="xml">
<dlid prefix="dlid=" suffix="&dummy=my.zip"/>
</source>

The prefix will be added before the download key and the suffix after the download key. Using the example above the full query added to the download link will be:
<source lang="php">
dlid=KEY&dummy=my.zip
</source>

The key is added before the <tt>onInstallerBeforePackageDownload</tt> event is triggered, so the full URL will be passed to the event.

===Exemples===
<div class="mw-translate-fuzzy">
== Exemples ==
Pour un exemple concret, veuillez consulter [https://github.com/joomla/joomla-cms/blob/3.6.4/administrator/components/com_banners/banners.xml le manifest pour le composant bannière de la version Joomla! 3.6.4].
</div>

D'autres exemples peuvent être trouvés dans le répertoire autonome des liens web :

<div class="mw-translate-fuzzy">
* [https://github.com/joomla-extensions/weblinks/blob/master/src/administrator/components/com_weblinks/weblinks.xml manifest com_weblinks]
* [https://github.com/joomla-extensions/weblinks/blob/master/src/modules/mod_weblinks/mod_weblinks.xml manifest mod_weblinks]
* [https://github.com/joomla-extensions/weblinks/blob/master/src/plugins/search/weblinks/weblinks.xml manifest plg_search_weblinks]
* [https://github.com/joomla/joomla-cms/blob/3.6.4/templates/protostar/templateDetails.xml manifest tpl_protostar (3.6.4)]
* [https://github.com/joomla/joomla-cms/blob/3.6.4/administrator/language/en-GB/en-GB.xml manifest en-GB (3.6.4)]
</div>

<noinclude>
[[Category:Development{{#translation:}}]]
[[Category:Extension development{{#translation:}}]]
[[Category:Specifications{{#translation:}}]]
</noinclude>

Translations:Manifest files/13/fr

2022-09-04T07:09:38Z

Lorangerart:

Chaîne de caractères qui identifie la version de Joomla! pour laquelle cette extension est développée. Ceci n'est pas utilisé dans le version {{JVer|3.x}} et a été retiré de la version {{JVer|4.0}} et des versions ultérieures.

Manifest files/fr

2022-09-04T07:09:10Z

Lorangerart:

<noinclude><languages /></noinclude>
<noinclude>
{{Joomla version|version=4.x}} {{Joomla version|version=3.x}} {{Joomla version|version=2.5|status=eos}}
</noinclude>
Avec Joomla, toutes les extensions proposent des fichiers manifestes. Ces fichiers recouvrent les informations générales concernant l'installation, ainsi que des paramètres pour la configuration de l'[[S:MyLanguage/extension|extension]] elle-même. Depuis Joomla! 2.5, il existe très peu de différences entre les différents formats de fichiers manifestes en fonction des différents [[S:MyLanguage/Extension types (technical definitions)|types d'extensions]] permettant ainsi à chaque type de bénéficier de la puissance de l'installateur Joomla.

==Conventions de nommage==
Le fichier doit être nommé <tt>manifest.xml</tt> (pour les versions de Joomlaǃ 2.5 et 3) ou <tt><extension_name>.xml</tt> (pour les versions de Joomlaǃ 2.5, 3 et 4) et situé dans le répertoire racine du package d'installation.

Joomla 4.x : la correspondance automatique du namespace va échouer si un nom de fichier tel que <tt>manifest.xml</tt> est utilisé. Voir https://github.com/joomla/joomla-cms/issues/37750

==Syntaxe==

===Élément à la racine===
{{notice|La nouvelle balise <code><extension></code> remplace l'ancienne <code><install></install></code> de la version Joomla {{JVer|1.5}}}}

La balise principale du fichier d'installation est :
<source lang=xml><extension></extension></source>

La balise ouvrante et fermante est la même pour toutes les extensions. Les attributs suivants sont autorisés à l'intérieur de la balise :

{|class="wikitable"
|-
! style="width: 150px" | Attribut || style="width: 150px" | Valeurs || Applicable à || Description
|-
| type || <code>component</code><br /><code>file</code><br /><code>language</code><br /><code>library</code><br /><code>module</code><br /><code>package</code><br /><code>plugin</code><br /><code>template</code><br/><code>element</code> || Toutes les extensions
| Cet attribut décrit à l'installateur le type de l'extension. En fonction de ce type, d'autres d'exigences supplémentaires s'appliqueront aux sous-balises.
|-
| version
| <code>2.5</code><br /><code>3.0</code> || Toutes les extensions
| Chaîne de caractères qui identifie la version de Joomla! pour laquelle cette extension est développée. Ceci n'est pas utilisé dans le version {{JVer|3.x}} et a été retiré de la version {{JVer|4.0}} et des versions postérieures.
|-
| method
| <code>install</code><br /><code>upgrade</code> || Toutes les extensions
| La valeur par défaut <code>install</code> sera également utilisée si l'attribut <tt>method</tt> n'est pas utilisé. La valeur <code>install</code> signifie que l'installateur va s'arrêter s'il trouve un fichier/dossier de la nouvelle extension.
|-
| client
| <code>site</code><br /><code>administrator</code> || Modules
| L'attribut <tt>client</tt> permet de préciser pour quel type de client d'application le nouveau module est disponible.
|-
| group
| ''string'' || Plugins
| Le nom du groupe indique pour quels groupes de plugins le nouveau plugin est disponible. Les groupes existants sont les noms de dossier du répertoire <tt>/plugins</tt>. Le programme d'installation va créer de nouveaux noms de dossier pour les noms de groupe qui n'existent pas encore.
|}

===Métadonnées===

Les éléments suivants peuvent être utilisés pour insérer des métadonnées. Aucun de ces éléments n'est obligatoire et s'ils sont présents, ils doivent être un enfant de l'élément racine.

<pre>
<name> – raw component name (e.g. com_banners).
<author> – author's name (e.g. Joomla! Project)
<creationDate> – date of creation or release (e.g. April 2006)
<copyright> – a copyright statement (e.g. (C) 2005 - 2011 Open Source Matters. All rights reserved.)
<license> – a license statement (e.g. NU General Public License version 2 or later; see LICENSE.txt)
<authorEmail> – author's email address (e.g. admin@joomla.org)
<authorUrl> – URL to the author's website (e.g. www.joomla.org)
<version> – the version number of the extension (e.g. 1.6.0)
<description> – the description of the component. This is a translatable field. (e.g. COM_BANNERS_XML_DESCRIPTION)
<element> – the internal name of the component. If omitted, name will be cleaned and used
</pre>

Remarque : les balises <name> et <description> sont des champs traduisibles de sorte que le nom et la description de l'extension pourront être présents dans la langue maternelle de l'utilisateur.

=== Fichiers de frontend ===

<source lang="xml">
<files folder="from-folder">
<filename>example.php</filename>
<folder>examples</folder>
</files>
</source>

Les fichiers à copier dans le répertoire de frontend doivent être placés dans les balises <code><files></code>. Vous pouvez utiliser l'attribut <code>folder</code> en option pour spécifier un répertoire '''du package ZIP'''. Chaque fichier à copier doit être nommé par l'élément <code><filename></code>. Si vous souhaitez copier un dossier entier à la fois, vous pouvez le définir comme un <code><folder></code>.

Pour les '''plugins''', le nom brut du plugin doit être placé dans l'attribut <code>plugin</code> de l'élément <code><filename></code> qui pointe vers le fichier contenant la classe du plugin. Par exemple, dans le cas d'un système de plugin appelé "exemple" (nom complet : <code>plg_system_exemple</code>), il faudra utiliser <code><filename plugin="exemple">exemple.php</filename></code>.

===Fichiers multimédias===

<source lang="xml>
<media folder="media" destination="com_example">
<filename>com_example_logo.png</filename>
<folder>css</folder>
<folder>js</folder>
</media>
</source>

Cet exemple permet de copier le fichier (<tt>/media/com_example_logo.png</tt>) et les dossiers ( <tt>/media/css/</tt> et <tt>/media/js/</tt> ) listés vers <tt>/media/com_example/</tt>, ainsi que la création du dossier <tt>com_example</tt> si nécessaire. Vous pouvez utiliser en option l'attribut <code>folder</code> pour spécifier un répertoire '''dans le package ZIP''' à partir duquel réaliser la (dans ce cas, <tt>media</tt>).

Les extensions doivent stocker les éléments, dont elles ont besoin pour être accessible sur le web (JS, CSS, images, etc), dans <code>media</code>. Cette fonctionnalité a été ajoutée dans le cadre du projet de développement d'une interface multi-site et du placement éventuel de fichiers de code (PHP) en dehors des espaces web serveurs accessibles.<br />Remarque: la section médias n'est pas analysé pour les extensions de type 'package'.

Ref:
* [https://groups.google.com/forum/#!msg/joomla-dev-cms/4CAASJqFY-k/PvPj14gP29EJ Google Groups - joomla-dev-cms thread]
* [https://groups.google.com/forum/#!msg/joomla-dev-cms/uNmhX98sKbE/p8p68Jke680J Google Groups - joomla-dev-cms thread]

===Section de l'administration===

<source lang="xml">
<administration>

</administration>
</source>

La section d'administration est définie par l'élément <code><administration></code>. Puisque seuls les [[S:MyLanguage/Component|composants]] concernent à la fois l'espace [[S:MyLanguage/Site (Application)|site]] et celui d'[[S:MyLanguage/Administrator (Application)|administration]], '''seuls les manifests pour composants doivent intégrer ces éléments'''.

====Fichiers de backend====

Les fichiers à copier dans le répertoire de backend doivent être placés dans l'élément <code><files></code> sous <code><administration></code>. Vous pouvez utiliser l'attribut optionnel <code>folder</code> pour spécifier un répertoire à copier depuis le '''pack ZIP'''. Voir les ''fichiers frontend'' pour plus d'informations.

====Liens de menu et sous-menus====
{{dablink|'''Note de version :''' avant Joomla! 3.4, le fait de ne pas avoir de balise <code><nowiki><menu></nowiki></code> dans votre fichier XML avait pour conséquence l création d'un élément de menu. Cette anomalie a été corrigée dans Joomla! 3.4 et ainsi, si aucune balise <code><nowiki><menu></nowiki></code> n'est présente dans votre fichier manifest, aucun menu d'administration ne sera créé pour le composant.}}

<source lang="xml">
<menu>COM_EXAMPLE</menu>
<submenu>

<menu link="anoption=avalue&anoption1=avalue1">COM_EXAMPLE_SUBMENU_ANOPTION</menu>
<menu view="viewname">COM_EXAMPLE_SUBMENU_VIEWNAME</menu>
</submenu>
</source>

Le texte pour l'élément du menu principal pour le composant est défini dans la balise <code><menu></code>, enfant de de la balise <code><administration></code>. Une balise <code><submenu></code> peut être présente (également comme enfant de <code><administration></code>), qui pourra contenir d'autres éléments de menu définis par <code><menu></code>.

En outre, chaque élément <code><menu></code> permet de définir les attributs suivants :

{| class="wikitable"
! style="width: 150px" | Attribut || Description
|-
| link || Un lien vers lequel renvoyer l'utilisateur lorsque l'élément de menu est cliqué. Vous pouvez utiliser "view" à la place.
|-
| img || Le chemin (relatif) à une image (16x16 pixels) qui apparait à côté de l'élément de menu.
<u>Doit être url compatible (par exemple sans espaces).</u>
|-
| alt ||
|-
| view || Un paramètre URL à ajouter au lien. Par exemple, <code><menu view="cpanel">COM_EXAMPLE</menu></code> dans le manifest XML com_example générerait l'URL de l'élément de menu <tt>index.php?option=com_example&view=cpanel</tt>. Vous pouvez utiliser "link" à la place.
|-
|}

La valeur à l'intérieur de la balise est le nom du menu. À La différence de ce qui se faisait pour Joomla! 1.5, vous ne pouvez pas utiliser une chaîne de caractère dans votre langue naturelle. Par exemple, si vous renseignez "Composant d'exemple" au lieu de COM_EXAMPLE, votre nom de composant qui s'afficherait en titre serait "composant-d-exemple" et vous seriez dans l'impossibilité de le traduire. Pour réaliser une traduction, vous devez créer un fichier nommé <tt>fr-FR.com_example.sys.ini</tt> '''(NDT : avant de pouvoir créer le fichier fr-FR, il convient de créer le fichier d'origine en-GB)''' dans <tt>administrator/languages/fr-FR</tt> (vous pouvez utiliser la balise manifest <code><languages></code> pour qu'il soit copié lors de l'installation) ou dans <tt>administrator/components/com_example/language/fr-FR</tt>. Dans ce dernier cas, vous ne devez pas inclure le fichier de traduction dans la balise <code><languages></code> balise. Tant que vous aurez placé le répertoire de langue dans vos balises <code><files></code>, il sera copié lors de l'installation du composant.

Le contenu de ce fichier devrait être :

<source lang="ini">
COM_EXAMPLE="Example Component"
COM_EXAMPLE_SUBMENU_ANOPTION="Another Option"
COM_EXAMPLE_SUBMENU_VIEWNAME="Another View"
</source>

Please note that the language string must be enclosed in double quotes, as per Joomla!'s translation standards.

{{note|Joomla! 1.6 and later sorts the Component menu items based on the actual translation of the key you supply in your XML manifest. This means that the sorting order is correct no matter what you call your translation key and no matter which language the site is being displayed in. Essentially, Joomla! 1.6 fixed the wrong sorting of the Components menu experienced under Joomla! 1.5 for the majority (non-English speaking!) of Joomla! users.}}

=== Dashboards ===
{{notice|This code only works in {{JVer|4.0}} and later}}

Specifies the details for displaying a dashboard for the component in the Administrator area for the site.
* It will make a dashboard icon appear next to the administrator menu item for the component
* The dashboard icon will click through to display modules assigned to the cpanel-example administrator module position
* The title and icon defined in the XML file will be used as the header and icon at the top of the component's dashboard page.

<source lang="xml">
<dashboards>
<dashboard title="COM_EXAMPLE_DASHBOARD_TITLE" icon="icon-lock">example</dashboard>
</dashboards>
</source>

===Configuration===
{{warning|<div class="mw-translate-fuzzy">
Les composants '''ne prennent pas en charge''' les définitions de configuration '''dans le manifeste'''. Ceci avait été mis en œuvre dans Joomla! 1.5. Ils est possible de définir les options de configuration pour différents niveaux à l'aide des [[S:MyLanguage/Component configuration metadata|métadonnées de configuration de composant]].
</div>}}
<div class="mw-translate-fuzzy">
La balise <code><config></code>, enfant de la racine, décrit les options de configuration de l'extension. En cas de besoin, les options seront affichées par le gestionnaire concerné (gestionnaire de plugins, gestionnaire de modules ou gestionnaire de templates). '''Les options de configuration peuvent également être définies dans un fichier séparé nommé <code>config.xml</code>. Son élément racine doit être <code><config></code>.'''
</div>

Chaque groupe de champs <code><fieldset></code> peut contenir un ou plusieurs éléments <code><field></code> (champ), chacun représentant un seul [[S:MyLanguage/form field|champ de formulaire]] avec une étiquette. Consultez les [[S:MyLanguage/Standard form field types|types de champs pour formulaires standards]] pour une liste des types de champs autorisés et un exemple de définitions de champs de formulaire XML.

=== Namespace ===
{{notice|This code only works in {{JVer|4.0}} and later}}

Specify the namespace to be used for autoloading the plugin. The given namespace will autoload to the root directory of your extension by default however you can optionally add a "path" attribute to the namespace element to specify a subpath within your extensions root directory.

===SQL===

<source lang="xml">
<install>
<sql>
<file driver="mysql" charset="utf8">sql/example.install.sql</file>
</sql>
</install>
<uninstall>
<sql>
<file driver="mysql" charset="utf8">sql/example.uninstall.sql</file>
</sql>
</uninstall>
</source>

Dans l'exemple ci-dessus, nous avons placé les fichiers SQL dans le répertoire <tt>admin/sql</tt> du paquet d'installation. Vous devez inclure le dossier <tt>sql</tt> dans les fichiers d'administration (tel que décrit dans "les fichiers backend").

Vous pouvez exécuter SQL lors de l'installation et/ou la désinstallation à l'aide des éléments <code><install></code> et <code><uninstall></code>. Une balise <code><sql></code> doit apparaître comme un enfant de ces éléments. <code><sql></code> peut contenir n'importe quel nombre d'éléments <code><file></code>, chacun devant définir un seul fichier SQL à exécuter. Leurs types de pilote de base de données sont décrits par l'attribut <code>driver</code>, leurs jeux de caractères par l'attribut <code>charset</code>.

<div class="mw-translate-fuzzy">
==== Mise à jour du schéma SQL====
</div>

Depuis la version 1.6, une balise <code><update></code> est disponible et vous permet de fournir une série de fichiers SQL pour mettre à jour le schéma actuel.

<source lang="xml">
<update>
<schemas>
<schemapath type="mysql">sql/updates/mysql</schemapath>
<schemapath type="sqlsrv">sql/updates/sqlsrv</schemapath>
</schemas>
</update>
</source>

Par exemple, pour passer de la version <code>1.0.0</code> à la version <code>1.0.1</code> dans une base de données '''MySQL''', un fichier <code>1.0.1.sql</code> doit être créé dans le dossier <code>sql/updates/mysql</code> et la balise <code><version></code> du manifest doit être mis à jour :
<source lang="xml">
<version>1.0.1</version></source>

La structure finale du dossier sql ressemblera à ceci (dans l'hypothèse d'une base de données '''MySQL''')
<source lang="xml">
sql
|-->example.install.sql
|-->example.uninstall.sql
|-->updates
|-->mysql
|-->1.0.1.sql</source>

Des fichiers similaires doivent être créés pour les versions suivantes.

<div class="mw-translate-fuzzy">
===Fichiers langue===
</div>
<div class="mw-translate-fuzzy">
Dans Joomla! 1.5, les développeurs d'extensions devaient placer les fichiers de langue dans le dossier général des langues de Joomla! à l'aide des balises <languages>...</languages> comme indiqué ci-dessous. '''Cette méthode peut toujours être utilisée avec la version''' {{JVer|3.x}}.
</div>

<source lang="xml">

<languages folder="langfiles">
<language tag="en-GB">en-GB.com_example.ini</language>
</languages>
</source>

<div class="mw-translate-fuzzy">
Depuis Joomla! 1.6, il vous est conseillé de placer les fichiers langue de votre extension dans le dossier même de votre extension. Joomla! chargera alors automatiquement les fichiers de langue depuis votre extension.
</div>

En plaçant les fichiers de langue dans le dossier de l'extension, vous permettez ainsi de les isoler et donc de les protéger. Par exemple, dans le cas ou un administrateur supprimerait une langue de son installation Joomlaǃ. Dans ce cas, les fichiers de langue de l'extension ne seront pas supprimés. Ils resteront alors en place et ne seront accessibles que si la langue est installée à nouveau.

La structure du dossier de langue pour le frontend et le backend est identique. Il convient de les placer dans la balise <code><languages></code> (par exemple '''en-GB''') pour chaque langue et dans le dossier comme suit : '''language/en-GB/'''. Vous devez aussi spécifier ces dossiers pour le frontend et le backend.

Dans votre manifest, il suffit simplement d'inclure votre dossier <tt><language></tt> dans la section fichiers. Les sous-répertoires pour chaque langue seront alors automatiquement copiés. À l'intérieur des groupes <code><files></code>, il vous suffit d'ajouter une balise <code><folder></code> à côté des éléments dans le groupe <tt><files></tt>, comme indiqué dans cet exemple :

<source lang="xml">
<files>
<filename plugin="alpha">alpha.php</filename>
<folder>sql</folder>
<folder>language</folder>
</files>
</source>

Notez que les deux techniques peuvent fonctionner ensemble. Voici un exemple du noyau :

<source lang="xml">
<files>
<filename plugin="languagecode">languagecode.php</filename>
<filename>index.html</filename>
<folder>language</folder>
</files>
<languages>
<language tag="en-GB">language/en-GB/en-GB.plg_system_languagecode.ini</language>
<language tag="en-GB">language/en-GB/en-GB.plg_system_languagecode.sys.ini</language>
</languages>
</source>

Les avantages pour cette solution sont les suivants :

Tous les fichiers ''.ini'' présents dans le dossier du noyau ont la priorité sur les fichiers dans les dossiers langue des extensions.
Par exemple, s'il existe, un fichier <tt>sys.ini</tt> d'un dossier du noyau sera toujours chargé dans le backend, sauf lors de l'installation d'une extension qui contient son propre fichier <tt>sys.ini</tt> dans un dossier de langue. Dans ce cas et uniquement ce cas, le fichier <tt>sys.ini</tt> dans le dossier de l'extension affichera son contenu traduit au moment de l'installation. C'est très pratique car un développeur peut avoir deux fichiers <tt>sys.ini</tt> avec un contenu différent.

Il est également beaucoup plus facile pour un utilisateur ayant besoin de trouver le fichier <tt>.ini</tt> d'une extension qui n'est pas disponible dans sa langue de l'ajouter dans le dossier principal. Il n'y a aucun risque qu'il ne soit supprimé en cas de désinstallation par erreur de l'extension.

Veuillez consulter également :
*[[S:MyLanguage/J2.5:Making non-core language packs|Créer un pack langue hors du noyau]]
*[[S:MyLanguage/Creating language packs for extensions in Joomla 2.5|Créer un pack langue pour une extension Joomla! 2.5]]

Au cours du développement, vous pouvez activer le système de débogage de langue dans la configuration globale de Joomlaǃ. Vous pourrez découvrir si un problème est levé. Depuis {{JVer|3.2}}, cela est nécessaire afin d'aider à déboguer le en-GB qui est '''toujours''' chargé en premier lorsque l'on est pas en mode de débogage et ainsi empêcher l'affichage des constantes.

===Fichier de script===

<source lang="xml">
<scriptfile>example.script.php</scriptfile>
</source>

<div class="mw-translate-fuzzy">
Un '''fichier de script''' (code PHP qui est exécuté avant, pendant et/ou après l'installation, la désinstallation ou la mise à jour) peut, en option, être défini à l'aide d'une balise <code><scriptfile></code>. Ce fichier doit contenir une classe nommée '<tt><element_name>InstallerScript''</tt> où <tt><element_name></tt> est le nom de votre extension (par exemple : com_nomducomposant, mod_nomdumodule, etc.). Pour les plugins, il convient de nommer également le groupe (par exemple : plgsystemnomduplugin). Les packages de bibliothèque ne prennent pas en charge les fichiers scripts. La structure de la classe sera comme suit :
</div>

This file should contain a class named "<element_name>InstallerScript" where <element_name> is the name of your extension (e.g. com_componentname, mod_modulename, etc.). Plugins must state the group (e.g. plgsystempluginname).

In {{JVer|4.0}} and later the structure of the class is as follows:

<source lang="php">

<?php

use Joomla\CMS\Installer\InstallerAdapter;

class com_componentnameInstallerScript
{
/**
* Constructor
*
* @param InstallerAdapter $adapter The object responsible for running this script
*/
public function __construct(InstallerAdapter $adapter)
{
}

/**
* Called before any type of action
*
* @param string $route Which action is happening (install|uninstall|discover_install|update)
* @param InstallerAdapter $adapter The object responsible for running this script
*
* @return boolean True on success
*/
public function preflight($route, InstallerAdapter $adapter)
{
return true;
}

/**
* Called after any type of action
*
* @param string $route Which action is happening (install|uninstall|discover_install|update)
* @param InstallerAdapter $adapter The object responsible for running this script
*
* @return boolean True on success
*/
public function postflight($route, $adapter)
{
return true;
}

/**
* Called on installation
*
* @param InstallerAdapter $adapter The object responsible for running this script
*
* @return boolean True on success
*/
public function install(InstallerAdapter $adapter)
{
return true;
}

/**
* Called on update
*
* @param InstallerAdapter $adapter The object responsible for running this script
*
* @return boolean True on success
*/
public function update(InstallerAdapter $adapter)
{
return true;
}

/**
* Called on uninstallation
*
* @param InstallerAdapter $adapter The object responsible for running this script
*/
public function uninstall(InstallerAdapter $adapter)
{
return true;
}
}

?>
</source>

Note that since Joomla 3.6 Joomla has shipped a basic script that you can use instead of shipping your own from scratch '''JInstallerScript''' which contains various helper methods commonly used through the community.

=== Library Manifests ===
{{notice|The section is based on {{JVer|4.0}} and later}}

A simple library manifest might look like this:
<source lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<extension type="library" method="upgrade" version="4.0">
<name>My Test library.</name>
<libraryname>mytest</libraryname>
<files>
<folder>Classes</folder>
<folder>language</folder>
<filename>mytest.php</filename>
</files>
</extension></source>

This will install the library into the <tt>JPATH_SITE/libraries/mytest</tt> folder.

What if your company has several libraries and you want to group them together under folder <tt>JPATH_SITE/libraries/mycompany</tt>?

Simple - include your company name in the <tt>libraryname</tt> property of each library like this:

<source lang="xml">
<libraryname>mycompany/mylibrary1</libraryname>
</source>

<source lang="xml">
<libraryname>mycompany/mylibrary2</libraryname>
</source>

These libraries will then be installed in the <tt>JPATH_SITE/libraries/mycompany/mylibrary1</tt> and <tt>JPATH_SITE/libraries/mycompany/mylibrary2</tt> folders.

Uninstalling <tt>mylibrary1</tt> will still leave <tt>mylibrary2</tt> installed on your site.

When using <tt>script files</tt> with such company libraries the installer class name should look like this:
<source lang="php">
class mycompanymylibrary1InstallerScript
</source>
<source lang="php">
class mycompanymylibrary2InstallerScript
</source>

<div class="mw-translate-fuzzy">
=== Serveurs de mise à jour ===
</div>

<source lang="xml">
<updateservers>
<server type="extension" priority="1" name="Extension Update Site">http://example.com/extension.xml</server>
<server type="collection" priority="2" name="Collection Update Site">http://example.com/collection.xml</server>
</updateservers>
</source>

Les serveurs de mise à jour peuvent être définis dans les balises <code><updateservers></code> comme enfant de la racine. Cet élément peut contenir une ou plusieurs balises <code><server></code> chacune avec la description depuis laquelle chercher les mises à jour. Chaque rubrique <code><server></code> permet de définir les attributs suivants :

{| class="wikitable"
! style="width: 150px" | Attribut || style="width: 150px" | Valeurs || Description
|-
| type || <code>extension</code><br /><code>collection</code> || Le type de serveur de mise à jour.
|-
| priority || ''integer'' || La priorité du serveur de mise à jour.
|-
| name || ''string'' || Le nom du serveur de mise à jour.
|}

<div class="mw-translate-fuzzy">
Pour plus d'informations :
* [[S:MyLanguage/J2.5:Developing a MVC Component/Adding an update server|Création d'une extension Joomla! - Ajout d'un serveur de mise à jour]]
* [[S:MyLanguage/J2.5:Managing Component Updates|Gestion des mises à jour de composants pour Joomla! 2.5]]
</div>

=== Supporting Download Keys ===

As of Joomla 4.0.0 users can enter their download keys in the Update Sites list. This gives them a single place to manage the download keys. When a user is going to update an extension, Joomla will check if there is a download key. If there is a download key, Joomla will add the download key to the update URL.

To support download keys you must include the <tt>dlid</tt> tag in the manifest file. The <tt>dlid</tt> tag takes 2 arguments:
* prefix
* suffix

The <tt>dlid</tt> tag will look like this in your manifest file:
<source lang="xml">
<dlid prefix="dlid=" suffix="&dummy=my.zip"/>
</source>

The prefix will be added before the download key and the suffix after the download key. Using the example above the full query added to the download link will be:
<source lang="php">
dlid=KEY&dummy=my.zip
</source>

The key is added before the <tt>onInstallerBeforePackageDownload</tt> event is triggered, so the full URL will be passed to the event.

===Exemples===
<div class="mw-translate-fuzzy">
== Exemples ==
Pour un exemple concret, veuillez consulter [https://github.com/joomla/joomla-cms/blob/3.6.4/administrator/components/com_banners/banners.xml le manifest pour le composant bannière de la version Joomla! 3.6.4].
</div>

D'autres exemples peuvent être trouvés dans le répertoire autonome des liens web :

<div class="mw-translate-fuzzy">
* [https://github.com/joomla-extensions/weblinks/blob/master/src/administrator/components/com_weblinks/weblinks.xml manifest com_weblinks]
* [https://github.com/joomla-extensions/weblinks/blob/master/src/modules/mod_weblinks/mod_weblinks.xml manifest mod_weblinks]
* [https://github.com/joomla-extensions/weblinks/blob/master/src/plugins/search/weblinks/weblinks.xml manifest plg_search_weblinks]
* [https://github.com/joomla/joomla-cms/blob/3.6.4/templates/protostar/templateDetails.xml manifest tpl_protostar (3.6.4)]
* [https://github.com/joomla/joomla-cms/blob/3.6.4/administrator/language/en-GB/en-GB.xml manifest en-GB (3.6.4)]
</div>

<noinclude>
[[Category:Development{{#translation:}}]]
[[Category:Extension development{{#translation:}}]]
[[Category:Specifications{{#translation:}}]]
</noinclude>

Translations:Manifest files/13/fr

2022-09-04T07:09:08Z

Lorangerart:

Joomla 3.x to 4.x Step by Step Migration/fr

2022-09-04T06:52:39Z

Lorangerart: Created page with "* [http://extensions.joomla.org/extensions/access-a-security/site-security/backup/1606 Akeeba Backup] est très populaire pour la sauvegarde et la restauration. Voir d'autres..."

<noinclude><languages /></noinclude>
{{warning|title=Attention !|Ce guide suppose que vous démarrez sur Joomla 3.10.x. Si vous êtes sur une version antérieure, assurez-vous de mettre à niveau vers Joomla 3.10 avant de passer à Joomla 4.

Il n'y a pas d'urgence. Assurez-vous que toutes vos extensions sont prêtes pour Joomla 4.x. Joomla 3.10.x sera supporté jusqu'au 16 août 2023.}}

Voici les instructions étape par étape pour migrer votre site 3.10.x vers Joomla ! 4.x. Bien qu'il existe des centaines de scénarios différents, ceci vous donnera la procédure de base à suivre. Les migrations très complexes seront probablement le résultat d'extensions tierces installées. Nous vous encourageons à contacter les développeurs des extensions tierces installées sur votre site Joomla pour connaître le chemin qu'ils suggèrent pour migrer leurs extensions.

== Intro ==
La migration de Joomla ! 3.10.x vers 4.x est considérée comme une mini-migration. En effet, les extensions de base de Joomla seront mises à niveau en un seul clic via le composant de mise à jour de Joomla ! dans la partie administrateur de Joomla. De nombreuses extensions tierces peuvent également être mises à niveau en un clic. D'autres ne le sont pas. Vous devez examiner chacune d'entre elles et déterminer le chemin que l'extension doit suivre pour passer de la version 3.10 à la version 4.x. Si vous ne l'avez pas encore fait, vous pourriez être intéressé par la lecture des documents suivants : [[S:MyLanguage/Migration Step by Step Self Assessment|Auto-évaluation]] et [[S:MyLanguage/Planning for Mini-Migration - Joomla 3.10.x to 4.x|Planification de la migration de 3.10 à 4.x]] avant de suivre les étapes suivantes
</br>Les extensions de base de Joomla ! sont :
* Catégories
* Articles
* Menus
* Modules (modules de base - pas de modules tiers)
* Journaux d'activité
* Bannières
* Champs
* Historique du contenu
* Contacts
* Messagerie
* Flux d'actualités
* Redirections
* Recherche (séparé en 4.x. Les sites 3.x existants pourront toujours migrer. Cependant, nous recommandons d'utiliser La recherche avancée à l'avenir. Voir les notes de la section Évaluation de chaque extension)
* Recherche avancée
* Tags
* Liens web (séparé mais votre site peut l'utiliser et il migrera. Voir les notes de la section Évaluation de chaque extension)

== Etape par étape ==
=== Créez un environnement de développement ===
# Assurez-vous que vous exécutez la dernière version de Joomla 3.10.x avant de poursuivre.
# Faites une sauvegarde de votre site 3.10.x. Vous pouvez utiliser un outil suggéré (voir les ''Outils suggérés'' en bas de page) ou vous pouvez le faire manuellement.
#*[[S:MyLanguage/Backup_Basics_for_a_Joomla!_Web_Site|Principes de base de la sauvegarde d'un site web Joomla ! ]]
#*[[S:MyLanguage/What_are_the_best_practices_for_site_backups%3F|Quelles sont les meilleures pratiques pour les sauvegardes de sites ?]]
# Assurez-vous que votre environnement est conforme aux [https://downloads.joomla.org/technical-requirements exigences techniques pour Joomla 4] avant de poursuivre.
# Créez une nouvelle base de données et un nouvel utilisateur pour restaurer votre site 3.10.x.
# Créez un site de test ou une zone de développement pour travailler et restaurez la copie de sauvegarde de votre site 3.10.x à l'un des endroits suivants :
#* Un sous-domaine.
#* Un sous-répertoire.
#* Un périphérique local. Joomla a un tutoriel détaillé sur l'installation de [https://sourceforge.net/projects/xampp/ XAMPP] à [[XAMPP]]. Cependant, [https://www.wampserver.com/en/ WAMP], [https://www.mamp.info/en/windows/ MAMP], [https://sourceforge.net/projects/lampas/ LAMP] sont toutes des alternatives appropriées.
#* Un nouveau compte d'hébergement sur un domaine temporaire à la racine. (Si vous souhaitez changer d'hébergement au cours du processus de migration).
#** Restauration d'un site sur un périphérique local. Voir [[S:MyLanguage/Installing Joomla locally|Installation de Joomla localement]] et [[S:MyLanguage/Setting up your workstation for Joomla development|Configuration de votre poste de travail pour le développement de Joomla]].
#** Restauration d'un site avec un outil listé en bas de page. (Lisez la documentation du développeur).
# Dans votre emplacement de test, mettez à jour votre instance Joomla ! 3.10.x vers la dernière version de maintenance.
# Assurez-vous que vous avez le dernier schéma de base de données mis à jour vers la dernière version 3.10.x en allant dans l'onglet {{rarr|Gestion des Extensions,Base de données}}. Si votre schéma n'est pas à jour comme dans l'image suivante, cliquez sur le bouton '''Corriger''' :{{-}}[[File:J310-admin-extension-database-fix-en.png|border|800px]]
# Vider la corbeille : Avez-vous des articles dans la corbeille ? Si c'est le cas, supprimez-les (ainsi que tous les médias qui peuvent leur être associés s'ils ne sont pas utilisés ailleurs sur le site). Les articles (ainsi que les catégories et les éléments de menu) laissés dans la corbeille peuvent empêcher une migration de se terminer sans erreur.
# Tester.
# Faites une nouvelle sauvegarde.

=== Evaluer chaque extension ===
Dans votre [[S:MyLanguage/Planning_for_Mini-Migration_-_Joomla_3.10.x_to_4.x|planning]], vous avez déterminé quelles extensions tierces restaient ou partaient et comment elles migraient. Pour cette partie de l'étape par étape, vous allez utiliser deux sections différentes du site de manière intensive ; La vérification avant mise à jour dans {{rarr|Composants,Mise à jour de Joomla !}} et {{rarr|Extensions,Gestion des extensions,Gerer}}. Vous allez examiner chaque extension installée sur votre site. Vous allez déterminer si elles doivent être mises à jour vers la dernière version ou désinstallées. Plus de précisions dans la [[Special:MyLanguage/:Pre-Update_Check|Vérification avant mise à jour]].
# Utilisation du contrôle de "pré-mise à jour" : pour pouvoir utiliser le contrôle de pré-mise à jour, vous devez configurer le composant de mise à jour de Joomla ! pour Joomla 4. Pour ce faire, procédez comme suit :
# Allez sur {{rarr|Components,Mise à jour de Joomlaǃ}}. (Il devrait indiquer qu'aucune mise à jour n'a été trouvée. Si ce n'est pas le cas, mettez à jour Joomla à la dernière version (doit être 3.10.x) et testez. Puis faites une autre sauvegarde). Cliquez sur le bouton Paramètres dans le coin supérieur droit.
# Sélectionnez ''Le prochain Joomlaǃ'' dans le menu déroulant pour le canal de mise à jour.{{-}}[[File:Migration_J3toJ4_update_channel-en.png|border|800px]]{{-}}
# Cliquez sur Enregistrer et fermer
# Vous verrez alors votre version installée de Joomla, la dernière version de Joomla ! et l'URL du package de mise à jour. Joomla vous montrera à nouveau la configuration requise pour Joomla 4. S'il signale que vous avez un système ou des extensions incompatibles, il vous le dira ici. Prenez un moment pour consulter cette page.{{-}}[[File:J310-admin-update_to_4-pre_update_check-en.png|border|800px]]{{amboxNew|image=notice|style=notice|title={{{title|Note importante}}}|text='''Ne faites PAS la mise à jour vers Joomla ! 4 maintenant. C'est seulement pour préparer vos extensions tierces et rendre le site compatible avec Joomla ! 4.'''}}
# Regardez le contrôle de pré-mise à jour et le contrôle de pré-mise à jour des extensions dans l'onglet Contrôle de pré-mise à jour du composant Joomla Update. Si une extension qui n'est pas dans votre planning est listée ici, ajoutez-la à votre liste d'extensions à examiner.
# Si vous avez migré de Joomla ! 2.5 à 3.x dans le passé, il peut y avoir quelques extensions restantes qui doivent être nettoyées. Voici les anciennes extensions 2.5 ou 3.x qui doivent être désinstallées avant la mise à jour vers Joomla 4 :
#;* plg_content_geshi
#;* template admin Bluestork
#;* Beez_20
#;* Beez5
#;* Atomic
## En ce qui concerne les templates, désinstallez tous les templates frontend ou backend de base, sauf Protostar et Beez3 (templates frontend) et Isis ou Hathor (templates administrateur). '''NOTE : Protostar n'est PAS compatible avec Joomla 4'''. Lors de la migration, il disparaîtra. Vous aurez besoin d'avoir un template sélectionné comme "par défaut" et vous pouvez utiliser Protostar ou Beez3. Protostar disparaîtra lors de la migration vers Joomla 4.x.
### Si vous rencontrez d'autres fichiers qui doivent être désinstallés, veuillez les ajouter à cette page. Ceci est un wiki, donc tout le monde peut ajouter à la page. Merci d'avance pour votre service.
# Vous remarquerez les balises indiquant si une extension est compatible ou non. Ces balises indiquent généralement la vérité si elles disent Non ou Oui. Si elles disent "Balise de compatibilité manquante", cela signifie que le développeur de l'extension n'a pas utilisé de balise dans son extension et que nous ne savons pas si elle est ou non compatible avec Joomla 4. Contactez le développeur pour vérifier.
# Mise à jour des extensions : mettez à jour toutes les extensions que vous conserverez dans votre site Web. Dans Joomla ! 3.10.x, vous pouvez aller dans {{rarr|Gestionnaire d'extensions, onglet Mise à jour}} et cliquer sur '''Trouver les mises à jour''' qui ajoutera une info-bulle dans la colonne Version, sous l'onglet Gérer, donnant quelques informations de compatibilité depuis le backend. Cette fonctionnalité ne prend en charge que les extensions qui se mettent à jour via l'onglet Mise à jour du gestionnaire d'extensions. Si vous avez installé des extensions qui n'utilisent pas la mise à jour des extensions Joomla, elles doivent être évaluées manuellement comme indiqué ci-dessous. Il en va de même pour les extensions qui ont une info-bulle. Vous devrez toujours vérifier le type de paquet et le chemin de migration avec le développeur de l'extension pour vérifier comment mettre à niveau/migrer.
# Désinstaller et examiner les extensions : allez dans {{rarr|Gestionnaire d'extensions, onglet Gérer}}.
# Cliquez sur le bouton ''Outils de recherche'' pour afficher les options de filtrage.
# Sélectionnez le package dans la liste déroulante.{{-}}[[File:J310-admin-extension-manage-package-en.png|800px]]{{-}}{{note|Il est recommandé de sélectionner d'abord le package, car si vous devez désinstaller quelque chose dans un package, il désinstallera automatiquement et en une seule fois les modules, les plugins ou tout autre élément associé dans le package.}}
# Désinstallez tous les packages qui ne sont plus nécessaires ou qui ne seront pas transférés vers Joomla 4.
# Répétez ce processus en passant par l'onglet Gérer pour tous les types dans la liste déroulante : Composant, Fichier, Langue, Bibliothèque, Module, Plugin et Template. Si l'auteur indique projet Joomla, ne touchez pas à ces extensions. Pour toutes les autres, assurez-vous de désinstaller celles qui ne sont pas utilisées ou qui ne sont pas compatibles avec Joomla! 4.x.{{-}}{{note|'''NOTE!''' Vous ne pourrez pas désinstaller un template qui est défini par défaut. Vous devrez sélectionner un template supporté par Core comme Beez3 ou Protostar et ensuite désinstaller le template si vous avez besoin de le faire. <br />''Autre rappel :''' '''Protostar n'est pas compatible avec Joomla 4.x'''. Lors de la migration, il disparaîtra. En le sélectionnant par défaut, vous arrivez simplement à Joomla 4.x.|type=serious}}
# Notez toutes les versions des packages et des composants en cours d'exécution que vous conserverez sur votre site. Vous pouvez les copier/coller dans un document pour référence.
# Pour toutes les extensions que vous gardez mais n'utilisez pas le gestionnaire d'extensions pour mettre à jour en un clic ({{rarr|Extensions,Gérer,Mettre à jour}}) mettez à jour toutes les extensions avec les dernières versions.
# Avant et pendant la mise à jour, notez si les extensions ont les versions 3.10.x et 4.x dans le même package. Si c'est le cas, elles pourront être mises à jour en un clic. Si ce n'est pas le cas, et que les versions 3.10 et 4.x ont des packages différents, vous devez les examiner au cas par cas. En règle générale, elles relèvent de l'un des scénarios suivants :
#* L'extension a des packages séparés mais lors de la mise à jour vers 4.x, ils détectent automatiquement cela et fonctionnent toujours. Assurez-vous que le développeur le confirme.
#* L'extension a des packages séparés qui doivent être désinstallés dans 3.10.x et ensuite installés avec la version de Joomla 4.x une fois que le site est migré. Un exemple de ceci pourrait être un plugin de contenu. Il est très simple de le désinstaller en 3.10.x puis de le réinstaller en 4.x.
#* Voir [[S:MyLanguage/Template_Considerations_During_Migration|Considérations sur les templates]] pour des informations plus spécifiques sur les templates et [[S:MyLanguage/J3.x:Converting_A_Previous_Joomla!_Version_Template|Conversion d'un template précédent de version de Joomla ! ]].

==== Notes sur la recherche (com_search) ====
Search (com_search) sera séparé de Joomla 4.x. La recherche (com_search) migrera vers Joomla 4. Après la migration, vous devrez le mettre à jour vers la version de Joomla 4.x via com_installer. Il continuera à être maintenu, mais plus de la même manière qu'une extension tierce en recevant des mises à jour via com_installer. Il est recommandé d'utiliserla Recherche avancée (com_finder) à l'avenir. La recherche sera toujours disponible à l'adresse https://extensions.joomla.org/category/official-extensions/ .

==== Notes sur les liens web ====
Les liens Web ont été dissociés dans la version 3.4 de Joomla. S'il était utilisé sur un site 2.5, le processus de migration en prendrait note et migrerait le composant liens web et ses données. Pour la migration de 3.10.x à 4.x, il en sera de même. Il est toujours disponible et maintenu sur le JED à l'adresse [https://extensions.joomla.org/category/official-extensions/ Official Extensions].

==== Notes sur l'ancien routage d'URL ====
L'ancien routage ne sera pas disponible dans Joomla 4.x. Seul le routage moderne sera disponible. Lorsque vous effectuez la migration, si vous utilisez le routage héritage, le système le changera automatiquement en routage moderne. Vous devrez exécuter un vérificateur de liens brisés sur votre site après la migration vers Joomla 4.x et "avant de mettre en ligne".

=== Passage à Joomla ! 4.x ===
Une fois que vous avez mis à jour ou désinstallé vos extensions tierces pour que seules celles compatibles avec Joomla ! 4 restent dans votre installation, continuez avec les étapes suivantes :
# Allez dans {{rarr|Système,Configuration,onglet Serveur}} et faites passer le rapport d'erreur de de Défaut à Maximum. Veillez enregistrer et fermer.{{-}} [[File:J310-system-global-config-server-tab-en.png|border|500px]]
# Faites une autre sauvegarde.
# Allez sur {{rarr|Composants, mise à jour de Joomla}}. (Il devrait être indiqué qu'aucune mise à jour n'a été trouvée. Si ce n'est pas le cas, mettez à jour Joomla à la dernière version et testez. Puis faites une autre sauvegarde). Cliquez sur le bouton Options dans le coin supérieur droit.
# Sélectionnez 'Joomla Next'' dans la liste déroulante pour le serveur de mise à jour.{{-}}[[File:J310-component-joomla-update-select-support-en.png|border|500px]]
# Cliquez sur Enregistrer et fermer.
# Vous verrez alors votre version installée de Joomla, la dernière version de Joomla ! et l'URL du paquet de mise à jour. Joomla vous montrera à nouveau la configuration requise pour Joomla 4. S'il signale que vous avez un système ou des extensions incompatibles, il vous le dira ici. Prenez un moment pour revoir cette page{{-}}[[File:J310-to-j4-dev-update-found-en.png|border|800px]]
# Si la mise à jour ne s'affiche pas, allez dans {{rarr|Gestionnaire d'extension,Mise à jour}} et cliquez sur Purge du Cache dans la barre d'outils. La mise à jour vers Joomla ! 4 devrait maintenant s'afficher.
# Croisez les doigts, et assurez-vous d'avoir cette sauvegarde disponible au cas où.
# Cliquez sur le bouton Installer la mise à jour.
# Faites du thé pendant que la barre d'état passe au vert. Le temps que cela prend dépend de votre site, de votre connexion Internet et de la vitesse du serveur. Le processus prend environ deux minutes. Lorsque la mise à jour est terminée, vous serez probablement déconnecté de l'administrateur. Reconnectez-vous. Deux fois.
# Si tout se passe bien, vous obtiendrez un tout nouveau look pour le panneau de l'administrateur du backend.{{-}}[[File:j4-administrator-overview-en.png|border|800px]]
# Allez dans {{rarr|Système,Maintenance,Base de données}} et cliquez sur ''Réparer'' si des erreurs apparaissent.
# Dans {{rarr|Système,Installation,Découvrir}} voyez s'il y a des extensions à installer. (Il ne devrait pas y en avoir !)
# Allez à l'interface de votre site et voyez s'il s'affiche même si ce n'est pas le bon template. Si oui, continuez. Si non, voir [[S:MyLanguage/Joomla 3.10 to 4.x Common Migration Errors|les erreurs fréquentes lors d'une migration]].
# Faites une sauvegarde.
# Installez votre nouveau template ou d'autres extensions si vous en avez à installer. Sauvegardez souvent.
# Configurez-les. Sauvegardez souvent.
# Exécutez un vérificateur de liens brisés et réparez tous les liens brisés.
# Testez tout. Sauvegardez souvent.
# Si tout fonctionne comme prévu, remettez le rapport d'erreur sur le système par défaut ({{rarr|Système,Configuration globale,onglet Système de configuration}}). Veillez à enregistrer et à fermer.

=== Mise en service de votre site Joomla ! 4.x ===
# Lorsque vous êtes prêt à mettre en ligne, sauvegardez votre site 3.10 pour la dernière fois. Restaurez-le dans un sous-répertoire ou un sous-domaine si vous le souhaitez.
# Sauvegardez votre site Joomla ! 4.x et déplacez ou restaurez votre site Joomla ! 4.x à la racine (ou changez les serveurs de noms si vous construisiez sur un domaine temporaire à la racine d'un nouveau compte d'hébergement).
# Testez à nouveau.
# Si vous aviez apporté des modifications de sécurité au fichier .htaccess, vous aurez peut-être à modifier une ou plusieurs lignes pour passer à la prochaine version de Joomla 4. Veuillez consulter [[S:MyLanguage/Htaccess_changes_after_joomla4.0.4| Modifications du htaccess après Joomla 4.0.4]] pour déterminer si vous devez modifier votre fichier ou non.
# Retirez le site Joomla ! 3.10 du serveur dans les deux jours qui suivent, sauf si vous avez modifié votre fichier ''robots.txt'' pour bloquer les robots des moteurs de recherche.
# Supprimez tous les sites de développement sur lesquels vous avez travaillé ou mettez-les à jour s'ils utilisent une version actuelle afin d'éviter toute tentative de piratage de votre serveur.

Si des données ont été modifiées sur le site 3.10 pendant la migration vers la version 4.x, vous devrez les transférer sur le site 4.x avant la mise en ligne. Vous pouvez le faire manuellement (assurez-vous de conserver les mêmes identifiants d'utilisateur - allez-y dans l'ordre) ou en utilisant une [https://extensions.joomla.org/category/migration-a-conversion/data-import-a-export%20transfer%20tool/third-party%20extension/ extension tierce].

== Outils suggérés ==
* [http://extensions.joomla.org/extensions/access-a-security/site-security/backup/1606 Akeeba Backup] est très populaire pour la sauvegarde et la restauration. Voir d'autres [https://extensions.joomla.org/tags/backup/ outils de sauvegarde].
==Informations connexes==
[[Special:MyLanguage/:Pre-Update_Check|Vérification préalable à la mise à jour]]
<noinclude>
[[Category:Migration/fr|Migration]]
[[Category:Tutorials/fr|Tutoriels]]
[[Category:Joomla! 4.x/fr{{#translation:}}]]</noinclude>

2022-09-01T15:57:56Z

Joomla 4.x : la correspondance automatique du namespace va échouer si un nom de fichier tel que <tt>manifest.xml</tt> est utilisé. Voir https://github.com/joomla/joomla-cms/issues/37750

Manifest files/fr

2022-09-01T12:10:53Z

Lorangerart:

<noinclude><languages /></noinclude>
<noinclude>
{{Joomla version|version=4.x}} {{Joomla version|version=3.x}} {{Joomla version|version=2.5|status=eos}}
</noinclude>
Avec Joomla, toutes les extensions proposent des fichiers manifestes. Ces fichiers recouvrent les informations générales concernant l'installation, ainsi que des paramètres pour la configuration de l'[[S:MyLanguage/extension|extension]] elle-même. Depuis Joomla! 2.5, il existe très peu de différences entre les différents formats de fichiers manifestes en fonction des différents [[S:MyLanguage/Extension types (technical definitions)|types d'extensions]] permettant ainsi à chaque type de bénéficier de la puissance de l'installateur Joomla.

==Conventions de nommage==
Le fichier doit être nommé <tt>manifest.xml</tt> (pour les versions de Joomlaǃ 2.5 et 3) ou <tt><extension_name>.xml</tt> (pour les versions de Joomlaǃ 2.5, 3 et 4) et situé dans le répertoire racine du package d'installation.

Joomla 4.x: Automatic namespace mapping will fail if a manifest file named <tt>manifest.xml</tt> is used. See: https://github.com/joomla/joomla-cms/issues/37750

==Syntaxe==

===Élément à la racine===
{{notice|The new tag <code><extension></code> replaces the old <code><install></install></code> from Joomla {{JVer|1.5}}}}

Le tag principal du fichier d'installation est :
<source lang=xml><extension></extension></source>

<div class="mw-translate-fuzzy">
La balise ouvrante et fermante est maintenant valable pour toutes les extensions. La nouvelle balise <code><extension></code> remplace les anciennes <code><install></install></code> depuis Joomla! {{JVer|1.5}}. Les attributs suivants sont autorisés à l'intérieur de la balise :
</div>

{|class="wikitable"
|-
! style="width: 150px" | Attribut || style="width: 150px" | Valeurs || Applicable à || Description
|-
| type || <code>component</code><br /><code>file</code><br /><code>language</code><br /><code>library</code><br /><code>module</code><br /><code>package</code><br /><code>plugin</code><br /><code>template</code><br/><code>element</code> || Toutes les extensions
| Cet attribut décrit à l'installateur le type de l'extension. En fonction de ce type, d'autres d'exigences supplémentaires s'appliqueront aux sous-balises.
|-
| version
| <code>2.5</code><br /><code>3.0</code> || Toutes les extensions
| <div class="mw-translate-fuzzy">
Chaîne de caractères qui identifie la version de Joomla! pour laquelle cette extension est développée.
</div>
|-
| method
| <code>install</code><br /><code>upgrade</code> || Toutes les extensions
| La valeur par défaut <code>install</code> sera également utilisée si l'attribut <tt>method</tt> n'est pas utilisé. La valeur <code>install</code> signifie que l'installateur va s'arrêter s'il trouve un fichier/dossier de la nouvelle extension.
|-
| client
| <code>site</code><br /><code>administrator</code> || Modules
| L'attribut <tt>client</tt> permet de préciser pour quel type de client d'application le nouveau module est disponible.
|-
| group
| ''string'' || Plugins
| Le nom du groupe indique pour quels groupes de plugins le nouveau plugin est disponible. Les groupes existants sont les noms de dossier du répertoire <tt>/plugins</tt>. Le programme d'installation va créer de nouveaux noms de dossier pour les noms de groupe qui n'existent pas encore.
|}

===Métadonnées===

Les éléments suivants peuvent être utilisés pour insérer des métadonnées. Aucun de ces éléments n'est obligatoire et s'ils sont présents, ils doivent être un enfant de l'élément racine.

<pre>
<name> – raw component name (e.g. com_banners).
<author> – author's name (e.g. Joomla! Project)
<creationDate> – date of creation or release (e.g. April 2006)
<copyright> – a copyright statement (e.g. (C) 2005 - 2011 Open Source Matters. All rights reserved.)
<license> – a license statement (e.g. NU General Public License version 2 or later; see LICENSE.txt)
<authorEmail> – author's email address (e.g. admin@joomla.org)
<authorUrl> – URL to the author's website (e.g. www.joomla.org)
<version> – the version number of the extension (e.g. 1.6.0)
<description> – the description of the component. This is a translatable field. (e.g. COM_BANNERS_XML_DESCRIPTION)
<element> – the internal name of the component. If omitted, name will be cleaned and used
</pre>

Remarque : les balises <name> et <description> sont des champs traduisibles de sorte que le nom et la description de l'extension pourront être présents dans la langue maternelle de l'utilisateur.

=== Fichiers de frontend ===

<source lang="xml">
<files folder="from-folder">
<filename>example.php</filename>
<folder>examples</folder>
</files>
</source>

Les fichiers à copier dans le répertoire de frontend doivent être placés dans les balises <code><files></code>. Vous pouvez utiliser l'attribut <code>folder</code> en option pour spécifier un répertoire '''du package ZIP'''. Chaque fichier à copier doit être nommé par l'élément <code><filename></code>. Si vous souhaitez copier un dossier entier à la fois, vous pouvez le définir comme un <code><folder></code>.

Pour les '''plugins''', le nom brut du plugin doit être placé dans l'attribut <code>plugin</code> de l'élément <code><filename></code> qui pointe vers le fichier contenant la classe du plugin. Par exemple, dans le cas d'un système de plugin appelé "exemple" (nom complet : <code>plg_system_exemple</code>), il faudra utiliser <code><filename plugin="exemple">exemple.php</filename></code>.

===Fichiers multimédias===

<source lang="xml>
<media folder="media" destination="com_example">
<filename>com_example_logo.png</filename>
<folder>css</folder>
<folder>js</folder>
</media>
</source>

Cet exemple permet de copier le fichier (<tt>/media/com_example_logo.png</tt>) et les dossiers ( <tt>/media/css/</tt> et <tt>/media/js/</tt> ) listés vers <tt>/media/com_example/</tt>, ainsi que la création du dossier <tt>com_example</tt> si nécessaire. Vous pouvez utiliser en option l'attribut <code>folder</code> pour spécifier un répertoire '''dans le package ZIP''' à partir duquel réaliser la (dans ce cas, <tt>media</tt>).

Les extensions doivent stocker les éléments, dont elles ont besoin pour être accessible sur le web (JS, CSS, images, etc), dans <code>media</code>. Cette fonctionnalité a été ajoutée dans le cadre du projet de développement d'une interface multi-site et du placement éventuel de fichiers de code (PHP) en dehors des espaces web serveurs accessibles.<br />Remarque: la section médias n'est pas analysé pour les extensions de type 'package'.

Ref:
* [https://groups.google.com/forum/#!msg/joomla-dev-cms/4CAASJqFY-k/PvPj14gP29EJ Google Groups - joomla-dev-cms thread]
* [https://groups.google.com/forum/#!msg/joomla-dev-cms/uNmhX98sKbE/p8p68Jke680J Google Groups - joomla-dev-cms thread]

===Section de l'administration===

<source lang="xml">
<administration>

</administration>
</source>

La section d'administration est définie par l'élément <code><administration></code>. Puisque seuls les [[S:MyLanguage/Component|composants]] concernent à la fois l'espace [[S:MyLanguage/Site (Application)|site]] et celui d'[[S:MyLanguage/Administrator (Application)|administration]], '''seuls les manifests pour composants doivent intégrer ces éléments'''.

<div class="mw-translate-fuzzy">
====Fichiers de backend====
</div>

Les fichiers à copier dans le répertoire de backend doivent être placés dans l'élément <code><files></code> sous <code><administration></code>. Vous pouvez utiliser l'attribut optionnel <code>folder</code> pour spécifier un répertoire à copier depuis le '''pack ZIP'''. Voir les ''fichiers frontend'' pour plus d'informations.

<div class="mw-translate-fuzzy">
====Liens de Menu et sous-menus====
</div>
{{dablink|'''Note de version :''' avant Joomla! 3.4, le fait de ne pas avoir de balise <code><nowiki><menu></nowiki></code> dans votre fichier XML avait pour conséquence l création d'un élément de menu. Cette anomalie a été corrigée dans Joomla! 3.4 et ainsi, si aucune balise <code><nowiki><menu></nowiki></code> n'est présente dans votre fichier manifest, aucun menu d'administration ne sera créé pour le composant.}}

<source lang="xml">
<menu>COM_EXAMPLE</menu>
<submenu>

<menu link="anoption=avalue&anoption1=avalue1">COM_EXAMPLE_SUBMENU_ANOPTION</menu>
<menu view="viewname">COM_EXAMPLE_SUBMENU_VIEWNAME</menu>
</submenu>
</source>

Le texte pour l'élément du menu principal pour le composant est défini dans la balise <code><menu></code>, enfant de de la balise <code><administration></code>. Une balise <code><submenu></code> peut être présente (également comme enfant de <code><administration></code>), qui pourra contenir d'autres éléments de menu définis par <code><menu></code>.

En outre, chaque élément <code><menu></code> permet de définir les attributs suivants :

{| class="wikitable"
! style="width: 150px" | Attribut || Description
|-
| link || Un lien vers lequel renvoyer l'utilisateur lorsque l'élément de menu est cliqué. Vous pouvez utiliser "view" à la place.
|-
| img || Le chemin (relatif) à une image (16x16 pixels) qui apparait à côté de l'élément de menu.
<u>Doit être url compatible (par exemple sans espaces).</u>
|-
| alt ||
|-
| view || Un paramètre URL à ajouter au lien. Par exemple, <code><menu view="cpanel">COM_EXAMPLE</menu></code> dans le manifest XML com_example générerait l'URL de l'élément de menu <tt>index.php?option=com_example&view=cpanel</tt>. Vous pouvez utiliser "link" à la place.
|-
|}

La valeur à l'intérieur de la balise est le nom du menu. À La différence de ce qui se faisait pour Joomla! 1.5, vous ne pouvez pas utiliser une chaîne de caractère dans votre langue naturelle. Par exemple, si vous renseignez "Composant d'exemple" au lieu de COM_EXAMPLE, votre nom de composant qui s'afficherait en titre serait "composant-d-exemple" et vous seriez dans l'impossibilité de le traduire. Pour réaliser une traduction, vous devez créer un fichier nommé <tt>fr-FR.com_example.sys.ini</tt> '''(NDT : avant de pouvoir créer le fichier fr-FR, il convient de créer le fichier d'origine en-GB)''' dans <tt>administrator/languages/fr-FR</tt> (vous pouvez utiliser la balise manifest <code><languages></code> pour qu'il soit copié lors de l'installation) ou dans <tt>administrator/components/com_example/language/fr-FR</tt>. Dans ce dernier cas, vous ne devez pas inclure le fichier de traduction dans la balise <code><languages></code> balise. Tant que vous aurez placé le répertoire de langue dans vos balises <code><files></code>, il sera copié lors de l'installation du composant.

Le contenu de ce fichier devrait être :

<source lang="ini">
COM_EXAMPLE="Example Component"
COM_EXAMPLE_SUBMENU_ANOPTION="Another Option"
COM_EXAMPLE_SUBMENU_VIEWNAME="Another View"
</source>

Please note that the language string must be enclosed in double quotes, as per Joomla!'s translation standards.

{{note|Joomla! 1.6 and later sorts the Component menu items based on the actual translation of the key you supply in your XML manifest. This means that the sorting order is correct no matter what you call your translation key and no matter which language the site is being displayed in. Essentially, Joomla! 1.6 fixed the wrong sorting of the Components menu experienced under Joomla! 1.5 for the majority (non-English speaking!) of Joomla! users.}}

=== Dashboards ===
{{notice|This code only works in {{JVer|4.0}} and later}}

Specifies the details for displaying a dashboard for the component in the Administrator area for the site.
* It will make a dashboard icon appear next to the administrator menu item for the component
* The dashboard icon will click through to display modules assigned to the cpanel-example administrator module position
* The title and icon defined in the XML file will be used as the header and icon at the top of the component's dashboard page.

<source lang="xml">
<dashboards>
<dashboard title="COM_EXAMPLE_DASHBOARD_TITLE" icon="icon-lock">example</dashboard>
</dashboards>
</source>

===Configuration===
{{warning|<div class="mw-translate-fuzzy">
Les composants '''ne prennent pas en charge''' les définitions de configuration '''dans le manifeste'''. Ceci avait été mis en œuvre dans Joomla! 1.5. Ils est possible de définir les options de configuration pour différents niveaux à l'aide des [[S:MyLanguage/Component configuration metadata|métadonnées de configuration de composant]].
</div>}}
<div class="mw-translate-fuzzy">
La balise <code><config></code>, enfant de la racine, décrit les options de configuration de l'extension. En cas de besoin, les options seront affichées par le gestionnaire concerné (gestionnaire de plugins, gestionnaire de modules ou gestionnaire de templates). '''Les options de configuration peuvent également être définies dans un fichier séparé nommé <code>config.xml</code>. Son élément racine doit être <code><config></code>.'''
</div>

Chaque groupe de champs <code><fieldset></code> peut contenir un ou plusieurs éléments <code><field></code> (champ), chacun représentant un seul [[S:MyLanguage/form field|champ de formulaire]] avec une étiquette. Consultez les [[S:MyLanguage/Standard form field types|types de champs pour formulaires standards]] pour une liste des types de champs autorisés et un exemple de définitions de champs de formulaire XML.

=== Namespace ===
{{notice|This code only works in {{JVer|4.0}} and later}}

Specify the namespace to be used for autoloading the plugin. The given namespace will autoload to the root directory of your extension by default however you can optionally add a "path" attribute to the namespace element to specify a subpath within your extensions root directory.

===SQL===

<source lang="xml">
<install>
<sql>
<file driver="mysql" charset="utf8">sql/example.install.sql</file>
</sql>
</install>
<uninstall>
<sql>
<file driver="mysql" charset="utf8">sql/example.uninstall.sql</file>
</sql>
</uninstall>
</source>

Dans l'exemple ci-dessus, nous avons placé les fichiers SQL dans le répertoire <tt>admin/sql</tt> du paquet d'installation. Vous devez inclure le dossier <tt>sql</tt> dans les fichiers d'administration (tel que décrit dans "les fichiers backend").

Vous pouvez exécuter SQL lors de l'installation et/ou la désinstallation à l'aide des éléments <code><install></code> et <code><uninstall></code>. Une balise <code><sql></code> doit apparaître comme un enfant de ces éléments. <code><sql></code> peut contenir n'importe quel nombre d'éléments <code><file></code>, chacun devant définir un seul fichier SQL à exécuter. Leurs types de pilote de base de données sont décrits par l'attribut <code>driver</code>, leurs jeux de caractères par l'attribut <code>charset</code>.

<div class="mw-translate-fuzzy">
==== Mise à jour du schéma SQL====
</div>

Depuis la version 1.6, une balise <code><update></code> est disponible et vous permet de fournir une série de fichiers SQL pour mettre à jour le schéma actuel.

<source lang="xml">
<update>
<schemas>
<schemapath type="mysql">sql/updates/mysql</schemapath>
<schemapath type="sqlsrv">sql/updates/sqlsrv</schemapath>
</schemas>
</update>
</source>

Par exemple, pour passer de la version <code>1.0.0</code> à la version <code>1.0.1</code> dans une base de données '''MySQL''', un fichier <code>1.0.1.sql</code> doit être créé dans le dossier <code>sql/updates/mysql</code> et la balise <code><version></code> du manifest doit être mis à jour :
<source lang="xml">
<version>1.0.1</version></source>

La structure finale du dossier sql ressemblera à ceci (dans l'hypothèse d'une base de données '''MySQL''')
<source lang="xml">
sql
|-->example.install.sql
|-->example.uninstall.sql
|-->updates
|-->mysql
|-->1.0.1.sql</source>

Des fichiers similaires doivent être créés pour les versions suivantes.

<div class="mw-translate-fuzzy">
===Fichiers langue===
</div>
<div class="mw-translate-fuzzy">
Dans Joomla! 1.5, les développeurs d'extensions devaient placer les fichiers de langue dans le dossier général des langues de Joomla! à l'aide des balises <languages>...</languages> comme indiqué ci-dessous. '''Cette méthode peut toujours être utilisée avec la version''' {{JVer|3.x}}.
</div>

<source lang="xml">

<languages folder="langfiles">
<language tag="en-GB">en-GB.com_example.ini</language>
</languages>
</source>

<div class="mw-translate-fuzzy">
Depuis Joomla! 1.6, il vous est conseillé de placer les fichiers langue de votre extension dans le dossier même de votre extension. Joomla! chargera alors automatiquement les fichiers de langue depuis votre extension.
</div>

En plaçant les fichiers de langue dans le dossier de l'extension, vous permettez ainsi de les isoler et donc de les protéger. Par exemple, dans le cas ou un administrateur supprimerait une langue de son installation Joomlaǃ. Dans ce cas, les fichiers de langue de l'extension ne seront pas supprimés. Ils resteront alors en place et ne seront accessibles que si la langue est installée à nouveau.

La structure du dossier de langue pour le frontend et le backend est identique. Il convient de les placer dans la balise <code><languages></code> (par exemple '''en-GB''') pour chaque langue et dans le dossier comme suit : '''language/en-GB/'''. Vous devez aussi spécifier ces dossiers pour le frontend et le backend.

Dans votre manifest, il suffit simplement d'inclure votre dossier <tt><language></tt> dans la section fichiers. Les sous-répertoires pour chaque langue seront alors automatiquement copiés. À l'intérieur des groupes <code><files></code>, il vous suffit d'ajouter une balise <code><folder></code> à côté des éléments dans le groupe <tt><files></tt>, comme indiqué dans cet exemple :

<source lang="xml">
<files>
<filename plugin="alpha">alpha.php</filename>
<folder>sql</folder>
<folder>language</folder>
</files>
</source>

Notez que les deux techniques peuvent fonctionner ensemble. Voici un exemple du noyau :

<source lang="xml">
<files>
<filename plugin="languagecode">languagecode.php</filename>
<filename>index.html</filename>
<folder>language</folder>
</files>
<languages>
<language tag="en-GB">language/en-GB/en-GB.plg_system_languagecode.ini</language>
<language tag="en-GB">language/en-GB/en-GB.plg_system_languagecode.sys.ini</language>
</languages>
</source>

Les avantages pour cette solution sont les suivants :

Tous les fichiers ''.ini'' présents dans le dossier du noyau ont la priorité sur les fichiers dans les dossiers langue des extensions.
Par exemple, s'il existe, un fichier <tt>sys.ini</tt> d'un dossier du noyau sera toujours chargé dans le backend, sauf lors de l'installation d'une extension qui contient son propre fichier <tt>sys.ini</tt> dans un dossier de langue. Dans ce cas et uniquement ce cas, le fichier <tt>sys.ini</tt> dans le dossier de l'extension affichera son contenu traduit au moment de l'installation. C'est très pratique car un développeur peut avoir deux fichiers <tt>sys.ini</tt> avec un contenu différent.

Il est également beaucoup plus facile pour un utilisateur ayant besoin de trouver le fichier <tt>.ini</tt> d'une extension qui n'est pas disponible dans sa langue de l'ajouter dans le dossier principal. Il n'y a aucun risque qu'il ne soit supprimé en cas de désinstallation par erreur de l'extension.

Veuillez consulter également :
*[[S:MyLanguage/J2.5:Making non-core language packs|Créer un pack langue hors du noyau]]
*[[S:MyLanguage/Creating language packs for extensions in Joomla 2.5|Créer un pack langue pour une extension Joomla! 2.5]]

Au cours du développement, vous pouvez activer le système de débogage de langue dans la configuration globale de Joomlaǃ. Vous pourrez découvrir si un problème est levé. Depuis {{JVer|3.2}}, cela est nécessaire afin d'aider à déboguer le en-GB qui est '''toujours''' chargé en premier lorsque l'on est pas en mode de débogage et ainsi empêcher l'affichage des constantes.

===Fichier de script===

<source lang="xml">
<scriptfile>example.script.php</scriptfile>
</source>

<div class="mw-translate-fuzzy">
Un '''fichier de script''' (code PHP qui est exécuté avant, pendant et/ou après l'installation, la désinstallation ou la mise à jour) peut, en option, être défini à l'aide d'une balise <code><scriptfile></code>. Ce fichier doit contenir une classe nommée '<tt><element_name>InstallerScript''</tt> où <tt><element_name></tt> est le nom de votre extension (par exemple : com_nomducomposant, mod_nomdumodule, etc.). Pour les plugins, il convient de nommer également le groupe (par exemple : plgsystemnomduplugin). Les packages de bibliothèque ne prennent pas en charge les fichiers scripts. La structure de la classe sera comme suit :
</div>

This file should contain a class named "<element_name>InstallerScript" where <element_name> is the name of your extension (e.g. com_componentname, mod_modulename, etc.). Plugins must state the group (e.g. plgsystempluginname).

In {{JVer|4.0}} and later the structure of the class is as follows:

<source lang="php">

<?php

use Joomla\CMS\Installer\InstallerAdapter;

class com_componentnameInstallerScript
{
/**
* Constructor
*
* @param InstallerAdapter $adapter The object responsible for running this script
*/
public function __construct(InstallerAdapter $adapter)
{
}

/**
* Called before any type of action
*
* @param string $route Which action is happening (install|uninstall|discover_install|update)
* @param InstallerAdapter $adapter The object responsible for running this script
*
* @return boolean True on success
*/
public function preflight($route, InstallerAdapter $adapter)
{
return true;
}

/**
* Called after any type of action
*
* @param string $route Which action is happening (install|uninstall|discover_install|update)
* @param InstallerAdapter $adapter The object responsible for running this script
*
* @return boolean True on success
*/
public function postflight($route, $adapter)
{
return true;
}

/**
* Called on installation
*
* @param InstallerAdapter $adapter The object responsible for running this script
*
* @return boolean True on success
*/
public function install(InstallerAdapter $adapter)
{
return true;
}

/**
* Called on update
*
* @param InstallerAdapter $adapter The object responsible for running this script
*
* @return boolean True on success
*/
public function update(InstallerAdapter $adapter)
{
return true;
}

/**
* Called on uninstallation
*
* @param InstallerAdapter $adapter The object responsible for running this script
*/
public function uninstall(InstallerAdapter $adapter)
{
return true;
}
}

?>
</source>

Note that since Joomla 3.6 Joomla has shipped a basic script that you can use instead of shipping your own from scratch '''JInstallerScript''' which contains various helper methods commonly used through the community.

=== Library Manifests ===
{{notice|The section is based on {{JVer|4.0}} and later}}

A simple library manifest might look like this:
<source lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<extension type="library" method="upgrade" version="4.0">
<name>My Test library.</name>
<libraryname>mytest</libraryname>
<files>
<folder>Classes</folder>
<folder>language</folder>
<filename>mytest.php</filename>
</files>
</extension></source>

This will install the library into the <tt>JPATH_SITE/libraries/mytest</tt> folder.

What if your company has several libraries and you want to group them together under folder <tt>JPATH_SITE/libraries/mycompany</tt>?

Simple - include your company name in the <tt>libraryname</tt> property of each library like this:

<source lang="xml">
<libraryname>mycompany/mylibrary1</libraryname>
</source>

<source lang="xml">
<libraryname>mycompany/mylibrary2</libraryname>
</source>

These libraries will then be installed in the <tt>JPATH_SITE/libraries/mycompany/mylibrary1</tt> and <tt>JPATH_SITE/libraries/mycompany/mylibrary2</tt> folders.

Uninstalling <tt>mylibrary1</tt> will still leave <tt>mylibrary2</tt> installed on your site.

When using <tt>script files</tt> with such company libraries the installer class name should look like this:
<source lang="php">
class mycompanymylibrary1InstallerScript
</source>
<source lang="php">
class mycompanymylibrary2InstallerScript
</source>

<div class="mw-translate-fuzzy">
=== Serveurs de mise à jour ===
</div>

<source lang="xml">
<updateservers>
<server type="extension" priority="1" name="Extension Update Site">http://example.com/extension.xml</server>
<server type="collection" priority="2" name="Collection Update Site">http://example.com/collection.xml</server>
</updateservers>
</source>

Les serveurs de mise à jour peuvent être définis dans les balises <code><updateservers></code> comme enfant de la racine. Cet élément peut contenir une ou plusieurs balises <code><server></code> chacune avec la description depuis laquelle chercher les mises à jour. Chaque rubrique <code><server></code> permet de définir les attributs suivants :

{| class="wikitable"
! style="width: 150px" | Attribut || style="width: 150px" | Valeurs || Description
|-
| type || <code>extension</code><br /><code>collection</code> || Le type de serveur de mise à jour.
|-
| priority || ''integer'' || La priorité du serveur de mise à jour.
|-
| name || ''string'' || Le nom du serveur de mise à jour.
|}

<div class="mw-translate-fuzzy">
Pour plus d'informations :
* [[S:MyLanguage/J2.5:Developing a MVC Component/Adding an update server|Création d'une extension Joomla! - Ajout d'un serveur de mise à jour]]
* [[S:MyLanguage/J2.5:Managing Component Updates|Gestion des mises à jour de composants pour Joomla! 2.5]]
</div>

=== Supporting Download Keys ===

As of Joomla 4.0.0 users can enter their download keys in the Update Sites list. This gives them a single place to manage the download keys. When a user is going to update an extension, Joomla will check if there is a download key. If there is a download key, Joomla will add the download key to the update URL.

To support download keys you must include the <tt>dlid</tt> tag in the manifest file. The <tt>dlid</tt> tag takes 2 arguments:
* prefix
* suffix

The <tt>dlid</tt> tag will look like this in your manifest file:
<source lang="xml">
<dlid prefix="dlid=" suffix="&dummy=my.zip"/>
</source>

The prefix will be added before the download key and the suffix after the download key. Using the example above the full query added to the download link will be:
<source lang="php">
dlid=KEY&dummy=my.zip
</source>

The key is added before the <tt>onInstallerBeforePackageDownload</tt> event is triggered, so the full URL will be passed to the event.

===Exemples===
<div class="mw-translate-fuzzy">
== Exemples ==
Pour un exemple concret, veuillez consulter [https://github.com/joomla/joomla-cms/blob/3.6.4/administrator/components/com_banners/banners.xml le manifest pour le composant bannière de la version Joomla! 3.6.4].
</div>

D'autres exemples peuvent être trouvés dans le répertoire autonome des liens web :

<div class="mw-translate-fuzzy">
* [https://github.com/joomla-extensions/weblinks/blob/master/src/administrator/components/com_weblinks/weblinks.xml manifest com_weblinks]
* [https://github.com/joomla-extensions/weblinks/blob/master/src/modules/mod_weblinks/mod_weblinks.xml manifest mod_weblinks]
* [https://github.com/joomla-extensions/weblinks/blob/master/src/plugins/search/weblinks/weblinks.xml manifest plg_search_weblinks]
* [https://github.com/joomla/joomla-cms/blob/3.6.4/templates/protostar/templateDetails.xml manifest tpl_protostar (3.6.4)]
* [https://github.com/joomla/joomla-cms/blob/3.6.4/administrator/language/en-GB/en-GB.xml manifest en-GB (3.6.4)]
</div>

<noinclude>
[[Category:Development{{#translation:}}]]
[[Category:Extension development{{#translation:}}]]
[[Category:Specifications{{#translation:}}]]
</noinclude>

Translations:Manifest files/88/fr

2022-09-01T12:10:52Z

Lorangerart:

Le fichier doit être nommé <tt>manifest.xml</tt> (pour les versions de Joomlaǃ 2.5 et 3) ou <tt><extension_name>.xml</tt> (pour les versions de Joomlaǃ 2.5, 3 et 4) et situé dans le répertoire racine du package d'installation.

J4.x:Selecting data using JDatabase/fr

2022-02-25T12:56:44Z

Lorangerart:

Translations:J4.x:Selecting data using JDatabase/13/fr

2022-02-25T12:56:39Z

Lorangerart:

Pour obtenir une nouvelle instance de la classe \Joomla\Database\DatabaseQuery, nous utilisons la méthode \Joomla\Database\DatabaseDriver getQuery :