[3.3] DB-Backup wiederherstellen -> Keine ACP-Anmeldung möglich

[Scanialady]

Für dein neues Testboard solltest du hier noch mal reinsehen: Knowledge Base - Mit dem Board umziehen

...
In der Tabelle phpbb_config war nichts anzupassen. Ging auch ohne Änderung. ...

...bevor das 2. Forum fälschlicherweise Blödsinn in die DB des 1. Forum speichert

Das sind beispielsweise Daten, die in der Tabelle phpbb_config überprüft werden müssen, ob die wirklich gleich bleiben dürfen.

Domainname: server_name
Server Port: server_port
Server Protokoll: server_protocol
Scriptpfad: script_path
Cookie-Domain: cookie_domain (im Zweifel leeren)
Cookie-Pfad: cookie_path (kann im Zweifel auf / gesetzt werden)
Sicherers Cookie: cookie_secure (1 für SSL, ansonsten 0)

Lies bitte den oben verlinkten Artikel dazu.

Beachte: JEDES MAL, wenn du im Testboard eine Datenbanksicherung des normalen Boards einliest, muss das noch einmal angepasst werden, sonst verbindest du wirklich die Boards miteinander

[hetshi]

Für dein neues Testboard solltest du hier noch mal reinsehen: Knowledge Base - Mit dem Board umziehen

Danke für die Info. Hatte ich gestern eh schon alles umgesetzt, nach der ersten DB-Querschießerei.

Beachte: JEDES MAL, wenn du im Testboard eine Datenbanksicherung des normalen Boards einliest, muss das noch einmal angepasst werden, sonst verbindest du wirklich die Boards miteinander

Das war die Lehre von gestern . Glücklicherweise bevor ich das 1. Board angepasst hatte.
Mein Fehler war, dass ich den Cache VOR dem ersten Aufrufen gelöscht habe. Bringt ja nichts. Sollte ja nach der Anpassung geschehen.

Wegen 'meiner eigenen Logistik' muss ich wohl auch nicht die Tabelle phpBB_config angreifen.
Eigentlich nutze ich 3 Browser, davon 2 nur fürs 2. Board; fürs 1. Board einen den 3.. Im 1. Browser (fürs 2. Board) importiere ich das DB-Backup (aus 1. Board), gehe im ACP auf Server und Domain, und stelle eigentlich nur die URL um. Erst danach öffne ich den 2. Browser (mit geleertem Cache) und logge mich ins 2. Board ein, bevor ich andere Änderungen mache.

Funktioniert bei mir, ohne mich extra in phpMyAdmin einloggen zu müssen.
Vielleicht täusche ich mich auch nur ? Werde ich noch beobachten und testen, ob das in der Form dann tatsächlich fehlerfrei funktioniert.

[Scanialady]

Cookienamen und Domain /Serverpfad zumindest musst du anpassen, das geht natürlich nur dann ohne direkten Datenbankeingriff, wenn du dich noch einloggen kannst. Das wiederum ist zweifelhaft, denn wenn du die Datenbank geändert (neue Datei eingelesen) hast, ist ja wieder alles weg und weist aufs Ursprungsboard.

[hetshi]

Fehler [hoffentlich] gefunden. Hier noch mein Nachbericht:

Mein kurzfristiges Ziel hatte ich mit dem Klon umsetzen können: alte neue Themen & Beiträge aus Backup rauskopiert und in neues Forum manuell übertragen; war binnen 2 Stunden erledigt. Danach hatte ich beide Foren nach allen o.e. Ratschlägen angepasst: lt. Knowledge Base Board umziehen, plus Cookienamen, Domain/Serverpfad (lt. Tipp @Scanialady : Danke), usw...

Theoretisch war alles korrekt. Beide Foren liefen parallel auch problemlos, bis ich im Hauptforum eine neue Moderatorenrolle anlegte und diese verschieben wollte; wieder gleiches Symptom wie davor, plus ominöse nicht korrigierbare Auswirkungen im Frontend.

Es musste also irgendwo noch ein anderer Fehler sein! Auf der Suche bin ich dann auf den Eintrag Probleme * Filezilla gestoßen. Ich hoffe jetzt ganz vorsichtig, dass es genau das war.

Denn bereits vor meinem Januar-Update hatte ich meine phpBB-Aktivitäten vom Windows-PC komplett auf den Linux-PC umgezogen, damit im Linux Filezilla neu installiert und in der Standard-Konfiguration genutzt. Ich erinnere mich jetzt wieder, dass es im Januar schon „fehlgeschlagene Übertragungen“ gab, die ich aber irgendwie hinbekommen habe.

Kurzum: Einstellungen FileZilla und Editor wurden zuerst angepasst. Danach installierte ich beide Foren komplett neu. Den letzten Fehler mit Anpassung der Moderatorenrollen habe ich gleich getestet, sowie alle anderen davor: Keine weiteren Fehler mehr aufgetreten. Bisher läuft alles wie es soll.

Jetzt drücke ich mir selbst alle Daumen, dass damit alle meine Fehlerquellen tatsächlich beseitigt und angepasst sind ***vorsichtig-3x-auf Holz-klopf***.

[LukeWCS]

Danke für die detaillierte Rückmeldung. Ein paar Anmerkungen am Rande:

Will ich ein DB-Backup über ACP->Wartung->Wiederherstellen einspielen, ist nach Eingabe BN+PW die /adm/index.php nicht mehr aufrufbar.

Da hilft nur noch eine komplette Wiederherstellung: phpBB-Dateien neu auf Server hochladen

Das ist nicht notwendig. Wir haben ein Tool welches auf Prüfung der phpBB Dateistruktur spezialisiert ist:

phpBB File Check - Zum prüfen auf Existenz und Intaktheit der phpBB Dateien

Dadurch kann man gezielt die effektiven Fehler beheben und muss nicht erneut das Komplettpaket hochladen was ja auch sehr zeitintensiv ist und dabei kann es ja auch wieder zu neuen Problemen kommen, wenn der erste Anlauf schon nicht fehlerfrei war.

Der Fehler war im Frontend nicht zu entdecken; hat alles wunderbar funktioniert. Nur im ACP, als später wieder Foren rauf/runter verschoben wurden, habe ich es anhand der Forumspfade entdeckt. Da wurde ein Forum ganz ominös von Ebene-1 plötzlich auf Ebene-4 eines anderes Forums gespeichert, obwohl im Frontend alles korekt angezeigt wurde.

Das hört sich stark nach left/right-ID Problematik an, die man gut mit dem STK beheben kann. So als Tipp falls das nochmal vorkommen sollte.

[hetshi]

... muss nicht erneut das Komplettpaket hochladen was ja auch sehr zeitintensiv ist

Anfänglich wars noch zeitintensiv. Aber seit Januar habe ich es schon sooo oft gemacht, dass ich es nebenher einfach aus dem Ärmel schütteln kann

Habe deshalb auch phpBB File Check ausprobiert und dafür die letzte fehlerhafte Version eingespielt.
Hier der Report:

Code: Alles auswählen

phpBB File Check v1.4.5
=======================

Version mode : Auto
MD5 source   : ZIP (1, 2, E)
phpBB Version: 3.3.14
MD5 Version 1: 3.3.14 (phpBB.com)
MD5 Version 2: 3.3.14 (phpBB.de)
PHP Version  : 8.2.27 (Linux)

Please wait, 4077 checksums are being processed...

-----------------------------------------------------------------------
{2:210}   NOTICE: [vendor/composer/installed.php] has the phpBB.de hash
-----------------------------------------------------------------------

Finished!

Report summary
---------------------
Checked files  : 4048
Missing files  :    0
Different files:    0
Notices        :    1

Script/PHP information
----------------------------------------------------------------------
Run time          : 1.091 seconds
Max execution time: 240 seconds
Memory peak usage : 3,944,560 bytes
Memory limit      : 256M
Services          : ZipArchive:1, cURL:1, Sockets:1, allow_url_fopen:1

"0 Missing & Different Files". Die Dateistruktur scheint demnach ok zu sein.
Oder erkennt man daran ev., ob die Ursache Filezilla mit den Standardeinstellungen war?
Ich vermute eigentlich immer noch, dass das ACP fehlerhafte DB-Einträge gesetzt hat. Die Ursache würde mich schon interessieren.

Das hört sich stark nach left/right-ID Problematik an, die man gut mit dem STK beheben kann. So als Tipp falls das nochmal vorkommen sollte.

Das Support Tool Kit scheint etwas veraltet zu sein: v.3.0.x? Damit könnte ich aber im 2. Testforum einmal gefahrlos rumprobieren
"Gut beheben?": Wo müsste ich rumprobieren und einstellen?

[LukeWCS]

"0 Missing & Different Files". Die Dateistruktur scheint demnach ok zu sein.

Ja, der phpBB Core ist einwandfrei. Zumindest jetzt.

Oder erkennt man daran ev., ob die Ursache Filezilla mit den Standardeinstellungen war?

Grundsätzlich ja, so konnten wir irgendwann und nach und nach Zusammenhänge mit fehlerhaft arbeitenden FZs herstellen; wegen falscher Einstellungen. Aber:

Ich vermute eigentlich immer noch, dass das ACP fehlerhafte DB-Einträge gesetzt hat. Die Ursache würde mich schon interessieren.

Mich interessiert die exakte Ursache auch immer. Aber im nachhinein lässt sich bei dir jetzt nichts mehr nachvollziehen. Es ist extrem schwer bis unmöglich, dass du wieder exakt das ursprüngliche Fehlerbild rekonstruieren kannst. Was man nachträglich aber recht sicher sagen kann:

Will ich ein DB-Backup über ACP->Wartung->Wiederherstellen einspielen, ist nach Eingabe BN+PW die /adm/index.php nicht mehr aufrufbar.

Das war sehr wahrscheinlich ein Dateifehler. Eine falsche .htaccess fällt auch darunter, da von dieser Datei Fehler ausgehen können, wenn diese falsch konfiguriert oder veraltet ist.

Nur im ACP, als später wieder Foren rauf/runter verschoben wurden, habe ich es anhand der Forumspfade entdeckt. Da wurde ein Forum ganz ominös von Ebene-1 plötzlich auf Ebene-4 eines anderes Forums gespeichert, obwohl im Frontend alles korekt angezeigt wurde.

Das war sehr sicher ein left/right Problem, also ein DB Problem.

Das Support Tool Kit scheint etwas veraltet zu sein: v.3.0.x?

Das offizielle STK für 3.0 wurde schon längst eingestellt (2015), das darf bei 3.3 nicht mehr eingesetzt werden. Zudem war 3.0 noch Mod Ära, da kannte das damalige STK noch gar keine Erweiterungen.

Es gab seitdem verschiedene Maintainer die das Projekt quasi inoffiziell weitergeführt haben. Zum Beispiel von AlexSheer und seit einiger Zeit von Tatiana5:

https://github.com/Tatiana5/phpBB3.2-STK

Und von Mahony gibts eine deutsche Version:

http://phpbb3-support.square7.ch/viewtopic.php?t=897

[hetshi]

Danke für deine ausführlichen Infos.

Mich interessiert die exakte Ursache auch immer. Aber im nachhinein lässt sich bei dir jetzt nichts mehr nachvollziehen. Es ist extrem schwer bis unmöglich, dass du wieder exakt das ursprüngliche Fehlerbild rekonstruieren kannst.

Das Fehlerbild kann ich mit den DB-Backups im 2. Forum wieder herstellen.

Nur im ACP, als später wieder Foren rauf/runter verschoben wurden, habe ich es anhand der Forumspfade entdeckt. Da wurde ein Forum ganz ominös von Ebene-1 plötzlich auf Ebene-4 eines anderes Forums gespeichert, obwohl im Frontend alles korekt angezeigt wurde.

Das war sehr sicher ein left/right Problem, also ein DB Problem.

Hab mir dazu das von dir empfohlene Mahoney-STK installiert. Danke für den Tipp.
Links-/Rechts-IDs kontrollieren durchlaufen lassen. Meldung => "Alle IDs waren richtig, so dass keine Korrektur vorgenommen werden musste.". Fehler immer noch da: Anzeige Rolle, wo keine angezeigt werden soll. Das Symptom war identisch: das ominöse Verschiebe-Verhalten.

ABER:
Habe im STK auch Auto-Kofiguration Cookies entdeckt. Da heißt es für die Cookie-Domain: subdomain.meine-domain.de
Hatte mich an die Tipps von @Scanialady vor der Neuinstallation gehalten, um bei beiden Foren extra die richtigen Cookie-Angaben zu machen. Dazu heißt im ACP -> Allgemein: Cookies -> Cookienamen: "Nun füge einen Punkt vor den gemeinsamen Domain-Namen und trage das Ergebnis in das Feld ein. In unserem Beispiel würdest du also .example.com einfügen (beachte den Punkt am Anfang).".

Ich habe das so verstanden, dass bei beiden Foren mit 2 unterschiedlichen Subdomains also ".meine-domain.de" OHNE Subdomain bei Cookie-Domain eingetragen werden soll. Das STK empfiehlt mir MIT Subdomain, ohne Punkt vor der Subdomain.

Was ist nun richtig?

[Mike-on-Tour]

Ich habe bei allen von mir betreuten Foren OHNE Subdomain, aber mit führendem Punkt. D.h., dass auch das "www" weg bleibt oder auch eine Subdomain wie "beta".
So steht es auch in der Beschreibung dieser Einstellung im ACP.

[LukeWCS]

Das Fehlerbild kann ich mit den DB-Backups im 2. Forum wieder herstellen.

Das Fehlerbild in der DB lässt sich mit einem Backup vom fehlerhaften Zustand natürlich 1:1 wiederherstellen. Aber laut deiner Beiträge gabs auch Dateifehler und genau die lassen sich später unmöglich exakt rekonstruieren. Wenn es beim Hochladen des Komplettpakets mit über 4K Dateien Fehler gab, egal welche, und man würde diesen Vorgang exakt wiederholen, wird es so gut wie sicher beim zweiten Durchlauf ganz andere Dateien betreffen und die Fehler wären auch anders gelagert, weil die Fehler bei den falschen FileZilla Standardeinstellungen "willkürlich" passieren. Womit das zusammenhängt weiss ich nicht, aber ich würde vermuten dass das von verschiedenen Faktoren wie aktuelle Last des Servers und/oder Verbindungsqualität Client<>Server abhängig ist.

Fakt ist: Bei FZ mit Standardeinstellungen sind Probleme bei der Übertragung bereits vorprogrammiert. Bei unseren empfohlenen Einstellungen wird der Vorgang deutlich zuverlässiger.

Links-/Rechts-IDs kontrollieren durchlaufen lassen. Meldung => "Alle IDs waren richtig, so dass keine Korrektur vorgenommen werden musste.". Fehler immer noch da: Anzeige Rolle, wo keine angezeigt werden soll. Das Symptom war identisch: das ominöse Verschiebe-Verhalten.

Okay seltsam, darauf kann ich mir gerade keinen Reim machen.