Bakery Upgrade / Update 1.0 nach 1.5.6

[instantflorian]

Hallo,

ist irgend jemanden schon mal ein Update eines Bakery 1.0-Shops auf die 1.5.6 gelungen? Ich hab's jetzt ein paar Stunden lang auf zwei verschiedenen Servern und in diversen Varianten probiert ("normales" Modul-Update, über Module > Erweitert upgrade.php aufrufen, Daten stumpf via FTP überschreiben und dann versuchen, upgrade.php auszuführen) - hat alles nicht das erwünschte Ergebnis gebracht.

D.h. entweder hat zwar das Upgrade-Script fröhlich vermeldet "Erfolgreich installiert", in Wirklichkeit ist aber nüscht passiert, und beim Hardcore-FTP-Überschreibeversuch kam der fatale Fehler "Call to a member function numRows() on a non-object on line 52 in modify.php".

Mach ich was falsch? Gibt's nen Trick?
(Vorher WB 2.7 auf 2.8.1 geupdated, PHP 5.2)

Grüße
-instantflorian.

[freeSbee]

Hallo Florian

ich nehme an, dass du die "Upgrade notes" gelesen hast:
http://www.bakery-shop.ch/#upgrade_notes

Besonders zu beachten ist beim Upgrade von Version 1.0 auf 1.5.6 die neue Verzeichnisstruktur der Produkt-Thumbs und Produktbilder.

Das Upgrade-Skript stoppt nach erfolgtem Upgrade und zeigt dir eine komplette Error log Liste an. Hier kannst du nach Fehlerursachen suchen.

Falls dich das nicht weiterbringt, ist es vermutlich am schnellsten, die Dateien per FTP hochzuladen und die DB per phpMySQL manuell auf den Stand von der Bakery Version 1.5.6 zu bringen.

Gruss Chirstoph

[instantflorian]

Hallo Christoph,

ja, die Upgrade-Notes hatte ich gelesen und die Thumbnail/Image-Verzeichnisse auch schon entsprechend vorbereitet. Wenn's das nur wäre *seufz*

Das Upgrade-Skript stoppt nach erfolgtem Upgrade und zeigt dir eine komplette Error log Liste an. Hier kannst du nach Fehlerursachen suchen.

Beim Updaten des Moduls kamen gar keine Ausgaben, und die Seite wurde sofort neu geladen.

Ich habe mir dann die upgrade.php angeschaut und von Hand die Versionsnummer der installierten Version auf 0.9 geändert, da ich den Eindruck hatte, dass mit der 1.0 keine der Bedingungen zum Ausführen der jeweiligen Upgrade-Befehle erfüllt waren. Daraufhin blitzten zwar kurz irgendwelche Infos auf, das Resultat war aber das selbe. Weder die Versionsnummer bei Module > Details zu Modul > bakery hatte sich geändert, noch sind die vorhandenen PHP-Dateien im Verzeichnis modules/bakery aktualisiert worden.

Ich habe dann via FTP die Dateien hochgeschoben und über Module > Erweitert die install.php ausgeführt, wodurch natürlich alle 120 Produkte gelöscht worden sind. Die habe ich dann über INSERT_INTO direkt in der Datenbank wieder angelegt.

Momentan kämpfe ich mit dem Problem, dass die Seiteneinstellungen leer sind und leider auch bleiben, d.h. Änderungen daran werden nicht übernommen, obwohl die Meldung "Erfolgreich" nach dem Speichern angezeigt wird.

Nun ja, die page_settings hätte ich natürlich dann auch hintenrum reinziehen sollen.

Grüße
-instantflorian.

[heinerle]

Hallo Betroffene und Problemlöser,

ich bin habe das gleiche Problem wie instantflorian, allerdings mit einer 0.91

