WebsiteBaker Support (2.12.x) > Modules

rss-feed-all

<< < (2/4) > >>

jacobi22:
es gibt schon einige "Kleinigkeiten", z.b. die Umbenennung der config.default.php in eine config.php im Install- und im Upgrade-Prozess mit der Folge, das die (user-eigene) Datei config.php nicht gefunden wird, weil das Script im falschem Ordner sucht (rss-feed-all statt rss_feed_all) und dementsprechend neu erstellt und damit überschrieben wird.

Und die view soll nicht laufen, weil sie die include.php nicht findet

Martin Hecht:
Bin gerade auf dem Sprung, aber zwei Sachen, die mir im Moment nicht ganz klar sind:

Was passiert mit der Addons-Tabelle bei einem solchen upgrade, bei dem sich der Installationsordner ändert? Stehen da dann zwei Module mit unterschiedlichem Pfad drin?

Und was passiert beim Upgrade mit dem alten Ordner? Der bleibt auch noch rumfliegen und wenn man später manuell die Module neu lädt, welches wird dann gefunden?

jacobi22:

--- Quote from: Martin Hecht on December 12, 2018, 03:36:23 PM ---Was passiert mit der Addons-Tabelle bei einem solchen upgrade, bei dem sich der Installationsordner ändert? Stehen da dann zwei Module mit unterschiedlichem Pfad drin?

Und was passiert beim Upgrade mit dem alten Ordner? Der bleibt auch noch rumfliegen und wenn man später manuell die Module neu lädt, welches wird dann gefunden?

--- End quote ---

sowohl die alten Tabellen wie auch die alten Ordner bleiben bis zu einer ausgelösten Aktion unberührt. In der addons-Tabelle werden dann (erst einmal) zwei Module registriert.
Mit entsprechendem Code in der upgrade.php des jeweiligen Modul's läßt sich der Spaß dann wieder korrigieren, Tabellen und Ordner, die nicht benötigt werden, auch wieder entfernen. z.b. mit


--- Code: ---// Delete table alte module tabellen
    $sql = 'DROP TABLE IF EXISTS `'.TABLE_PREFIX.'mod_alte_tabelle`';
    $database->query($sql);
--- End code ---

analog der alte Ordner über die bekannten PHP-Funktionen

jacobi22:
um es weiter auszuführen....
in diesem Fall (RSS-Feed-All) ist es ja recht einfach, keine Datenbank, drei Aufrufe in den Scripten und die Github-Links (keine Ahnung, ob man das dort auch anpassen muß)

vom Grundprinzip gibt es ja eine neue Modulversion, da die aber mit den bereits registrierten Modulen nicht übereinstimmt, wird es auf jeden Fall eine Neuinstallation. Der Name des ZIP spielt keine Rolle, mit Bindestrich oder Unterstrich ist egal.
Je nach Modul gibt es entweder eine install-struct.sql, eine install-upgrade.sql und / oder eine install.php sowie eine upgrade.php
Install-Prozeß sollte klar sein, hier wird, egal ob SQL-Datei oder PHP mit den neuen Namen gearbeitet.
Der Install setzt ja voraus, das weder Ordner noch Tabellen bestehen, meckert, wenn der Ordner schon vorhanden ist und überschreibt gnadenlos DB-Tabellen mit gleichem Namen.
Ist das Modul bereits mit anderem Namen installiert, gäbe es nun zwei Module und dazu die entsprechenden DB-Tabellen (wenn im Modul genutzt)

Arbeitet das Modul mit Datensätzen, wäre es schade, wenn diese nun verloren gingen, von daher würde ich versuchen, die Tabellen des alten Moduls zu kopieren oder diese umzubenennen. Dies ließe sich schon im Install machen, wenn geprüft ist, ob die alten Tabellen vorhanden sind (abfragen, ob die alte Tabelle vorhanden ist, mit if-else einen Schalter setzen, wenn JA, mit CREATE TABLE alte_tabelle LIKE neue_tabelle kopieren, wenn nein, nur neue erstellen.
Im Anschluß, neue Tabelle prüfen und mit DROP TABLE IF EXISTS die alten Tabellen löschen (wenn kopiert wurde).
Nun noch Verzeichnis löschen und die Addons-Tabelle bereinigen

Anhaltspunkte gibt es in der admin/modules/uninstall.php und im großen upgrade-script.php

Martin Hecht:
Sowas in der Art hatte ich befürchtet. Bei dem Snippet ist es ja wie du sagst relativ einfach. Um es sauber zu machen, könnte ich die config.php aus dem alten Pfad, falls vorhanden, herkopieren, dann die Deinstallation des alten Moduls irgendwie anstoßen und schließlich die neue Installation. Ich muss jedenfalls den alten Ordner loswerden und in der Tabelle, in der die installierten Addons geführt sind, am Ende nur och einen Eintrag für das Modul und zwar mit dem richtigen, neuen Pfad drin stehen haben. Am besten führe ich mir die entsprechenden Passagen des Core mal selbst zu Gemüte, so als Gute-Nacht-Lektüre und dann schau ich mal wie man damit am besten umgeht...
- oder die Modulverwaltung würde Bindestriche im Ordnernamen in einer der kommenden Versionen wieder zulassen, das wäre natürlich auch eine Lösung des Problems ;)

@Dietmar, danke für die Wünsche und CHANGLOG schiebe ich nach unten, hab ich bei einem der anderen Module letztens auf Franks HInweis auch schon gemacht.

Navigation

[0] Message Index

[#] Next page

[*] Previous page