Joomla! Documentation - User contributions [en]

Talk:Adding changelog to your manifest file

2024-03-13T22:15:34Z

Rogerco: further ideas

Discussion
Just above the example changelog it says `Each node can be repeated as many times as needed.`

This is not strictly true. You can have several item nodes within a parent
eg
<source lang="xml">
<change>
<item>item 1</item>
<item>item 2</item>
</change>
</source>
but you can't repeat the parent <change> node
<source lang="xml">
<change>
<item>item 1</item>
</change>
<change>
<item>item 2</item>
</change>
</source>
Only the last <change> elements will be displayed
==============================================

Second suggestion. Although Joomla doesn't currently (v5.0.3) display it it would seem good practice to include a <data> node
<source lang="xml">
<changelog>
<element>com_lists</element>
<type>component</type>
<version>4.0.0</version>
<date>13th March 2024</date>
...
</source>
This would enable improvements to the information presented in the layout.
Similarly a <title> node might also be useful. Currently I use an `<addition<item>` node to provide a title, but it would be better to save the <addition> node for real additions. Also it would enable the title to be displayed above the <security> and <fix> nodes in the formatted layout.

Talk:Adding changelog to your manifest file

2024-03-13T21:55:22Z

Rogerco: comment on repeating nodes

J3.x talk:Developing an MVC Component/Adding Tags

2020-07-15T07:30:04Z

Rogerco: Changes needed to work with Tags component

In order to work with the tags component better two further changes are needed:

1. add language strings to the admin <code>en-GB.com_helloworld.sys.ini</code> file so that the filter options in the tag component admin view pick them up
<source lang="xml">
COM_HELLOWWORLD_TAGS_CATEGORY="Helloworld Category"
COM_HELLOWWORLD_TAGS_HELLOWORLD="Helloworld Message"

</source>
2. Do whatever is needed to make that filter option work like it does for Articles. It should show a count of the number of items with each state for each tag, but I don't see how it works...

Manifest files

2019-07-12T16:34:37Z

Rogerco: Clarified that plugins and modules must use the manifest xml and not a separate config.xml. Previous version implied they could use config.xml

<noinclude><languages /></noinclude>
<noinclude>{{page|needs updating|}}</noinclude>
<noinclude>
{{Joomla version|version=3.x}} {{Joomla version|version=2.5|status=eos}}
</noinclude>
<translate>
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 [[S:MyLanguage/extension|extension]] itself. Since Joomla! 2.5, there are very few differences between the manifest file formats for the different [[S:MyLanguage/Extension types (technical definitions)|types of extensions]], allowing each type to access the full power of the Joomla! installer.</translate>

<translate>
==Naming conventions== 
</translate>
<translate>
The file must be named <tt>manifest.xml</tt> or <tt><extension_name>.xml</tt> and located in the root directory of the installation package.</translate>

<translate>
==Syntax== 
</translate>

<translate>
=== Root element === 
</translate>
<translate>
The primary tag of the installation file is:</translate>
<source lang=xml><extension></extension></source>

<translate>
This starting and closing tag is now valid for all extensions. The new tag <code><extension></code> replaces the old <code><install></install></code> from Joomla {{JVer|1.5}}. The following attributes are allowed within the tag:</translate>

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

<translate>

=== Metadata === 
</translate>

<translate>
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.</translate>

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

<translate>
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.</translate>

<translate>=== Front-end files === </translate>

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

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

<translate>

For '''plugins''', the raw name of the plugin should be placed in the <code>plugin</code> attribute on the <code><filename></code> element that points to the file containing the plugin's class. For example, in the case of a system plugin called "example" (full name <code>plg_system_example</code>), use <code><filename plugin="example">example.php</filename></code>.</translate>

<translate>=== Media files === </translate>

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

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

<translate>
Extensions should be storing assets they need to be web accessible (JS, CSS, images etc) in <code>media</code>. 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. 
Note: the media section is not parsed for 'package' type extensions.</translate>

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]

<translate>
=== Administration section === 
</translate>

<source lang="xml">
<administration>

</administration>
</source>

<translate>
The administration section is defined in the <code><administration></code> element. Since only [[S:MyLanguage/Component|components]] apply to both the [[S:MyLanguage/Site (Application)|site]] and the [[S:MyLanguage/Administrator (Application)|administrator]], '''only component manifests can include this element'''.</translate>

<translate>
==== Back-end files ==== 
</translate>

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

