Uninstall - notwendig? In welchem Umfang?

[webald]

Ist es notwendig zu einem Modul neben der Install-Funktion auch eine Uninstall-Funktion zu haben?

Soll neben dem deaktivieren eines Moduls auch Daten geändert oder gelsöcht werden? Sollten Einstellungen in der Tabelle configuration auf einen Null-Wert oder vergleichbar gesetzt werden oder der Key ganz ausder Tabelle gelöscht werden?

Man bedenke den Nachteil beim Löschen eines Keys: wird dieser irgendwo anders im Code benutzt gibt es einen Fehler (fehlender Key) und Teile des Shops funktioieren u. U. nicht mehr.

Gleiches gilt für vom Modul angelegte Spalten in Datenbanktabellen oder sogar komplette Tabellen. Löschen?

Oder wollt Ihr lieber manuell entfernen?

Linkback: https://www.modified-shop.org/forum/index.php?topic=32671.0

[hendrik]

Du redest von Zahlungs-, Versand- und Zusammenfassungsmodulen?

Im Uninstall stellst du den Zustand wieder her wie vor der Installation. Alles was du bei der Installation aufbaust sollte rückstandslos wieder entfernt werden.

Wenn du die configuration-Keywords noch woanders im Shop hart gecodet hast. Ist nicht so toll gelöst. Eigentlich sollten die Module für ihre Daten verantwortlich sein. Wenn schon denn schon. Prüfe vor der Verwendung der fremden config-Keywords deren Existenz.

if( defined('MODUL_WERT') ) {
  .......
} else {
  ...ausweichroutine wenn nicht definiert ....
}

Oder man vermeidet die Deinstalltion deaktiviert nur. Deine Admins (Shopbetreiber) müssen instruiert werden.

Gruß
hen

[webald]

Es gibt ja noch mehr Modul-Möglichkeiten, ggf. auch neue Möglichkeiten in zukünftigen Versionen. Es besteht ja durchaus die Möglichkeit, dass Module Daten und Einstellungen anderer Module nutzen oder aufeinender aufbauen. etwa sowas wie lfd. Rechnungsnummer, PDF-Rechnung, Dokumenten-Archiv.

Löscht man alles was zum Modul gehört, oder ganze Tabellen, sind ja u. U. wichtige Bewegungsdaten weg. Da kann "rückstandslos entfernen" unerwünscht sein.

[Gulliver72]

Da man relevante Daten, wie Rechnungen sowieso extra sichern sollte, dürfte das auch keine Rolle spielen.

Wenn Module aufeinander aufbauen, muß in der Deinstallation geprüft werden, ob entsprechende Module vorhanden sind. Wenn ja, muß eine Warnung ausgegeben werden und Abbruch. Gegebenfalls müssen alle abhängigen Module deinstalliert werden. Wie bei jeder modularen Software mit Installation/Deinstallationroutine.

Wenn ein Modul mit Abhängigkeit auf den Markt kommt, muß das jeweilige Basismodul mindestens in der Deinstallationsroutine auf das neue Modul gepatcht werden.

Edit: ggf. kann die Routine auch Wahlmöglickeiten beinhalten. Macht dann aber auch alles etwas komplizierter und fehleranfälliger

[p3e]

Dann müsste aber jedes aktivierte Modul irgendwo hinterlegen, welche Tabelleneinträge es nutzt. Nur dann kann das Modul bei der Deinstallation so vorgehen wie von Gulliver72 vorgeschlagen.

[webald]

Ich weiss, dass ich in letzter Zeit immer mal wieder eigenartige Fragen stelle, aber ich bin der Meinung, dass eine Design-Richtlinie oder Best-Practice für Eigententwicklungen notwendig ist/wird.

Nachdem die Version 2.0 nun als Testversion öffentlich zugänglich ist, möchte ich mal auf https://demo.modified-shop.org/tags/modified-2.00/admin/accounting.php?page=1&cID=1 hinweisen. Was meint Ihr wofür der neue Bereich "Zugriffsbereich einfügen" ist? Damit werden neue Spalten in admin_access angelegt, und somit auch Rechte für neue Module/Dateien vergeben. Erweiterungen werden also leichter zum Einbau werden - gekoppelt mit der Gefahr, dass jeder wild losprogrammiert.

Nun komme ich zurück zu meinem Ausgang: Installations-Funktion (auch da bleibt die Frage nach einem einheiltichen wie noch zu stellen) und dem Eingangsposting mit der Frage Deinstallation und in welchem Umfang.

Eine Design-Richtlinie soll aber noch mehr enthalten. Was muss im Code enthalten sein? Wie ist der schematische Standard-Aufbau eines Moduls? Wo werden Module installiert, eigene Dateien hinkopiert (z. T. geklärt), ....

Und am Ende hoffen wir alle drauf, dass Dokuman eine schöne Zusammenfassung schreibt...