Upgrade to 4.x nicht erfolgreich. Joomla!-Backend größtenteils kaputt.

Zitat von WM-Loose

Die Frage ist vielmehr, was da bei dir schiefläuft und nicht bei Joomla.

Dieses Verhalten tritt nur auf, wenn die DB-Inhalte nicht komplett entfernt wurden oder es bereits vorher schon eine fehlerhafte Joomla3-Installation war,

Zusätzlich muss natürlich das Joomla Verzeichnis auch komplett geleert sein.

Wie sollen denn sonst J4 Dateien in der 3er Version auftauschen?

Joomla bedient sich ja nicht einer KI die selbstständig irgendwelche Dateien holt und dann in deine J3 Installation kopiert.

Alles anzeigen

Hi,

naja bisher habe ich das so bei keiner anderen Software gehabt, die auf eine neue Version und bei Nicht-Erfolg auf eine alten Version ge-rollbacked wurde.

Ich habe hier alle eure Tipps befolgt und zum größten Teil auch selbst bereits durchgeführt und werde halt jetzt nochmal bei Strato nach einem Komplett-Reset des Servers und der Datenbank auf einen Stand vom 04.04 anfragen und schauen, ob das zur Besserung führt.

Ich werde außerdem NOCHMAL den Reparieren Button ausprobieren, da ich nun das alte Workspace und die alte Datenbank habe.

LG Nicolas

Update: Jaaaaa, lecker.

Reparieren hat wieder die Website zerschossen. Lieblich.

Keine gute Funktion, liebe Leute!

Zitat von jsc_01

Bei jeder Inhalts-Änderung an meiner Webseite local oder Web oder bei manuellen Backups wird bei mir die DB repariert, noch niemals gab es damit ein Problem.

Hey,

ja also ich finde es auch sehr bemerkenswert. Habe soetwas auch noch nie gesehen.

Wenigstens kenne ich ja den Weg, wie man zumindest die Website wieder schnell holen kann.

Ich habe da mittlerweile so eine Vorahnung, die etwas mit dem Hoster zu tun haben könnte.

Am Ende läuft das auf Self-Hosting hinaus. Damit bin ich bisher immer bestens gefahren und muss nicht 5 Jahre warten, bis ich mir meinen Webspace vollständig runtergeladen/hochgeladen habe.

Eigene Set-Up Scripts dafür zu schreiben, wäre auch kein Hexenwerk.

Zitat von Elwood

Irgendwann (bei Strato nach 4 Wochen) werden die Backups beim Hoster mit der defekten Installation überschrieben.

Hey,

ist mir bewusst aber danke dir, die Info kann so Manchem den Tag retten . Da ich die Updates etc. alle innerhalb von 3 Tagen gemacht habe, schätze ich, dass das ok sein sollte bis jetzt.

Habe auch lokal alle Back-Ups von vor dem Upgrade für sowohl Webspace als auch Datenbank. D.h. da bin ich auch abgesichert.

ISO 27001 würde ich sowieso nicht mehr Erfüllen, aber wer tut das schon im Prozess eines Website-Umbaus, um die sich seit 9+ Jahren niemand gekümmert hat.

Liebe Grüße

Nicolas

Aber mal eine ganz andere Frage: Wenn man auf die alte Version roll-back macht, wieso werden Scripts getriggert, die mit dem versuchten Update auf die neue Version erstellt wurden. Man könnte doch super-einfach überprüfen, welche Joomla! Version gerade aktuell ist und dafür die entsprechend Dateien/Scripts aufrufen, bzw. im Rollback-Prozess dynamisch downloaden, oder nicht?

Kenne mich mit Joomla! Dev nicht aus, deswegen die Frage. Interesse am Entwickeln eines Webdev-Frameworks besteht nämlich.

Zitat von drmenzelit

Es gibt kein Rollback in Joomla, außer das Einspielen von einem Backup (und wie hier schon oft erwähnt wurde immer in einem leeren Ordner und einer leeren Datenbank und Dateien + DB müssen zueinander passen). Wenn du ein Update versucht hast und schief gegangen ist, gibt ein kein Rollback-Button in Joomla, die dir das Problem löst. Meine Vorgehensweise (die ich auch schon mal in meinem Blog erklärt habe) ist immer ein Update (vor allem Major Versions) auf einer Kopie der Seite zu machen, am besten in einer Subdomain, wenn alles gut geht, switcht man einfach die Domain und löscht die alten Daten.

Der ursprüngliche Inhaber hat mir zum Zeitpunkt des Updates nicht die nötigen Zugänge gegeben, um es auf einer Test-Domain (Trotz Absprache) auszuprobieren. Nach dem Incident habe ich so nun alle.

Der Rollback sollte meiner Meinung nach für so eine wichtige Funktion entsprechend funktionieren. Dann muss man nur noch ein Logging-Script laufen haben, dass nicht innerhalb von Joomla! läuft, welches aber genau die Änderungen trackt. Dann kann Joomla! auf dieses Logging-File zugreifen und einen Rollback mit den entsprechenden Informationen machen. Als ich damals ein Azure-Komplett Rollback Programm geschrieben habe, habe ich auch automatisch auf dem Back-Up Server eine exakte Kopie des Webservers/Webspaces erstellt und allem drum und dran. Das hat bedeutet, dass man bei einem Update-Fehlschlag innerhalb von 5 Minuten eine exakt funktionierende Rollback-Website mit Datenbank und allem drum und dran hatte.

Da ich aber hier bei Strato als Kunde absolut unflexibel bin, kann ich mir so ein Programm nicht schnell selbst schreiben, allein schon wegen der Stunden-langen Down und Uploads.

