---
title: "Plugin oder Theme veröffentlichen"
description: "Ein öffentliches GitHub-Repository und eine Anfrage. Keine Warteschlange, kein Konto."
canonical: "https://smabar.com/de/docs/publish/"
lang: de
---

# Plugin oder Theme veröffentlichen

> Ein öffentliches GitHub-Repository und eine Anfrage. Keine Warteschlange, kein Konto.

Kanonische HTML-Fassung: https://smabar.com/de/docs/publish/ · Sprache: de · Herausgeber: smabar (https://smabar.com)

---

Jeder kann ein Plugin oder Theme im Community Store listen. Der Store liest öffentliche GitHub-Repositories, prüft die Form dessen, was er findet, und listet es sofort.

## Was das Repository braucht

- Ein Plugin: `smabar.json` im Wurzelverzeichnis für ein einzelnes Plugin oder `plugins/<id>/smabar.json` für mehrere. Die `id` im Manifest ist die Store-Kennung; Kennungen gehören dem, der sie zuerst beansprucht, Plugins und Themes sind getrennte Namensräume.
- Ein Theme: `themes/<name>.json`.
- Eine `LICENSE`-Datei im Wurzelverzeichnis. Ohne sie wird das Repository abgelehnt.
- Eine `README.md` neben dem Manifest. Der Store zeigt sie auf der Plugin-Seite.
- Keine Symlinks und keine Git-Submodule irgendwo in einem Plugin-Ordner, und höchstens zweihundert Ordner darunter.

Hat dein Agent das Plugin gebaut, bitte ihn, das Repository vorzubereiten; er kennt das Manifest-Format und kann die README schreiben.

## Versionen

Die `version` im Manifest ist die Update-Einheit: erhöhen und pushen, und jede Installation bekommt die neue Version angeboten. Ein Release-Tag `v<version>` (einzelnes Plugin) oder `<id>-v<version>` (Sammlungen und Themes) heftet die gelistete Version an dieses Tag; ohne Releases listet der Store den Standard-Branch. Ein Tag, dessen Version von der Datei abweicht, wird abgelehnt, nie still korrigiert.

## Einreichen

Eine Anfrage prüft die Plugins und Themes deines Repositorys:

```sh
curl -X POST https://store.smabar.com/submit \
  -H 'content-type: application/json' \
  -d '{"url":"https://github.com/<owner>/<repo>"}'
```

Die Antwort nennt jedes gefundene Plugin und Theme mit `accepted` oder `rejected` und bei einer Ablehnung die verletzte Regel. Pro Repository werden **höchstens 20 neue Plugins und Themes zusammen innerhalb rollender 24 Stunden** veröffentlicht. Updates bereits gelisteter Einträge verbrauchen keine Plätze. Weitere Einträge werden zunächst abgewiesen; sobald das Repository gelistet ist, versucht der stündliche Crawl sie erneut, wenn Plätze frei werden – auch ohne weiteren Commit. Löschen von Einträgen oder Umbenennen des Repositorys setzt das Limit nicht zurück.

Zehn Einreichungsversuche pro Stunde und Adresse sind erlaubt. Zusätzlich darf eine Adresse standardmäßig höchstens **fünf neue Repositories von drei verschiedenen GitHub-Konten innerhalb von 24 Stunden** einreichen; IPv6-Adressen teilen sich das Kontingent ihres /64-Netzes. Dasselbe Repository erneut einzureichen verbraucht keinen weiteren Platz im Quellenlimit. Bei HTTP 429 nennt die Antwort die Wartezeit. Der Betreiber kann ganze Repositories oder GitHub-Konten einschließlich zukünftiger Einträge sperren; gesperrte Quellen erhalten HTTP 403.

## Was der Store nicht tut

Er prüft keinen Code, führt ihn nicht aus, signiert ihn nicht und hostet ihn nie. Clients laden von GitHub, prüfen den Inhalt gegen den signierten Katalog und zeigen jede Voraussetzung vor der Installation. Beliebtheit ist kein Sicherheitssignal, und der Store tut nicht so. Stellt sich eine Version als schädlich heraus, wird sie gesperrt, was sie auf jedem Rechner deaktiviert, aber nichts löscht.