Skip to content

package.xml

package.xml describes package metadata that QUIQQER can show in package management, marketplaces, backend views, and package integrations.

Use it for package title, description, images, support links, copyright information, supported languages, and provider declarations.

Basic Structure

Create package.xml in the package root.

xml
<quiqqer>
    <package>
        <title>
            <locale group="vendor/package" var="package.title"/>
        </title>

        <description>
            <locale group="vendor/package" var="package.description"/>
        </description>
    </package>
</quiqqer>

Use locale references for title and description instead of hard-coded text. Keep the actual translations in locale.xml.

Images And Previews

Use <image> for the main package image and <preview> for additional preview images.

xml
<image src="URL_OPT_DIR/vendor/package/bin/images/logo.jpg"/>

<preview>
    <image src="URL_OPT_DIR/vendor/package/bin/images/preview/preview-1.png"/>
    <image src="URL_OPT_DIR/vendor/package/bin/images/preview/preview-2.png"/>
</preview>

Use package asset paths for images that belong to the package. Current packages commonly use URL_OPT_DIR/vendor/package/... for public package assets.

The <support> block documents where developers and administrators can find help and package sources.

xml
<support>
    <email><![CDATA[support@example.com]]></email>
    <forum><![CDATA[https://community.example.com]]></forum>
    <source><![CDATA[https://dev.example.com/vendor/package]]></source>
    <issues><![CDATA[https://dev.example.com/vendor/package/issues]]></issues>
    <wiki><![CDATA[https://dev.example.com/vendor/package/wikis/home]]></wiki>
</support>

Use stable URLs that match the repository and support process for the package.

Use <copyright> for package owner and license information.

xml
<copyright>
    <name><![CDATA[Vendor Name]]></name>
    <license><![CDATA[GPL-3.0+]]></license>
</copyright>

If the package has multiple licenses, declare each license explicitly.

Provider Declarations

Packages can declare provider classes in <provider>. Providers connect the package to platform or domain extension points.

xml
<provider>
    <cookie src="\Vendor\Package\CookieProvider"/>
</provider>

The child node name is the provider type. The src attribute is the PHP class that implements the provider. Provider classes should be fully qualified and autoloadable through Composer.

xml
<provider>
    <auth src="\Vendor\Package\Auth\Provider"/>
    <desktopSearch src="\Vendor\Package\BackendSearch\Provider"/>
    <installationWizard src="\Vendor\Package\Installation\Wizard"/>
</provider>

Each provider type defines its own expected contract. For example, desktopSearch providers implement QUI\BackendSearch\ProviderInterface, while installationWizard providers implement QUI\InstallationWizard\InstallationWizardInterface.

QUIQQER core provides platform provider types such as auth, desktopSearch, installationWizard, rest, and mcp. Other packages can add additional provider APIs by reading provider declarations from installed packages.

Only declare providers that the package actually implements.

Real Package Shape

A module can combine localized metadata, previews, support links, and Composer metadata. quiqqer/bricks is a good module reference for package metadata, image previews, support links, and Composer alignment.

xml
<quiqqer>
    <package>
        <title>
            <locale group="quiqqer/bricks" var="package.title"/>
        </title>

        <description>
            <locale group="quiqqer/bricks" var="package.description"/>
        </description>

        <image src="URL_OPT_DIR/quiqqer/bricks/bin/images/Logo.jpg"/>

        <preview>
            <image src="URL_OPT_DIR/quiqqer/bricks/bin/images/preview/Bricks_1.jpg"/>
            <image src="URL_OPT_DIR/quiqqer/bricks/bin/images/preview/Bricks_2.jpg"/>
        </preview>
    </package>
</quiqqer>

A package can declare providers when it implements a platform extension point:

xml
<quiqqer>
    <package>
        <title>
            <locale group="quiqqer/cache" var="package.title"/>
        </title>

        <description>
            <locale group="quiqqer/cache" var="package.description"/>
        </description>

        <provider>
            <cookie src="\QUI\Cache\CookieProvider"/>
        </provider>
    </package>
</quiqqer>

A template package can use the same metadata structure without domain providers:

xml
<quiqqer>
    <package>
        <title>
            <locale group="quiqqer/template-presentation" var="package.title"/>
        </title>

        <description>
            <locale group="quiqqer/template-presentation" var="package.description"/>
        </description>

        <image src="URL_OPT_DIR/quiqqer/template-presentation/bin/img/Logo.png"/>
    </package>
</quiqqer>

Practical Checklist

Before publishing package.xml:

  • Use localized title and description entries.
  • Store package images under package assets and reference them with URL constants.
  • Add support links that match the repository and issue tracker.
  • Declare copyright and license information.
  • Declare only implemented providers.
  • Keep provider classes autoloadable through Composer.
  • Keep package metadata consistent with composer.json.

Released under GPL-3.0-or-later.