Ich bekomme es nicht hin. Ich spiele in WB 2.8.1 das neue Bakery (1.5.6) ein, bekomme kurz angezeigt "Erfolgreich aktuallisiert" und dann springt die Routine wieder auf die Modulseite.
Nun sollte man annehmen, dass Bakery jetzt in Version 1.5.6 vorhanden ist, dem ist aber nicht so.
Ein Klick auf "Details zum Modul" zeigt es: Ich bekomme die Info, dass ich Bakery in Version 0.91 installiert habe.
Schaue ich mir nun den Shop an, sehe ich weiterhin das alte Backend. Ich kann das daher beurteilen, weil ich Bakery in aktuelleren Versionen bei anderen WB-Installationen bereits im Einsatz habe und daher weiss, dass das Backend anders aussehen müsste.
Christoph, du schreibst:

Das Upgrade-Skript stoppt nach erfolgtem Upgrade und zeigt dir eine komplette Error log Liste an. Hier kannst du nach Fehlerursachen suchen.

Das tut es eben nicht. Es kommt "Erfolgreich aktuallisiert".
Lassen wir mal aussen vor, dass vielleicht anschliessend die Thumbs und Images nicht mehr passen, damit kann ich mich anschliessend beschäftigen. Viel wichtiger wäre mir, dass ich den Shop überhaupt auf eine aktuelle Version bekomme (nach Möglichkeit ohne den Bestand der Datenbank zu zerschiessen).

Was mache ich falsch? Gibt es wirklich nur den Weg, den Florian beschrieben hat und wobei ich alle Datensätze einbüsse und anschliessend manuell wieder einfügen muss? Ich bin kein Vollprofi in Sachen MySQL und befürchte dahingehend Probleme.

Gruss
Thomas

[freeSbee]

Hallo Thomas

Welche Bakery Version zeigt dir die Datei /modules/bakery/info.php (auf dem Server) in der Variablen $module_version = 'X.XX'; an?
Welche Bakery Version ist in der Datenbank-Tabelle addons gespeichert?

Gruss Christoph

[heinerle]

mir wird in info.php '0.91' gezeigt und in der Datenbank steht auch diese Version.
Es sieht also so aus, als ob das Upgrade teilweise ausgeführt wird und an irgendeiner Stelle abbricht. Einige Verzeichnisse sind ja geändert, aber etliches nicht.
Etliche Verzeichnisse und Dateien tragen das heutige Datum, andere das Datum der alten Version.

[instantflorian]

Um mich da mal kurz einzuklinken: genau so war es bei mir auch. So ist z.B. das neue Lightbox-Verzeichnis problemlos angelegt worden, die ganzen alten schon vorher vorhandenen modify_irgendwas.ph p-Dateien im Bakery-Verzeichnis sind aber beim Update nicht überschrieben worden.
Auch die Änderung der Datenbanktabellen hatte wohl nicht geklappt, denn sonst wären ja nicht die geschilderten PHP-Fehlermeldungen aufgetreten.

Mit dem SQL-Gerfickel ist das gar nicht sooo kompliziert. Ich bin da auch alles andere als versiert und habe es hinbekommen. Aber schön wäre es natürlich trotzdem, wenn es eine elegantere Lösung gäbe.

Viele Grüße
-instantflorian.

[freeSbee]

Welche Rechte haben die (alten) Dateien und Verzeichnisse?

[instantflorian]

Dateien 745, Verzeichnisse 755

[freeSbee]

Dateien 745, Verzeichnisse 755

Dh, nur der Datei- / Verzeichniseigentümer darf ändern. Wenn PHP nicht der Eigentümer ist, können die neuen Dateien nicht geschrieben werden.

Leider gibt das WB Installskript keinen Fehler aus, wenn eine Datei oder einzelne Dateien nach dem entzippen nicht ins Modulverzeichnis geschrieben werden können. Es wird nur eine Fehlermeldung ausgegeben, wenn das Entzippen vollständig fehl schlägt.

Auf der Website von PclZip steht:

Notice that if one file extraction fail, the full extraction does not fail. The method does not return an error, but the file status is set with the error reason.

Gruss Christoph

[instantflorian]

Hallo Christoph,