<translate>
==== Menu links and submenus ==== 
</translate>
{{dablink|<translate>
'''Version Note:''' Prior to Joomla 3.4, not having a <code><nowiki><menu></nowiki></code> tag in your manifest XML file still led to a menu item being created. This bug was fixed in Joomla 3.4, so if there is no <code><nowiki><menu></nowiki></code> tag in your manifest file, then no admin menu item is created for the component.</translate>}}

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

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

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

{| class="wikitable"
! style="width: 150px" | <translate>
Attribute</translate> || <translate>
Description</translate>
|-
| link || <translate>
A link to send the user to when the menu item is clicked. You can use "view" instead.</translate>
|-
| img || <translate>
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) !</translate>
|-
| alt ||
|-
| view || <translate>
An URL parameter to add to the link. For example, <code><menu view="cpanel">COM_EXAMPLE</menu></code> in com_example's XML manifest would cause the URL of the menu item to be <tt>index.php?option=com_example&view=cpanel</tt>. You can use "link" instead.</translate>
|-
|}

<translate>
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.</translate>

<translate>
The contents of that file should be:</translate>

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

<translate>
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.</translate>

<translate>
=== Configuration === 
</translate>
{{warning|<translate>
Components '''do not support''' configuration definitions '''in the manifest'''. This was a way implemented in Joomla! 1.5. They can define configuration options for multiple levels using [[S:MyLanguage/Component configuration metadata|Component configuration metadata]].</translate>}}
<translate>
The <code><config></code> 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 for Components are defined in a separate file named <code>config.xml</code>. Its root element should be <code><config></code>, plugins and modules use the <code><config></code> section in the extension manifest file.'''</translate>

<translate>
Each fieldset must contain one or more <code><field></code> elements, each representing a single [[S:MyLanguage/form field|form field]] with a label. See [[S:MyLanguage/Standard form field types|Standard form field types]] for a list of allowed form field types and example XML form field definitions.</translate>

<translate>
=== SQL === 
</translate>

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

<translate>
In the above example, we put the SQL files in the <tt>admin/sql</tt> folder of the installation package. You have to include the <tt>sql</tt> folder in the administration files (as described in ''Back-end files'').</translate>

<translate>
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.</translate>

<translate>
==== Update of the SQL schema ==== 
</translate>

<translate>
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.</translate>

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

<translate>
For example, in order to go from version <code>1.0.0</code> to version <code>1.0.1</code> in a '''MySQL''' database, a <code>1.0.1.sql</code> file must be created inside the <code>sql/updates/mysql</code> folder and the <code><version></code> tag of the manifest must be updated to</translate>
<source lang="xml">
<version>1.0.1</version></source>

<translate>
The final structure of the sql folder will look like this (assuming a '''MySQL''' database)</translate>
<source lang="xml">
sql
|-->example.install.sql
|-->example.uninstall.sql
|-->updates
|-->mysql
|-->1.0.1.sql</source>

<translate>
Similar files must be created for subsequent versions.</translate>

<translate>
=== Language files === 
</translate>
<translate>
In Joomla! 1.5, extension developers had to put extension language files in the Joomla! main language folder using the <languages>...</languages> tag as shown below. '''This method can still be used in Joomla!''' {{JVer|3.x}}.</translate>

<source lang="xml">

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

<translate>
Since Joomla! 1.6 it is recommended that you place your extension's language files in your extension folder. Joomla! will then automatically load your extension's language files.</translate>

<translate>
By storing extension language files in the extension folder, you benefit by 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.</translate>

<translate>
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.</translate>

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

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

<translate>
Note that both ways can work together. Here is an example from core:</translate>

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

<translate>
The advantages of this solution are the following:</translate>

<translate>
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 the 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 two ''.sys.ini'' files with different contents.</translate>

<translate>
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. There is no risk that it will be deleted in case of uninstalling the extension by mistake or any other reason.</translate>

<translate>
See also:
*[[S:MyLanguage/J2.5:Making non-core language packs|Making non-core language packs]]
*[[S:MyLanguage/Creating language packs for extensions in Joomla 2.5|Creating language packs for extensions in Joomla 2.5]]</translate>

<translate>
During development you can turn on language debugging in the Joomla! global configuration. You can investigate if a problem 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.</translate>

<translate>
=== Script file === 
</translate>

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

<translate>
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>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). Library packages do not support script files. The structure of the class is as follows:</translate>

<source lang="php">

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

</source>

<translate>
=== Update servers === 
</translate>

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

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

{| class="wikitable"
! style="width: 150px" | <translate>
Attribute</translate> || style="width: 150px" | <translate>
Values</translate> || <translate>
Description</translate>
|-
| type || <code>extension</code> <code>collection</code> || <translate>
The update server type</translate>
|-
| priority || ''integer'' || <translate>
The priority of the update server</translate>
|-
| name || ''string'' || <translate>
The name of the update server</translate>
|}

<translate>
More info:
* [[S:MyLanguage/J2.5:Developing a MVC Component/Adding an update server|Building a Joomla! Extension - Adding an update server]]
* [[S:MyLanguage/J2.5:Managing Component Updates|Managing Component Updates in Joomla 2.5]]</translate>

<translate>
== Examples == 
</translate>
<translate>
For a real-life example, see [https://github.com/joomla/joomla-cms/blob/3.6.4/administrator/components/com_banners/banners.xml the manifest of the Banner component in the latest version of Joomla! 3.6.4].</translate>

<translate>
Some more examples can be found in the standalone weblinks repo:</translate>

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

<noinclude>
<translate>

[[Category:Development]]
[[Category:Extension development]]
[[Category:Specifications]]
</translate>
</noinclude>

Deploying an Update Server

2015-04-03T11:55:37Z

Rogerco: noted a gotcha in the download url section

{{version/tutor|2.5,3.x}}

== Introduction ==
This tutorial is designed to teach developers how to create an update server for integration with the update system introduced in Joomla!. By adding an update server listing to your extension's manifest, developers enable users to update their extensions via the Extension Manager's Update (see [[Help25:Extensions Extension Manager Update|Joomla 2.5]] and [[Help31:Extensions Extension Manager Update|Joomla 3.x]] helpscreens) view with only a few clicks.

== Defining an update server ==
In order to use this feature, an update server must be defined in your extension's manifest. This definition can be used in all Joomla! 2.5 and newer compatible extensions but is not available for templates. You can use two options for your server type; collection or extension. These will be explained in detail shortly. This code should be added to the extension manifest file, within the root "extension" element. The update server is defined as follows for each type:

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

Multiple servers can be defined within the <updateservers> tag.

== Server types ==
=== Collection ===
The collection server type allows developers to define an extension's manifest to pull updates from a collection. This type of server can be used if the developer wants to define all of their extension's updates in a single file (not recommended) or if their extension has multiple sub-extensions which are not distributed or updated at the same time (such as a package extension type). The below example is the collection definition used by the updater when processing core Joomla! updates:

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

All definitions must be defined between <extensionset> tags in your collection manifest. The <extensionset> tag has two optional parameters; name and description. For each extension that this collection references, a separate <extension> tag is required. The <extension> tag has the following parameters, all of which are required for updates to properly process:

* '''name''' - The name of the extension
* '''element''' - The untranslated extension name i.e. mod_custom
* '''type''' - The extension type (component, module, plugin, etc.)
* '''version''' - The latest version of the extension
* '''detailsurl''' - The URL of the XML file which contains that extension's individual update definitions

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

<source lang="xml">
<update>
<name>Joomla! 1.7</name>
<description>Joomla! 1.7 CMS</description>
<element>joomla</element>
<type>file</type>
<version>1.7.0</version>
<infourl title="Joomla!">http://www.joomla.org/</infourl>
<downloads>
<downloadurl type="full" format="zip">http://joomlacode.org/gf/download/frsrelease/15279/66552/Joomla_1.6.5_to_1.7.0_Package.zip</downloadurl>
</downloads>
<tags>
<tag>stable</tag>
</tags>
<maintainer>Sam Moffatt</maintainer>
<maintainerurl>http://sammoffatt.com.au</maintainerurl>
<section>Testing</section>
<targetplatform name="joomla" version="1.6"/>
</update>
</source>

The following section describes the elements of a single update entity.

* '''name''' - The name of the extension, this name will appear in the Name column of the Extension Manager's Update view (required)
* '''description''' - A short description of the extension (optional) -- if you choose to use <![CDATA[]]>, double-quotes will break the HTML formatting. Use single quotes with your HTML entities.
* '''element''' - The installed name of the extension (required). For plugins, this needs to be same as plugin attribute value for main file in plugin manifest. For <filename plugin="pluginname">pluginname.php</filename>, element value should be '''pluginname'''.
* '''type''' - The type of extension (component, module, plugin, etc.) (required)
* '''folder''' - Specific to plugins, this tag describes the type of plugin being updated (content, system, etc.) (required for plugins)
* '''client''' Required for modules as of 3.2.0. - The client ID of the extension, which can be found by looking inside the #__extensions table. To date, use 0 for "site" and 1 for "administrator". Plugins and front-end modules are automatically installed with a client of 0 (site), but you will need to specify the client in an update or it will default to 1 (administrator) and then found update would not be shown because it would not match any extension. Components are automatically installed with a client of 1, which is currently the default.
** ''Warning'': The tag name is <'''client'''> for Joomla! 2.5 and <'''client_id'''> for 1.6 and 1.7. If you use <client_id> (rather than <client>) on a 2.5 site, it will be ignored.
* '''version''' - The version of the release (required)
* '''infourl''' - A URL to point users to containing information about the update (optional) (In CMS 2.5, if set, this URL will be displayed in the update view)
* '''downloads''' - The section which lists all download locations
** '''downloadurl''' - The URL to download the extension from; the <downloadurl> tag has two required parameters:
*** '''type''' - The type of package (full or upgrade)
*** '''format''' - The format of the package (zip, tar, etc.)
** '''NB''' - there must be no newline before or after the URL; it needs to all be on one line or you will get Error connecting to the server: malformed when the update is run
* '''tags''' - A list of tags relevant to this version. Joomla! 3.4 and later uses this to determine the stability level of the update. The valid tags are:
** ''dev'': Development versions, very unstable and pre-alpha (e.g. nightly builds)
** ''alpha'': Alpha quality software (features not implemented, show-stopper bugs)
** ''beta'': Beta quality software (all features implemented, show-stopper bugs possible, minor bugs almost certain)
** ''rc'': Release Candidate quality software (no show-stopper bugs, minor bugs may still be present)
** ''stable'': Production quality software All other tags are currently ignored. If you provide more than one tag containing one of the aforementioned stability keywords only the LAST tag will be taken into account. If you do not provide any tags Joomla! will assume it is a stable version.
* '''maintainer''' - The name of the extension maintainer (similar to the <author> tag in a manifest) (optional)
* '''maintainerurl''' - The website of the extension maintainer (similar to the <authorUrl> tag in a manifest) (optional)
* '''section''' - Optional (unknown use)
* '''targetplatform''' - A tag to define platform requirements, requires the following elements
** '''name''' - The name of the platform dependency; as of this writing, it should ONLY be "joomla"
** '''version''' - The version of Joomla! the extension supports
** '''min_dev_level''' and '''max_dev_level''' - These attributes were added in 3.0.1 to allow you to select a target platform based on the developer level ("z" in x.y.z). They are optional. You can specify either one or both. If omitted, all developer levels are matched. For example, the following matches versions 4.0.0 and 4.0.1. <code><targetplatform name="joomla" version="4.0" min_dev_level="0" max_dev_level="1"/></code>
*** '''Note:''' If your extension is Joomla! 2.5 and/or 3.1 compatible, you will be required to have separate <update> definitions for each version due to the manner in which the updater checks the version if you specify a number. However to show your extension on all Joomla versions that support automatic updates add <code><targetplatform name="joomla" version=".*"/></code>. If you want your extension to show on all {{JVer|3.x}} versions then rather than specifying a version in the version tag add in <code><targetplatform name="joomla" version="3.[012345]"/></code>. This will show the update to all 3.x versions.
* '''php_minimum''' - Beginning with 3.2.2, a minimum supported PHP version can be supplied in the update stream. If the server does not meet the minimum, a message is displayed to the user advising that an update is available but cannot be installed due to unsupported requirements.

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

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

'''Important for plugins:''' Plugins have to include <folder> and <client> elements to work properly

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

== Supporting Tools ==
Maintaining your update server files can be difficult depending on the manner in which you set up your files. An extension which can help you to maintain this is the Akeeba Release System, available free of charge from https://www.akeebabackup.com

== Contributors ==
*[[User:mbabker|Michael Babker]]
*[[User:Renekorss|Rene Korss]]
[[Category:Development]]

Sending email from extensions

2008-07-19T13:30:43Z

Rogerco: New page: This works to send an email to the currently logged in user when used in a function in a model for a component and called from a view: $user =& JFactory::getUser(); $message =& JFac...

This works to send an email to the currently logged in user when used in a function in a model for a component and called from a view:

$user =& JFactory::getUser();
$message =& JFactory::getMailer();
$message->addRecipient($user->email);
$message->setSubject('Your subject string');
$message->setBody("Your body string\nin double quotes if you want to parse the \nnewlines etc");
$sender = array( 'sender@email.address.org', 'Sender Name' );
$message->setSender($sender);
$sent = $message->send();
if ($sent != 1) echo 'Error sending email';