При переносе WordPress сайта с локального компьютера на сервер (или наоборот) сайт перестает работать. Аналогичная проблема возникает и при смене домена, по которому сайт доступен.
Признаки неработоспособности бывают самые разные - не отображаются некоторые страницы, не отображаются картинки в библиотеке медиафайлов, не грузятся стили, не работают слайдеры, и т.д., и т.п.
В чем причина такого поведения и как правильно перенести WordPress сайт или сменить его домен?
Ответ
Начнем с причин. Глобально, их три.
В первую очередь так происходит потому, что все ссылки в базе WordPress хранятся как абсолютные. Например, ссылка на иконку сайта выглядит примерно так:
http://mysite.com/wp-content/uploads/2017/01/cropped-test-favicon.png
Для правильной работы сайта на новом домене (например, https://newsite.org) ссылка в базе должна измениться на
https://newsite.org/wp-content/uploads/2017/01/cropped-test-favicon.png
Обратите внимание на то, что даже при простом переводе сайта с http на https, все ссылки внутри базы надо менять!
За использованием абсолютных ссылок в WordPress лежат серьезные доводы. Почитайте этот ответ на английском StackOverflow, в котором даны объяснения. В том числе, приведено мнение одного из ведущих разработчиков WordPress. Единственная проблема, которая возникает при использовании абсолютных ссылок - перенос сайтов. Однако перенос сайта с относительными ссылками в общем случае ещё более проблематичен. В упомянутом ответе это тоже обсуждается.
Вторая причина проблем при переносе - сериализованные данные в базе. Все современные плагины (включая WooCommerce, слайдеры, различные визуальные редакторы типа Visual Composer), темы - хранят данные в базе в сериализованном виде. Это упакованные в строки массивы и объекты. Несколько примеров:
Информация о последнем отредактированном файле из темы twentyseventeen:
(39, 'recently_edited', 'a:3:{i:0;s:46:\"/var/www/test/wp-content/themes/test/style.css\";i:2;s:50:\"/var/www/test/wp-content/themes/test/functions.php\";i:3;s:0:\"\";}', 'no'),
Данные Jetpack
(5104, 'jpsq_sync-1494597052.351881-573008-5', 'a:6:{i:0;s:21:\"jetpack_sync_constant\";i:1;a:2:{i:0;s:7:\"ABSPATH\";i:1;s:14:\"/var/www/test/\";}i:2;i:1;i:3;d:1494597052.351856;i:4;b:0;i:5;a:9:{s:12:\"display_name\";s:4:\"kagg\";s:10:\"user_email\";s:12:\"info@kagg.eu\";s:2:\"ip\";s:14:\"87.110.237.209\";s:7:\"is_cron\";b:0;s:11:\"is_wp_admin\";b:1;s:7:\"is_rest\";b:0;s:9:\"is_xmlrpc\";b:0;s:10:\"is_wp_rest\";b:0;s:7:\"is_ajax\";b:0;}}', 'no'),
Данные популярного плагина бэкапа сайтов BackWPUp
(5884, 'backwpup_jobs', 'a:1:{i:1;a:32:{s:5:\"jobid\";i:1;s:10:\"backuptype\";s:7:\"archive\";s:4:\"type\";a:3:{i:0;s:6:\"DBDUMP\";i:1;s:4:\"FILE\";i:2;s:8:\"WPPLUGIN\";}s:12:\"destinations\";a:1:{i:0;s:6:\"FOLDER\";}s:4:\"name\";s:15:\"Database backup\";s:14:\"mailaddresslog\";s:12:\"info@kagg.eu\";s:20:\"mailaddresssenderlog\";s:28:\"BackWPup test
во всех примерах можно найти путь к папке сайта на сервере: /var/www/test/
Вот пример сохраненных настроек из очень популярного SEO-плагина Yoast
(291, 2, 'wp_yoast_notifications', 'a:3:{i:0;a:2:{s:7:\"message\";s:309:\"The configuration wizard helps you to easily configure your site to have the optimal SEO settings.
We have detected that you have not finished this wizard yet, so we recommend you to start the configuration wizard to configure Yoast SEO.\";s:7:\"options\";a:8:{s:4:\"type\";s:7:\"warning\";s:2:\"id\";s:31:\"wpseo-dismiss-onboarding-notice\";s:5:\"nonce\";N;s:8:\"priority\";d:0.80000000000000004;s:9:\"data_json\";a:0:{}s:13:\"dismissal_key\";N;s:12:\"capabilities\";s:14:\"manage_options\";s:16:\"capability_check\";s:3:\"all\";}}i:1;a:2:{s:7:\"message\";s:768:\"We\'ve noticed you\'ve been using Yoast SEO for some time now; we hope you love it! We\'d be thrilled if you could give us a 5 stars rating on WordPress.org!
If you are experiencing issues, please file a bug report and we\'ll do our best to help you out.
By the way, did you know we also have a Premium plugin? It offers advanced features, like a redirect manager and support for multiple keywords. It also comes with 24/7 personal support.
Please don\'t show me this notification anymore\";s:7:\"options\";a:8:{s:4:\"type\";s:7:\"warning\";s:2:\"id\";s:19:\"wpseo-upsell-notice\";s:5:\"nonce\";N;s:8:\"priority\";d:0.80000000000000004;s:9:\"data_json\";a:0:{}s:13:\"dismissal_key\";N;s:12:\"capabilities\";s:14:\"manage_options\";s:16:\"capability_check\";s:3:\"all\";}}i:2;a:2:{s:7:\"message\";s:162:\"Don\'t miss your crawl errors: connect with Google Search Console here.\";s:7:\"options\";a:8:{s:4:\"type\";s:7:\"warning\";s:2:\"id\";s:17:\"wpseo-dismiss-gsc\";s:5:\"nonce\";N;s:8:\"priority\";d:0.5;s:9:\"data_json\";a:0:{}s:13:\"dismissal_key\";N;s:12:\"capabilities\";s:14:\"manage_options\";s:16:\"capability_check\";s:3:\"all\";}}}'),
Здесь мы видим в сериализованных данных строку с упоминанием домена: href=\"http://test.kagg.eu/wp-admin/?page=wpseo_configurator\". Она мало того, что сериализована, да ещё и экранирована (\").
Третья причина - наличие в базе путей к файлам. Они могут быть не только от корня WordPress, но и от домашнего каталога пользователя хостинг-аккаунта или даже от корня веб-сервера (некоторые плагины так делают). Пути могут быть представлены как обычными строками, так и сериализованными данными (первый пример выше). При переносе на другой хостинг их тоже надо менять.
Что произойдет, если просто перекинуть базу как есть на новый сервер? Очевидно, перестанут работать вещи, связанные с путями к файлам и ссылками, содержащими предыдущий домен.
Что надо делать? Очевидно, менять пути к файлам на новые и имя домена в базе. Вопрос, как. Совершенно непригодны два плохих совета, которые часто можно встретить:
Заменить в базе в таблице wp_options записи c option_name = siteurl и home на новое имя домена. Работает только на самых примитивных сайтах.
Сделать дамп базы в файл .sql, и провести текстовые замены путей и домена, затем залить базу на новый сервер. Это прямой путь к разрушению сайта. Сериализованные данные при этом будут безнадежно испорчены.
Рассмотрим первый пример выше с сериализованными данными. После текстовой замены /var/www/test/ на, скажем, /home/i/account-name/site-name.org/public_html (как на одном популярном хостинге), из строки
s:46:\"/var/www/test/wp-content/themes/test/style.css\"
получится строка
s:46:\"/home/i/account-name/site-name.org/public_html/wp-content/themes/test/style.css\"
Только ее длина уже ни разу не 46 символов, и WordPress не сможет прочитать эти сериализованные данные из базы.
Таким образом, оба "популярных" совета надо признать вредными.
Как правильно переносить сайт?
Надо использовать программные средства, специально предназначенные для этого. Упомянутые ниже программы корректно работают с сериализованными данными, пересчитывая длину строк.
Скрипт Database Search and Replace поможет корректно внести изменения в базу. Для этого пользователь должен, правда, понимать, что он делает, знать, например, какие пути на старом сайте и какие - на новом.
Плагин WP Migrate DB позволяет корректно подготовить базу для миграции. Для завершения процесса пользователь должен использовать phpMyAdmin для импорта базы на новом сервере.
Самым простым и автоматизированным решением лично мне представляется плагин Duplicator, который снимает копию локального сайта, предоставляет для скачивания 2 файла: .zip и installer.php, которые надо перенести на новый сервер и там запустить installer.php. Все остальное плагин проделает автоматически. В большинстве случаев имеет смысл переносить только базу с помощью этого плагина, а файлы копировать по FTP.
С мультисайтом ситуация несколько сложнее. Плагины Duplicator и All-in-One WP Migration переносят их только в платной версии.
Мне неизвестны бесплатные плагины для переноса мультисайтов. Если хочется сделать перенос мультисайта бесплатно, то можно скопировать базу, а потом воспользоваться Database Search and Replace.
Комментариев нет:
Отправить комментарий