После миграции веб-сайта WordPress я не могу получить доступ к администратору (белая страница)

Я пытаюсь переместить сайт WordPress с локального сервера на онлайн-сервер.

Проблема заключается в том, что после миграции, если я попытаюсь открыть страницу администрирования (wp-admin), я получаю только белую страницу, как вы можете видеть здесь: http://scorejava.com/wordpress/wp-admin/. Все остальное выглядит хорошо на главной странице: http://scorejava.com/wordpress/.

На моем локальном веб-сервере у меня есть сайт WP в папке: /var/www/wordpress. Я переместил его в папку Wordpress, которая находится в моем корневом каталоге моего онлайн-сервера.

Я также импортирую локальную базу данных в единственную базу данных с помощью MySql, а затем я использую Поиск и замена для баз данных WordPress Script, чтобы автоматически автоматически вносить в базу данных все http://localhost/wordpress таблицы с http://scorejava.com/wordpress/.

Ответ 1

На вашем сайте есть ошибка, и вам нужно выяснить, что происходит.

URL-адреса WordPress

При переносе сайтов WordPress, где изменяется URL-адрес, вам нужно будет сообщить WordPress о новом URL-адресе. WordPress хранит эту информацию в базе данных, поэтому, если вам это нравится, вы можете найти правильную запись в таблице wp_options в своей базе данных и обновить ее значение.

Я покажу некоторые исправления для стандартных установок WordPress (где URL-адрес сайта - это корень WordPress), но вам может потребоваться использовать разные значения для home и siteurl, если у вас есть другая настройка.

Исправить URL через SQL

Вам нужно будет обновить соответствующие поля в БД, те, которые являются элементами wp_options, где option_name - siteurl или home. Вы можете найти эти поля, используя phpmyadmin, mysql-workbench или другой инструмент управления базами данных, или вы можете использовать следующий запрос, изменяя URL-адрес, чтобы быть вашим.

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

Исправить URL-адреса через wp-config.php

Однако вы также можете сделать это через wp-config.php, который мне кажется намного более удобным. Просто откройте wp-config.php и добавьте строки:

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

Очевидно, вам нужно указать правильный URL.

Возможно, это единственная ошибка, с которой вы столкнулись, и после добавления этих строк в wp-config.php вы сможете войти и использовать свой сайт в обычном режиме.

Отладка ошибок WordPress

Однако, если вы продолжаете испытывать проблемы, и в любое время, когда работаете над созданием веб-сайта, вы захотите увидеть выход ошибки. Вы можете проверить журналы своего сервера для получения информации об ошибках, но для WordPress вам может быть проще просто отображать ошибки на странице. Чтобы включить отображение ошибок, измените следующую настройку на true в wp-config.php.

define('WP_DEBUG', true);

Теперь WordPress отобразит все ошибки, с которыми он сталкивается непосредственно на веб-странице. Обязательно измените настройку на false для использования на производственной площадке.

Работа с wp-config.php

Этот файл будет находиться в корневом каталоге вашей установки Wordpress. Чтобы внести какие-либо изменения, упомянутые здесь, вы можете либо отредактировать файл непосредственно на сервере (например, через ssh), либо загрузить файл с FTP-клиентом, внести изменения в текстовый редактор и снова загрузить файл.

Также рекомендуется сохранить резервную копию, прежде чем вносить какие-либо изменения в случае, если вы что-то сломаете во время работы.

Ссылки

Вы можете прочитать все об изменении URL-адреса сайта WordPress на странице docs.

Ответ 2

Поздно к вечеринке я пережил это недавно, и мне удалось решить проблему. Вот что я сделал.

Шаг 1: Установите WP_DEBUG в true из файла wp-config.php

Шаг 2: Я попробовал domain.com/wp-login.php вместо domain.com/wp-admin, чтобы я мог получить по крайней мере форму входа и некоторые ошибки Warning: Cannot modify header information - headers already sent by

Шаг 3: Я добавил ob_start(); в wp-login.php файл после <?php в первой строке, конечно, чтобы немного втянуть меня.

Шаг 4: Этот трюк сработал. Я отключил все плагины, и ошибки ушли.

Шаг 5: Активизировал все плагины один за другим, чтобы определить, какой плагин вызывает ошибку. Поэтому я могу исправить ошибку в определенном плагине. Как и один плагин, добавляющий стиль до wp_enqueque_style, поэтому я устанавливаю его в функцию и правильно зацепию.

Были и некоторые незначительные ошибки, подобные функциям deprecated. Это зависит от вас, хотите ли вы его исправить или использовать альтернативный плагин.

И не забудьте удалить ob_start из wp_login.php файла. Основные файлы не должны меняться.

Надеюсь, это поможет кому-то вроде меня.

Ответ 3

Внутри ваших настроек для вашей панели управления WordPress есть два поля с именем "Адрес (адрес) WordPress" и "Адрес сайта (URL)". Они также известны как параметры "Главная" и "URL-адрес сайта" для вашего сайта. Значения должны соответствовать серверу, на котором вы на самом деле работаете.

