¶ Plugin Update Checker
¶ Überblick
Der Plugin Update Checker prüft automatisch GitHub auf verfügbare Updates aller installierten osTicket-Plugins und zeigt Update-Badges direkt in der Plugin-Liste an (Admin Panel > Manage > Plugins). Kein manuelles Besuchen von GitHub-Repositories mehr, um nach neuen Versionen zu schauen.
Installed Plugins
Plugin Name (instances) Version Status Date Installed
----------------------------------------------------------------------
Markdown Support (2) 1.0.0 [1.2.0] Enabled 2025-01-10
^^^^^^^ klickbares Badge
API Endpoints (3) 1.1.0 [1.1.2] Enabled 2025-01-05
Priority Icons (1) 1.0.3 Enabled 2025-01-08
(kein Badge = aktuell)
¶ Hauptfunktionen
- Automatische Update-Prüfung - Fragt die GitHub Releases API für alle Plugins mit GitHub-URL ab
- Klickbare Badges - Oranges Update-Badge mit Versionsnummer, verlinkt zur GitHub-Release-Seite
- Dateibasiertes Caching - Konfigurierbare Cache-Dauer (Standard: 6 Stunden), verhindert übermäßige API-Aufrufe
- Optionaler GitHub-Token - Unterstützung für Personal Access Token für höhere Rate Limits (5.000 statt 60 Anfragen/Stunde)
- Null Performance-Einfluss - Nur auf der Plugin-Seite aktiv, sofortiger Return auf allen anderen Seiten
- PJAX-Support - Badges werden nach dynamischer Navigation erneut angewendet
- XSS-sicher - URL-Validierung, JSON-Encoding mit
JSON_HEX_TAG - Keine Core-Modifikationen - Output-Buffer-basierte Asset-Injection
¶ Inhaltsverzeichnis
- Voraussetzungen
- Installation
- Konfiguration
- Funktionsweise
- Plugin-Voraussetzungen
- Fehlerbehebung
- Technische Details
- FAQ
¶ Voraussetzungen
| Komponente | Version | Hinweis |
|---|---|---|
| osTicket | 1.18.x | Getestet mit 1.18.x |
| PHP | 8.1+ | Erforderlich |
| PHP cURL | beliebig | Erforderlich für GitHub API-Aufrufe |
| Moderner Browser | ES6+ | Chrome, Firefox, Edge, Safari |
¶ Installation
¶ Schritt 1: Plugin herunterladen
¶ Methode 1: ZIP-Download (Empfohlen)
- Besuche GitHub Releases
- Lade die neueste Release-ZIP herunter
- Entpacke und lade den Ordner
update-checknach/include/plugins/auf deinen osTicket-Server - Führe
composer install --no-devim Plugin-Verzeichnis aus
Endgültiger Pfad: /pfad/zu/osticket/include/plugins/update-check/
¶ Methode 2: Git Clone
cd /pfad/zu/osticket/include/plugins
git clone https://github.com/markus-michalski/osticket-plugin-update-check.git update-check
cd update-check
composer install --no-dev
¶ Schritt 2: Plugin aktivieren
- Melde dich im osTicket Admin Panel an
- Navigiere zu: Admin Panel -> Manage -> Plugins
- Finde "Plugin Update Checker" in der Plugin-Liste
- Klicke auf "Enable"
Das Plugin erstellt automatisch eine Singleton-Instanz und beginnt sofort mit der Update-Prüfung.
¶ Schritt 3: Konfigurieren (Optional)
- Klicke auf "Instances" neben "Plugin Update Checker"
- Klicke auf die Instanz, dann auf "Config"
- Passe die Einstellungen nach Bedarf an (siehe Konfiguration)
¶ Verzeichnisstruktur
include/plugins/update-check/
+-- plugin.php # Plugin-Metadaten
+-- class.UpdateCheckPlugin.php # Haupt-Plugin-Klasse
+-- config.php # Konfigurationsformular
+-- src/
| +-- AssetInjector.php # Output-Buffer-Injection
| +-- FileCache.php # Dateibasierter Cache
| +-- GitHubReleaseChecker.php # GitHub API-Client
| +-- PluginUpdateCollector.php # Update-Datensammler
+-- assets/
| +-- update-badges.css # Badge-Styling
| +-- update-badges.js # DOM-Manipulation
+-- vendor/ # Composer-Autoload
+-- README.md
+-- CHANGELOG.md
¶ Konfiguration
¶ Verfügbare Einstellungen
| Einstellung | Standard | Beschreibung |
|---|---|---|
| Cache-Dauer | 6 Stunden | Wie lange GitHub-API-Antworten gecacht werden |
| GitHub-Token | (leer) | Optionaler Personal Access Token für höhere Rate Limits |
¶ GitHub Rate Limits
| Modus | Limit | Empfehlung |
|---|---|---|
| Ohne Token | 60 Anfragen/Stunde | Ausreichend für weniger als 10 Plugins |
| Mit Token | 5.000 Anfragen/Stunde | Empfohlen für viele Plugins |
¶ GitHub-Token einrichten
Falls du viele Plugins hast oder Rate-Limit-Fehler siehst:
- Gehe zu GitHub Settings > Developer Settings > Personal Access Tokens
- Klicke auf "Generate new token (classic)"
- Vergib einen Namen (z.B. "osTicket Update Checker")
- Keine Scopes nötig - Zugriff auf öffentliche Repositories ist ausreichend
- Kopiere den Token und füge ihn in die Plugin-Konfiguration ein
¶ Funktionsweise
¶ Update-Check-Ablauf
- Die
bootstrap()-Methode des Plugins erkennt, ob der User auf/scp/plugins.phpist - Auf anderen Seiten: sofortiger Return (null Performance-Einfluss)
- Auf der Plugin-Seite: Sammelt Update-Daten für alle Plugins mit GitHub-URLs
- GitHub-API-Antworten werden im Temp-Verzeichnis gecacht (konfigurierbare TTL)
- Output Buffer injiziert CSS und JavaScript vor dem Seitenende
- JavaScript liest Update-Daten und fügt Badges zu den Plugin-Tabellenzeilen hinzu
¶ Versionsvergleich
Das Plugin verwendet PHPs version_compare() mit v-Präfix-Entfernung:
v1.2.0und1.2.0werden identisch behandelt- Nur neuere Versionen lösen ein Badge aus (nicht gleiche oder ältere)
- Pre-Release-Tags werden nicht speziell behandelt
¶ Caching-Strategie
- Erfolgs-Cache: Speichert die neueste Release-Info für die konfigurierte TTL (Standard: 6 Stunden)
- Fehler-Cache: Speichert "kein Ergebnis" für 1 Stunde (verhindert Hammering bei Fehlern/Rate Limits)
- Cache-Ort:
sys_get_temp_dir() . '/osticket-update-check/' - Cache-Format: JSON-Dateien mit
expires_at- unddata-Feldern
¶ Plugin-Voraussetzungen
Damit ein Plugin Update-Checks erhält, muss seine plugin.php eine GitHub-URL im url-Feld enthalten:
<?php return [
'id' => 'vendor:plugin-name',
'version' => '1.0.0',
'name' => 'Mein Plugin',
'url' => 'https://github.com/user/repo', // Erforderlich!
'plugin' => 'class.MyPlugin.php:MyPlugin',
];
Unterstützte URL-Formate:
https://github.com/user/repohttps://github.com/user/repo.githttp://github.com/user/repo
Zusätzlich erforderlich:
- Der Plugin-Entwickler muss GitHub Releases (getaggte Versionen) erstellen, damit Updates erkannt werden
- Der Release-Tag sollte Semantic Versioning folgen (z.B.
v1.0.0oder1.0.0)
¶ Fehlerbehebung
¶ Keine Badges sichtbar
Prüfe:
-
Plugin aktiviert?
- Admin Panel -> Plugins -> Plugin Update Checker muss "Enabled" anzeigen
- Eine Instanz muss existieren und aktiv sein
-
Plugins haben GitHub-URL?
- Öffne die
plugin.phpdes Ziel-Plugins - Prüfe, ob ein
'url' => 'https://github.com/...'-Eintrag vorhanden ist
- Öffne die
-
GitHub Releases vorhanden?
- Besuche das GitHub-Repository des Plugins
- Prüfe, ob veröffentlichte Releases existieren (nicht nur Tags)
-
PHP-Fehlerprotokoll prüfen:
grep "UpdateCheck" /pfad/zu/osticket/include/ost-errors.log -
Cache leeren:
rm -rf /tmp/osticket-update-check/
¶ Rate-Limit-Probleme
Symptome: Badges verschwinden nach vielen Prüfungen.
Lösung:
- 1 Stunde warten (Fehler-Cache-TTL)
- Oder einen GitHub Personal Access Token in den Plugin-Einstellungen konfigurieren (siehe Konfiguration)
¶ Badge zeigt falsche Version
Mögliche Ursachen:
- Gecachte Daten sind veraltet - Cache leeren und Seite neu laden
- GitHub Release verwendet ein unerwartetes Tag-Format
- Das
version-Feld inplugin.phpstimmt nicht mit der tatsächlich installierten Version überein
¶ Technische Details
¶ Architektur
Das Plugin folgt einer sauberen Trennung der Zuständigkeiten:
| Klasse | Verantwortlichkeit |
|---|---|
UpdateCheckPlugin |
Bootstrap, Seitenerkennung, Orchestrierung |
UpdateCheckConfig |
Admin-Konfigurationsformular |
FileCache |
Dateibasiertes Caching mit TTL |
GitHubReleaseChecker |
GitHub API-Client, URL-Parsing, Versionsvergleich |
PluginUpdateCollector |
Iteriert Plugins, sammelt Update-Daten |
AssetInjector |
Output-Buffer-Injection von CSS/JS |
¶ Asset-Injection
Das Plugin verwendet Output-Buffer-Injection (ob_start() Callback) - dasselbe bewährte Pattern wie das Priority Icons-Plugin:
ob_start(function (string $buffer) use ($injector, $updateData): string {
try {
return $injector->inject($buffer, $updateData);
} catch (\Throwable $e) {
error_log('[UpdateCheck] Asset injection failed: ' . $e->getMessage());
return $buffer;
}
});
Warum ob_start()?
| Methode | Problem |
|---|---|
Signal::connect('apps.scp') |
Feuert nur auf dem Apps-Tab, nicht auf der Plugin-Liste |
$ost->addExtraHeader() |
global $ost ist NULL während bootstrap() |
| Externe CSS/JS-Dateien | include/.htaccess blockiert HTTP-Zugriff |
ob_start() Callback |
Zuverlässig, Crash-geschützt mit try-catch |
¶ Sicherheit
-
XSS-Prävention:
- JSON-Encoding mit
JSON_HEX_TAG | JSON_HEX_APOSverhindert Script-Injection - JavaScript URL-Validierung (
isValidHttpUrl()) erlaubt nurhttp:- undhttps:-Protokolle - Kein
innerHTMLfür benutzerkontrollierte Daten
- JSON-Encoding mit
-
SSL-Verifizierung:
CURLOPT_SSL_VERIFYPEER = trueundCURLOPT_SSL_VERIFYHOST = 2bei allen API-Aufrufen
-
Doppel-Injection-Schutz:
- Prüft auf
data-plugin="update-check"vor der Injection
- Prüft auf
-
Crash-Schutz:
- try-catch im
ob_start()-Callback verhindert weißen Bildschirm bei Fehlern
- try-catch im
-
Keine Datenbankmodifikationen:
- Plugin liest nur Plugin-Metadaten und cached in Temp-Dateien
¶ Performance
| Szenario | Auswirkung |
|---|---|
| Nicht-Plugin-Seiten | Null (frühzeitiger Return in bootstrap()) |
| Plugin-Seite, warmer Cache | < 10ms zusätzliche Ladezeit |
| Plugin-Seite, kalter Cache | ~5s pro Plugin (cURL-Timeout), danach gecacht |
| cURL-Timeout | 5 Sekunden pro Anfrage |
¶ FAQ
¶ Allgemeine Fragen
F: Prüft das Plugin auch seine eigenen Updates?
A: Ja! Da das Plugin selbst eine GitHub-URL in seiner plugin.php hat, prüft es auch seine eigenen Updates.
F: Was passiert, wenn GitHub nicht erreichbar ist?
A: Das Plugin cached Fehler für 1 Stunde und gibt graziös zurück. Kein Badge wird angezeigt und keine Fehler werden dem Benutzer angezeigt. Fehler werden im PHP-Fehlerprotokoll protokolliert.
F: Funktioniert es mit privaten GitHub-Repositories?
A: Nur wenn du einen GitHub Personal Access Token konfigurierst, der Zugriff auf das private Repository hat. Ohne Token sind nur öffentliche Repositories zugänglich.
F: Was passiert, wenn ich das Plugin deaktiviere?
A: Die Badges verschwinden sofort. Keine Daten werden verändert - das Plugin injiziert nur CSS/JS in die Seitenausgabe.
¶ Technische Fragen
F: Warum werden Assets inline geladen statt als externe Dateien?
A: Die include/.htaccess von osTicket enthält Deny from all, was den HTTP-Zugriff auf alle Dateien im include/-Verzeichnis blockiert. Inline-Injection umgeht dies ohne Core-Dateien zu modifizieren.
F: Warum dateibasierter Cache statt Datenbank?
A: osTicket bietet keine allgemeine Cache-API. Dateibasiertes Caching mit sys_get_temp_dir() ist einfach, erfordert keine Datenbankmodifikationen und funktioniert auf allen Systemen.
F: Funktioniert es mit NGINX?
A: Ja. Da alle Assets inline injiziert werden, gibt es keine externen Dateianfragen, die durch Webserver-Konfigurationen blockiert werden könnten.
F: Wie findet das Plugin heraus, welche Plugins geprüft werden sollen?
A: Es verwendet PluginManager::allInstalled(), um alle installierten Plugins zu iterieren, und liest dann die plugin.php-Metadaten jedes Plugins über PluginManager::getInfoForPath(), um das url-Feld zu finden. Nur URLs mit github.com werden geprüft.
¶ Lizenz
Dieses Plugin wird unter der GNU General Public License v2 veröffentlicht, kompatibel mit dem osTicket-Core.
Siehe LICENSE für Details.
¶ Support
Bei Fragen oder Problemen erstelle bitte ein Issue auf GitHub:
Issue Tracker: https://github.com/markus-michalski/osticket-plugin-update-check/issues
Bei der Meldung von Problemen bitte angeben:
- osTicket-Version (Admin Panel -> Settings -> About)
- PHP-Version (
php -v) - Plugin-Version
- Browser-Konsolen-Fehler (F12 -> Console)
- PHP-Fehlerprotokoll-Einträge mit
[UpdateCheck]
¶ Beitragen
Entwickelt von Markus Michalski
Beiträge willkommen!
- Repository forken
- Feature-Branch erstellen
- Pull Request einreichen
¶ Changelog
Siehe CHANGELOG.md für die Versionshistorie.