Nach der Migration der WordPress-Website kann ich nicht auf den Administrator zugreifen (weiße Seite)

Auf Ihrer Website ist ein Fehler aufgetreten, und Sie müssen herausfinden, was passiert.

WordPress-URLs

Wenn Sie WordPress Sites migrieren, bei denen sich die URL ändert, müssen Sie WordPress über die neue URL informieren. WordPress speichert diese Informationen in der Datenbank. Wenn Sie damit vertraut sind, können Sie den richtigen Eintrag in der Tabelle wp_options in Ihrer Datenbank finden und deren Wert aktualisieren.

Ich werde einige Korrekturen für Standard WordPress) -Installationen zeigen (wobei die Site-URL WordPress root) ist), aber Sie können müssen unterschiedliche Werte für home und siteurl verwenden, wenn Sie ein anderes Setup haben.

URLs über SQL reparieren

Sie müssen die relevanten Felder in der Datenbank aktualisieren. Dies sind die Einträge von wp_options, Wobei option_namesiteurl oder home ist. Sie können diese Felder mit phpmyadmin, mysql-workbench oder einem anderen Datenbankverwaltungstool finden, oder Sie können die folgende Abfrage verwenden und die URL so ändern, dass sie Ihre eigene ist.

UPDATE `wp_options` SET `option_value`='http://www.myurl.com' WHERE `option_name` IN ('siteurl', 'home');

URLs über wp-config.php Reparieren

Sie können dies jedoch auch über wp-config.php Tun, was ich als wesentlich komfortabler empfinde. Öffnen Sie einfach wp-config.php Und fügen Sie die Zeilen hinzu:

// Site URLS (override DB settings)
define('WP_HOME','http://www.myurl.com');     //<-- NO TRAILING /
define('WP_SITEURL','http://www.myurl.com');  //<-- NO TRAILING /

Natürlich müssen Sie Ihre korrekte URL angeben.

Möglicherweise ist dies der einzige Fehler, den Sie haben. Nachdem Sie diese Zeilen zu wp-config.php Hinzugefügt haben, können Sie sich anmelden und Ihre Site normal verwenden.

Debugging WordPress Fehler

Wenn jedoch weiterhin Probleme auftreten und Sie gerade an der Entwicklung einer Website arbeiten, wird möglicherweise eine Fehlerausgabe angezeigt. Sie können in Ihren Serverprotokollen nach Informationen zu den Fehlern suchen. Möglicherweise ist es jedoch praktischer, wenn WordPress) einfach die Fehler auf der Seite anzeigt. Ändern Sie die folgende Einstellung in true, um die Fehleranzeige zu aktivieren. in wp-config.php.

define('WP_DEBUG', true);

Jetzt zeigt WordPress alle aufgetretenen Fehler direkt auf der Webseite an. Ändern Sie die Einstellung auf false, um sie auf einer Produktionssite zu verwenden.

Arbeiten mit wp-config.php

Diese Datei befindet sich im Stammverzeichnis Ihrer wordpress Installation. Um die hier genannten Änderungen vorzunehmen, können Sie die Datei entweder direkt auf dem Server bearbeiten (z. B. über ssh) oder Laden Sie die Datei mit einem FTP-Client herunter, nehmen Sie Ihre Änderungen mit einem Texteditor vor und laden Sie die Datei erneut hoch.

Es ist auch eine gute Idee, eine Sicherungskopie zu erstellen, bevor Sie Änderungen vornehmen, falls Sie während der Arbeit etwas beschädigen.

Verweise

Sie können alles über das Ändern der WordPress Site-URL auf der Docs-Seite lesen.

Spät zur Party, ich habe dies kürzlich erlebt und es geschafft, das Problem zu lösen. Hier ist was ich getan habe.

Schritt 1: Setzen Sie WP_DEBUG auf true aus der wp-config.php-Datei

Schritt 2: Ich habe domain.com/wp-login.php anstelle von domain.com/wp-admin versucht. Dadurch konnte ich ein Anmeldeformular und einige Fehler von Warning: Cannot modify header information - headers already sent by erhalten.

Schritt 3: Ich habe ob_start(); in wp-login.php-Datei nach <?php in der ersten Zeile hinzugefügt, natürlich, um mich für eine Weile zu interessieren.

Schritt 4: Dieser Trick hat funktioniert. Ich habe alle Plugins deaktiviert und Fehler sind verschwunden.

