Ответ 1

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

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

OP на самом деле не запрашивает альтернативы функции импорта/экспорта wordpress, но поскольку это миграция прошла кислый (плюс тот факт, что функция импорта/экспорта wordpress оставляет много желанием), Я постараюсь ответить на вопрос Аланса относительно альтернативных способов миграции wordpress между серверами/местоположениями/доменами.

В опасности заявить очевидное: Этот ответ будет длинным!

Отладка ошибок Wordpress вообще

Шаг 1. Убедитесь, что вы видите, что не так.

Включить режим отладки и убедиться, что display_errors включен, и определен соответствующий уровень error_reporting. Это важно для любого развития Wordpress.

Откройте wp-config.php и найдите эту строку:

define('WP_DEBUG', false);

Замените его:

//Switch on wordpress' built-in debug mode
define('WP_DEBUG', true);
/**
 * Just a convenient check so you can leave the next few lines unchanged
 * for next time you need debugging, and just switch true/false above.
 */
if (WP_DEBUG) {
    //Handle all errors regardless of error level
    ini_set('error_reporting', -1);
    //Display errors directly in the browser
    ini_set('display_errors', 'On');
}

... если по какой-то причине строка уже не существует, просто вставьте ее где-нибудь выше строки, говорящей.

/* That all, stop editing! Happy blogging. */

Это позволит вам увидеть дополнительную информацию о большинстве ошибок (php-).

Примечания:

• В большинстве случаев просто установка WP_DEBUG в true будет автоматически включать display_errors - однако я нашел выше, чтобы рассмотреть некоторые случаи кросс, где ошибки, которые не показаны, несмотря на WP_DEBUG, были true.
• На живом (производственном) сайте может быть очень нежелательно отображать ошибки для каждого посетителя, поэтому вы можете:
  • включить WP_DEBUG условно, например, по IP: define('WP_DEBUG', $_SERVER['REMOTE_ADDR'] === '123.123.123.123'); (очевидно, заменяя ваш фактический IP-адрес)
  • ошибки журналов вместо их отображения - см. wordpress codex для получения дополнительной информации: Отладка в WordPress
• Если у вас установлены низкокачественные или устаревшие плагины или темы, вы, скорее всего, увидите много результатов от плохо написанных функций внутри них.

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

Шаг 2. Воспроизводите ошибку

Что бы вы ни делали, чтобы проблема возникла - сделайте это снова. Это должно дать вам кое-что для работы, например, просто вставив его в Google и посмотрев, что получится. Скорее всего, вы не первый, кто испытал все проблемы, которые у вас есть.

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

Вы также можете попытаться вставить какой-то намеренно сломанный код в wp-config.php, чтобы убедиться, что на самом деле будут напечатаны ошибки. Например, введите this_function_surely_does_not_exist(); сразу после директив ini_set().

Некоторые узлы ограничивают использование ini_set(), поэтому если все еще не работает, но вы не видите никаких ошибок, попробуйте выяснить, как вы можете установить соответствующие настройки php.ini - это может быть на вашем хостинге (cPanel, Plesk и т.д.), у вас может быть прямой доступ к вашему php.ini через FTP... или они не могут предложить никакой возможности его установить (сразу найдите другого провайдера!)

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

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

Найти фактические пределы и настройки

Не верьте, что только потому, что у вас есть файл с именем php.ini, который содержит строку с текстом memory_limit = 128M, ваш предел памяти на самом деле равен 128M. Это можно установить множеством разных способов, что единственный надежный способ узнать, это спросить php, каков его текущий предел памяти. Это справедливо для большинства php.ini -settings!

Чтобы получить представление о том, как выглядит ваша рабочая среда, создайте файл (желательно в корневой папке установки Wordpress) под названием phpinfo.php со следующим содержимым:

