Wordpress: "postname"-Permalinks funktionieren nicht nach Umzug+Update

Photon

Commodore
Registriert
Apr. 2006
Beiträge
5.036
Hallo zusammen,

folgendes Szenario: Ich habe bisher noch nie mit WordPress gearbeitet, bin nun aber in die missliche Lage gekommen, die Betreuung einer recht umfangreichen Webseite, die in Wordpress umgesetzt ist, übernehmen zu müssen. Mein Vorgänger hat sich in die Bedienung des Wordpress-Editors reingefuchst, hat aber keinen Background in Sachen Hosting und Administration. Deshalb ist der aktuelle Zustand nun, dass die WordPress-Instanz schon einige Versionen hinter dem aktuellen Release ist und auch eine zweistellige Anzahl von Plugins um eine Aktualisierung bitten.

Ich weiß nicht, wie es in professionellen Umgebungen üblich ist, aber ich stelle es mir immer so vor, dass eine größere Webseite nicht im laufenden Betrieb editiert wird, sondern eine zweite Version existiert, an der gebastelt werden kann, die dann, wenn man mit der Bastelei zufrieden ist, in production geschickt wird. Aber so einen Workflow haben wir, wie man sich denken kann, nicht.

Nachdem Updates ja gerne mal Probleme verursachen, wollte ich keine Operation am offenen Herzen durchführen und habe eine Sicherung der WordPress-Instanz mit dem Plugin Duplicator erstellt. Dann habe ich eine virtuelle Maschine aufgesetzt, dort Apache, PHP und MySQL eingerichtet und die Sicherung wieder eingespielt.

Dann hab ich was Dummes gemacht: Statt die Webseite im Ist-Zustand in der virtuellen Maschine zu testen, habe ich direkt die Aktualisierungen in der VM-Instanz installiert. Wäre damit alles gut gegangen, wüsste ich, dass es sicher ist, die Aktualisierungen zu machen, und hätte sie auch in der Live-Version durchgeführt.

Leider kam es anders: Die Hauptseite funktioniert zwar weiterhin, aber alle Unterseiten werden nicht gefunden und ich weiß nicht, ob es an der Konfiguration der Umgebung in der VM liegt oder an den Aktualisierungen... Ich habe jedoch herausfinden können, dass wenn man die Permalinks auf "Einfach" stellt, die Unterseiten wieder aufgerufen werden können. Sie sollen jedoch auf "Beitragsname" stehen und das klappt leider nicht.

Nun weiß ich leider nicht, ob der Fehler durch das Update oder durch die Umgebung in der VM entstanden ist, und hab entsprechend Angst, das Update in der Live-Version zu fahren. Prinzipiell könnte ich eine neue VM aufsetzen, dort wieder alles einrichten und dann die Webseite vor dem Update testen. Der Vorgang hat mich jedoch einen ganzen Tag gekostet (das Einspielen der Sicherung mit Duplicator alleine schon viele Stunden) und da dachte ich mir: Vielleicht kennt ja jemand das Problem und hat einen guten Tipp, wie ich der Ursache auf die Schliche kommen kann?

Danke für alle Tipps und ein frohes Neues! :)

Viele Grüße,
Photon
 
Vielleicht reicht es schon, wenn die Permalink-Struktur in den Wordpress Einstellungen erneut gespeichert wird. Ein häufiges Problem bei so Transfers.

Photon schrieb:
Nachdem Updates ja gerne mal Probleme verursachen, wollte ich keine Operation am offenen Herzen durchführen und habe eine Sicherung der WordPress-Instanz mit dem Plugin Duplicator erstellt. Dann habe ich eine virtuelle Maschine aufgesetzt, dort Apache, PHP und MySQL eingerichtet und die Sicherung wieder eingespielt.
Zum Aufsetzen lokaler Instanzen gibt es mittlerweile Local by Flywheel, ohne Gefrickel mit PHP Versionen, Datenbanken und sonstigem.

Ohne weitere Details über genutzte Plugins und Themes kann man nicht viel mehr dazu sagen, außer, dass die Reihenfolge der Plugin-Aktivierung ebenso eine Rolle spielen kann, ob es wieder reibungslos hochkommt. Bei der bestehenden Instanz kann man mal probieren, alle Plugins zu deaktivieren bzw. wenn inaktive vorhanden sind, diese manuell zu aktivieren.

Caching Plugins sollte man hingegen deaktivieren. Wie du vielleicht merkst, ist es mit ein wenig Vorwissen, das Ganze systematischer anzugehen.

Was mit Duplicator viele Stunden dauert - außer viele Stunden zuzusehen - weiß ich nicht, also, nochmal ran und final dann die geplanten Schritte fürs Produktivsystem anwenden. Ansonst riskierst halt auch das Produktivsystem zu crashen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Photon und madmax2010
@M4ttX Sorry für die sehr späte Antwort. Ich habe nun, wie von dir vorgeschlagen, die Prozedur wiederholt. Mir ist nun am Ende des Backup-Wiederherstellens die Meldung aufgefallen, ich solle wp-includes/php.ini löschen, da sonst Links nicht funktionieren würden. Habe mich schon gefreut, die Ursache des Problems gefunden zu haben, und die Datei weggeschoben, doch leider ist auch bei diesem Durchlauf dasselbe Problem da. Immerhin weiß ich, dass es schon vor dem Update da war, sodass das Update es nicht erst verursacht hat. Trotzdem würde ich gerne das Problem lösen, um das Update testen zu können.

M4ttX schrieb:
Caching Plugins sollte man hingegen deaktivieren. Wie du vielleicht merkst, ist es mit ein wenig Vorwissen, das Ganze systematischer anzugehen.
Könntest du da mehr Details dazu geben? Meinst du, vor der Backup-Erstellung auf dem Produktivsystem?

M4ttX schrieb:
Zum Aufsetzen lokaler Instanzen gibt es mittlerweile Local by Flywheel, ohne Gefrickel mit PHP Versionen, Datenbanken und sonstigem.
Wie kann man das denn in Kombination mit Duplicator nutzen (oder einer anderen Backup-Lösung)? Will ja keine frische neue Instanz aufsetzen sondern die existierende Klonen.

M4ttX schrieb:
Ohne weitere Details über genutzte Plugins und Themes kann man nicht viel mehr dazu sagen, außer, dass die Reihenfolge der Plugin-Aktivierung ebenso eine Rolle spielen kann, ob es wieder reibungslos hochkommt. Bei der bestehenden Instanz kann man mal probieren, alle Plugins zu deaktivieren bzw. wenn inaktive vorhanden sind, diese manuell zu aktivieren.
Kann da sehr gerne mehr Details nachliefern! Meinst du, es könnte helfen, auf der Spielwiese mit eingespieltem Backup alle Plugins zu deaktivieren und dann wieder zu aktivieren?
Ergänzung ()

Nachtrag:

Es war dieses Problem: https://stackoverflow.com/questions...-on-localhost-but-work-perfectly-on-live-serv
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: M4ttX
Zurück
Oben