Hi
Es ist enorm schwerig, Pluginupdates mit nur einer update.meta zu schreiben. Es ist zwar durch geschickte Queries möglich und irgendwie kann man wohl auch php-code in meta-Dateien unterbringen, aber ein Updatesystem wie es bei Systemupdates mit den Versionsabhängigen SQLs sollte bei Plugins auch vorhanden sein.

Gruß, Peter

Grundsätzlich kannst du in die 'update.meta' Datei auch PHP schreiben,
einfach mit dem Preamble '<?php' in der 1. Zeile einleiten.
Für die von dir geforderte Funktionalität fehlt einfach nur die übergabe der aktuellen Plugin-Version an das Update-Script(meta), dann könnte man das selbst in dem Update-Script(meta) verarbeiten, wenn man die eigene Versions-Nr kennt.

Ansonsten, ja das wäre ein schönes Feature

Hi
nuja dazu wollte ich in der Pluginname_meta.php ein Define mit der version einbauen, aber prinzipiell sollte auch das besser abstrahiert werden, z.B. so wie das bei dem Systemupdates gelöst ist, wo automatich alle SQL-Updates von der aktuellen Version ausgehend eingespielt werden.

Gruß, Peter

Nunja zunächst nicht schlecht gedacht,
aber bedenke das das Update Script von SF nix anderes mach:
1. Select in der Db die 'alte Version'
2. Ausführen aller Updates von Version > 'alte Version'
... thats it
Das Problem ist das die Update Methode erst aufgerufen wird wenn das Plugin in der Db schon aktualisiert ist. Grundsätzlich war das ganze nur dazu gedacht mal ein paar Values einzuspielen
Deine 'aktuelle Version' ist ja in der Datei 'pluginname.cmsplug' enthalten, brauch also nicht (und soll auch nicht) in die 'pluginname_meta.php'
(die Information wäre nach einem ändern der Version über 'Administration->Plugins->Plugin bearbeiten' ehe wieder hinfällig).
'pluginname.cmsplug' ist eine XML-Datei die beim Download eines Plugins erzeugt wird und alle Daten des Plugins enthält und
beim Upload wieder gelesen wird (grundsätzlich wie bei Modulen).
Um das ganze richtig zu lösen müsste man wohl einiges umbauen.

Gruß

Hmm..
Okay also kann ich aus der update.meta garnicht feststellen welche Version vorher installiert war.
Also ist eine Erweiterung der class.plugin_meta.php nur noch wichtiger
Eine Idee:
Die Metadateien bleiben aus kompatibilitätsgründen erhalten, primär wird aber alles über die pluginname_meta abgewickelt wird. In dieser Datei könnten die Methoden install(), update($from) und uninstall() überschrieben werden. Von hier aus können ja ohne weiteres DB-Objekte erstellt werden und Queries abgesetzt werden, bei update abhängig des in $from angegeben Wertes.

Gruß, Peter

Soo

Also aus meiner sicht muss da was passieren
Ich hab mich jetzt ein weilchen mit dem Workaround rumgeplagt, die _call_files-Methode in der einenen plugin_peta zu überschreiben und dann über einen Wert in der values-Tabelle die Version zu identifizieren und in der update.meta als PHP-Script das ganze auszuwerten, aber das funktiniert scheinbar (bei mir) nicht in der client_update.meta und das debuggen ist extrem kompliziert (Änderungen müssen immer erst als cmsplug exportiert werden, dann eine alte Version importiert und die neue drüber-geupdatet. Alle Debug-Ausgaben müssen in eine Datei erfolgen weil echo-Ausgaben ignoriert werden, ...

Kann man da nich was machen? Updates werden immer wichtiger werden, je komplizierter die Plugins werden. Ich möchte garnicht an den Newsletter denken :-/

Gruß, Peter