Schritt 5: Alle Plugins nacheinander aktiviert, um herauszufinden, welches Plugin Fehler verursacht. Damit ich den Fehler in einem bestimmten Plugin beheben kann. Als gäbe es vor wp_enqueque_style ein Plugin-Addierstil, so habe ich es auf eine Funktion gesetzt und es richtig angehängt.

Es gab auch kleinere Fehler wie deprecated-Funktionen. Es liegt an Ihnen, ob Sie es korrigieren oder ein alternatives Plugin verwenden möchten.

Und vergessen Sie nicht, ob_start aus der wp_login.php-Datei zu entfernen. Die Kerndateien sollten nicht geändert werden.

Hoffe das hilft jemandem wie mir.

In Ihren Einstellungen für Ihr WordPress-Dashboard gibt es zwei Felder mit den Namen "WordPress-Adresse (URL)" und "Site-Adresse (URL)". Diese Einstellungen werden auch als "Startseite" und "Website-URL" für Ihre Website bezeichnet. Die Werte müssen mit dem Server übereinstimmen, auf dem Sie tatsächlich ausgeführt werden.

Wenn Sie nicht zum Administrator gelangen, können Sie phpmyadmin verwenden, in Ihre Datenbank gehen, die Felder der Tabelle wp_options suchen und sicherstellen, dass sie Ihre Domäne widerspiegeln.

In den meisten Fällen sollte es ausreichen.

Ich habe selbst einige Male gegen den gefürchteten "White Screen of Death" gekämpft. Sie können die Threads auf der Wordpress Support Site durchsuchen, um Vorschläge zu erhalten, oder Google für viele, viele Geschichten und Ratschläge, die sich mit diesen Themen befassen. Ich kann dafür keine einzige, autoritative Referenz empfehlen.

In den meisten meiner Fälle wurde dies durch Whitespace nach einem schließenden ?>-Tag verursacht, das aufgrund von Änderungen in Newline-Schemata zwischen meinen Dev- und Produktionsservern eingeführt wurde, normalerweise in einem Plugin.

Sie können auch versuchen, Wordpress in den debug-Modus zu setzen oder error_reporting(E_ALL); zur ersten Zeile der /wp-admin/admin.php-Datei Ihrer Site hinzuzufügen, um zu sehen, ob diese Hinweise enthalten.

Ich war in der Lage, dies zu vermeiden (Touch Wood), indem ich das XCloner Plugin verwende, um Übertragungen zwischen meinem Win dev-Rechner und dem * nix-Produktionsserver vorzunehmen.

Bearbeiten Sie wp-content/themes/active-theme-folder/function.php und fügen Sie diesen Code unmittelbar vor

<?php
define('WP_HOME','http://www.myurl.com');     //<-- NO TRAILING /
define('WP_SITEURL','http://www.myurl.com');

Fügen Sie in Ihrer wp-config.php-Datei direkt über der Zeile mit der Zeile zum Stoppen der Bearbeitung diese Zeile hinzu:

define('RELOCATE',true);
/* That's all, stop editing! Happy blogging. */

Gehen Sie dann zu Ihrer Anmelde-URL, aktualisieren Sie die Seite und melden Sie sich an. WICHTIG: Wenn Sie sich anmelden können, entfernen Sie die RELOCATE-Zeile, bevor Sie fortfahren. Dann navigiere zu:

Settings > General

Setzen Sie Ihre Wordpress-URL und Ihre Site-Adresse auf die richtigen Speicherorte:

WordPress Address (URL): http://example.com/wordpress

Site Address (URL): http://example.com/myblog

Klicken Sie auf "Speichern".

Fügen Sie die folgende Zeile in die wp-config.php-Datei ein: 

define('WP_HOME', 'http://' . $_SERVER['SERVER_NAME']);

define('WP_SITEURL', WP_HOME . '/');

Ich füge diese Antwort dem Streit hinzu, in der Hoffnung, dass es jemand anderem helfen könnte. Ich befolgte alle obigen Ratschläge ohne Erfolg. Ich musste die PHP) -Dateien hacken, um meinem Administrator den Zugriff auf das Bedienfeld zu ermöglichen. Im Bedienfeld habe ich festgestellt, dass meinem Administratorkonto keine Administratorrolle zugewiesen wurde.

Dies ist mein Hack zu "wp-includes /abilities.php"