Liebe Grüße

Nicolas.

Zitat von christine2

Hallo Nicolas,

Irgendwie kenne ich mich da nicht mehr aus, mit dieser "Rollback" Geschichte. Welchen Stand Du nun hast usw. ...

Für was braucht es ein Logging-Script usw.?

Die ganze Prozedere betr. Backup wie/wo man das einspielt, wurde Dir von den KollegInn[en] vielfach erklärt.

Irgendwo war glaub ne Frage wegen Überprüfungen. Gibt da auch so einige. 1 davon:

/administrator/logs/1.joomla_update.php

Sieht dann so ca. aus:

Nochmals: wie ist jetzt der Stand der Dinge? Hattest ja geschrieben, dass die Seite auf J 3.10 ist.

Wenn ich aber die URL in #1 aufrufe, gibt es diese nicht.

Meldung von Strato: This website is currently not available.

Liebe Grüße

Christine

Alles anzeigen

Hi Christine,

Die Seite ist bewusste erst einmal deaktiviert, weil ich gerade das Webspace rausgelöscht habe und es mit einem vorherigen ersetze.

Die Datenbank, die eingespielt wurde, ist synchron mit dem Webspace. Nur um das mal hier breit zu treten: Strato braucht mittlerweile 2 Stunden, um ein einfaches Webspace Backup hochzuladen.

Die Hoffnung des Webspace-Purges und DANN einer BackUp Wiederherstellung über Strato ist, dass die durch Upgrade auf 4.x gelangten Dateien auf der Domain nicht mehr existieren. Die Back-Up Datenbank vom 07.04 hat sich ja nicht magischerweise an das Joomla 4.x Update angepasst, denn dann würde es den Sinn eines Back-Ups verlieren.

Elwood Mag ja alles sein, aber ich rede hier von einem nicht konfigurierbaren Joomla! Back-End. Da ist nichts mit Akeeba-Backup ;).

Mich würde einfach nur interessieren, warum nach einem Versions-Rollback, dem Einspielen eines Webspace Back-Ups gepaart mit der entsprechenden Datenbank Joomla! dennoch meint, Fehlermeldungen für Columns und Schemas zu werfen, die in 3.10 nicht existieren. Was an diesem Prozess macht auch nur ansatzweise Sinn? Wie Jürgen schon festgestellt hat, gibt es diese Sachen in 3.10 nicht. Wie kann es also sein, dass aus einem geback-upten Webspace mit einem Versions-Rollback Joomla! 1. meint über nicht-existierende Einträge/FormFields sich beschweren zu müssen und 2. als Konsequenz das halbe Backend nicht mehr funktioniert und 3. es bei Joomla! für soetwas im Webspace keine Fallback-Routinen definiert sind?

Das sind die Sachen, mit denen ich rumrätsele.

Die Website ist ja einfach wieder zu holen, sodass sie im Browser für den normalen Nutzer funktioniert. Aber ich verstehe einfach bestimmte Entscheidungen, die beim Updaten/Rollback-schreiben gemacht wurden, nicht.

Liebe Grüße

Nicolas

Zitat von Elwood

Ich arbeite seit einiger Zeit mit Joomla und habe schon viele Seiten erstellt und viele Backups erstellt und wiederhergestellt.

Aber was bedeutet denn ein Versions-Rollback und dem Einspielen eines Backups?

Sag mal? Ich habe auch schon sehr viele Seiten erstellt und BackUps erstellt und wiederhergestellt, in einem System von 140 verschiedenen Kunden mit GROßEN Datenbanken, Configs, komplizierten Kubernetes-Cluster Setups und Monitoring-Funktionen, wie auch WAF-Konfigurationen in Azure gearbeitet und Programme/Azure Workflows geschrieben. Reicht das, um dich davon zu überzeugen, dass ich weiß, wovon ich rede? Deine Joomla!-Snob Art und Weise kann einen schon sehr die Nerven aufreiben, sorry.

Akeeba-Backup und Xammp schön und gut, es gibt auch andere Programme, die das genauso gut bewerkstelligen können.

Ich habe eher das Gefühl, dass du die Situation eines Zurückgehens auf 3.x mit den entsprechenden Schwierigkeiten nicht (mehr) kennst.

Mag sein, dass deine Routinen und Vorschläge für die neueren Versionen wie geschmiert laufen, das ist ja auch schließlich das Ziel, wenn Joomla! eine neue besserer Version rausbringt.

Es beantwortet dennoch nicht meine Fragen:

1. Warum gibt es bei Joomla! keine Fallback-Routinen für verschiedene Versionen?

2. Warum wird nach dem Kompletten Ersetzen eine Webspaces und einer Datenbank trotzdem noch Fehlermeldungen einer neueren ENTFERNTEN Version geworfen?

3. Warum entscheidet sich Joomla! dafür, das Back-End zusammenfallen zu lassen, anstelle Extensions der Scripte, die diese Fehler verursachen, einfach zu deaktivieren, sodass man zumindest seine Back-End wieder einsehen kann mit allen Extensions/Modulen/PlugIns/Komponenten?

Liebe Grüße

Nicolas

Zitat von Elwood

Nur nochmal nachgefragt:

Vor dem Update hast du das Allrounder upgedatet auf 4 oder auf das Protostar umgeschaltet?

Ja... Ich habe extra noch den Update Checker durchlaufen lassen und es war alles fein. :C

Habe ja jeweils zurückgehen müssen, damit unser altes Template funktioniert, das ist aus dem Back-Up.