Если вы не можете добраться до администратора, вы можете использовать phpmyadmin, зайти в свою базу данных, найти поля в таблице wp_options и убедиться, что они отражают ваш домен.

В большинстве случаев этого должно быть достаточно.

Ответ 4

Я боролся с ужасным "Белым экраном смерти" сам несколько раз. Вы можете просматривать потоки на сайте поддержки Wordpress, чтобы подбирать некоторые предложения или Google для много и много рассказов людей и советов, касающихся этих. Я не могу рекомендовать одну, авторитетную ссылку для этого.

В большинстве случаев это было вызвано пробелами после закрывающего тега ?>, который появился из-за изменений схем новой строки между моими dev и производственными серверами, обычно в плагине.

Вы также можете попробовать поставить Wordpress в режим отладки или добавить error_reporting(E_ALL); в первую строку вашего сайта /wp-admin/admin.php, чтобы узнать, они дают вам любые подсказки.

Мне лично удалось избежать этого (коснитесь дерева), используя плагин XCloner для переноса между моей машиной Win Dev и * nix.

Ответ 5

Измените wp-content/themes/active-theme-folder/function.php и добавьте этот код непосредственно перед:

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

Ответ 6

У меня была такая же проблема после перехода на локальный сервер. Первая попытка не удалась, потому что в базе данных было много файлов с жесткой кодировкой. Поэтому я попробовал еще раз и позаботился о том, чтобы создать тот же путь, что и на реальном сервере, и то же имя хоста и имя_базы. Теперь сайт был хорош, но wp-login дал белый экран.

С wp-debug я обнаружил, что проблема была вызвана плагином wp-super-cache, который имел полный путь к файлу, закодированный в config.php Изменение этого пути до полного локального пути сделало трюк.

Ответ 7

Добавьте следующую строку в файл wp-config.php:

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

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

Ответ 8

В вашем файле wp-config.php чуть выше строки прекратить редактирование, добавьте эту строку:

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

Затем перейдите по URL-адресу входа в систему, обновите страницу и войдите в систему. ВАЖНО: Если вы можете войти в систему, удалите строку RELOCATE, прежде чем продолжить. Затем перейдите к:

Settings > General

Установите URL-адрес Wordpress и адрес сайта в правильных местах:

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

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

Нажмите "Сохранить".

Ответ 9

Вот шаги, которые я обычно следую.

  1. Загрузить файлы и базу данных.
  2. Установите правильные права доступа к файлу.
  3. Обновите конфигурации базы данных в файле wp-config.php, чтобы они соответствовали имени входа в базу данных сервера.
  4. Обновите таблицу wp_options для обновления URL сайта и домашнего URL.
  5. Если все идет хорошо, вы можете войти в систему администратора, используя wp-login.php в качестве URL.
  6. Первое, что нужно сделать, это перейти к постоянным ссылкам и нажать "Сохранить", чтобы автоматически обновить файл .htaccess. Если нет разрешения на запись, это покажет, что вы можете скопировать его и отредактировать файл через ftp.
  7. Следующее, что вы можете легко обновить все URL-адреса с помощью плагина под названием velvet urls. Пользуюсь им много лет. Это обновит все другие URL в базе данных.

Всех этих шагов будет достаточно, если все пойдет правильно.

Если вы получили пустую страницу или что-то еще, вы можете включить отчеты об ошибках и записать логи из самого файла конфигурации wp. Вы можете попробовать некоторые из них для отладки.

  1. Просто удалите плагины из папок одну за другой.
  2. Удалите пользовательскую тему, которую вы используете.

Если вы не редактировали основные файлы, в основном это решит проблему. Единственный другой шанс - несоответствие версий для php или mysql, что также очень важно учитывать при переносе. Надеюсь, это кому-нибудь поможет.

Ответ 10

Во многих случаях при переносе файлов на другой сервер эта проблема возникает просто из-за незначительной ошибки в одном из ваших файлов PHP. Ошибка заключается в дополнительных символах после закрывающего тега?> PHP в файле. Это могут быть просто пробелы или возвраты, но они часто могут быть причиной белого экрана смерти.

Основным виновником является файл functions.php в вашей теме WordPress. Посмотрите на это в текстовом редакторе файлов (часто доступном для большинства учетных записей хостинга) и убедитесь, что вы удалили все строки после закрывающего тега.

Если он не находится в этом файле, используйте отчет об ошибках для идентификации файла-виновника, это может быть плагин или другой файл в вашей теме.

Как упоминал Jon Surrell, включите отображение ошибок, измените следующий параметр на true в wp-config.php.

define('WP_DEBUG', true);

Ответ 11

Я добавляю этот ответ в бой, в надежде, что он может помочь кому-то еще. Я следовал всем советам выше, но безрезультатно. Мне действительно пришлось взломать PHP файлы, чтобы заставить моего администратора иметь доступ к панели. Именно через панель я обнаружил, что моей учетной записи администратора не была назначена роль администратора.

Это мой хак в "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 );
}    

Это позволило появиться панели администратора с доступом к https://example.com/wp-admin/users.php, а затем я мог назначить роль. Затем я отключил файл functions.php, чтобы у всех пользователей были правильные права, теперь, когда мне назначен "Администратор".