Actions

Difference between revisions of "Manifest files"

From Joomla! Documentation

(Add 2.5 and 3.x version tags)
m (Fixed layout)
 
(16 intermediate revisions by 8 users not shown)
Line 1: Line 1:
{{RightTOC}}{{version|2.5,3.x}}
+
{{version|2.5,3.x}}
==Introduction==
+
 
 
Within Joomla there are manifest files for all of the extensions. These files include the general installation information as well as parameters for the configuration of the [[extension]] itself. Since Joomla! 2.5 {{JVer|2.5}}, there are very few differences between the manifest file formats for the different [[Extension types (technical definitions)|types of extensions]], allowing each type to access the full power of the Joomla! installer.
 
Within Joomla there are manifest files for all of the extensions. These files include the general installation information as well as parameters for the configuration of the [[extension]] itself. Since Joomla! 2.5 {{JVer|2.5}}, there are very few differences between the manifest file formats for the different [[Extension types (technical definitions)|types of extensions]], allowing each type to access the full power of the Joomla! installer.
  
Line 44: Line 44:
  
 
<pre>
 
<pre>
<name> &ndash; raw component name (e.g. com_banners)
+
<name> &ndash; raw component name (e.g. com_banners).
 
<author> &ndash; author's name (e.g. Joomla! Project)
 
<author> &ndash; author's name (e.g. Joomla! Project)
 
<creationDate> &ndash; date of creation or release (e.g. April 2006)
 
<creationDate> &ndash; date of creation or release (e.g. April 2006)
Line 55: Line 55:
 
</pre>
 
</pre>
  
 
+
Note: The <name> and <description> tags are also translatable fields so that the name and description of the extension can be shown to the user in their native language.
  
 
=== Front-end files ===
 
=== Front-end files ===
Line 121: Line 121:
 
| img || The (relative) path to an image (16x16 pixels) to appear beside the menu item.  
 
| img || The (relative) path to an image (16x16 pixels) to appear beside the menu item.  
 
<u>Must be an url compatible as a file too (e.g. no spaces) !</u>
 
<u>Must be an url compatible as a file too (e.g. no spaces) !</u>
 +
|-
 
| alt ||
 
| alt ||
 
|-
 
|-
Line 127: Line 128:
 
|}
 
|}
  
The value inside the tag is the menu's label. Unlike Joomla! 1.5, you can not use a natural language string. For example, if you would enter "Example Component" instead of COM_EXAMPLE, it would result in your component name appearing as example-component in the menu and you would be unable to provide a translation. In order to provide a translation you need to create a file named en-GB.com_example.sys.ini in administrator/languages/en-GB (you can use the manifest's <code><languages></code> tag to copy it during installation) or in administrator/components/com_example/language/en-GB. In the latter case, you must not include the translation file in the <code><languages></code> tag. As long as you have placed the language directory in your <code><files></code> tag, it will be copied along when the component is being installed.
+
The value inside the tag is the menu's label. Unlike Joomla! 1.5, you can not use a natural language string. For example, if you would enter "Example Component" instead of COM_EXAMPLE, it would result in your component name appearing as example-component in the menu and you would be unable to provide a translation. In order to provide a translation you need to create a file named en-GB.com_example.sys.ini in administrator/languages/en-GB (you can use the manifest's <code>&lt;languages&gt;</code> tag to copy it during installation) or in administrator/components/com_example/language/en-GB. In the latter case, you must not include the translation file in the <code>&lt;languages&gt;</code> tag. As long as you have placed the language directory in your <code><files></code> tag, it will be copied along when the component is being installed.
  
 
The contents of that file should be:
 
The contents of that file should be:
Line 137: Line 138:
 
</source>
 
</source>
  
Please note that the language string must be enclosed in double quotes, as per Joomla!'s translation standards. Important 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 for the majority (non-English speaking!) of Joomla! users experienced under Joomla! 1.5.
+
Please note that the language string must be enclosed in double quotes, as per Joomla!'s translation standards. Important 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.
  
 
{{Needsinfo|In Platform 11.1 no alt attribute processed and if link provide in menu tag other provided attributes were ignore. The other tags are task, view, controller, act, layout, sub. Please confirm this, please.}}
 
{{Needsinfo|In Platform 11.1 no alt attribute processed and if link provide in menu tag other provided attributes were ignore. The other tags are task, view, controller, act, layout, sub. Please confirm this, please.}}
Line 162: Line 163:
 
</source>
 
</source>
  
