Strategie-Frage an WB Insider

[chio]

Hallo, darum geht:
Ich verwende bei meinen Modulen gerne eine "module-settings.php", in der neben den Voreinstellung für die Moduloptionen (was sonst in add.php steht) auch noch ein paar Variable für diverse - globale - Einstellungen sind. Etwa ob in Members Aliases verwendet werden und so Zeug. Dinge, die nur einen fachkundigen Administrator zu interessieren haben, der "Kunde" (Normalbenutzer) soll das gar nicht sehen.

Problem dabei: Bei einem Update werden eventuell gemachte Einstellungen dort wieder überschrieben.
Das gleiche gilt übrigens für die frontend.css

Jetzt habe ich mir folgendes überlegt:
Ich gebe ins Modulverzeichnis kein "module-settings.php", sondern "module-settings.orig.php", dasselbe für die frontend.css.

in add.php gebe ich folgendes an:

$mpath = WB_PATH.'/modules/topics/';
if (!file_exists($mpath.'module-settings.php')) { copy($mpath.'module-settings.orig.php', $mpath.'module-settings.php') ; }
if (!file_exists($mpath.'frontend.css')) { copy($mpath.'frontend.orig.css', $mpath.'frontend.css') ; }
require_once(WB_PATH."/modules/topics/module-settings.orig.php");
require_once(WB_PATH."/modules/topics/module-settings.php");

Die Dateien werden also kopiert und dabei umbenannt, wenn sie _noch_ nicht vorhanden sind.
Könnte das ein Fallstrick werden?
Ist das so vernünftig?

Dass sowohl "module-settings.php", als auch "module-settings.orig.php" includet werden, hat folgenden Grund: In späteren Versionen könnten Variable dazukommen, die berücksichtigt werden müssen. Bereits vorhandene werden aber durch die alten Werte überschrieben.

[erpe]

Hi Chio,

ob das vernünftig ist, kann ich nicht sagen, aber ich mache genau das (ohne den php-code), um mir bei einem update des Moduls die angepassten Formatierungen auf alle Fälle zu erhalten, da ich nicht immer daran denke, dass vor einem Modul update auch noch mal zu sichern.
Bisher konnte ich keine Nachteile dabei erkennen.

Gruss

erpe

[Stefek]

Eine Sicherung der ursprünglichen Settings halte ich für sehr sinvoll.
Grade wenn man an die Loops und andere HTML Gefriemle rangeht, passiert es schon mal, dass man bestimmte Parameter überschreibt, die man doch noch braucht.

Stefek

[BerndJM]

Hi chio,

eigentlich eine sehr vernünftige Überlegung, aber (kann sein, das ich jetzt grade einen graviernden Denkfehler mache) müßte nicht die Reihenfolge des includens umgedreht sein, damit die alten Einstellungen eben nicht überschrieben werden?

Grüßle Bernd

[chio]

Naja, Denkfehler...
Ist etwas verworren, was "Original" ist. Das Original ist die jeweils mit dem Modul mitgelieferte Datei. Es wird kein "Backup" gemacht, sondern eine bereits vorhandene Datei wird einfach nicht mehr angerührt - auch wenn sie alte Werte enthält und/oder nie verändert wurde.
Deswegen muss .orig.php VOR .php geladen werden, weil .orig.php Variable enthalten könnte, die in .php noch nicht vorhanden sind. In diesem Fall gelten dann die neuen Werte.
Beim CSS ist das schwieriger - bis unmöglich. Da werden dann ewig die alten Werte beibehalten.

Allerdings: Ich könnte feststellen, ob beide Dateien verschieden sind und zb. in den Optionen darauf hinweisen. Mal sehen ob das sinnvoll ist.

[Ralf (Berlin)]

Hallo Chio,

grundsätzlich ist dein Ansatz richtig, ich versuche dieses Problem in meinen Modulen seit einiger Zeit über eine MySQL Tabelle zu lösen, funktioniert ebenfalls prima. Hierzu habe ich ein Datenbank Objekt geschrieben, das im Grunde ganz simpel aufgebaut ist - der Vorteil hierbei ist, dass Einträge die noch nicht existieren automatisch mit einem Default Wert angelegt werden, bereits vorhandene Einstellungen werden bei einem Update nicht überschrieben - und den Konfigurationsdialo g für das Backend gibt's quasi "fer umme" oben drauf. Ein praktisches Beispiel findest du im imageOptimizer (class dbImageOptimizerCfg und für das Backend class imageOptimizerContr ol extends dbImageOptimizerCfg)

Da dies sehr gut funktioniert und sich in der Praxis bewährt habe ich vor ähnliche Datenbank Objekte für die Sprachdateien, Templates (der Module) und die CSS Dateien zu schreiben. Bei den Sprachdateien geht es mir vor allen auch darum das Handling zu verbessern, wenn die Sprachdateien tausend Einträge und mehr enthalten (PrintShop) wird die Pflege zur Quälerei und mit der Zeit häufen sich Leichen (Einträge die gar nicht mehr benötigt werden). Hier habe ich ein Rundum Sorglos Paket im Kopf, das dann auch die Übersetzung vereinfachen wird und hilft, Leichen rauszukehren...

