[UPDATE] CF4 v4.1.0 to v4.2.0

Changelogs für Sprachdatei- und Templateentwickler

 
cback
Admin
Avatar
Geschlecht:
Herkunft: Saarland
Alter: 38
Homepage: cback.net
Beiträge: 17610
Dabei seit: 12 / 2003
Betreff:

Re: [UPDATE] CF4 v4.1.0 to v4.2.0

 · 
Gepostet: 20.09.2017 - 22:41 Uhr  ·  #17
Hi Fragz,

also von 4.1 auf 4.2 hat sich an den dafür zuständigen Dateien nichts mehr geändert, ich habe gerade auch den Test gemacht, das funktioniert noch.

Ich denke die betroffenen hatten eventuell noch eine 4.0 im Einsatz oder hatten die ACP Dateien beim Update nicht richtig überschrieben, damit der neue Code aktiv wird. Bei der 4.0 lag das Problem definitiv auf CF4 Seite, aber jetzt mit dem Zwischenschritt vorm Dateikopieren kann es da zu keinem Fehler mehr kommen, da er dann definitiv die Versionsnummer aus der alten package_info.php nimmt und diese im neuen Plugin an die Update-Routine weitergibt. (Beim 4.0 kam das Problem, da es in einem einzigen Schritt getan wurde, was manchmal die Dateien schneller kopiert hat als er die Funktion getriggert hat oder das er Variablen wieder überschrieben hat - das wurde ja dann in der 4.1 komplett geändert in 2 Steps.).

Generell brauchst Du aber auch für Plugin Versionen kein Config-Wert in der DB zu erzeugen: wichtig ist nämlich die Versionskennung in der package_info.php, die eben auch für das Update benutzt wird. Die ist dann letztendlich auch für die Pluginversion ausschlaggebend.

Ich sehe da bei Dir aber eventuell noch einen anderen Fehler (ich sehe nicht wo Du das Feld erzeugst aber vielleicht gibts damit ja schon ein Problem):
Code
$Core->set_config('social_like_version', '1.2.0', false, true); 


Du setzt den Update in der "DYNAMIC" Tabelle nicht in der "CONFIG" Tabelle. Deine Threema DB Eintragung ist aber in der CONFIG eingetragen. Steht Deine Versionskennung auch in der CONFIG oder hattest Du die explizit in der DYNAMIC? Falls es in der Config steht müsste das so aussehen:
Code
$Core->set_config('social_like_version', '1.2.0', false, false); 


(also zweiter Wert auch auf false, damit er die CONFIG nimmt, nicht die DYNAMIC und den Cache auch danach neu aufbaut).



Aber ein Fehler in der 4.2 sehe ich an der Stelle nicht. Hab gerade eins meiner Test-Plugins durchgejagt lokal + im online testforum, da liefen alle Queries durch und die module_update Funktion wird mit dem richtigen Versionswert aufgerufen. Denke also mal da war entweder bei den Betroffenen noch etwas falsch (vielleicht auch nur ein Dateirecht im Pluginordner, sodass er etwas nicht überschreiben konnte) oder noch irgendwo was im Plugin.


Andere spontane Ideen wo man ggf. nach Fehlern suchen könnte wären jetzt nur noch:

In Deinem INSERT Query hast Du es so:
Code
\'fragz_threema_share\', \'1\' , \'1\'


Das letzte Feld ist ein Integer. Möglicherweise lehnen streng konfigurierte DB Server den Query so ab. Kannst es dann mal so versuchen:

Code
\'fragz_threema_share\', \'1\' , 1


Die Hochkomma beim ersten 1 sind OK, das ist ein VARCHAR Feld.


Und ansonsten noch das Cache Management:
Du benutzt ja die CF4 eigene Config-Tabelle für einen Extrawert, das heißt Du müsstest Dich um den Neuaufbau dieses Caches auch selbst kümmern. Eventuell ist der Eintrag schon in der DB, aber die Cache Datei noch veraltet. Du müsstest zusätzlich oben in der Funktion die Cache Klasse nachladen mit:
Code
$Cache = Controller::getClass('Cache');


und nach Deinem DB INSERT nach dem $DB->free(); noch einmal:
Code
$Cache->cache_drop(CONFIG);


damit er auch die neue Config-Tabelle mit dem neuen Zusatzwert lädt.

Also vielleicht ist die DB schon aktuell aber der Cache noch nicht.

Ansonsten hätte ich spontan keine Ideen mehr.


LG,
Chris
Fragz
koffeeinsuechtiger coding freak
Avatar
Geschlecht:
Herkunft: Neuss
Alter: 38
Homepage: fragz.de
Beiträge: 2217
Dabei seit: 03 / 2008
Betreff:

