Manifest files
(→Menu links and submenus) |
(Added information about language files + the largely undocumented way to present localised installation messages when installing plugins, modules, etc.) |
||
| Line 139: | Line 139: | ||
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 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. | ||
| + | |||
| + | === Language files === | ||
| + | Including the language INI files in your extension installation package is not sufficient. You have to tell Joomla! where to find them so that it can install them. This is done by means of up to two <languages> tags. In the case of a component, you need a <languages> tag both under the root tag (<manifest> or <install>) of the XML file (for the front-end translation files) and one inside the | ||
| + | <administration> tag (for the back-end translation files). In both cases, the syntax looks like that: | ||
| + | |||
| + | <source lang="xml"> | ||
| + | <languages folder="langfiles"> | ||
| + | <language tag="en-GB">en-GB.com_example.ini</language> | ||
| + | </languages> | ||
| + | </source> | ||
| + | |||
| + | The content of the folder attribute of this tag is the relative path of the directory holding the translation files. The path is relative to the your installation package, not the site's root. Each <language> tag '''must''' specify the ISO-code of the language in the tag attribute. | ||
| + | |||
| + | You should not that, by default, the language files are not loaded during installation time unless you use a special convention. | ||
| + | |||
| + | For components, you must place a directory named language inside your component's backend directory and make sure it's being installed, i.e. you have referenced it in your <administration> tag's <files> tag. For other extension types, create a directory named language inside your installation archive's root. In all cases, create one subdirectory per language and put your .sys.ini translation file in there. For example, if you have plg_content_example, create the file language/en-GB/en-GB.plg_content_example.sys.ini and put all installation-time messages' translations in there. This file will be loaded automatically by Joomla! right after all files have been copied and before running your script file and/or displaying the post-installation message (e.g. the extension's description). | ||
=== Script file === | === Script file === | ||
Revision as of 12:01, 7 December 2011
Please note that the content on this page is currently incomplete. Please treat it as a work in progress.
- This article was last edited by Nikosdion (talk| contribs) 17 months ago. (Purge)
Contents |
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! 1.6
, 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.
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
. The following attributes are allowed within the tag:
| Attribute | Values | Applicable to | Description |
|---|---|---|---|
| type | componentmoduleplugintemplate |
All extensions | This attribute describes the type of the extension for the installer. Based on this type further requirements to sub-tags apply. |
| version | 1.6 |
All extensions | String that identifies the version of Joomla for which this extension is developed. For Joomla 1.6 a version higher than 1.5 is required. |
| method | newupgrade |
All extensions | The default value install will be also used if the method attribute is not used. In these cases the installer will gracefully stop if he finds any existing file/folder of the new extension |
| client | siteadministrator |
Modules | The client allows 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)
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>.
Administration section
<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>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 |
| 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 for the majority (non-English speaking!) of Joomla! users experienced under Joomla! 1.5.
| Information required: 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. |
Configuration
| 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> <sql> <file driver="mysql" charset="utf8">example.install.sql</file> </sql> </install> <uninstall> <sql> <file driver="mysql" charset="utf8">example.uninstall.sql</file> </sql> </uninstall>
You can execute SQL during installation and/or uninstallation using the <install> and <uninstall> elements, respectively. An <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.
Language files
Including the language INI files in your extension installation package is not sufficient. You have to tell Joomla! where to find them so that it can install them. This is done by means of up to two <languages> tags. In the case of a component, you need a <languages> tag both under the root tag (<manifest> or <install>) of the XML file (for the front-end translation files) and one inside the <administration> tag (for the back-end translation files). In both cases, the syntax looks like that:
<languages folder="langfiles"> <language tag="en-GB">en-GB.com_example.ini</language> </languages>
The content of the folder attribute of this tag is the relative path of the directory holding the translation files. The path is relative to the your installation package, not the site's root. Each <language> tag must specify the ISO-code of the language in the tag attribute.
You should not that, by default, the language files are not loaded during installation time unless you use a special convention.
For components, you must place a directory named language inside your component's backend directory and make sure it's being installed, i.e. you have referenced it in your <administration> tag's <files> tag. For other extension types, create a directory named language inside your installation archive's root. In all cases, create one subdirectory per language and put your .sys.ini translation file in there. For example, if you have plg_content_example, create the file language/en-GB/en-GB.plg_content_example.sys.ini and put all installation-time messages' translations in there. This file will be loaded automatically by Joomla! right after all files have been copied and before running your script file and/or displaying the post-installation message (e.g. the extension's description).
Script file
<scriptfile>example.script.php</scriptfile>
A script file (PHP code that is run before, during and/or after installation, uninstallation and upgrading) can be defined using a <scriptfile> element.
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 | extensioncollection |
The update server type |
| priority | integer | The priority of the update server |
| name | string | The name of the update server |
Examples
For a real-life example, see the manifest of the Banner component in version 1.6.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:
- com_alpha manifest
- mod_alpha manifest
- plg_system_alpha manifest
- tpl_simple manifest
- lng_xx-XX manifest