function current_user_can( $capability ) {
    $current_user = wp_get_current_user();

    if ( empty( $current_user ) ) {
        return false;
    }

return true;  // HACK to get superuser power to any logged in user

    $args = array_slice( func_get_args(), 1 );
    $args = array_merge( array( $capability ), $args );

    return call_user_func_array( array( $current_user, 'has_cap' ), $args );
}    

Dadurch konnte der Administratorbereich mit Zugriff auf https://example.com/wp-admin/users.php angezeigt werden, und dann konnte ich die Rolle zuweisen. Ich habe dann die functions.php enthackt, um sicherzustellen, dass alle Benutzer die richtigen Rechte haben, nachdem mir "Administrator" zugewiesen wurde.

Ich hatte das gleiche Problem nach der Migration zu einem lokalen Server. Ein erster Versuch schlug fehl, da sich in der Datenbank viele hartcodierte Dateipfade befanden. Ich versuchte es erneut und sorgte dafür, dass derselbe Pfad wie auf dem Live-Server und derselbe Hostname und der gleiche Datenbankname angelegt wurden. Nun war die Website gut, aber wp-login ergab einen weißen Bildschirm.

Mit wp-debug habe ich herausgefunden, dass das Problem durch ein wp-super-cache-Plugin verursacht wurde, das einen vollständigen Dateipfad in der config.php .__ festcodiert hatte. 

Dies sind die Schritte, die ich normalerweise befolge.

1. Dateien und Datenbank hochladen.
2. Stellen Sie die richtigen Dateiberechtigungen ein.
3. Aktualisieren Sie die Datenbankkonfigurationen in der Datei wp-config.php, um sie dem Server-Db-Login anzupassen.
4. Aktualisieren Sie die wp_options-Tabelle zum Aktualisieren der Site-URL und der Home-URL.
5. Wenn alles gut geht, sollten Sie sich mit dem wp-login.php als URL beim Admin anmelden können.
6. Als Nächstes müssen Sie zu den Permalinks gehen und auf Speichern klicken, um die .htaccess-Datei automatisch zu aktualisieren. Wenn kein Schreibrecht vorhanden ist, können Sie es kopieren und die Datei über ftp bearbeiten.
7. Als nächstes können Sie alle URLs problemlos mit einem Plugin namens velvet urls aktualisieren. Ich benutze es seit vielen Jahren. Es werden alle anderen URLs in der Datenbank aktualisiert.

Alle diese Schritte reichen aus, wenn alles richtig läuft.

Wenn Sie eine leere Seite oder etwas erhalten, können Sie die Fehlerberichterstattung aktivieren und die Protokolle aus der WP-Konfigurationsdatei selbst schreiben. Sie können einige davon zum Debuggen ausprobieren.

1. Entfernen Sie einfach Plugins nacheinander aus den Ordnern.
2. Entfernen Sie das von Ihnen verwendete benutzerdefinierte Design.

Wenn Sie die Kerndateien nicht größtenteils bearbeitet haben, wird das Problem behoben. Nur eine andere Chance ist der Versionskonflikt für PHP oder MySQL, der auch bei der Migration sehr wichtig ist. Hoffe das hilft jemandem.

In vielen Fällen tritt das Problem bei der Migration von Dateien auf einen anderen Server auf einen geringfügigen Fehler in einer Ihrer PHP -Dateien auf. Der Fehler besteht aus zusätzlichen Zeichen nach dem schließenden?> PHP - Tag in der Datei. Dies können nur einfache Leerzeichen oder Renditen sein, aber sie können oft die Ursache für den weißen Bildschirm des Todes sein.

Hauptursache ist die Datei functions.php in Ihrem WordPress-Theme. Betrachten Sie es in einem einfachen Textdatei-Editor (häufig für die meisten Hosting-Konten verfügbar) und stellen Sie sicher, dass Sie alle Zeilen nach dem schließenden Tag löschen.

Wenn die Datei nicht in dieser Datei enthalten ist, verwenden Sie die Fehlerberichterstattung, um die Täterdatei zu identifizieren. Möglicherweise befindet sie sich in einem Plugin oder einer anderen Datei in Ihrem Design.

Ändern Sie, wie von Jon Surrell beschrieben, die Fehleranzeige, und ändern Sie die folgende Einstellung in wp-config.php auf true.

define('WP_DEBUG', true);