In above example, we put sql files in "admin/sql" folder of installation package. You have to include "sql" folder in administration files.
+
In the above example, we put the SQL files in the "admin/sql" folder of the installation package. You have to include the "sql" folder in the administration files.
  
You can execute SQL during installation and/or uninstallation using the <code><install></code> and <code><uninstall></code> elements, respectively. An <code><sql></code> element should appear as a child of these elements. <code><sql></code> can contain any number of <code><file></code> elements, each defining a single SQL file to execute. Their database driver types are described by the <code>driver</code> attribute, their character sets by the <code>charset</code> attribute.
+
You can execute SQL during the installation and/or uninstallation using the <code><install></code> and <code><uninstall></code> elements, respectively. A <code><sql></code> element should appear as a child of these elements. <code><sql></code> can contain any number of <code><file></code> elements, each defining a single SQL file to execute. Their database driver types are described by the <code>driver</code> attribute, their character sets by the <code>charset</code> attribute.
  
 
==== Update of the SQL schema ====
 
==== Update of the SQL schema ====
Line 177: Line 178:
 
</source>
 
</source>
  
Since 1.6, there is also an <code><update></code> tag, which allows to provide a series of SQL files to update the current schema.
+
Since 1.6, there is also an <code><update></code> tag, which allows you to provide a series of SQL files to update the current schema.
  
 
=== Language files ===
 
=== Language files ===
In Joomla! 1.5, we put extension language files in Joomla! main language file, using <languages>..</languages> tag as shown below. '''This tag considered to be deprecated since Joomla! 1.6.''' We encourage you to put extension 's language files in extension folder and Joomla! is responsible for loading of required language files.
+
In Joomla! 1.5, extension developers had to put extension language files in the Joomla! main language file, using the <languages>..</languages> tag as shown below. '''This method can still be used in''' {{rarr|2.5,3.x}}.
  
 
<source lang="xml">
 
<source lang="xml">
<!-- Joomla! 1.5 language tag, deprecated since Joomla! 1.6 -->
+
<!-- Joomla! 1.5 language tag -->
 
<languages folder="langfiles">
 
<languages folder="langfiles">
 
<language tag="en-GB">en-GB.com_example.ini</language>
 
<language tag="en-GB">en-GB.com_example.ini</language>
Line 189: Line 190:
 
</source>
 
</source>
  
Storing extension language files in extension folder, you gain benefit when removing some language from Joomla! installation. As your language files were not removed, when reinstall the language again you can use that files without install them again.
+
Since Joomla! 1.6 it has been encouraged placing your extension's language files in your extension folder. Joomla! will then automatically load your extension's language files.
 +
 
 +
By storing extension language files in the extension folder, you gain the benefit of isolating and protecting your extension's language files.  For example, an administrator removes a language from their Joomla! installation. Your extension's language files will not be removed. They will remain in place and will be available if the language is installed again.
 +
 
 +
The structure of the language folder for frontend and backend is the same. You put them in the language tag (e.g. '''en-GB''' ) of each language in your language folder i.e. '''language/en-GB/'''. You have to specify those folders in the front-end and back-end files too.
 +
 
 +
