File manifest
From Joomla! Documentation
All'interno di Joomla ci sono dei file manifest per tutte le estensioni. Questi file includono le informazioni generali per l'installazione sotto forma di parametri per la configurazione dell'estensione. Rispetto a Joomla! 2.5, ci sono pochissime differenze tra i formati di file manifest per i diversi tipi di estensioni, permettendo ogni tipo di accedere a tutta la potenza del programma di installazione di Joomla!.
Naming conventions
The file must be named manifest.xml or <extension_name>.xml and located in the root directory of the installation package.
Sintassi
Root element
The new tag <extension> replaces the old <install></install> from Joomla 
The primary tag of the installation file is:
<extension></extension>Questo tag di apertura e di chiusura ora è valido per tutte le estensioni. Il nuovo tag <extension> sostituisce il vecchio <install></install> di Joomla . I seguenti attributi sono ammessi all'interno del tag:
| Attributo | Valori | Applicabili a | Descrizione |
|---|---|---|---|
| type | componentfilelanguagelibrarymodulepackageplugintemplateelement |
Tutte le estensioni | Questo attributo descrive il tipo di estensione per il programma di installazione. Alcuni sub-tag si basano su questo tipo. |
| version | 2.53.0 |
Tutte le estensioni | Stringa che identifica la versione di Joomla per il quale la presente estensione è stata sviluppata. |
| method | installupgrade |
Tutte le estensioni | Il valore predefinito install verrà utilizzato anche se il metodo di attributo non è utilizzato. Il valore install significa che il programma di installazione si interromperà se trova un qualsiasi file o cartella esistente della nuova estensione.
|
| client | siteadministrator |
Moduli | L'attributo client consente di specificare per quale applicazione client il nuovo modulo è disponibile. |
| group | string | Plugin | Il nome del gruppo specificare per quale gruppo di plugin il nuovo plugin è disponibile. I gruppi esistenti sono i nomi di cartella all'interno della directory /plugins. Il programma di installazione crea nuove cartelle per i nomi di gruppo che ancora non esistono. |
Metadati
I seguenti elementi possono essere utilizzati per inserire i metadati. Nessuno di questi elementi è necessario, se presenti, devono essere figli dell'elemento radice.
<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
Nota: I tag <name> e <description> sono campi traducibili così che il nome e la descrizione dell'estensione possano essere mostrati all'utente nella loro lingua madre.
Files del Front-end
<files folder="from-folder">
<filename>example.php</filename>
<folder>examples</folder>
</files>I file da copiare nella directory del front-end devono essere messi in un elemento <files>. È possibile utilizzare l'attributo facoltativo folder per specificare una directory "'nel pacchetto ZIP di" da cui copiare. Ogni file da copiare deve essere rappresentato da un elemento <filename>. Se si desidera copiare l'intera cartella in una sola volta, si può definire come <folder>.
Per plugins, il nome raw del plugin deve essere collocato in un attributo plugin del'elemento <filename> che punti al file contenente la classe del plugin. Per esempio, nel caso di un plugin system che si chiama "example" (nome completo plg_system_example), usare <filename plugin="example">example.php</filename>.
File multimediali
<media folder="media" destination="com_example">
<filename>com_example_logo.png</filename>
<folder>css</folder>
<folder>js</folder>
</media>Questo esempio copia il file (/media/com_example_logo.png) e le cartelle ( /media/css/ e /media/js/ ) elencate in /media/com_example/, creando la cartella com_example, se necessario. È possibile utilizzare l'attributo facoltativo cartella per specificare una directory nel pacchetto Zip da cui copiare (in questo caso, media).
Le estensioni devono contenere tutto ciò di cui hanno bisogno per essere accessibile via web (JS, CSS, immagini, ecc) in media. Tra le altre cose, questa funzionalità è stata aggiunta come un passo nella progressione verso il supporto al multi-sito e l'eventuale trasferimento di file di codice (PHP) al di fuori delle aree web accessibili al server.
Nota: la sezione media non viene analizzato per il 'pacchetto' di tipo 'package'.
Ref:
Amministrazione
<administration>
<!-- various elements -->
</administration>La sezione amministrazione è definita nell'elemento <administration>. Poiché solo Component si applicano sia al sito e amministratore, solo i manifest di componenti possono includere questo elemento.
Files di Back-end
I file da copiare nella directory del back-end directory debbono essere posti in un elemento <files> sotto il <administration>. È possibile utilizzare l'attributo facoltativo folder per specificare una directory nel pacchetto ZIP di da cui copiare. Vedere la parte sui "Files del Front-end" per ulteriori regole.
<menu> nel tuo file manifest XML portava comunque alla creazione di una voce di menu. Questo bug è stato risolto in Joomla 3.4, quindi, se nel file manfest non c'è il tag <menu> nessuna voce di menu verrà creata per il componente in amministrazione. <menu>COM_EXAMPLE</menu>
<submenu>
<!--
Note that all & must be escaped to & for the file to be valid
XML and be parsed by the installer
-->
<menu link="anoption=avalue&anoption1=avalue1">COM_EXAMPLE_SUBMENU_ANOPTION</menu>
<menu view="viewname">COM_EXAMPLE_SUBMENU_VIEWNAME</menu>
</submenu>Il testo per la voce di menu principale per il componente è definito nell'item <menu>, un figlio di <administration>. Può anche esserci un elemento <submenu> (anche un figlio di <administration>), che può contenere ulteriori voci di menu definiti tramite <menu>.
Inoltre, ogni elemento <menu> può definire i seguenti attributi:
| Attributo | Descrizione |
|---|---|
| link | Un link cui inviare l'utente quando la voce di menu viene cliccata |
| img | Il percorso (relativo) percorso di un'immagine (16x16 pixel) che appare accanto alla voce di menu.
Deve essere un url compatibile come un qualunque file (ad esempio, senza spazi) ! |
| alt | |
| view | Un parametro URL da aggiungere al link. Per esempio, |
Il valore all'interno del tag è l'etichetta di menu. A Differenza di Joomla! 1.5, è possibile non utilizzare una stringa di linguaggio naturale. Per esempio, se inserisci "Esempio Componente" invece di COM_EXAMPLE, il risultato finale sarebbe il nome del componente che appaiono come esempio-componente nel menu e potrebbe essere impossibile fornire una traduzione. Per fornire una traduzione, è necessario creare un file denominato en-GB.com_example.sys.ini in administrator/languages/en-GB (si può usare il tag <language> per copiarlo durante l'installazione) o in administrator/components/com_example/language/en-GB. In quest'ultimo caso, non è necessario includere il file di traduzione nel tag <lingue>. Se si è messa la directory della lingua nel tag <files>, essa verrà copiato durate l'installazione del componente.
Il contenuto di tale file deve essere:
COM_EXAMPLE="Example Component"
COM_EXAMPLE_SUBMENU_ANOPTION="Another Option"
COM_EXAMPLE_SUBMENU_VIEWNAME="Another View"Please note that the language string must be enclosed in double quotes, as per Joomla!'s translation standards.
Dashboards
This code only works in 
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.
<dashboards>
<dashboard title="COM_EXAMPLE_DASHBOARD_TITLE" icon="icon-lock">example</dashboard>
</dashboards>
Configuration
L'elemento <config>, un figlio di root, descrive le opzioni di configurazione per l'estensione. Se applicabile, le opzioni saranno mostrate da appositi Manager (Gestore di Plugin, Modulo di Manager o Gestore del Modello). Opzioni di configurazione può anche essere definito in un file separato denominato config.xml. Il suo elemento principale dovrebbe essere <config>.
Ogni fieldset deve contenere uno o più elementi <field>, ognuno dei quali rappresenta un singolo campo modulo con una etichetta. Vedi Tipi standard di campi modulo per un elenco dei tipi di campi modulo e di esempio di definizioni XML di campi modulo..
Namespace
This code only works in 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
<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>Nell'esempio di sopra, abbiamo messo il file SQL nella cartella admin/sql del pacchetto di installazione. È necessario includere la cartella sql nel file di amministrazione (come descritto in "Files di Back-end").
È possibile eseguire SQL durante l'installazione e/o disinstallazione utilizzando gli elementi <install> e <uninstall>, rispettivamente. Un elemento <sql> dovrebbe apparire come figlio di questi elementi. <sql> può contenere qualsiasi numero di elementi <file>, ognuno per definire un singolo file SQL da eseguire. I loro tipi di driver di database sono descritti mediante l'attributo driver, i loro set di caratteri dall'attributo charset.
Aggiornamento dello schema SQL
Da 1.6, c'è anche un tag <update>, che permette di fornire una serie di file SQL per aggiornare lo schema corrente.
<update>
<schemas>
<schemapath type="mysql">sql/updates/mysql</schemapath>
<schemapath type="sqlsrv">sql/updates/sqlsrv</schemapath>
</schemas>
</update>Per esempio, per andare dalla versione 1.0.0 alla versione 1.0.1 in un database "MySQL"', un file 1.0.1.sql deve essere creato all'interno della cartella di sql/updates/mysql e il tag <version> del manifest deve essere aggiornato
<version>1.0.1</version>
La struttura finale di sql cartella sarà simile a questa (supponendo un data base "MySQL")
sql
|-->example.install.sql
|-->example.uninstall.sql
|-->updates
|-->mysql
|-->1.0.1.sqlSimili files devono essere creati per le versioni successive.
File delle lingue
In Joomla! 1.5, gli sviluppatori di estensioni dovevano porre i files di lingua dell'estensione nella cartella principale di Joomla!, usando il tag <lingue>...</lingue> tag, come illustrato di seguito. "Questo metodo può ancora essere utilizzato in Joomla!"' 
.
<!-- Joomla! language tag -->
<languages folder="langfiles">
<language tag="en-GB">en-GB.com_example.ini</language>
</languages>Da Joomla! 1.6 è stato incoraggiato il posizionamento dei file di lingua nella cartella dell'estensione. Joomla! quindi caricherà automaticamente i file di lingua della tua estensione.
Memorizzando il file di lingua dell'estensione nella cartella dell'estensione, si guadagna il vantaggio di isolare e proteggere del file di lingua dell'estensione. Per esempio, un amministratore rimuove una lingua da loro Joomla! installazione. I file di lingua dell'estensione non verranno rimossi. Essi rimarranno lo stesso e saranno di nuovo disponibile se la lingua verrà installato di nuovo.
La struttura del cartella del linguaggio, per il frontend e il backend è la stessa. Li metti nel tag del linguaggio (ad esempio, ""en-GB"' ) di ogni lingua nella cartella della lingua, cioè "'language/en-GB/"'. È necessario specificare quelle cartelle anche nei files del front-end e del back-end dei file.
Nel manifesto è sufficiente includere la cartella "linguaggio"" nella sezione file, il sub-directory per ogni lingua saranno automaticamente copiati. All'interno del gruppo <files> è sufficiente aggiungere un elemento <folder> a fianco di elementi in "'<files>"' gruppo, come illustrato in questo esempio:
<files>
<filename plugin="alpha">alpha.php</filename>
<folder>sql</folder>
<folder>language</folder>
</files>È anche degno di nota che entrambi i modi possono lavorare insieme. Ecco un esempio dal core:
<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>I vantaggi di questa soluzione sono i seguenti:
Tutti i file ini presenti nella cartella core hanno la precedenza sui file di estensione del linguaggio/ cartella. Per esempio un file sys.ini sarà sempre caricato da cartelle core in back-end, se esiste, tranne quando l'installazione di un'estensione che contiene un sys.ini file in una cartella della lingua. In quel caso e solo in quel caso, il sys.file ini nella cartella di estensione verrà visualizzato il suo contenuto tradotto al momento dell'installazione. Questo è molto utile come sviluppatore può avere 2 files sys.ini con contenuti diversi. Descrizione di l'installazione di successo, come pure un tutorial in back-end, per esempio.
Inoltre, è molto più facile per un utente che necessita di un file ini per un'estensione che non prevede la lingua desiderata, aggiungerlo in cartelle principali. Nessun rischio di essere cancellati in caso di disinstallare l'estensione per errore o per qualsiasi altro motivo.
Vedi anche:
Durante lo sviluppo si può attivare la lingua di debug nella configurazione globale di Joomla!. Così si può capire se sorge un problema. Come già nella 3.2, questo è necessario per aiutare il debug così en-GB "e'sempre"' caricato per primo quando non è in modalità di debug per impedire la visualizzazione di Costanti.
File di Script
<scriptfile>example.script.php</scriptfile>Un file di script opzionale (codice PHP che viene eseguito prima, durante e/o dopo l'installazione, la disinstallazione e l'aggiornamento), può essere definito utilizzando un elemento <scriptfile>. Questo file deve contenere una classe denominata "<element_name>InstallerScript" dove <element_name> è il nome dell'estensione (ad esempio com_componentname, mod_modulename, etc.). I Plugin richiedono di indicare il gruppo (ad esempio, plgsystempluginname). I package di librerie non supportano scriptfiles. La struttura della classe è la seguente:
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 and later the structure of the class is as follows:
<?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;
}
}
?>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
The section is based on and later
A simple library manifest might look like this:
<?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>This will install the library into the JPATH_SITE/libraries/mytest folder.
What if your company has several libraries and you want to group them together under folder JPATH_SITE/libraries/mycompany?
Simple - include your company name in the libraryname property of each library like this:
<libraryname>mycompany/mylibrary1</libraryname> <libraryname>mycompany/mylibrary2</libraryname>These libraries will then be installed in the JPATH_SITE/libraries/mycompany/mylibrary1 and JPATH_SITE/libraries/mycompany/mylibrary2 folders.
Uninstalling mylibrary1 will still leave mylibrary2 installed on your site.
When using script files with such company libraries the installer class name should look like this:
class mycompanymylibrary1InstallerScriptclass mycompanymylibrary2InstallerScriptI server di aggiornamento
<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>Server di aggiornamento possono essere definiti nell'elemento <updateservers>, un figlio di root. Questo elemento può contenere uno o più elementi <server>, ciascuno descrivente una posizione da cui recuperare gli aggiornamenti. Ogni elemento <server> può definire i seguenti attributi:
| Attributo | Valori | Descrizione |
|---|---|---|
| type | extensioncollection |
Il tipo server di aggiornamento |
| priority | integer | La priorità del server di aggiornamento |
| name | string | Il nome del server di aggiornamento |
Ulteriori informazioni:
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 dlid tag in the manifest file. The dlid tag takes 2 arguments:
- prefix
- suffix
The dlid tag will look like this in your manifest file:
<dlid prefix="dlid=" suffix="&dummy=my.zip"/>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:
dlid=KEY&dummy=my.zipThe key is added before the onInstallerBeforePackageDownload event is triggered, so the full URL will be passed to the event.
Examples
For a real-life example, see the manifest of the Banner component in the latest version of Joomla! 3.9.16.
Il processo di test utilizza di Joomla! usa diverse estensioni per verificare se il programma funziona correttamente. Le ultime versioni dei file manifest di queste estensioni sono: