DJ-Mega Menu

  • Wird vermutlich erstmal der sichere Weg sein, bevor ich jetzt die Hauptdatenbank lösche, neu hochlade und dann eventuell der große Knall kommt, richtig?

    P.S. Die Datenbank löscht Du ja nicht, sondern wenn, dann nur die Inhalte (Tabellen) darin. Ich würde in deinem Fall die DB Exportieren, alle Dateien per FTP Kopieren, alles Aktualisieren und dann wieder auf den Server hochschieben. Somit gehst Du sicher, dass die Liveseite nicht abgschossen wird.

  • Habe gerade mit 1&1 telefoniert. Über den Login des Hosters habe ich die Möglichkeit, eine Sicherung der Dateien bis einschließlich letzten Samstag einzuspielen.


    Eine Wiederherstellung der Datenbank ist drei Monate rückwirkend möglich, wäre allerdings kostenpflichtig.


    Hältst du eine Wiederherstellung der Dateien vom letzten Sonntag für sinnvoll, wenn ihr bereits einen Datenbankfehler vermutet?


    Da meine letzte Sicherung aus September ist, klingt die Wiederherstellung der Datenbank vom letzten Sonntag inkl. Wiederherstellung der Dateien leider nach der einzig sinnvollen Variante.


    Werde gleich nochmal meine Kunden anrufen und ihr die Botschaft durchgeben. Oder habt ihr eine alternative Idee?

  • P.S. Die Datenbank löscht Du ja nicht, sondern wenn, dann nur die Inhalte (Tabellen) darin. Ich würde in deinem Fall die DB Exportieren, alle Dateien per FTP Kopieren, alles Aktualisieren und dann wieder auf den Server hochschieben. Somit gehst Du sicher, dass die Liveseite nicht abgschossen wird.

    Gute Idee! Somit hätte ich zumindest eine Sicherung des aktuellen Standes.

  • Habe gerade mit 1&1 telefoniert. Über den Login des Hosters habe ich die Möglichkeit, eine Sicherung der Dateien bis einschließlich letzten Samstag einzuspielen.


    Eine Wiederherstellung der Datenbank ist drei Monate rückwirkend möglich, wäre allerdings kostenpflichtig.


    Hältst du eine Wiederherstellung der Dateien vom letzten Sonntag für sinnvoll, wenn ihr bereits einen Datenbankfehler vermutet?

    Das halte ich allein schon aus Haftungsrechtlichen Gründen für sehr Sinnvoll, damit erst einmal wieder alles läuft. alles andere muss danach besprochen, bzw aktualisiert werden.

  • Wird ab jetzt auf jeden Fall beherzigt und regelmäßig gemacht!


    Den Kunden erreiche ich gerade nicht. Das Backup des heutigen Standes lade ich gerade herunter. Anschließend wird die Datenbank gesichert.


    Danach wird dann der Stand der Dateien vom letzten Sonntag eingespielt.


    Vielleicht habe ich Glück und das Problem hat sich damit bereits erledigt.

  • Nachdem ich nun deine September-Version mit der aktuellen Webseite verglichen habe, habe ich folgendes festgestellt:


    In allen Tabellen, in denen ein "autoincrement" benötigt wird (keine Ahnung, welche alle) ist dieses verschwunden.

    Neue Beiträge, Menüs ... und wohl auch Module, User usw. bekommen alle immer die Id=0. Das dürfte das eigentliche Problem sein.


    Wie kann das autoincrement verschwinden? War deine Sicherung vom September noch vom alten Hoster, so dass das beim Umzug verschwunden ist.

    In der alten Sicherung ist es noch überall drin.


    Ich weiß auch nicht, wie Joomla nun reagiert, wenn man das autoincrement in den Tabellen nachträglich einfügt, in denen es benötigt wird.

    Wäre vielleicht einen Versuch wert.

  • Mit der Sicherung vom alten Hoster kann der autoincrement-Fehler nicht zusammenhängen, da bis zum Anfang dieser Woche alles noch ordnungsgemäß funktioniert hat. Erst als ich drei weitere Kategorien angelegt habe und die bisherigen Beiträge diesen Kategorien zuordnen wollte (um dies später im Menü entsprechend abzubilden), trat die besagte Problematik mit dem Menü auf.


    Die Sicherung des heutigen Standes ist jetzt durch. Da ich aus privaten Gründen leider bereits um 16 Uhr Feierabend machen muss, wird sich das Thema auf morgen früh verschieben.


    Ich vermute, dass sich das nachträgliche autoincrement nur auf die Einträge auswirken würde, die danach hinzu kommen. Sicher sagen kann ich das aber auch nicht.


    Sollten wir bis morgen früh noch keine bessere Idee haben, würde ich den Datenbestands vom letzten Sonntag wiederherstellen. Bringt dies nichts, müsste die Datenbank vom September eingespielt oder alternativ die Sicherung von 1&1 angefordert werden.

  • Erst als ich drei weitere Kategorien angelegt habe und die bisherigen Beiträge diesen Kategorien zuordnen wollte (um dies später im Menü entsprechend abzubilden), trat die besagte Problematik mit dem Menü auf.

    ....

    Ich vermute, dass sich das nachträgliche autoincrement nur auf die Einträge auswirken würde, die danach hinzu kommen. Sicher sagen kann ich das aber auch nicht.


    Solange man keine neuen Module, Beiträge, Kategorien, Menüpunkt, Erweiterungen generiert/installiert, macht sich das fehlende "autoincrement" auch nicht bemerkbar.

    Wenn du aber z.B. mehrere neue Kategorien anlegst und diese alle die Id=0 bekommen, hast du ein Problem:



    Gleiches mit dem Installieren von Komponenten wie AkeebaBackup oder JCE. Wird in der entsprechenden Tabelle die id mit einem autoinkrement versehen (und Primärschlüssel), dann werden diese Erweiterungen auch wieder im jeweiligen administrator-Menü angezeigt.


    Teilweise müssen vorher alle mehrfachen Einträge entfernt werden. Insgesamt einiges an Puzzlearbeit.


    Vielleicht weiß jemand, was die Autoinkremente entfernt haben könnte, wenn es nicht durch einen DB-Import/Export geschehen sein sollte?

    Doch wie kann man in einem Rutsch alle Inkremente wieder herstellen? Eventuell durch Einspielen eines Joomla 3.8.x to 3.8.13-Packages mit anschließender DB-Reparatur im Backend?


    Natürlich würde wohl auch der manuelle Weg funktionieren:

    - Frisches Joomla zum Vergleich installieren

    - Alle DB-Tabellen vergleichen und bzgl. Primärschlüssel und Autoinkrement korrigieren, dabei mehrfache Einträge korrigieren


    Zu beachten: Wenn du von 1&1 das Backup eingespielt bekommst, sollten die Dateien und die DB-Tabellen des Joomla-Projekts vom gleichen Tag stammen. Mittlerweile hat dein Joomla ja einige Aktualisierungen erhalten, so dass die DB nicht mehr ganz passen würde.

    Und dann müsstest du nachschauen, ob die genannte Problematik mit dem Autoinkrement da bereits bestand.

    Dann würde es dir nichts nutzen. Dann müsstest du das Problem beheben oder die Sicherung von Anfang September nehmen. Diese läuft ja.

  • Ich habe gerade die ursprüngliche SQL Datei geprüft, die wir damals zur Zeit des Umzugs importiert haben. In dieser sind viele autoincrements vorhanden. Deswegen gehe ich davon aus, dass der Datenbankexport in Ordnung gewesen sein wird.


    Gestern Abend habe ich alle Texte die wir in der Zwischenzeit verändert haben zwischen gespeichert. D.h. ich werde jetzt den Stand von Montag zurücksetzen. Funktioniert die Seite danach nicht einwandfrei, setze ich einfach den Stand vom September zurück. Dann ist ja alles wieder wie vorher. Sobald das durch ist, können wir dann nochmal gucken, ob sich die Erweiterungen aktualisieren lassen und ob die Tabellen dann so aufbereitet sind, dass ich problemlos neue Kategorien anlegen kann.

  • Zieh dir zur Sicherheit am besten mittels FileZilla das letzte Akeeba-Backup (730 MB) nochmal auf deinen Rechner.

    Dieses beinhaltet auch das jpa (364 MB) von Anfang September.

    Lösche es anschließend vom Server, damit du Platz bekommst!


    Mach dann nochmal ein aktuelles Akeeba-Backup, welches du auch downloadest und anschließend vom Server löschen kannst.


    Dass sämtliche Primärschlüssel und Autoinkremente verschwinden, kann ich mir nur durch einen DB-Export/-Import erklären. Möglicherweise hast du nach dem Umzug noch mal die DB mit falschen Einstellungen verschoben. Dies wäre dann der Stichtag.


    Die Problematik betrifft auch nicht nur die neuen Kategorien, sondern seit längerem auch Menüpunkte, Module, SPBuilder usw. Das ist auch die Erklärung, warum du mit Joomla solche Schwierigkeiten hattest.


    EDIT: Manche Erweiterungen wie der JCE wollen mit der automatischen Aktualisierung auf die Pro-Version updaten. Wenn man diese nicht installiert hat, sondern lediglich die Core-Version, dann kommt es zur Fehlermeldung. Ist normal.

    Hier einfach das zip (Core-Version) vom Anbieter downloaden und über "Paketdatei installieren" aktualisieren. Das funktioniert auf jeden Fall.


    Viel Erfolg!

  • Erneut hallo zusammen,


    mein Joomla Abenteuer geht weiter.


    Bei dem Versuch, die Sicherung der Webseite aus dem September einzuspielen, wird die Tabelle "n_akeeba_common" hinsichtlich des utf8mb4_unicode_ci bemängelt.


  • Recht hast du. Danke. Habe einfach beide "Force UTF-8" Haken angeklickt und es lief durch.


    Bekomme aber immer noch eine 505 Fehlermeldung. Jetzt muss ich den Beitrag welcher über den SP Page Builder läuft wahrscheinlich wieder als Hauptbeitrag festlegen, richtig? Den finde ich in der Liste der Beiträge aber nicht....

  • In der lokalen Testversion lief die Seite entweder sofort oder ich hatte eine Kleinigkeit geändert. Könnte ein Menüpunkt "Startseite" gewesen sein. Lokal habe ich gerade keinen Zugriff um das zu überprüfen.

    Ein 500er könnte aber auch noch an der configuration.php oder der .htaccess liegen. Letztere hatten wir ja mal angepasst an den neuen Hoster. Musst du möglicherweise erneut machen.

    Morgen kann ich noch mal reinschauen.

  • Hattest du für die Seite nicht ein SSL-Zertifikat? Momentan wird nur http genutzt.


    Die max_execution_time liegt laut PHP-Info bei 50000 Sekunden. Normal wären so 60 bis 120. Spätestens der Akeeba-Konfiguration-Assistent fängt da an zu meckern.


    Ich komme an die .htaccess nicht dran, da sich die Zugangsdaten geändert haben.

  • Hallo JoomlaWunder,


    entschuldige die späte Antwort. Bin seit heute morgen krank geschrieben.


    Ich habe gestern knapp 2 Stunden mit dem 1&1 Support telefoniert. Hierbei haben wir auch das FTP Passwort angepasst. Das neue lasse ich dir morgen früh zukommen.


    Und ja, ein SSL Zertifikat ist für die Webseite hinterlegt. Vielleicht hängt das noch mit der .htaccess zusammen?


    Das die Webseite sofort erscheint, wenn die Servereinstellungen angepasst sind, klingt super. Ich müsste dann nur noch wissen, welche Einstellungen wo anzupassen sind. Der Kunde ist inzwischen (verständlicherweise) leider sehr verärgert.


    Sobald die Seite wieder online ist, möchte ich natürlich unbedingt verhindert, dass ein solches Problem erneut auftritt. Habe nur leider die Sorge, dass es wieder zum genau gleichen Problem kommt, wenn ich neue Kategorien anlegen würde. Wie können wir das verhindern?


    Und wo reduziere ich die max_execution_time?