First Module

This guide shows the smallest practical path for creating a QUIQQER extension package.

Use it when you want to add functionality to a QUIQQER project without changing the base system. The result is a Composer package with the type quiqqer-module.

Goal

Create a package that can be installed into a QUIQQER system and extended later with PHP classes, XML configuration, backend controls, events, templates, or console commands.

Requirements

Before starting:

• a working QUIQQER installation exists
• Composer can run in the installation
• you know where package repositories are checked out locally
• PHP and package developer tools are available for your project

See Developer Setup before creating a package from scratch.

Package Directory

Create a new repository or directory for the package:

vendor/module-example/
├─ composer.json
├─ locale.xml
├─ package.xml
└─ src/
   └─ Vendor/
      └─ ModuleExample/
         └─ Module.php

Use the real Composer vendor and package name for your project. Keep the package name stable because installations and other packages will reference it.

Minimal composer.json

Create composer.json:

{
  "name": "vendor/module-example",
  "type": "quiqqer-module",
  "description": "Example QUIQQER module.",
  "license": "GPL-3.0-or-later",
  "require": {
    "php": "^8.1",
    "quiqqer/core": "^2"
  },
  "autoload": {
    "psr-4": {
      "Vendor\\ModuleExample\\": "src/Vendor/ModuleExample/"
    }
  }
}

Use quiqqer-module for normal extension packages. Use quiqqer-template only for template packages.

See composer.json for the full reference.

Minimal package.xml

Create package.xml:

<?xml version="1.0" encoding="UTF-8"?>
<quiqqer>
    <package>
        <title>
            <locale group="vendor/module-example" var="package.title"/>
        </title>

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

package.xml contains QUIQQER-facing metadata such as title, description, images, support links, and provider declarations. Title and description should reference translations from locale.xml.

See package.xml for more fields.

Minimal locale.xml

Create locale.xml for package translations:

<?xml version="1.0" encoding="UTF-8"?>
<quiqqer xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="https://www.quiqqer.com/docs/schemas/2.x/locale.xsd">
    <locales>
        <groups name="vendor/module-example" datatype="php,js">
            <locale name="package.title">
                <de><![CDATA[Beispielmodul]]></de>
                <en><![CDATA[Example Module]]></en>
            </locale>

            <locale name="package.description">
                <de><![CDATA[Beispielmodul für QUIQQER.]]></de>
                <en><![CDATA[Example QUIQQER module.]]></en>
            </locale>
        </groups>
    </locales>
</quiqqer>

Every package needs a locale file. Use locale variables for package metadata, visible XML labels, backend controls, JavaScript, and PHP output.

See Localization for the full reference.

Add A PHP Class

Create a first PHP class:

<?php

namespace Vendor\ModuleExample;

final class Module
{
    public static function name(): string
    {
        return 'vendor/module-example';
    }
}

This class does not change system behavior yet. It verifies that your namespace and Composer autoloading are shaped correctly.

Install The Module In Development

For local package development, use a development install or path repository workflow that points the QUIQQER installation to your checkout.

Then require the package from the QUIQQER installation root:

./console composer require vendor/module-example:dev-main

Use the branch name that exists in your repository, for example dev-main or dev-next-2.x.

If the package is developed from a local checkout, see Development Installs.

Import Package Metadata

Composer install and update workflows usually trigger the required QUIQQER setup steps automatically.

Run setup explicitly when you changed package XML metadata in a local checkout without reinstalling/updating the package, or when you need to re-import package metadata during development:

./console setup

Setup imports package metadata and XML configuration.

Add The First Feature

Choose one small extension point:

Goal	Add
Add backend navigation	menu.xml
Add package settings	settings.xml
React to a system event	events.xml
Add a console command	console.xml
Add backend UI behavior	Controls and Inputs
Add a provider	Package Development

Start with one file and one behavior. Do not add every XML file to a new package unless the package actually needs it.

Check The Package

Before handing the package over:

• run the package's PHPCS and PHPStan tools if configured
• check composer.json validity
• confirm locale.xml contains at least the package title and description
• run setup in a development installation
• verify the package appears as installed
• verify the first feature manually in the administration interface or CLI

Use the package's own tooling as the source of truth. Current packages commonly use PHIVE tools under ./tools/.

Next Steps

• Package Development
• XML Configuration
• Package APIs
• Development Workflow