kannst Du mir mal ein altes Bakery-Installationszip (1.0 oder so) zur Verfügung stellen, damit ich das Updaten mal testen kann? Bin mir nicht sicher, ob es wirklich an den Besitzrechten liegt, da es von der Serverkonfiguration abhängt, ob so strikt zwischen dem FTP-Besitzer und PHP-User unterschieden wird.
Das Updaten der Datenbank hatte ja auch nicht geklappt, wenn ich mich recht entsinne, das würde ich auch noch einmal gern überprüfen.

Grüße
-instantflorian.

[freeSbee]

Hallo Florian

kannst Du mir mal ein altes Bakery-Installationszip (1.0 oder so) zur Verfügung stellen, damit ich das Updaten mal testen kann?

www.bakery-shop.ch/downloads/old/bakery_1.0.zip

Gruss Christoph

[instantflorian]

ok, Du hattest natürlich recht... mit einer normal installierten und nicht via FTP hin und her geschobenen Installation funktioniert das Update reibungslos.

Hm. Aber wenn der FTP-User der Eigentümer ist - und man macht ja gern mal eine Komplettkopie, um ein Update einzuspielen - klappt's nicht, auch wenn Verzeichnisse und Dateien auf 777 gesetzt sind.

Grüße
-instantflorian.

[heinerle]

Welche Rechte haben die (alten) Dateien und Verzeichnisse?

FastCGI-Umgebung mit PHP4 und PHP5, somit STandardrechte, also Datei 644 und Verzeichnis 755.
Völlig ausreichend bei jeder anderen Software. Das Verzeichnisrecht von 755 reicht zum Anlegen von Dateien und Unterverzeichnissen aus und das Recht 644 ermöglicht auch das Manipulieren von exitierenden Dateien.
Die Frage wäre also: An welcher Stelle ist der Stop? An welcher Stelle bricht er das Überschreiben ab?

mit einer normal installierten und nicht via FTP hin und her geschobenen Installation funktioniert das Update reibungslos.

Das dürfte bei mir eigentlich nicht sein (ist es aber leider doch). Bei meiner CGI-Umgebung ist sowohl bei einer normalen Installation, als auch bei der Komplettkopie der gleiche Benutzer und die gleiche Gruppe für die Dateien und Verzeichnisse hinterlegt. Beim Kopieren wie beim Installieren haben die Dateien den gleichen Besitzer.
Ich habe es aber gerade getestet: Habe in dem Verzeichnis noch eine alte Testinstallation, gleiche Bakery-Version 0.91, dort hab ich grad einfach das Upgrade drübergezogen und es funktioniert.

Das würde aber im Umkehrschluss bedeuten: Ich kann niemals ein Backup rückspielen, denn nach dem Rückspielen des Backupes würde ich keine Modulupdates mehr einspielen können


Ich arbeite bei einem Webhoster und wir sagen unseren Kunden bei einem Serverwechsel immer: Einfach Backup in den neuen Account kopieren, Datenbank einspielen fertig. Und das hat bisher immer funktioniert, weil man eben bei der FastCGI-Umgebung nicht auf unterschiedliche Rechte achten muss zwischen altem und neuem System.
Installiert eine Anwendung eine neue Datei, dann gehört die dem Besitzer webXXX und die Datei hat das Recht 644. Lädt webXXX die gleiche Datei mit FTP in den Account, gehört ihm die Datei auch und hat ebenfalls automatisch 644.
Deshalb klingt es für mich unlogisch, dass es diesen Unterschied zwischen kopieren und installieren gibt.

[heinerle]

ich muss nochmals kurz nachfragen:
Ist das ein Problem vom Modul Bakery, oder ist es eher ein genreller Bug bei der Versionsverwaltung der Module im Backend?

[freeSbee]

Hallo Thomas

Es handelt sich nicht um einen Bug weder von Bakery noch von WB. Probleme tauche auf, wenn Dateien via FTP hochgeladen wurden und diese später von WB überschrieben werden sollten.

