Erweiterungen entwickeln

Eine Erweiterung ist ein Composer-Paket. Wird sie über red.Commerce ausgeliefert, wird daraus ein unterschriebenes Archiv, das eine Installation selbst einspielt — ohne dass jemand an die Konsole muss.

Dieser Text beschreibt, was dafür stimmen muss. Wie ein Plugin im jeweiligen Produkt eingehängt wird — Ereignisse, Erweiterungspunkte, Oberfläche —, steht im Handbuch des Produkts.

Das Paket #

Holen Sie sich das Startgerüst, statt es abzuschreiben: Im Kundencenter unter Anbieten → So veröffentlichen Sie eine Erweiterung laden Sie ein fertiges Paket herunter — composer.json, Manifest, src/, CHANGELOG.md, README.

Es ist kein Beispiel, sondern das Referenz-Plugin des Produkts: dasselbe, das in unserer CI mitläuft und jeden Erweiterungspunkt benutzt. Bricht der Kern die Plugin-Schnittstelle, fällt es dort auf und nicht bei Ihnen. Ein abgeschriebenes Beispiel altert, und der erste, dem es auffällt, wäre ein Anbieter, dessen Paket abgewiesen wird.

Geben Sie beim Herunterladen Ihre Kennung an, sind Paketname, Namensraum, Klassen- und Dateiname bereits gezogen.

Drei Felder tragen den Vertrag:

Was Kundschaft über Ihre Fassung liest #

Die CHANGELOG.md in Ihrem Archiv, und nicht ein Feld beim Hochladen.

## [1.1.0] — 19.08.2026

> Ein Satz, der diese Fassung einordnet. Wird die Zusammenfassung.

### Hinzugefügt

- Was neu ist. Darf über mehrere Zeilen gehen,
  eingerückt fortgesetzt.

Zulässig sind sechs Überschriften: Hinzugefügt, Geändert, Veraltet, Entfernt, Behoben, Sicherheit. Eine andere wird nicht übergangen, sondern gemeldet.

Ein Abschnitt „Sicherheit" macht die Fassung zum Sicherheitsupdate. Die fließt in jeder Verzugsstufe zum Kunden — auch zu einem Betrieb, der im Rückstand ist. Eine Lücke bleibt eine Lücke.

Die eine Einschränkung #

Eine auslieferbare Erweiterung darf nur PHP und die Pakete ihres eigenen Produkts voraussetzen. Alles andere weist der Bauschritt zurück.

Der Grund steht auf der Gegenseite: Die Zielinstallation entpackt das Archiv und meldet die Erweiterung an — sie löst keine Abhängigkeiten auf. Das ist der Preis dafür, dass kein Betreiber an die Konsole muss, und er ist nur dann keiner, wenn es nichts aufzulösen gibt.

Wer eine echte Fremdabhängigkeit braucht, bekommt kein Archiv. Dann bleibt der gewöhnliche Weg über Composer — mit Konsole, wie bisher. Das ist eine Einschränkung mit Ansage und keine Lücke.

In der Praxis trifft es selten zu. Was ein Plugin üblicherweise braucht — HTTP, Warteschlange, Validierung, PDF — bringt das Produkt bereits mit.

Was ausgeliefert wird #

Nicht das Verzeichnis, sondern ein daraus gebautes Archiv:

• reproduzierbar — sortierte Einträge, flache Zeitstempel, feste Rechte. Zweimal derselbe Quellstand ergibt Byte für Byte dasselbe Archiv. Ohne das ließe sich nach einem Vorfall nicht nachweisen, dass das ausgelieferte Archiv aus dem Quellstand stammt, auf den es sich beruft.
• ohne Tests und Werkbankdateien — tests/, vendor/, .git, node_modules, composer.lock gehen nicht mit.
• mit genau einem Verzeichnis auf oberster Ebene, benannt nach dem Paketteil der Kennung: aus redshop/plugin-versandrechner wird plugin-versandrechner/.
• unterschrieben mit ed25519 unter der Kennung p1, dazu eine SHA-256.

Dieselbe Nummer bedeutet dieselben Bytes #

Ein zweiter Bau derselben Version mit anderem Inhalt wird abgewiesen. Eine Installation, die 1.2.0 geprüft und eingespielt hat, darf darunter nichts anderes vorfinden.

Wer etwas ändert, vergibt eine neue Nummer. Das ist keine Förmlichkeit: Es ist die einzige Art, wie eine fremde Maschine wissen kann, was auf ihr liegt.

Der Weg zum Kunden #

1. Sie prüfen, so oft Sie wollen — im Kundencenter unter „Anbieten" gibt es den Knopf „Nur prüfen". Er packt Ihr Archiv aus, sagt Ihnen, was nicht stimmt, und wirft es sofort wieder weg: kein Vorgang, keine Datei bei uns. Geprüft wird Kennung gegen composer.json, Typ, fremde Abhängigkeiten, Einträge, die aus dem Verzeichnis führen, eine Nummer, die schon ausgeliefert ist.
2. Dann laden Sie hoch. Dafür wird Ihr Konto einem Anbieter zugeordnet, und die Zwei-Faktor-Anmeldung ist Pflicht: Wer Code auf fremde Maschinen bringt, hat mehr Rechte als jemand, der Rechnungen ansieht.
3. Wir sehen es an und geben frei. Dabei wird das Archiv aus Ihrem Upload neu gebaut und unterschrieben — was ausgeliefert wird, ist nie die hochgeladene Datei.
4. Die Erweiterung erscheint im Verzeichnis unter red-commerce.com/erweiterungen.
5. Ein Betrieb erwirbt sie; kostenlose stehen jedem Vertrag ohnehin offen.
6. Die Lizenzantwort seiner Installation nennt sie beim nächsten Abgleich.
7. Eingespielt wird im Backend seines Systems, von einem Menschen. Nichts wird ungefragt installiert.

Warum ein Mensch dazwischen steht

Unter dem ausgelieferten Archiv steht unsere Unterschrift, und ihr vertraut jede Installation. Die maschinelle Prüfung findet, was maschinell entscheidbar ist — sie liest kein PHP und beurteilt nicht, was Ihr Code tut. Solange das so ist, unterschreibt kein Automat.

Eine Ablehnung kommt immer mit Begründung. Wer nicht erfährt, was fehlt, lädt dasselbe noch einmal hoch.

Was wir dabei zusagen #

Was noch nicht geht #

Kostenpflichtige Erweiterungen fremder Anbieter. Der Weg über das Kundencenter steht, aber Abrechnung und Auszahlung brauchen einen Anbietervertrag — Haftung, Widerruf, Anteile. Bis dahin geht der Weg für kostenlose Erweiterungen.

Ihr eigener Signaturschlüssel. Heute unterschreiben wir, und deshalb sehen wir jede Einreichung an. Vorgesehen ist, dass Anbieter künftig selbst unterschreiben und wir nur noch eine Anbieterliste beglaubigen — dann steht unter Ihrem Code Ihre Unterschrift, und ein Sperrfall ist ein Eintrag weniger in unserer Liste. Das kommt mit dem ersten Produkt-Release.

Sprechen Sie uns an. Was gebraucht wird, bauen wir eher selbst, als dass wir es liegen lassen.