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

Hallo zusammen,

vor kurzem habe ich eine Joomla! Website übernommen, die seit fast 10 Jahre nicht mehr richtig gemanaged wurde und ich mich wundere, wie noch alles halbwegs funktioniert.

Wie zu sehen ist, befindet sich unser Joomla! auf der 3.10.x Version. Entsprechend wollte ich unser Joomla! upgraden auf 4. Ich habe folgendes gecheckt: {plugins, components, extensions, modules}. Es schien alles ok zu sein nach dem Pre-Update Check. Die veraltete PHP-Version wurde auch akzeptiert. (diese befindet sich im "Extended Support", a.ka. Life-Line bei Strato). Ich habe kein Akeeba-Backup erstellt, denn 1. hat es mir in der Joomla! Oberfläche gesagt, dass das Back-Up mit dem momentanen zustand aktuell sei und 2. wir ein tägliches Webspace-Backup bei Strato haben.

Ein Datenbank-Backup vom 08.04 existierte ebenfalls. Also, was kann bei einem Upgrade auf Joomla! 4.x schon schief gehen? Hm... so ziemlich alles, wie sich herausstellte.

1. Joomla! Backend funktionierte nicht mehr. 2. Website war nicht mehr erreichbar. => Problem!!

Partialer Fix: In Strato BackUp Control habe ich das Webspace vom 08.04 zurückgeholt. Immernoch ein Problem, Fehlermeldungen auf Website beim Anzeigen der Artikel, Fotos etc.

Also habe ich bei Strato auch die Datenbank vom 08.04 restored. Glücklicherweise funktionierte die Website nun wieder und das Joomla! Backend funktionierte nun auch wieder teilweise. Aber eben nur teilweise.

Das Problem ist, dass ich folgendes nicht kann: Plugins, Module, Extentions, Templates auflisten/managen. Konfiguration kann ich auch nicht aufrufen.

Außerdem können keine Artikel hinzugefügt werden. Ich bekomme überall Fehlermeldungen mit JFormField irgendwas...

Also Debugging und Error Reporting an und Folgendes kommt, wenn ich versuche, einen Artikel zu bearbeiten:

Class 'JFormFieldTextarea' not found

/mnt/../../../htdocs/Joomla-34/libraries/src/Form/Field/EditorField.php:25

Call stack

# Function Location

1 () JROOT/libraries/src/Form/Field/EditorField.php:25

2 include_once() JROOT/libraries/loader.php:557

3 JLoader::loadByPsr4()

4 spl_autoload_call()

5 class_exists() JROOT/libraries/src/Form/FormHelper.php:188

6 Joomla\CMS\Form\FormHelper::loadClass() JROOT/libraries/src/Form/FormHelper.php:120

7 Joomla\CMS\Form\FormHelper::loadType() JROOT/libraries/src/Form/FormHelper.php:76

8 Joomla\CMS\Form\FormHelper::loadFieldType() JROOT/libraries/src/Form/Form.php:1985

9 Joomla\CMS\Form\Form->loadFieldType() JROOT/libraries/src/Form/Form.php:1922

10 Joomla\CMS\Form\Form->loadField() JROOT/libraries/src/Form/Form.php:277

11 Joomla\CMS\Form\Form->getField() JROOT/components/com_content/views/form/tmpl/edit.php:37

12 include() JROOT/libraries/src/MVC/View/HtmlView.php:701

13 Joomla\CMS\MVC\View\HtmlView->loadTemplate() JROOT/libraries/src/MVC/View/HtmlView.php:230

14 Joomla\CMS\MVC\View\HtmlView->display() JROOT/components/com_content/views/form/view.html.php:133

15 ContentViewForm->display() JROOT/libraries/src/MVC/Controller/BaseController.php:664

16 Joomla\CMS\MVC\Controller\BaseController->display() JROOT/components/com_content/controller.php:118

17 ContentController->display() JROOT/libraries/src/MVC/Controller/BaseController.php:702

18 Joomla\CMS\MVC\Controller\BaseController->execute() JROOT/components/com_content/content.php:43

19 require_once() JROOT/libraries/src/Component/ComponentHelper.php:402

20 Joomla\CMS\Component\ComponentHelper::executeComponent() JROOT/libraries/src/Component/ComponentHelper.php:377

21 Joomla\CMS\Component\ComponentHelper::renderComponent() JROOT/libraries/src/Application/SiteApplication.php:194

22 Joomla\CMS\Application\SiteApplication->dispatch() JROOT/libraries/src/Application/SiteApplication.php:233

23 Joomla\CMS\Application\SiteApplication->doExecute() JROOT/libraries/src/Application/CMSApplication.php:225

24 Joomla\CMS\Application\CMSApplication->execute() JROOT/index.php:49