Installieren Sie Dateien mit den dafür vorgesehenen Funktionen von WB. Erweiterungen, Module, Sprachdateien und Seiten sollten über das WebsiteBaker Backend installiert oder gelöscht werden. Nachträgliche Änderungen oder das Verschieben von Ordnern und Dateien mittels FTP Programm führt letztendlich fast immer zu Problemen.

Quelle (siehe "Empfehlung"): http://www.websitebaker2.org/topics/dateien-und-berechtigungen.php#anker3

Weitere Informationen: http://www.websitebaker2.org/topics/dateien-und-berechtigungen.php

Gruss Christoph

[heinerle]

Sorry, aber die Aussage passt so nicht bei mir.

Wie gesagt: Ich arbeite im Support bei nem Hoster. Ich weiss also auch, dass die Rechte identisch sein müssen. Das ist nicht das Problem.

Server alt: FastCGI
Dateirecht 644
Verzeichnisrecht 755
Benutzer webxxx
Gruppe webxxx

Server neu: FastCGI
Dateirecht 644
Verzeichnisrecht 755
Benutzer webxxxxxx
Gruppe webxxxxxx

Egal ob ich Dateien per FTP hochlade, oder ob die Dateien mittels PHP-Script erzeugt werden (PHP-Upload), der Benutzer und die Gruppe ist immer gleich und auch die Dateien und Verzeichnisse haben automatisiert 644 und 755.

Ich habe es auch verglichen:
Der gleiche Account, ein WB mit Bakery (älter 2.7) schon immer dort installiert, ein zweiter WB als Backup eingespielt (der Shop, bei dem ich die Probleme habe). Bei beiden sind ALLE Rechte und Benutzer identisch
Shop1 liess sich perfekt mit dem Update versehen, Shop2 (das eingespielte Backup) zickt rum.

Ich kenn mich nicht mit dem Framework/Core aus, hab ich leider bislang zu wenig Zeit gehabt, mich intensiv damit zu beschäftigen, aber ich vermute einen Bug oder Denkfehler beim Programmieren.

Warum?
Der einzige Unterschied bei meinen beiden Installationen ist das Datum der Erstellung der Dateien und Verzeichnisse.
orginale Installation = jede Datei und jedes automatisch erzeugte Verzeichnis trägt entweder das Erstellungsdatum als es angelegt wurde, oder das Datum aus der Zip-Datei des Modules
Backup-Installation = jede Datei und jedes Verzeichnis trägt das Datum vom Einspielen des Backups, weil sie ja genau an diesem Tag komplett neu am Server erzeugt wurden

Problem somit: JEDE Datei und JEDES Verzeichnis aus dem Backup ist somit NEUER als jede Moduldatei, die ich per Update auf einen neueren Stand bringen will.
Aber kein User kann bei einem shared hosting das Erstellungsdatum der Dateien zurücksetzen.

Ich weiss nicht ob ich richtig liege, aber prüft eventuell die Modulinstallation, ob eine ältere Version der Datei vorhanden ist und überschreibt die Datei nur auf Grund dieser Prüfung?
z.B.:
ist info.php vorhanden?
-> JA -> ist die Datei im System älter als Datei aus ZIP?
   -> JA -> Überschreibe die Datei mit ZIP
   -> NEIN -> Behalte Datei bei
-> NEIN -> spiele die Datei aus der ZIP ein

Wenn die Prüfung so vorgenommen wird, dann ist das falsch.
Es müsste nur in der Datenbank die Versionsnummer eines Modules abgelegt werden. Dann prüft die Upgrade- / Installationsroutin e, welche Version in der Datenbank steht und vergleicht mit der Version, die eingespielt werden soll.
Damit erhalte ich ein exaktes Ergebnis und könnte die alten Dateien überschreiben.

Kannst du bestätigen, dass ich mit meiner These in etwa richtig liege und die Prüfung nicht korrekt erfolgt? Du kennst den Grundaufbau von WB besser.

[freeSbee]

Hallo Thomas

