Erweiterungen sicher testen
Eine Erweiterung muss in einer frischen Installation und bei vorhandenen Inhalten funktionieren. Testen Sie die tatsächlichen CMS-Dialoge, die Besucherausgabe und den Upgradeweg. Ein fehlerfreier Installationsbefehl genügt allein nicht.
Den kleinsten Eingriff wählen
Prüfen Sie zunächst, ob eine Einstellung, ein Core-Block mit Custom Template oder ein Theme-Stil genügt. Ein eigener Block ist für neue editierbare Daten sinnvoll; ein Paket bündelt mehrere Komponenten. Das Ändern von concrete/ würde beim Core-Update überschrieben und macht die Ursache später schwer nachvollziehbar. Bewahren Sie die Core-Datei als Referenz auf und implementieren Sie die Erweiterung in Anwendung oder Package.
Abbildung 1: Prüfen Sie vorhandene Funktionen und installierte Erweiterungen, bevor neuer Code entsteht.
Ein Override einer Core-Ansicht braucht einen klaren Zweck und einen Test nach Core-Updates: Markup, Variablen und Assets können sich geändert haben. Für wiederkehrende Reaktionen auf Ereignisse kann ein Event-Listener geeigneter sein als ein tiefer Override. Events und Services beschreibt die Entscheidung.
Einen verlässlichen Prüfpfad aufbauen
Halten Sie Ziel-Core, PHP-Version, Datenbank und installierte Pakete fest. Führen Sie statische Prüfungen für PHP und Assets aus. Testen Sie dann genau die Funktion: Hinzufügen und Bearbeiten eines Blocks, Formularvalidierung, Veröffentlichung, Besucheransicht und Fehlermeldung. Öffnen Sie betroffene Seiten auf schmalem und breitem Bildschirm; prüfen Sie Fokus und Tastatur. Ein Screenshot zeigt das Layout, aber nicht, ob der Bearbeitungsmodus funktioniert.
Ein Test auf leerer Datenbank reicht nicht für ein Paket-Upgrade. Legen Sie eine zweite Installation mit bestehenden Seiten, Dateien und Anfragen an, sichern Sie sie, führen Sie das Upgrade aus und vergleichen Sie die vorhandenen IDs und Inhalte. Wiederholen Sie den Upgrade-Befehl, damit doppelte Composer-Sets, Attribute oder Blöcke auffallen. Für den Inhaltsswap benötigen Sie getrennte Tests für „behalten“ und die explizit gewählte Austauschoption. Package erstellen nennt die Schutzpunkte.
Fehler eingrenzen und dokumentieren
Wenn ein Fehler auftaucht, notieren Sie Auslöser, erwartetes Verhalten, tatsächliches Ergebnis, betroffene Core-Version und die korrigierte Annahme. Prüfen Sie im Core, welcher Dienst oder welche Routine die Aktion tatsächlich ausführt. Ein HTTP-502-Fehler beim Installieren kann etwa ein PHP-Timeout, ein Speicherlimit oder ein abgebrochener Import sein; ohne Log und Datenbankprüfung ist eine zweite Installation riskant.
Überführen Sie eine verallgemeinerbare ConcreteCMS-Erkenntnis in die Projektregeln, statt einen einmaligen Pfad oder Testbenutzer dort einzutragen. Prüfen Sie abschließend, ob ein fremder Redakteur mit normalen CMS-Dialogen arbeiten kann. Ein HTML-Blob aus einer statischen Vorlage erfüllt diese Bedingung nicht, selbst wenn die Besucherseite richtig aussieht.
Weiterlesen
- ConcreteCMS-Erweiterungen planen
- Pakete installieren und aktualisieren
- CIF und Startinhalte verwenden
Quelle: Concrete CMS Dokumentation (EN) · Stand: ConcreteCMS 9.5.7