Damit einhergehend stechen auch immer die gleichen roten Warning heraus: NO INDEX KEY COULD BE USED und FILESORT (WHERE/ON Queries), das direkt mit dem NIKCBU Fehler zusammenhängt.

Erst einmal sieht es aus wie ein Datenbank-Fehler, aber diese habe ich ja wieder hergestellt und die Probleme scheinen beim Aufrufen bestimmter Funktionen zu sein. Vorherrschend: Irgendeine Class existiert nicht, d.h. ein PHP Class Object.

Übrigens: Die "Reparieren" Option in Joomla! hat dafür gesorgt, dass das Backend komplett zerpflückt wurde. Irgendein Spaßvogel mit einem "Meister" Label im Englischsprachigen Forum, hat es einem Nutzer vorgeschlagen. Tja, Pech gehabt.

Zurück zum Thema:

Als ich Strato gefragt habe zum Webspace Rollback, haben sie mir gesagt, dass bei einem Webspace Restore, die durch ein Joomla!-Update neu generierten Dateien nicht gelöscht werden sondern nur die alten Dateien mit existierenden überschrieben werden. Warum Strato diesen Mechanismus für eine gute Idee hält, fällt mir schwer zu verstehen.

Das heißt, es gibt eigentlich nur eine Möglichkeit: Das Webspace hat nun Dateien/Scripts drin, die aufgerufen werden, die aber nicht zu Joomla 3.10 gehören.