Bei den CSS und Template-Dateien ist die Grundidee, dass diese bei der Installation in einer Datenbank abgelegt werden und nur wenn sie noch nicht existieren oder sich funktional geändert haben als physikalische Dateien ins Modul Verzeichnis geschrieben werden - dadurch hat der Anwender ebenfalls freie Hand und nur noch unumgängliche Änderungen überschreiben die Anpassungen, die der Anwender vorgenommen hat.

Die Sprachvariante steht ganz oben auf meiner Liste und wird zeitnah kommen...

Gruß
Ralf

[chio]

Hallo Ralf,
ja, die Sprachdateien, die sind natürlich ebenfalls betroffen.
Aber hier denke ich: Da hat der User nichts darin herumzufrickeln, und wenn er es tut, dann muss er wissen, was er tut. Das würde ja sonst kein Ende nehmen.
Das kann bei einem so umfangreichen Projekt wie deinem Printshop anders sein, aber bei einem DAU-Modul?

Die meisten Sprach-Datei Ausgaben sind im Backend, und da wird es der Durchschnittsuser verzeihen, wenn es gramatikalisch nicht so ideal ist.
Im Frontend wird es dann schwer: 100k Options oder eine module-settings.php, in dem das nötigste untergebracht ist.

Ich habe schon daran gedacht, die alten & neuen settings zu mischen und in eine neue Datei (oder DB-Felder) zu speichern, aber da habe ich nicht das Hirn dazu.

[Ruud]

(Soryy for my English, German writing is not for me )

$mpath = WB_PATH.'/modules/topics/';
if (!file_exists($mpath.'module-settings.php')) { copy($mpath.'module-settings.orig.php', $mpath.'module-settings.php') ; }
if (!file_exists($mpath.'frontend.css')) { copy($mpath.'frontend.orig.css', $mpath.'frontend.css') ; }
require_once(WB_PATH."/modules/topics/module-settings.orig.php");
require_once(WB_PATH."/modules/topics/module-settings.php");

[offtopic]Cool this php coding tag. After 625 posts.. Never knew it existed[/offtopic]

I hope I understand the issue correctly.. Here are my thoughts..

What will happen if you are at version 4.2?
Will it be like:

require_once(WB_PATH."/modules/topics/module-settings.1.0.php");
require_once(WB_PATH."/modules/topics/module-settings.1.3.php");
require_once(WB_PATH."/modules/topics/module-settings.1.4.php");
require_once(WB_PATH."/modules/topics/module-settings.1.7.php");
.......
require_once(WB_PATH."/modules/topics/module-settings.4.1.php");
require_once(WB_PATH."/modules/topics/module-settings.php");

I agree this problem needs a solution.
Some installer routines that will only add settings/css-rules if they do not yet exist might be very handy sometimes.

I have used a nice routine to update the database without losing data and without having to know the previous version. You can find it in this message.
The code was found in the WB2.7 upgrade script, and modified a bit to be used in any upgrade.php.

Something similar for adding css rules to an existing frontend.css (including tests if the rules are not yet existing) could be made too.

Ruud

[chio]

Hi Ruud
So kompliziert wäre das gar nicht:
Es gäbe immer nur

require_once(WB_PATH."/modules/topics/module-settings.orig.php"); //for the module in general, all Versions
require_once(WB_PATH."/modules/topics/module-settings.php"); //maybe changed by the user

//Example:
//1) orig:
$feature = true;
$newfeature = true;

//2)
$feature = false; //dont need this
//------
//result:
$feature = false;
$newfeature = true;

In module-settings sollten nur Variable stehen, die sich auf die ganze Installation auswirken, oder ein paar unwichtige Kleinigkeiten, die man sonst in den Code schreiben würde, weil die Settings (Options) damit überfrachtet wären. Bei "members" zb $use_aliases, weil es ein Chaos geben würde, wenn verschiedene Sections verschiedene Einstellungen haben würden.

Oder die Defaultwerte für die Options....
Die ändern sich doch in Wahrheit ohnehin nie. Aber _wenn_ sie jemand ändert, dann will er nicht, dass sie beim Update überschrieben werden.

CSS: Das zu parsen und neu zu mischen stelle ich mir sehr heikel vor. Ich zb lösche da gerne mal fast alles raus und übertrage es ins template.css. Wenn frontend.css jedesmal neu zusammengemischt wird, hätte ich plötzlich die alten Styles wieder drin stehen. Na, Danke!

Man könnte - zb in der Hilfe zum Modul - einen Schalter machen: "Neue Werte übernehmen". Und dann einfach alles drüberkopiren.