<?php
//Your memory limit
echo 'memory_limit: ' . ini_get('memory_limit') . '<br>';
//Your maximum size of post-data (including file uploads)
echo 'post_max_size: ' . ini_get('post_max_size') . '<br>';
//The maximum file size for uploads
echo 'upload_max_filesize: ' . ini_get('upload_max_filesize') . '<br>';
//Maximum runtime for PHP скриптs (in seconds)
echo 'max_execution_time: ' . ini_get('max_execution_time') . '<br>';
//Current error reporting level
echo 'error_reporting: ' . ini_get('error_reporting') . '<br>';
//Are errors displayed?
echo 'display_errors: ' . ini_get('display_errors') . '<br>';
//Will errors be logged?
echo 'log_errors: ' . ini_get('log_errors') . '<br>';
//Where will errors be logged?
echo 'error_log: ' . ini_get('error_log') . '<br>';
//What is the absolute path of this files parent folder
// = the complete path to your wordpress "root folder"
echo 'root of wordpress: ' . __DIR__ . '<br>';

/**
 * If you are curious to see *a lot* of information about your environment
 * then uncomment this line too:
 */
//phpinfo();

/**
 * This should print whatever is in the error log, but it could potentially
 * be huge, so use with caution!
 */
//echo '<pre>' . file_get_contents(ini_get('error_log')) . '</pre><br>';

Вы должны знать, что все приведенные выше значения могут быть изменены во время выполнения script - и некоторые (плохое качество) плагины действительно будут. Я видел, что плагины пытаются увеличить memory_limit, например, - все это прекрасно и денди, за исключением 6-7 лет, и плагин, "увеличивающий" предел памяти до 32 МБ, фактически испортил установку, потому что в настоящее время 64 МБ необходимы для довольно простая установка wordpress, а 128 МБ - более разумный минимум для большинства. Проблема заключается в том, что единственный способ реально знать значения, которые обязательно должны выполняться в любой заданной точке выполнения, - это вставить вышеприведенное право в этой точке.

Некоторая распространенная причина ошибок, которые случаются "по случаю", особенно в связи с импортом или загрузкой файлов, заключается в том, что либо memory_limit, post_max_size, либо upload_max_filesize установлены слишком низко - вы можете попытаться увеличить их, используя ini_set() вызывает wp-config.php:

ini_set('memory_limit', '256M');
ini_set('post_max_size', '128M');
ini_set('upload_max_filesize', '64M');

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

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

Если вы все еще застряли на квадрате, задайте вопрос о переполнении стека и будьте очень многословным о том, что вы сделали до того, как все отправилось на юг;)

Клонирование/миграция/перемещение или резервное копирование сайта wordpress

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

Однако, если я, как и я, вы предпочитаете делать это вручную, чтобы понять (и контролировать) процесс, вот метод, который я использую для перемещения, переименования, клонирования или резервного копирования установок Wordpress в обычном режиме - он должен работать практически для любых автономных (т.е. если вы пытаетесь переместить многопользовательский режим, вам, вероятно, следует искать другой путеводитель).

Эти инструкции должны работать, если вы

• переход с одного сервера на другой - например, разработка в производство
• переход из одного домена в другой
• переход из подпапки в корень домена (или другой способ)
• взяв резервную копию (просто остановитесь на полпути через процесс и продолжайте, где вы остановились, если вам когда-либо понадобится создать резервную копию)

Основные шаги:

• Получить копию всех файлов
• Получить копию всей базы данных
• Необходимые исправления в файлах
• Загрузка файлов на новый сервер (или же при восстановлении резервной копии)
• Загрузите базу данных на новый сервер
• Необходимые исправления в базе данных

Для этого требуется, чтобы у вас был доступ к:

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

Все достойные планы хостинга, и почти все недорогие планы общего хостинга поставляются с phpMyAdmin и доступом к FTP. VPS, частные серверы и т.д., Очевидно, имеет прямой доступ к файлам и базе данных, который будет еще лучше (или, по крайней мере, быстрее).

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

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

Шаг 1. Получите копию всех файлов

Вы хотите получить все файлы в "корне" вашей установки Wordpress. Это папка, содержащая wp-content, wp-admin и wp-includes плюс около 15-20 файлов. Убедитесь, что вы также скрываете файлы (например, файл .htaccess, скорее всего, будет скрыт по умолчанию, если вы используете FTP - в некоторых случаях этот файл абсолютно не имеет значения, но в других это может быть необходимо, поэтому просто убедитесь, что вы все )

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

Если у вас есть VPS или какое-либо решение с SSH или какой-либо другой формой доступа к консоли, используйте это и перейдите к "корню" вашей установки, а затем запустите все, что бы это сделать - что-то вроде zip -r my_wp_backup.zip .. Загрузите файл, используя то, что у вас есть.