In your manifest you simply include the ''''language'''' folder in your files section, the sub-directories for each language automatically be copied. Inside the <files> group you simply add a <folder> element alongside the items in the '''<files>''' group as shown in this example:
 +
 
 +
<source lang="xml">
 +
<files>
 +
<filename plugin="alpha">alpha.php</filename>
 +
<folder>sql</folder>
 +
<folder>language</folder>
 +
</files>
 +
</source>
 +
 
 +
It is also notable that both ways can work together. Here is an example from core:
 +
<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>
 +
 
 +
The advantages of this solution are the following:
 +
 
 +
All ini files present in the core folder have precedence over the files in the extension language/ folder.
 +
For example a sys.ini file will always be loaded from core folders in back-end if it exists, except when installing an extension which contains a sys.ini file in a language folder. In that case and only that case, the sys.ini file in the extension folder will display its translated content at install time. This is very handy as a developer can have 2 sys.ini files with different contents. A description of the successful install as well as a tutorial in back-end for example.
 +
 
 +
Also, it is much easier for a user needing an ini file for an extension that does not provide it in the language desired, to add it in the main folders. No risk for it to be deleted in case of uninstalling the extension by mistake or any other reason.
  
The structure of language folder for frontend and backend is the same. You put them in <language> tag of your folder e.g. language/en-GB/. You have to specify these folders in front-end and back-end files too.
+
See also:
 +
*[[J2.5:Making non-core language packs|Making non-core language packs]]
 +
*[[Creating language packs for extensions in Joomla 2.5]]
  
During development you can turn on language debuggin in Joomla! global configuration. So you can investigate if the problems exists.
+
During development you can turn on language debugging in the Joomla! global configuration. So you can investigate if a problems arises. As of 3.2, this is necessary to help debug as en-GB is '''always''' loaded first when not in debug mode to prevent displaying Constants.
  
 
=== Script file ===
 
=== Script file ===
Line 201: Line 238:
 
</source>
 
</source>
  
An optional '''script file''' (PHP code that is run before, during and/or after installation, uninstallation and upgrading) can be defined using a <code><scriptfile></code> element. This file should contain a class named "<element_name>IntallerScript" where <element_name> is the name of your extension (e.g. com_componentname, mod_modulename, etc.). Plugins requires to state the group (e.g. plgsystempluginname). The structure of the class is as follows:
+
An optional '''script file''' (PHP code that is run before, during and/or after installation, uninstallation and upgrading) can be defined using a <code><scriptfile></code> element. This file should contain a class named "<element_name>IntallerScript" where <element_name> is the name of your extension (e.g. com_componentname, mod_modulename, etc.). Plugins requires to state the group (e.g. plgsystempluginname). Library packages do not support scriptfiles. The structure of the class is as follows:
  
 
<source lang="php">
 
<source lang="php">
Line 212: Line 249:
 
* @param  JAdapterInstance  $adapter  The object responsible for running this script
 
* @param  JAdapterInstance  $adapter  The object responsible for running this script
 
*/
 
*/
public function __constructor(JAdapterInstance $adapter);
+
public function __construct(JAdapterInstance $adapter);
 
 
 
/**
 
/**
 
* Called before any type of action
 
* Called before any type of action
 
*
 
*
* @param  string  $route  Which action is happening (install|uninstall|discover_install)
+
* @param  string  $route  Which action is happening (install|uninstall|discover_install|update)
 
* @param  JAdapterInstance  $adapter  The object responsible for running this script
 
* @param  JAdapterInstance  $adapter  The object responsible for running this script
 
*
 
*
Line 227: Line 264:
 
* Called after any type of action
 
* Called after any type of action
 
*
 
*
* @param  string  $route  Which action is happening (install|uninstall|discover_install)
+
* @param  string  $route  Which action is happening (install|uninstall|discover_install|update)
 
* @param  JAdapterInstance  $adapter  The object responsible for running this script
 
* @param  JAdapterInstance  $adapter  The object responsible for running this script
 
*
 
*
Line 284: Line 321:
  
 
More info:
 
More info:
* [[Developing_a_Model-View-Controller_Component/2.5/Adding_an_update_server|Building a Joomla! Extension - Adding an update server]]
+
* [[J2.5:Developing a MVC Component/Adding an update server|Building a Joomla! Extension - Adding an update server]]
* [[Managing Component Updates with Joomla!2.5 - Part 1|Managing Component Updates in Joomla 2.5]]
+
* [[J2.5:Managing Component Updates|Managing Component Updates in Joomla 2.5]]
  
 
== Examples ==
 
== Examples ==

Latest revision as of 17:54, 7 July 2014


Within Joomla there are manifest files for all of the extensions. These files include the general installation information as well as parameters for the configuration of the extension itself. Since Joomla! 2.5 Joomla 2.5, there are very few differences between the manifest file formats for the different types of extensions, allowing each type to access the full power of the Joomla! installer.

Contents

Naming conventions

The file must be named manifest.xml or <extension_name>.xml and located in the root directory of the installation package.

Syntax

Root element

The primary tag of the installation file is:

<extension></extension>

This starting and closing tags are now valid for all extensions. The new tag <extension> replaces the old <install></install> from Joomla Joomla 1.5. The following attributes are allowed within the tag:

Attribute Values Applicable to Description
type component
file
language
library
module
package
plugin
template
All extensions This attribute describes the type of the extension for the installer. Based on this type further requirements to sub-tags apply.
version 2.5
3.0
All extensions String that identifies the version of Joomla for which this extension is developed.
method install
upgrade
All extensions The default value install will be also used if the method attribute is not used. The install value means the installer will gracefully stop if it finds any existing file/folder of the new extension.
client site
administrator
Modules The client attribute allows you to specify for which application client the new module is available.
group string Plugins The group name specifies for which group of plugins the new plugin is available. The existing groups are the folder names within the directory /plugins. The installer will create new folder names for group names that do not exist yet.


Metadata

The following elements can be used to insert metadata. None of these elements are required; if they are present, they must be a child of the root element.

<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)

Note: The <name> and <description> tags are also translatable fields so that the name and description of the extension can be shown to the user in their native language.

Front-end files

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

Files to copy to the front-end directory should be placed in the <files> element. You can use the optional folder attribute to specify a directory in the ZIP package to copy from. Each file to copy must be represented by a <filename> element. If you want to copy an entire folder at once, you can define it as a <folder>.

Media files

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

This example will copy the file(s) (/media/com_example_logo.png) and folders ( /media/css/ and /media/js/ ) listed to /media/com_example/, creating the com_example folder if required. You can use the optional folder attribute to specify a directory in the ZIP package to copy from (in this case, media).

Extensions should be storing assets they need to be web accessible (JS, CSS, images etc) in media. Amongst other things this feature was added as step in the progression to multi-site support and the eventual move of code files (PHP) out of the web accessible areas of the server.

Ref:

Administration section

        <administration>
                <!-- various elements -->
        </administration>

The administration section is defined in the <administration> element. Since only components apply to both the site and the administrator, only component manifests can include this element.

Back-end files

Files to copy to the back-end directory should be placed in the <files> element under the <administration>. You can use the optional folder attribute to specify a directory in the ZIP package to copy from. See Front-end files for further rules.

Menu links and submenus

        <menu>COM_EXAMPLE</menu>
        <submenu>
                <menu link="anoption=avalue">COM_EXAMPLE_SUBMENU_ANOPTION</menu>
                <menu view="viewname">COM_EXAMPLE_SUBMENU_VIEWNAME</menu>
        </submenu>

The text for the main menu item for the component is defined in the <menu> item, a child of <administration>. A <submenu> element may also be present (also a child of <administration>), which may contain more menu items defined by <menu>.

Additionally, each <menu> item can define the following attributes:

Attribute Description
link A link to send the user to when the menu item is clicked
img The (relative) path to an image (16x16 pixels) to appear beside the menu item.

Must be an url compatible as a file too (e.g. no spaces) !

alt
string An URL parameter to add to the link. For example, <menu view="cpanel">COM_EXAMPLE</menu> in com_example's XML manifest would cause the URL of the menu item to be index.php?option=com_example&view=cpanel.

The value inside the tag is the menu's label. Unlike Joomla! 1.5, you can not use a natural language string. For example, if you would enter "Example Component" instead of COM_EXAMPLE, it would result in your component name appearing as example-component in the menu and you would be unable to provide a translation. In order to provide a translation you need to create a file named en-GB.com_example.sys.ini in administrator/languages/en-GB (you can use the manifest's <languages> tag to copy it during installation) or in administrator/components/com_example/language/en-GB. In the latter case, you must not include the translation file in the <languages> tag. As long as you have placed the language directory in your <files> tag, it will be copied along when the component is being installed.

The contents of that file should be:

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. Important 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.

Configuration

Stop hand nuvola.svg.png
Warning!

Components do not support configuration definitions in the manifest. This is a way implemented in Joomla! 1.5. They can define configuration options for multiple levels using Component configuration metadata.

The <config> element, a child of the root, describes the configuration options for the extension. If applicable, the options will be shown by the appropriate Manager (Plugin Manager, Module Manager or Template Manager). Configuration options can also be defined in a separate file named config.xml. Its root element should be <config>.

Under the <config> element, one or more <fieldset> elements may appear, each representing a HTML <fieldset>, a group of form fields visually grouped together. The optional name attribute can be used on the <fieldset> to define the name of the fieldset, as in <fieldset name="params">.

Each fieldset must contain one or more <field> elements, each representing a single form field with a label. See Standard form field types for a list of allowed form field types and example XML form field definitions.

SQL

    <install folder="admin">
        <sql>
            <file driver="mysql" charset="utf8">sql/example.install.sql</file>
        </sql>
    </install>
    <uninstall folder="admin">
        <sql>
            <file driver="mysql" charset="utf8">sql/example.uninstall.sql</file>
        </sql>
    </uninstall>

In the above example, we put the SQL files in the "admin/sql" folder of the installation package. You have to include the "sql" folder in the administration files.

You can execute SQL during the installation and/or uninstallation using the <install> and <uninstall> elements, respectively. A <sql> element should appear as a child of these elements. <sql> can contain any number of <file> elements, each defining a single SQL file to execute. Their database driver types are described by the driver attribute, their character sets by the charset attribute.

Update of the SQL schema

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

Since 1.6, there is also an <update> tag, which allows you to provide a series of SQL files to update the current schema.

Language files

In Joomla! 1.5, extension developers had to put extension language files in the Joomla! main language file, using the tag as shown below. This method can still be used in 2.5  3.x.

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

Since Joomla! 1.6 it has been encouraged placing your extension's language files in your extension folder. Joomla! will then automatically load your extension's language files.

By storing extension language files in the extension folder, you gain the benefit of isolating and protecting your extension's language files. For example, an administrator removes a language from their Joomla! installation. Your extension's language files will not be removed. They will remain in place and will be available if the language is installed again.

The structure of the language folder for frontend and backend is the same. You put them in the language tag (e.g. en-GB ) of each language in your language folder i.e. language/en-GB/. You have to specify those folders in the front-end and back-end files too.

In your manifest you simply include the 'language' folder in your files section, the sub-directories for each language automatically be copied. Inside the <files> group you simply add a <folder> element alongside the items in the <files> group as shown in this example:

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

It is also notable that both ways can work together. Here is an example from 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>

The advantages of this solution are the following:

All ini files present in the core folder have precedence over the files in the extension language/ folder. For example a sys.ini file will always be loaded from core folders in back-end if it exists, except when installing an extension which contains a sys.ini file in a language folder. In that case and only that case, the sys.ini file in the extension folder will display its translated content at install time. This is very handy as a developer can have 2 sys.ini files with different contents. A description of the successful install as well as a tutorial in back-end for example.

Also, it is much easier for a user needing an ini file for an extension that does not provide it in the language desired, to add it in the main folders. No risk for it to be deleted in case of uninstalling the extension by mistake or any other reason.

See also:

During development you can turn on language debugging in the Joomla! global configuration. So you can investigate if a problems arises. As of 3.2, this is necessary to help debug as en-GB is always loaded first when not in debug mode to prevent displaying Constants.

Script file

    <scriptfile>example.script.php</scriptfile>

An optional script file (PHP code that is run before, during and/or after installation, uninstallation and upgrading) can be defined using a <scriptfile> element. This file should contain a class named "<element_name>IntallerScript" where <element_name> is the name of your extension (e.g. com_componentname, mod_modulename, etc.). Plugins requires to state the group (e.g. plgsystempluginname). Library packages do not support scriptfiles. The structure of the class is as follows:

class com_componentnameInstallerScript
{
        /**
         * Constructor
         *
         * @param   JAdapterInstance  $adapter  The object responsible for running this script
         */
        public function __construct(JAdapterInstance $adapter);
 
        /**
         * Called before any type of action
         *
         * @param   string  $route  Which action is happening (install|uninstall|discover_install|update)
         * @param   JAdapterInstance  $adapter  The object responsible for running this script
         *
         * @return  boolean  True on success
         */
        public function preflight($route, JAdapterInstance $adapter);
 
        /**
         * Called after any type of action
         *
         * @param   string  $route  Which action is happening (install|uninstall|discover_install|update)
         * @param   JAdapterInstance  $adapter  The object responsible for running this script
         *
         * @return  boolean  True on success
         */
        public function postflight($route, JAdapterInstance $adapter);
 
        /**
         * Called on installation
         *
         * @param   JAdapterInstance  $adapter  The object responsible for running this script
         *
         * @return  boolean  True on success
         */
        public function install(JAdapterInstance $adapter);
 
        /**
         * Called on update
         *
         * @param   JAdapterInstance  $adapter  The object responsible for running this script
         *
         * @return  boolean  True on success
         */
        public function update(JAdapterInstance $adapter);
 
        /**
         * Called on uninstallation
         *
         * @param   JAdapterInstance  $adapter  The object responsible for running this script
         */
        public function uninstall(JAdapterInstance $adapter);
}

Update servers

    <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>

Update servers can be defined in the <updateservers> element, a child of the root. This element may contain one or more <server> element, each describing a location to fetch updates from. Each <server> item can define the following attributes:

Attribute Values Description
type extension
collection
The update server type
priority integer The priority of the update server
name string The name of the update server

More info:

Examples

For a real-life example, see the manifest of the Banner component in the latest version of Joomla! 2.5.

The Joomla testing process uses several extensions to test whether the installer works correctly. The latest versions of the manifests of these extensions are:

Contributors