Erweiterungen

Warum viele SuiteCRM-Plugins Updates erschweren

SuiteCRM verdankt einen großen Teil seiner Verbreitung der Erweiterbarkeit. Genau diese Stärke wird in langlebigen Installationen zum Betriebsrisiko: Nicht, weil Erweiterungen per se problematisch wären, sondern weil die Summe der Eingriffe in denselben Kern schwer test- und upgradebar wird. Dieser Artikel beschreibt den Mechanismus, typische Muster und einen Arbeitsansatz für Admins und IT-Leitung – ohne einzelne Community-Projekte pauschal abzuwerten.

1. Was „Plugin-Chaos“ hier bedeutet – und was nicht

Mit „Plugin-Chaos“ ist keine moralische Wertung gemeint und auch kein Aufruf, den Extension Store zu meiden. Gemeint ist ein Zustand der Instanz:

• Viele Packages sind installiert, aber nur ein Teil ist fachlich noch aktiv im Prozess.
• Mehrere Erweiterungen berühren denselben Bereich (z. B. E-Mail, Layouts, Workflows, Dateien).
• Custom Code und Packages sind vermischt; niemand kann in unter einer Stunde sagen, was beim Upgrade „kritisch“ ist.
• Staging existiert nur als Theorie – oder die Staging-Daten sind so veraltet, dass Tests falsche Sicherheit geben.

Das Gegenteil ist nicht „null Erweiterungen“, sondern klare Verantwortung und eine beherrschbare Testmatrix.

2. Warum Upgrades an der Kombination scheitern

Ein SuiteCRM-Upgrade (Patch oder Major) verändert Kernverhalten, UI-Schichten, Abhängigkeiten und oft PHP-Anforderungen. Jede Erweiterung, die an diesen Stellen andockt, muss zur neuen Kombination passen. Die Komplexität wächst nicht linear:

• Zwei unkritische Report-Erweiterungen sind oft unkritisch.
• Zwei Erweiterungen, die beide den Mail-Versand oder denselben Logic-Hook-Punkt belegen, erzeugen Interaktionseffekte.
• Zehn Pakete plus projektspezifische Hooks erzeugen eine Testfläche, die kein Team ad hoc abdecken kann.

Deshalb ist die Aussage „bei uns war das Upgrade problematisch wegen Plugins“ meist ungenau. Präziser: Das Upgrade war problematisch, weil die Instanz vor dem Upgrade nicht upgrade-fähig modelliert und getestet war.

Faktor	Niedriges Risiko (Tendenz)	Höheres Risiko (Tendenz)
Eingriffstiefe	Darstellung, Reports, leichte Felder	Hooks, Schema, Scheduler, Auth, Mail, Storage
Anzahl aktiver Vendoren	1–2 mit Release-Pflege	Viele, teils ohne SuiteCRM-8-Release
Custom Code	Dokumentiert, in Repo, getestet	„Irgendwo im custom/“, Autor weg
Staging	Produktionsnah, wiederholbar	Nur Produktiv oder leere Demo
Besitz	Package-Owner benannt	„Läuft seit Jahren, niemand anfassen“

Tabelle als Orientierung, keine Scorecard. Eine einzige tief greifende, ungewartete Erweiterung kann riskanter sein als fünf oberflächliche.

3. Typische Reibungspunkte im Detail

3.1 Fehlende Zielversion

SuiteCRM 8 ist architektonisch nicht „SuiteCRM 7 mit neuer Haut“. Packages, die nur für 7.x gepflegt wurden, lassen sich nicht zuverlässig „irgendwie mitnehmen“. Entweder es gibt einen unterstützten Stand für Ihre Ziel-8.x-Linie – oder Sie planen Ersatz, Abschaltung oder Eigenaufwand.

3.2 Doppelte Funktionen

Zwei Lösungen für Rechnungen, zwei Mail-Hilfen, zwei Workflow-Erweiterungen: Fachlich entsteht Doppelpflege, technisch doppelte Hook-Ketten und unklare „Source of Truth“. Vor dem Upgrade lohnt die Frage: Welche Lösung ist führend – und welche nur historisch?

3.3 Custom Code ohne Vertrag

Projektspezifische Anpassungen sind legitim. Ohne Versionskontrolle, ohne kurze Beschreibung („welcher Hook, welches Modul, welcher Business-Fall“) und ohne Testfall werden sie zum blinden Passagier jedes Upgrades.

3.4 Daten- und Dateivolumen

Selbst bei sauberen Packages verlängern große Anhangsbestände und Historien Kopier-, Backup- und Testfenster. Das ist kein Plugin-Problem im engeren Sinn, aber es multipliziert jeden Fehlversuch.

4. Arbeitsmodell: von der Liste zur Entscheidung

Ein brauchbares Vorgehen in vier Runden:

1. Inventar (1–2 Tage Fokus, je nach Größe): Installierte Packages, Versionen, letzter bekannter Maintainer, „produktiv ja/nein“, betroffene Module.
2. Risikoklassen: A = blockiert Kernprozess, B = wichtig aber workarroundbar, C = historisch/optional. Nur A und B müssen vor dem Upgrade eine klare Story haben.
3. Staging mit Absicht: Nicht „einmal upgraden und schauen“, sondern: definierte Testfälle (Login, Lead→Opportunity, Mail, ein Report, ein kritischer Custom-Flow).
4. Entscheidung dokumentieren: behalten (mit Version), ersetzen, abschalten, oder bewusst „nach dem Upgrade neu bauen“. Undatiert „später“ ist keine Entscheidung.

5. Wenige abgestimmte Module vs. viele isolierte Add-ons

Abgestimmte Modul-Suiten ändern die Risikostruktur: weniger unabhängige Release-Zyklen, gemeinsame Annahmen zu SuiteCRM-Versionen, oft gemeinsame UX- und Admin-Muster. Das ist kein automatischer Qualitätsbeweis – schlechte Suites existieren – aber die Testfläche wird planbarer, wenn ein Anbieter die Kombinationsmatrix intern mitdenkt.

Isolierte Add-ons bleiben sinnvoll, wenn sie schmal, gut gepflegt und klar begrenzt sind. Das Problem ist die unkontrollierte Anhäufung ohne Eigentümer.

6. Was dieser Text bewusst nicht behauptet

• Keine pauschale Aussage „Community-Plugins sind schlecht“.
• Keine Garantie, dass gebündelte Suiten jedes Upgrade risikofrei machen.
• Keine pauschalen Stunden- oder Kostenersparnisse – die hängen von Inventar und Disziplin ab.

Wenn Sie als Nächstes nur eine Sache tun: Schreiben Sie die Liste der aktiv genutzten Erweiterungen und markieren Sie, wer sie fachlich und technisch verantwortet. Ohne diese Liste bleibt jedes Upgrade ein Ratespiel.

← Zurück zum Magazin