Если у вас есть только FTP-доступ к вашим файлам, это может занять некоторое время, но вы просто входите в систему с FTP (мой любимый FTP-клиент FileZilla, потому что он прост в использовании и позволяет несколько одновременных передач... но любой клиент должен быть в порядке). Перейдите к "root" wordpress и перенесите все файлы в локальную папку на вашем компьютере (не забудьте показать скрытые файлы!)

Шаг 2. Получите копию всей базы данных

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

Просто войдите в phpMyAdmin, выберите свою базу данных, нажмите "Экспорт" и примите значения по умолчанию (параметры сильно различаются в зависимости от версии, но значения по умолчанию должны быть хорошими для любой "нормальной" базы данных Wordpress). Это должно дать вам либо загрузку файла с именем, заканчивающимся на ".sql", либо большим текстовым полем с огромным количеством текста в нем. Если вы получите последнее, просто скопируйте его в обычный текстовый файл на вашем локальном компьютере - блокнот, блокнот ++ или любой другой текстовый редактор будет работать (т.е. Не используйте слово, документы google или любой другой богатый текстовый редактор!)

Если у вас нет доступа к phpMyAdmin, вы можете либо установить его (который я не буду описывать), либо вы должны найти другой способ экспорта базы данных, например:

• Если у вас есть доступ к консоли, эта команда должна дать вам полезный дамп: mysqldump -u your_database_username -p your_db_name > my_backup.sql - если вы не знаете имя своей базы данных, загляните в wp-config.php(также содержит ваше имя пользователя и пароль, если вы этого не знаете)
• Если у вас нет доступа к консоли, попробуйте изучить панель управления вашего провайдера - наверняка у вас есть способ сделать дамп базы данных.

Шаг 3. Сделайте необходимые исправления в файлах

Теперь вы должны иметь полную резервную копию на своем локальном диске.

• Если вы просто делаете резервную копию, вы закончили - файлы и база данных готовы для загрузки в одно и то же место, и все будет восстановлено в текущем состоянии.
• Если вы переходите на другой сервер или другое место на том же сервере, узнайте:
  • каков ваш новый путь (загрузите файл phpinfo.php выше, если ваш провайдер не дает вам никаких подсказок)
  • что ваше новое имя и пароль для базы данных
  • если вам требуется специальное имя хоста для подключения к базе данных (в большинстве случаев достаточно localhost, но некоторые провайдеры имеют выделенные mysql-серверы, которые требуют подключения к другому имени хоста)

Исправьте файл wp-config.php - соответствующие строки:

/** The name of the database for WordPress */
define('DB_NAME', 'your_database_name');

/** MySQL database username */
define('DB_USER', 'your_database_username');

/** MySQL database password */
define('DB_PASSWORD', 'your_database_password');

/** MySQL hostname */
define('DB_HOST', 'localhost');

Хотя довольно редко некоторые плагины записывают информацию в файлы, которые необходимо обновить, поэтому, если абсолютный путь вашей корневой папки wordpress или абсолютный URL-адрес вашей установки изменяется в процессе миграции, вы также должны сделать полный поиск и замена для них:

• Если старый абсолютный путь к вашей установке был /var/www/www.example.com/web/blog, а ваш новый абсолютный путь /var/www/blog.example.com/public_html, то поиск и замена этих файлов во всех файлах. Не включайте конечную косую черту!
• Если старый URL был http://www.example.com/blog, а новый URL-адрес будет http://blog.example.com, выполните поиск www.example.com/blog с заменой blog.example.com. Не включайте http:// и не включайте конечную косую черту!

Обратите внимание, что если по какой-то причине вы находитесь в ситуации, когда вы не знаете свой старый абсолютный путь и/или URL-адрес, вы можете найти их в базе данных, так что сначала сделайте шаг 5 и посмотрите в таблице prefix_options для значения siteurl (ваш абсолютный URL) и upload_path обычно содержат ваш абсолютный путь (плюс /wp-content/uploads) - если это не так, то в таблице, вероятно, будут другие строки в таблице, которые могут рассказать вам, найдите что-то, начинающееся с /var/www или /home/something.