Heute mache ich den Job von Strato und mache einen manuellen Webspace Restore mit einem Back-Up vom Strato Back-Up Server. (Scheinbar sind die Strato-Menschen nicht in der Lage, das selbst zu tun oder sie wollen es einfach nicht tun. Download vom Backup-Server dauert übrigens 3h+ je nach Zeit. Und unsere Website ist klein! Mit dem Upload ist das ähnlich, aber wenigstens kann ich meine Computer-CPU verwenden, um die Dateien vor dem Hochladen zu verschlüsseln. Das geht dann also schneller. (Strato-Backup Server brauchen so lange, weil sie für bestimmte Pakete extrem wenig CPU Power zuweisen.)

Auch habe ich gesehen (auch in Videos), dass Leute vorschlagen, auf die Datenbank zuzugreifen und bestimmte Spalten/Tabellen zu löschen. 1. Halte ich manuelles Rumfummeln in der Datenbank nicht für eine gute Lösung, selbst als jemand, dr SQL kann. 2. Wie soll mir das mit dem Joomla! Backend helfen? 3. Warum werden beim Joomla!-Versions-Rollback die neu generierten Dateien nicht gelöscht? Das kann doch nur zu Problemen führen. Oder ist das einfach ein Problem von der 3.10.x Version/de dazugehörenden Updater/Rollback-Programm?

Und noch eine allgemeinere Frage:

Assuming the Manual Webspace Override does not lead to an Improvement: What can I do to get all this back to normal?

Angenommen, dass das manuelle Webspace Überschreiben auf dem SFTP-Server führt zu keiner Verbesserung im Back-End: Was kann ich dann noch tun?

P.S.: Ich würde Leuten von Strato als Hoster abraten, wenn sie sichergehen wollen, dass die Website-Inhalte bei einem Restore auch wirklich alle ersetzt werden. Das ist die einfachste Aufgabe der Welt und wird jedem Werkstudenten als 1. Ticket in einem Hosting-Unternehmen erstellt, aber Strato scheint das nicht bewerkstelligen zu können.

Ich freue mich auf Tipps und Hilfe!

LG Nicolas

Ok,

das ist einen Versuch wert. Bisher habe ich erst das Webspace gelöscht und restored, dann probiert und dann die Datenbank restored und nochmal geschaut.

Was meinst du mit:

"Allerdings werden die Backups von hinten neu überschrieben.

Irgendwann gibt es kein funktionierendes Backup mehr."

Die Back-Ups bei Strato werden mit der aktuellen (Back-Up?) Version überschrieben?

Ich habe noch die Option, bei Strato komplett Reset zu einem vorherigen Stand zu machen. Zumindest wurde das so von jemandem im englisch-sprachigen Forum beworben.

Was genau meinst du mit "das fehlerhafte Update reparieren?"

Geht es hier um manuelle Datenbank-Eintrags-Entfernungen? Das fände ich komisch

Wenn du den Joomla!-Workspace selbst meinst, wo habe ich im Backend genau die Option dazu, bzw. wo kann ich mich in der Reparatur probieren?

Extensions rausschmeißen geht ja nicht, weil dafür müssten sie erstmal gelistet werden, was ja nicht funktioniert, wie ich oben bereits geschildert habe.

Für mich macht es tatsächlich in meinem Mental Model keinen Sinn mehr, wo jetzt noch der Fehler liegen könnte. Soweit ich weiß, läuft die Joomla!-instanz ja auf unserer Domain bei Strato. Kann es sein, dass außerhalb des /root Verzeichnisses beim Upgraden auf 4.x sich Dateien geändert haben, die mit dem Webspace selbst zwar zusammenhängen aber nicht mit einem Webspace-Backup zurückgeholt werden können? Dann wäre es doch Aufgabe von Strato, das wieder zu restoren, oder?

Denn mir ist folgendes aufgefallen: Im Ordner /Joomla/administrator/config/ liegen lauter .txt Dateien, die verknüpft sind Dateien aus mit dem /home/httpd/... Ordner. Ich könnte mir vorstellen, dass diese Dateien in den nicht-ansteuerbaren und traversierbaren Verzeichnissen des SFTP-Servers sich beim Webspace Restore nicht mit zurückgesetzt haben, aber durch das Joomla!-Update verändert wurden.

Macht Joomla! beim Update so etwas außerhalb des Webspaces?

Danke schonmal für die erste Hilfe!

LG Nicolas

Ja, also Back-Ups von sowohl DB als auch Webspace habe ich lokal. Auf der Website und somit in die Datenbank ist seit dem 05.04. nichts mehr passiert (Keine neuen Einträge/Artikel). D.h. Webspace und Datenbanken ab dann sollten synchronisierbar sein.

Das Wichtigste habe ich auch: Bilder und neueste Artikel. Die alten Artikel können sowieso weg aber ich würde sie gerne im Archiv beibehalten. Ist ja immerhin die Vereinshistorie a.k.a. Seele für manche.

Wenn also DB-Delete und Webspace-Delete und das Restore nicht klappt, habe ich mir genau das überlegt, was du vorschlägst: Neue DB-Instanz, Test-Domain, PHP-Version auf 8, direkt die neueste stabile Joomla-Version und Website replizieren. Ursprüngliche Idee war ja sowieso ein Re-Design der Website.

Das mit dem Update Reparieren verstehe ich allerding noch nicht und würde diese Option wenigstens mal ausprobiert haben für die Zukunft.

Danke für eure Hilfe!

Zitat von hechtnetz

Unterschätz das nicht! Eine meiner Seiten ist von einem Angelverein. Die würden Hechtsuppe aus mir machen.

Wenn Du ein korrektes Backup hast kannst Du auch das Update (entweder lokal oder) in der Test-(Sub-)Domain anstoßen und im Erfolgsfall die Hauptdomain auf das Ergebnis umbiegen.

Jupp, das ist exakt der Plan.

Fällt euch vielleicht hierzu noh etwas ein (Zahlen ersetzt mit "?"):

Table 'DB???????.#__history' doesn't exist

Table 'DB???????.#__guidedtours' doesn't exist

Table 'DB???????.#__user_mfa' doesn't exist

wird als Fehler in Joomla! gemeldet.

Da ich aber sowohl Webspace und Datenbank vom 08.04 eingespielt habe, sollte diese Meldung eigentlich nicht auftauchen, oder?

Sagt mir auch, das hier: Database Table Structure Up to Date: Nein

Und es geht immer um das Gleiche: FormField->List/ListedGroup/Group

Auf Reparieren werde ich nicht klicken, das zerschießt mir höchstwahrscheinlich wieder die Website.

LG Nicolas

Wie meinst du das? Dass Reparieren zu der Korrumption führt? Oder dass ich auf Reparieren klicken soll?

LG Nicolas

Ja genau,

ich habe sowohl Webspace wie auch Datenbank-Inhalte gelöscht und neu reingespielt. Es sagt mir auch, dass meine aktuelle Joomla-Version 3.10 ist.

Wieso also bekomme ich in der Backend-Control immernoch Fehlermeldungen von einer Joomla! Version für Dinge, die IN DIESER Joomla! Version gar nicht vorkommen sollten? Ich habe auch Browser-Cache geleert usw. Ich verstehe nicht, warum ich bei einem Joomla! Rollback dann weiterhin Fehlermeldungen von einer neuen Joomla!-Version bekomme, die gar nicht existieren dürfte nach dem einspielen des alten Webspaces und einer älteren Datenbank, die beide DEFINITV vor dem versuchten Update auf 4.x erfolgt sind?

Das macht doch sonst keine Software, die man auf eine neue Version updated un roll-backed? Was läuft da schief bei Joomla!?

Zitat von jsc_01

Natürlich nicht. Wenn die Überprüfung der DB meldet, das sie korrumpiert ist, heilt die sich nicht von selbst oder durch Handauflegen, dann kannst du nur auf "Reparieren" klicken.

Machst du das nicht, hast du kein valides System mehr. Mit einer funktionierenden DB kannst du immer noch dein System retten.

Hm, ich habe auf Reparieren geklickt gehabt und das hat mir 2 mal die Website zerschossen (nachdem ich alles auf den Stand von vor dem Upgrade gebracht habe). Was macht dieser Reparatur-Knopf eigentlich?