Es müsste nur in der Datenbank die Versionsnummer eines Modules abgelegt werden. Dann prüft die Upgrade- / Installationsroutin e, welche Version in der Datenbank steht und vergleicht mit der Version, die eingespielt werden soll.
Damit erhalte ich ein exaktes Ergebnis und könnte die alten Dateien überschreiben.

WB vergleicht vor dem Installieren oder Upgrade eines Moduls die Modul-Versionen, indem es die hart codierten Variablen $module_version aus der neuen und der alten info.php Datei des Moduls ausliest und vergleicht.

Fürs Entpacken des Modul-Zips benutzt WB - wie bereits in einem früheren Post erwähnt - die Methode extract() der Klasse PclZip. In der Methoden-Beschreibung im Code steht:

By default, if a newer file with the same name already exists, the file is not extracted.

Gruss Christoph

[heinerle]

Hallo Christoph,

wenn der Vorgang so abläuft, wie du es schreibst, dann ist das, mal vorsichtig ausgedrückt, grosse Sch****

Kein Benutzer ohne eigenen Webserver kann somit bei Datenverlust oder Serverwechsel sein Backup einfach einspielen und WB läuft wieder.   
Jede aus dem Backup eingespielte Datei trägt ein neueres Datum der Erzeugung. Dadurch wird jedes Update eines Modules unmöglich gemacht.
Daraus ergibt sich dann noch ein viel extremeres Problem:
Was passiert, wenn in einem Modul eine Sicherheitslücke auftaucht?
Der WB-Benutzer mit dem betroffenen Modul kann es nicht per Update auf einen "sicheren" Stand bringen, er kann KEIN Patch einspielen und er kann somit die Lücke nicht beseitigen.
Und....
Er versucht vielleich das Upgrade mit dem Patch einzuspielen, bekommt KEINE Fehlermeldung (so wie ich bei Bakery 0.91 auf 1.5.6) und ist somit der Meinung, das Problem beseitigt zu haben.
Wenn der Benutzer glaubt, dass das Patch fehlerfrei eingespielt ist, hat er ja keinen Grund, auf "Details zum Modul" zu klicken, denn nur dort würde er sehen, dass die info.php nicht überschrieben wurde.

