Skip to content

package.xml ​

XML schema: package.xsd · Linking and validation.

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 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="https://www.quiqqer.com/docs/schemas/2.x/package.xsd">
    <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. For example, quiqqer/ai-mcp 1.5.0 and later reads mcpSkill providers for MCP skill registration.

xml
<provider>
    <mcp src="\Vendor\Package\MCP\Provider"/>
    <mcpSkill src="\Vendor\Package\MySkillProvider"/>
</provider>

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 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="https://www.quiqqer.com/docs/schemas/2.x/package.xsd">
    <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 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="https://www.quiqqer.com/docs/schemas/2.x/package.xsd">
    <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 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="https://www.quiqqer.com/docs/schemas/2.x/package.xsd">
    <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.