PrestaShop-Modulintegrität prüfen und sicher reparieren
Was Modul-Integritätsprüfungen reparieren, wann Migrationen nötig sind und wie Sie fehlende Tabellen, Hooks, Rechte und gescheiterte Reparaturen behandeln.
Nutzen Sie das Modulintegritätssystem von mypresta.rocks, um fehlende Infrastruktur zu finden und unterstützte Reparaturen auszuführen. Diese Prüfungen setzen voraus, dass das Modul sie implementiert; sie sind keine native Reparaturfunktion von PrestaShop. Halten Sie Sicherungen und ausdrückliche Migrationen für Geschäftsdaten, destruktive Schemaänderungen und die Wiederherstellung nach einem Vorfall bereit.
So würden wir vorgehen
Wir würden die fehlgeschlagene Prüfung lesen, bevor wir eine Reparatur wählen. Der Weg hängt von Ihrer installierten Modulversion, gemeinsamen Tabellen, Integrationen, Theme-Platzierungen, dem Shop- und Marktumfang, vorhandenen Daten und den Zugriffsrechten Ihres Teams ab. Unterscheiden Sie fehlende Infrastruktur von verlorenen Datensätzen und bewusster Konfiguration.
Verwenden Sie bei einer wesentlichen Änderung eine private Staging-Kopie mit isolierten ausgehenden Integrationen. Erproben Sie die Reparatur und den betroffenen Ablauf, dokumentieren Sie das Rückgängigmachen der Änderung und planen Sie anschließend die Live-Arbeiten mit einer benannten Person zur Ergebniskontrolle. Eine Datenbankwiederherstellung benötigt einen Plan für Bestellungen und andere Schreibvorgänge seit der Sicherung.
Bei einer vereinbarten Installations- oder Konfigurationsaufgabe umfasst der PrestaShop Module Installation & Configuration Service die Einrichtung und die Prüfung des betroffenen Ablaufs.
Teilreparaturen und Fehler handhaben
- Erstellen Sie eine Sicherung, bestätigen Sie den Wiederherstellungsweg und notieren Sie Modul-, PrestaShop- und PHP-Versionen.
- Sichern Sie die Meldung der fehlgeschlagenen Prüfung und klären Sie, ob das Problem Struktur, Daten, Zugriff oder Konfiguration betrifft.
- Führen Sie die unterstützte Reparatur einmal aus und wiederholen Sie dann die relevanten Prüfungen.
- Lesen Sie PHP- und Anwendungsprotokolle, wenn eine Prüfung weiter fehlschlägt.
- Prüfen Sie die betroffene Funktion mit einem normalen Mitarbeiterkonto und dem richtigen Shop-Kontext, einschließlich des Ablaufs im Frontoffice, falls dieser betroffen ist.
Eine Reparatur kann manche Vorgänge abschließen, bevor ein anderer scheitert. Deuten Sie eine neu erstellte Tabelle oder eine geladene Verwaltungsseite nicht als Nachweis, dass alle Reparaturen erfolgreich waren. Fehlgeschlagener Schema- oder Tab-Abgleich sollte für eine spätere Prüfung offenbleiben, statt eine neue Erfolgsmarkierung zu erhalten.
Verursachen fehlende Datensätze den Fehler, stoppen Sie wiederholte Einrichtungsversuche und stellen Sie die Daten über einen kontrollierten Wiederherstellungsprozess wieder her oder rekonstruieren Sie sie.
Nutzen Sie bei einer ungelösten Reparatur den Leitfaden zu Lizenzierung und Support. Geben Sie die fehlgeschlagene Prüfung, Versionen, den Shop-Kontext, die versuchte Aktion und relevante geschwärzte Protokolle an. Lassen Sie Zugangsdaten und Kundendaten aus dem Ticket heraus.
Deklarationen des mypresta.rocks-Moduls verstehen
Ein Modul kann seine Tabellen, das erwartete Schema, Hooks, Admin-Controller und erforderliche Konfiguration deklarieren. Seine Integritätsprüfungen vergleichen diese Anforderungen mit dem Shop. Gemeinsame Tabellen können mehreren Modulen dienen, unter anderem für Konfiguration und Mitarbeitereinstellungen.
Diese Prüfungen ersetzen weder eine Sicherung noch eine Sicherheitsuntersuchung. Das Neuerstellen einer Tabelle stellt ihre Struktur wieder her, nicht die gelöschten Zeilen.
Additive Reparatur von Migration trennen
Wählen Sie anhand der fehlgeschlagenen Prüfung die unterstützte Aktion und die Grenze, an der Sie stoppen müssen.
| Was Sie sehen | Bereich | Unterstützte Reparatur oder Aktion | Grenze |
|---|---|---|---|
| Die Prüfung meldet eine fehlende Tabelle. | Fehlende Tabellen | Deklarierte Strukturen über den unterstützten Schema- oder Installerweg erstellen. | Verlorene Datensätze erfordern Datenwiederherstellung. |
| Eine deklarierte Spalte, ein Index oder ein Typ weicht ab. | Schemaabweichungen | Unterstützte fehlende Spalten und Indizes ergänzen und unterstützte kompatible Typerweiterungen anwenden. | Inkompatible Typänderungen, Verengungen, das Entfernen von Objekten, Fremdschlüsseländerungen und Umwandlungen von Geschäftsdaten benötigen gezielte Migrationen. |
| Die Prüfung meldet eine fehlende deklarierte Hook-Registrierung. | Hooks | Registrierungen gemäß Deklarationen und dem Umfang aktivierter Shops wiederherstellen. | Vom Händler bewusst entfernte Anzeigeplatzierungen müssen von fehlenden technischen Registrierungen unterscheidbar bleiben. |
| Eine erforderliche Einstellung fehlt. | Konfiguration | Erforderliche Einstellungen melden, die Aufmerksamkeit benötigen. | Keine Zugangsdaten erfinden oder Händlerentscheidungen durch geratene Standardwerte ersetzen. |
| Ein deklarierter Backoffice-Eintrag fehlt oder weicht ab. | Admin-Menüs | Deklarierte Tabs gemäß der Tab-Regelung des Moduls abgleichen. | Änderungen bestehender Tabs hängen von der Abgleichsregelung ab; Reparatur ist nicht auf das Erstellen von Zeilen beschränkt. |
| Die Prüfung meldet fehlende Rollen-Infrastruktur. | Rollen und Zugriff | Erforderliche Rollen-Infrastruktur erstellen, soweit unterstützt. | Mitarbeiterrechte separat prüfen. Die Wiederherstellung einer zuvor vorhandenen, inzwischen fehlenden Berechtigung darf den Zugriff nicht stillschweigend erweitern. |
DDL kann Tabellen sperren oder wegen vorhandener Zeilen, Berechtigungen oder inkompatibler Schemas scheitern. Sichern Sie vor der Reparatur einer Live-Datenbank und testen Sie wesentliche Änderungen in Staging.
Eine fehlende Tabelle nach einer Wiederherstellung bearbeiten
Ein Modul meldet nach einer Datenbankwiederherstellung eine fehlende Tabelle. Bestätigen Sie Tabellenname, Datenbank und installierte Modulversion, bevor Sie etwas erstellen. Enthielt sie Händlerregeln, kann das Erstellen den Strukturfehler beheben, während die Regeln weiterhin fehlen. Stellen Sie die Datensätze über ein kontrolliertes Verfahren aus einer kompatiblen Sicherung wieder her und testen Sie anschließend das von ihnen gesteuerte Verhalten.
Scheitert die nächste Prüfung an einem Index, bewahren Sie beide Ergebnisse auf und lesen Sie den Datenbankfehler. Setzen Sie das Modul nicht als Abkürzung zurück und installieren Sie es nicht neu. Prüfen Sie zuerst, was diese Aktionen entfernen oder initialisieren.
Wissen, wann Prüfungen laufen
Der Infrastruktur-Guard kann eine erfolgreiche Prüfmarkierung bis zu 3.600 Sekunden wiederverwenden. Änderungen an Modulversion, Schema und Controller-Signaturen können frühere Prüfungen erzwingen. Dieser Cache dient der Infrastrukturprüfung und verspricht nicht, dass jede Diagnose stündlich läuft.
Der Guard überspringt CLI-Ausführung und Anfragen mit einem als wahr ausgewerteten Parameter ajax. Andere Prüfungen haben eigene Einstiegspunkte, und Frontoffice-Reparaturen nutzen eingeschränkte Wege. Verlassen Sie sich nicht auf eine beliebige Hintergrundanfrage, um jede Reparatur auszuführen.
Eine Integritätsansicht kann Einzelprüfungen, Reparaturaktionen und Auto-Setup anbieten. Das Modul steuert, welche Prüfungen verfügbar sind und ob eine fehlende kritische Struktur zu dieser Ansicht weiterleitet.
Wiederholbare Reparaturen gestalten
Im Integritätssystem von mypresta.rocks bilden Deklarationen wie getIntegrityConfig(), getHooks() und getAdminControllers() die Grundlage der Prüfungen. Das Schema und die verfügbaren Reparatur-Callbacks bestimmen, was repariert werden kann.
Deklarieren Sie das beabsichtigte Schema einmal und nutzen Sie additiven Abgleich für unterstützte Änderungen. Halten Sie destruktive Änderungen und Datenmigrationen in ausdrücklichen Upgradeschritten.
Wiederholbarkeit hängt vom Vorgang ab. Das Erstellen eines fehlenden Objekts oder eine Prüfung vor Ergänzung einer Spalte kann wiederholbar sein. Ein eigener Installer oder Reparatur-Callback kann Daten schreiben oder andere Nebenwirkungen auslösen; prüfen Sie ihn daher vor Zulassung wiederholter Ausführung.
Prüfen Sie nach Update, Serverumzug oder Datenbankwiederherstellung Deklarationen, Shop-Zuordnungen, Rechte und erforderliche Konfiguration. Testen Sie Fehlerwege einschließlich eines Datenbanknutzers ohne ALTER-Berechtigung und eines vorhandenen Indexnamens mit anderer Definition.
Gemeinsame Tabellen müssen die von anderen Modulen genutzten Daten behalten. Entfernen Sie diese nicht bei der Bereinigung eines einzelnen Moduls.
Fragen an Ihren Entwickler oder Ihre Agentur
- Welche Objekte und Shop-Zuordnungen ändert diese Aktion?
- Kann sie Daten schreiben, Integrationen auslösen oder gemeinsame Tabellen eines anderen Moduls beeinflussen?
- Was belegt den Erfolg und wie wird ein teilweiser Fehlschlag behoben?
Häufige Fragen von Shopbetreibern
Bedeutet eine grüne Prüfung, dass die Funktion funktioniert?
Sie bestätigt die zum Prüfzeitpunkt kontrollierten Anforderungen. Ein zwischengespeichertes Ergebnis kann vor späteren Änderungen entstanden sein. Wiederholen Sie nach der Reparatur die relevanten Prüfungen und testen Sie auch die Kunden- oder Mitarbeiteraufgabe. Nicht deklarierte Abhängigkeiten können weiterhin ausfallen.
Stellt Auto-Setup gelöschte Datensätze wieder her?
Gehen Sie nicht davon aus. Prüfen Sie die unterstützten Aktionen des Moduls und nutzen Sie für fehlende Geschäftsdaten einen getesteten Sicherungs- und Wiederherstellungsprozess.
Sollte ich eine Reparatur ausführen, wenn ein Block verschwindet?
Prüfen Sie zuerst Shop-Kontext, vorgesehene Hook-Platzierung und Theme-Unterstützung. Bei einem bewusst ausgehängten Block ist vor einer Reparatur eine Konfigurationsentscheidung nötig.