Die Handhabung PclZip auf die beschriebene Art ist ein "Bug" in WB.
Mein englisch ist leider grosser Mist, aber ich hab mir mal PclZip angeschaut.
Die Lösung könnte aber so aussehen: PCLZIP_OPT_REPLACE_ NEWER(http://www.phpconcept.net/pclzip/user-guide/42)
Da steht explizit:

By using PCLZIP_OPT_REPLACE_ NEWER, you give to PclZip the ability to extract and replace the existing file in any situation. This can be usefull in situation like restoring an backup copy of some files/folders.

- Vergleiche Versionen (hardcodierte $module_version)
-> ZIP-Modulversion älter
  - Abbruch
-> ZIP-Modulversion neuer
  --> ZIP-Version der Datei älter
    -- ABBRUCH
  --> ZIP-Version der Datei neuer
    -- Erzwinge das Überschreiben mittels PCLZIP_OPT_REPLACE_ NEWER

Damit wäre das Problem behoben. Ich denke, dass von den Core-Programmierern niemand daran gedacht hat, dass manchmal auch Backups eingespielt oder Serverwechsel durchgeführt werden und dann Backups nicht mehr das orginale Datum der Dateien tragen.

Was denkst du von meiner Lösung?

*******************************************

Übrigens: ein manuelles Einspielen der neuen Shopversion ist für einen Laien nicht durchführbar, so wie es Florian beschrieben hat.
Die alten Tabellen aus Bakery 0.91 enthalten zum Teil Felder, die in neuen Versionen nicht vorhanden sind.
Aber kaum ein normaler Nutzer (und WB richtet sich ja auch explizit auf Grund der einfachen Handhabung an diese Nutzer) kann die Datenbanktabellen manuell korrigieren und nach dem Aufruf von install.php (wie von Florian beschrieben) die danach fehlenden Tabellen händisch wiederherstellen. Hilfreich wäre also für den Fall eines Upgrades, wenn der neuen Bakery-Version für den Upgrade-Fall eine komplette SQL-Datei enthalten wäre, inklusive aller jemals verwendeten Felder.
Dann muss der eher unerfahrene Benutzer nur die bakery-Tabellen löschen (das kann auch ein Anfänger) und dann die SQL-Datei einspielen. Schon hat er ein brauchbares Gerüst.

Normale Benutzer sind solche, denen ich in unserem Support solche Sätze schreibe:

Was noch interessant für Sie sein könnte, wäre vielleicht das CMS (Content Management System) Websitebaker.

http://websitebaker.org

Es ist in der Bedienung recht einfach und auf der Homepage finden Sie unter dem Menüpunkt "help" finden Sie unter "Basis Doku" eines der (meiner Meinung nach) besten Handbücher.

Ich habe dieses System schon einigen anderen Kunden empfohlen, die sich selbst den Status "absoluter Anfänger" gegeben hatten und diese Kunden sind gut damit zurechtgekommen.

Von diesen Kunden kann man nicht erwarten, dass Sie manuell in eine bestehende Tabelle eingreifen um Felder hinzuzufügen.

[freeSbee]

Betreffend Modul Upgrade im allgemeinen:

By using PCLZIP_OPT_REPLACE_ NEWER, you give to PclZip the ability to extract and replace the existing file in any situation. This can be usefull in situation like restoring an backup copy of some files/folders.

- Vergleiche Versionen (hardcodierte $module_version)
-> ZIP-Modulversion älter
  - Abbruch
-> ZIP-Modulversion neuer
  --> ZIP-Version der Datei älter
    -- ABBRUCH
  --> ZIP-Version der Datei neuer
    -- Erzwinge das Überschreiben mittels PCLZIP_OPT_REPLACE_ NEWER

Damit wäre das Problem behoben. Ich denke, dass von den Core-Programmierern niemand daran gedacht hat, dass manchmal auch Backups eingespielt oder Serverwechsel durchgeführt werden und dann Backups nicht mehr das orginale Datum der Dateien tragen.

Was denkst du von meiner Lösung?

Hat jemand aus dem Core Team mitgelesen?
Was ist eure Meinung?
Kann jemand gegebenenfalls ein Ticket eröffnen?

Danke und Gruss Christoph

[heinerle]

Hallo Christoph,

hast du eine Rückmeldung bekommen?

Hast du vielleicht irgendwo eine SQL-Datei, die ALLE jemals verwendeten Felder enthält?
Wie gesagt: Ich habe es händisch gemacht, wie von Florian empfohlen, aber ich musste einige Felder manuell hinzufügen und dieses Vorgehen kann man niemanden empfehlen, der von Programmierung keine Ahnung hat (die MySQL-Statements müssen ja aus PHP-Scripten ausgelesen werden und man muss zusätzlich noch ein altes DB-Backup vorliegen haben) und der auch nicht weiss, wie er mit phpMyAdmin und dessen Fehlermeldungen umgehen soll.

Ein "Rohling" aller zu erzeugenden Tabellen würde da hilfreich sein.

[Luisehahne]

PCLZIP_OPT_REPLACE_ NEWER

Dürfte in der 2.8.x Version, das Problem nicht lösen, da erstmal im temp Ordner entpackt wird und nach Abprüfung auf Gültigkeit die Dateien in den Moduleordner kopiert werden.

In der neuen 2.9.0.dev, die in den nächsten Tagen im SVN zur Verfügung stehen wird, gehen wir andere Wege. Es wird nicht sofort entpackt, erst prüfen wir die im Zip enthaltenen Dateien, prüfen die info.php auf Gültige Einträge.

Wenn ok, wird alles innerhalb des Moduleordner gelöscht, und das Zip anschliessend sofort in den Moduleordner entpackt. Kein Umweg mehr über die temp. Damit eine Fehlerquelle weniger.

Dietmar

[freeSbee]

MySQL Datei angehängt.

Gruss Christoph