Шаг 4. Загрузка файлов на новый сервер или новое место

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

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

Шаг 5. Загрузите базу данных на новый сервер

Опять же, варианты меняются:

• Если phpMyAdmin доступен, просто войдите в систему, выберите свою базу данных, нажмите "Импорт" и загрузите файл с шага 2. Иногда я даже выбираю вкладку SQL и просто вставляю весь контент прямо в большое текстовое поле.
• Если у вас есть доступ к консоли, вы можете загрузить файл и запустить mysql -u your_database_username -p your_new_db_name < my_backup.sql

Шаг 6. Сделайте необходимые исправления в базе данных

Если вы восстанавливаете резервную копию на тот же сервер и местоположение, вы сделали.

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

Вам также необходимо знать, что множество плагинов, а также некоторые функции wordpress используют функцию php serialize для легкого хранения сложных данных в базе данных. Этот формат очень чувствителен к изменениям, поэтому "регулярный" поиск и замена очень (very!), вероятно, сломают все.

К счастью, есть бесплатный инструмент, специально разработанный с учетом этого. У меня нет привязки, но я не могу рекомендовать межсоединение/поиск базы данных и замена. Он ухожен, очень удобен для пользователя, и я никогда лично не испытывал, что он все испортил.

Загрузите его, используя ссылку выше, разархивируйте ее, переименуйте в папку something_random_for_security и загрузите ее в корневую папку wordpress. Затем перейдите в http://blog.example.com/something_random_for_security в своем браузере (очевидно, заменяя соответствующие части URL-адреса).

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

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

Как и файлы, вам необходимо найти:

• ваш старый абсолютный путь и замените его новым абсолютным путем (исключая конечную косую черту)
• ваш старый абсолютный URL-адрес и замените его новым абсолютным URL-адресом (за исключением протокола http:// и конечной косой черты)

Сначала вы можете использовать кнопку "Сухой запуск", чтобы увидеть, что будет изменено, и если могут возникнуть какие-либо очевидные проблемы - после этого просто нажмите кнопку "Живой запуск", и она пережевывает всю вашу базу данных, заменяя ее serialize() - безопасный способ, если это необходимо.

Шаг 6,5 Разбитые постоянные ссылки

Если вы переместили свой сайт из одной папки в другую папку (или вверх или вниз по уровню), то permalinks/ "pretty URLs" могут не работать (т.е. ваша первая страница в порядке, но все остальное - одна большая ошибка), Это из-за правил в том, что "скрытый" .htaccess файл "запутан". Исправление очень просто - просто зайдите в "Настройки" → "Перманентные ссылки" в текстовом редакторе Wordpress... вам не нужно вносить какие-либо изменения, файл автоматически обновляется, как только вы посещаете страницу.

Готово

Убедитесь, что все работает, затем отправляйтесь праздновать...

Ответ 2

Ваши директивы находятся в неправильном формате. Попробуйте

upload_max_filesize = 64M
post_max_size = 90M
memory_limit = 128M
max_execution_time = 120

Если это не работает, спросите своего веб-хостинга; вы не сможете вносить изменения в php.ini.

И попробуйте запустить debug https://codex.wordpress.org/Debugging_in_WordPress, чтобы уловить ошибки PHP, которые могут указывать путь к проблеме и решению.

Ответ 3

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

И также ссылайтесь на здесь

Ответ 4

попробуйте это, сделав необходимые изменения для загрузки файла в php или wordpress i.e

post_max_size = 90M
max_execution_time = 120
upload_max_filesize = 64M
memory_limit = 128M

другие шаги,

1)Increase the PHP memory limit via .htaccess (e.g. php_value memory_limit 64M)..
2)Increase the PHP memory limit via wp-config.php (e.g. efine(‘WP_MEMORY_LIMIT’, ’64MB’);)

наконец, проверьте,

https://codex.wordpress.org/Importing_Content

Ответ 5

Эти шаги могут помочь:

• После отображения пустой страницы страница продолжает работать в фоновом режиме (это можно увидеть в полете, обновив таблицу wp_posts или wp-admin).
• Внутри wp-includes/deprecated.php есть функция с именем wp_get_http() с @set_time_limit( 60 );, измените ее на 0, чтобы отключить ограничение.