Using the installer API to support package installation

From Joomla! Documentation

Copyedit.png
This Article Needs Your Help

This article is tagged because it NEEDS REVIEW. You can help the Joomla! Documentation Wiki by contributing to it.
More pages that need help similar to this one are here. NOTE-If you feel the need is satistified, please remove this notice.


Packaging

The script needs to be extended for sorting your files into folders within the archive, which are needed for the Joomla! extension installer API. See the recommended file locations below:

Development file Archive folder
/components/com_<component name>/** /site/** (mimic folder structure)
/administrator/components/com_<component name>/** /admin/** (mimic folder structure)
/language/en-GB/en-GB.com_<component name>.ini /language/site (flatten structure: discard language code subfolders)
administrator/language/en-GB/en-GB.com_<component name>.ini /language/admin (flatten structure: discard language code subfolders)
install.<component name>.php /
uninstall.<component name>.php /
install.<component name>.sql /admin
uninstall.<component name>.sql /admin
<component name>.xml The manifest file /

The Component Manifest File

Your component needs an xml-file declaring meta data (author, license, etc.), which files are included and indicates some special files to the installer API, like the included languages and SQL-scripts for (un)installing.

The most important xml-elements are explained below. There is a manifest DTD for Joomla! 1.5 components which can be used as a guide to the syntax, but it cannot be used to validate the manifest due to a problem with the 1.5 component installer. This should be corrected for Joomla! 1.6 onwards.

The root element

<install type="component|module|..." method="upgrade">
    <name>component name</name>
    <version>x.y</version>
...

Enter the type of your extension, and indicate whether the installer shall be able to overwrite existing files. If the method attribute is not given, the installer will quit gracefully when encountering any existing file on the webspace.

The file list

<install>
    <files folder="site">
        <folder>views</folder>
        ...
        <filename>component-name.php</file>
        ...

    <administration>
        <files folder="admin">
            ...

List all files which make up the code of your component, which will later go to the component subfolder of the site. Same for the administration part.

The language files

<install>
    <languages folder="language/site">
        <language tag="en-GB">en-GB.com_<component name>.ini</language>
        ...

    <administration>
        <languages folder="language/admin">
            <language ...

The language files for the front-end will be copied to the respective language code subfolders. Same for the administration part.

SQL scripts

<install>
    <install>
        <sql>
            <file driver="mysql">install.component.sql</file>
        </sql>
    </install>
    <uninstall>
        <sql>
            <file driver="mysql">uninstall.component.sql</file>
        </sql>
    </uninstall>

If you need tables added or altered for your component, put the statements into an sql script. The sql statements will be executed by the installer after copying of the files. Do not forget to indicate the way back and develop a script for cleaning up when the components shall be uninstalled.

Custom install code

<install>
    <installfile>install.component.php</installfile>
    <uninstallfile>uninstall.component.php</uninstallfile>

The code in these files will be executed by the installer upon install/uninstall. See API description below.

Custom Installer Code API

If you need more to be done to the live site upon (un)installation than deploying the files, languages, and executing SQL statements, the installer files are your way. For example, you might need to update existing data entries in the tables during an upgrade installation. Indicate the scripts in the manifest file (see above), and the code will be executed after deployment.

The install script should define exactly one function:

function com_install()

The uninstall script, respectively, should also define exactly one function:

function com_uninstall()