Dringend! Reanimation eines alten phpWCMS 1.2.5/6

[kukki]

Irgendwann, irgendwie, irgendwo erwischt es jeden einmal

Wegen eines Angriffs auf dessen Website hat ein Kunden von vor 8 Jahren seine asbach-uralte Website aus Angst eingestampft -
ohne je eine Sicherung gemacht zu haben

Jetzt kommt der Anruf: HILFE!. Na ja, auf meinem PC und in meinen Sicherungen habe ich alle Bilder (/../images) und eine Datenbank wiedergefunden.
So wie es aussieht in einer phpWCMS-Version 1.2.6.

Hat jemand eine solche noch irgendwo zu liegen und kann mir diese als *.zip/ *.rar zur Verfügung stellen?
Um die Seite zu reanimieren, bräuchte ich eine solch alte Standardversion. Ich habe noch ein Setup-Verzeichnis gefunden von dieser Installation, da war die letzte Upgradeversion #13 13__1.2.5-DEV_to_1.2.6-DEV.sql entahlten.

Bitte per PM melden, Danke!

[kukki]

Wirklich verkramt, aber doch noch gefunden, wer kommt schon auf die Idee über "phpWCMS.de" sich dahinzuhangeln Mal sehen, was draus wird

Trotzdem aber meine Frage: Ist noch irgend ein Stolperstein dabei, den es gilt zu beachten? Oder kann ich einfach die letzte Version drüberbügeln und die DB-Update sehr gewissenhadft durchführen, incl. der Patches (Verfallsdatum etc.)

[Old Boy]

Ich würde mich da fragen, wie gross war der Umfang der Altversion...

Ist es ggf. doch sinnvoller, etwas NEUES aufzuziehen, anstatt sich durch die diversen Updates zu hangeln, um auf den aktuellen Stand zu kommen. Am Ende ist der komplette CSS-Kram - insbesondere hinsichtlich der Bilder - ja doch "anders" und überarbeitungswürdig!

Ich würde die Altversion nur lokal lauffähig machen und die Inhalte in eine neu aufgesetzte Variante "von Hand" übernehmen. Dabei kann man gleich die Struktur von Template und Artikeln anpassen, denn die "Eigentümer" wurschteln da doch meist rum und alles ist wenig flexibel in der Summary untergebracht... hört sich nach Arbeit an... geht aber meist deutlich nervenschonender von statten

[kukki]

Ich würde mich da fragen, wie gross war der Umfang der Altversion...

Ziemlich groß, zumal hier noch eine zweite Website integriert war - eine Website in einer Website mit völlig anderem Layout.
Daher die Frage, ob man nicht die uralte Version erst einmal zum Laufen bringt und dann nur noch die neuste Version drüberbügelt, incl. der Datenbankupdates und den entsprechenden Setup-Schriiten. Deswegen die Suche/ Frage nach einem Stolperstein, der das Projekt dann doch scheitern ließe. CSS und Layout mache ich "midde" Füße, wichtiger ist der Inhalt in der Datenbank und die Bilder im Bereich /content/images Die ganze Sache hätte ich sowieso lokal vorbereitet, aber ich wollte halt keine Überraschungen haben.

[Oliver Georgi]

Wozu ein Update, wenn es auch so läuft. Wenn aber eh ein Update ansteht, macht die vorherige Installation der alten Version keinen Sinn.

[kukki]

Oliver, was läuft hier auch so Hab ich da was verkehrt geschrieben ...
nöö - eigentlich nicht!

Ich habe nur eine alte DB-Sicherung von 2006 und die Bilder auf meinem lokalen PC gefunden, eben auch noch die alte frontend.css.
Das ist ja schon mal was.

Aber jetzt kommen ein paar Knackpunkte - die aus den Upgrades bis zur Version V. 1.7.4 herrühren, und ... das sind keine Neuigkeiten, sondern wurden von mir und auch anderen beschrieben.

Wenn man ein Upgrade der Datenbanken macht, das bei mir völlig fehlerlos abging , hat man mit der /Version 1.2.6/ 43 Tabellen in der Datenbank.
Eine Neuinstallation dagegen hat nur 42 Tabellen
Beim Vergleich beider Bestände ergibt das Upgrade 8 überflüssige Tabellen, die bei der Neuinstallierung gar nicht dabei sind:
_module; _imgcache; _forum; /_fonts_styles; /_fonts_colors; /_fonts; /_blog; /_bid (wäre schön, wenn diese überflüssigen Sachen bei einem Upgrade mit gelöscht werden würden.

ABER: es fehlen dafür nach einem umfangreichen Upgrade: /_redirect; /_language; /_glossy; /_ads_* (4 Stück) und
es fehlen im Upgrade in der Tabelle /_articlecat einige Tabellenspalten. u.a.

Hier die Aufstellung:



Dann gehts weiter.
Wenn man die Daten upgraden will, gibt es Probleme mit den Timestamps und mit Type=MyISAM.
Letzteres kann man per Hand für einen Import in die Serverdatenbank mit Engine=MyISAM umrubeln. Die TimetampsUpdates habe ich bereits per Hand überall geändert auf (?)Lange=6, denn die alte Einstellung 10 wurde nicht akzeptiert!

[update]

Ich denke doch, dass alle fehlenden Felder und Tabellen bei einem schrittweisen update ergänzt werden, oder?

[kukki]

Was habe ich nun insgesamt gemacht?

1. Lokal ein altes 1.2.6 installiert und dort die Datenbank importiert,
2. Dann lokal ein neues 1.7.4x installiert und dort hinein die Datenbank importiert.
3. Ein Update gefahren duch ALLE Versionen und alle Änderungen, die im Setupbildschirm stehen. Umbennungen der Verzeichnisse für config.inc.php. Alles ohne Fehlermeldungen!
4. Ein neues phpWCMS auf dem Server installiert und eine leere Datenbank angelegt, incl. einer aktuellen neuen config.inc.php.
5. Der Versuch die Daten dort hinnein zu importieren scheiterte erst einmal an:

#1064 - ...check the manual that corresponds to your MySQL server version for the right syntax to use near '(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) ,
`address_subscription` blob NOT NU' at line 22

[kukki]

Ich denke doch, dass alle fehlenden Felder und Tabellen bei einem schrittweisen update ergänzt werden, oder?

Dachte ich auch, habs zweimal gemacht, mit dem gleichen Ergebnis.

Ich werde das alles noch einmal wiederholen - nicht mehr heute-, allein schon wegen der fehlenden Felder, das wurmt mich

PS.: Die "zuvielen" Tabellen machen beim Import in die neuste Version (nach Upgrade) probleme, da diese Felder nicht vorhanden sind, aber dafür Daten bereitsgestellt sind - sogenannte Karteileichen! Die müssen bei einer solchen Reanimation per Hand behandelt werden, indm man diese karteileichen aus dem Import-Sql-Anweisungen raus nimmt.

[Oliver Georgi]

Deine lokale MySQL läuft im STRICT Modus. Damit dürften einige ältere Updates Steps unter Umständen scheitern. Es darf auch keine alte Version in eine neuere Datenbank importiert werden. Alte Daten werden aktualisiert. Und auch wichtig — erst nach Update der 1.26 nach 1.5 im alten Stil in das Backend einloggen. Oder vorher unbedingt noch mal content/tmp leeren.