Re: [UPDATE] CF4 v4.1.0 to v4.2.0

 · 
Gepostet: 21.09.2017 - 09:59 Uhr  ·  #18
HiHo,

ah da war es doch.

Das Feld wird bei der Install erzeugt

Code
public function module_install()
    {
        $DB = Controller::getClass('DB');

        $DB->set_sql('INSERT INTO ' . HOOKS . ' (`hook_order`, `hook_name`, `hook_active`, `hook_key`, `hook_sid`, `hook_code`, `hook_module`) VALUES (0, \'Social Like\', 1, \'class_core_header_1\', \'cback\', \'$head_hook .= \\\'<link rel="stylesheet" type="text/css" href="./modules/social_like/templates/css/social.css" media="screen, projection, handheld, tv" />
\\\';\', \'social_like\');');
        $DB->execute();
        $DB->free();

        $DB->set_sql('INSERT INTO ' . CONFIG . ' (`name`, `value`, `numeric`) VALUES
          (\'social_like_version\', \'1.1.0\' , \'0\')');
        $DB->execute();
        $DB->free();
}



Bei dem Update war das case '1.0.0' Schuld.

Code
switch ($old_version) {
            case '1.0.0':

                $DB->set_sql('INSERT INTO ' . CONFIG . ' (`name`, `value`, `numeric`) VALUES
          (\'fragz_facebook_share\', \'1\' , \'1\')');
                $DB->execute();
                $DB->free();

                $Core->set_config('social_like_version', '1.1.0', false, true);

            case '1.1.0':

                $DB->set_sql('INSERT INTO ' . CONFIG . ' (`name`, `value`, `numeric`) VALUES
          (\'fragz_threema_share\', \'1\' , \'1\')');
                $DB->execute();
                $DB->free();

                $Core->set_config('social_like_version', '1.2.0', false, true);


Durch das false beim ersten set_config hat er wohl abgebrochen und ab da nichts mehr weiter durchlaufen
cback
Admin
Avatar
Geschlecht:
Herkunft: Saarland
Alter: 38
Homepage: cback.net
Beiträge: 17610
Dabei seit: 12 / 2003
Betreff:

Re: [UPDATE] CF4 v4.1.0 to v4.2.0

 · 
Gepostet: 21.09.2017 - 13:53 Uhr  ·  #19
Huhu,

joah manchmal übersieht man das. :)

Wenn Du die direkte CF4 Config-Tabelle nutzt für Dein Plugin wäre es noch wichtig, dass Du auch da am Besten vor den Configwert immer Deinen Autornamen schreibst, nicht, dass bei einem Update mal zufällig ein gleichnamiger Configwert dazukommt und es dann Kollisionen gibt. Außerdem ist noch zu sagen: Die set_config prüft auf bereits existierende Configwerte. Falls Du also gerade mit INSERT installiert hast würde set_config im nächsten Installschritt noch nichts machen, weil er den Wert in dem Moment noch nicht kennt. Also ggf. dann das per UPDATE-Query realisieren (nur beim installer, im Plugin kannst Du dann get_config und set_config verwenden wie gewohnt) und danach manuell den Config-Cache droppen (wie in meinem Code vorher).


Auch eine Falle ist übrigens:
Beim Updaten musst Du auch daran denken ggf. geänderte Hookpoints auch zu aktualisieren.
Da diese keine Arbeitsdaten speichern kannst Du sie beim Updaten aber auch einfach deinstallieren (nur die Hooks!) und danach nur die Hooks nochmal installieren.

Ich persönlich mache wenn das so umfangreich ist gerne den Hook-Install in eine eigene Funktion in der package_setup, die ich dann bei dem eigentlichen installer und beim updater aufrufen kann und so doppelten Code vermeide.

In meinem Plugin "CBACK AccountSwitcher" kannst Du in der package_setup.php so ein konstrukt sehen, falls Du da ein Beispiel möchtest. :)


Vielleicht so als kleiner Hinweis noch nebenher, man denkt da gerade wenn man es zum ersten Mal macht oft nicht dran und dann sucht man sich wieder einen Wolf wo jetzt ein Fehler passiert ist bis man drauf kommt. :) - Also ist keine Kritik sondern nur schon mal ein kleiner Zusatzhinweis. (Und weil ich selber auch schon mal vergessen hatte in der Updatefunktion einen Pluginhook zu aktualisieren und mir dann einen Facepalm über mich selbst verpassen musste. *lol* ;)).

LG,
Chris
Gewählte Zitate für Mehrfachzitierung:   0

Registrierte in diesem Topic

Aktuell kein registrierter in diesem Bereich

Die Statistik zeigt, wer in den letzten 5 Minuten online war. Erneuerung alle 90 Sekunden.