Этот файл не имеет структуры wxr отсутствует неверный номер версии wxr
Если вы часто переезжаете с сервера на сервер или меняете хостинг провайдера, то наверняка вы уже выработали свою схему переноса файлов сайта. Но что делать новичкам сайтостроя, для которых слово «бекап» также ново, как «хостинг» или «домен»? Разработчики платформы WordPress потрудились на славу, выпустив для CMS специальный плагин WordPress Importer, который, по сути, представляет собой штатную систему для создания бекапа как всего сайта в целом, так и его отдельных частей. При этом не нужно обладать какими-либо особыми познаниями в Вордпресс или программировании, чтобы научиться работать с данным плагином.
Конечно, никто не отменял общепринятых способов переезда сайтов от одного хостера к другому. Вы по-прежнему можете сделать дамп базы в PHPmyAdmin, скачать его по FTP, и затем «залить» на новый сервер. Если блог «молодой», то ручной переезд займет не более часа. Но когда речь идет о сайте на WP с большим объемом файлов, то бекап данных может затянуться, а в некоторых случаях из-за криво залитой базы и вовсе обернуться неработоспособностью проекта. Именно для этих случаев существует плагин WordPress Importer, который позволяет без лишних проблем легко переносить данные с одного сервера на другой, а также создавать сайты-клоны из одной сохраненной базы.
Кроме того, если вы когда-нибудь использовали купленные темы, то в них, как правило, загрузка демо-данных и настроек делается также с помощью этого расширения.
Установка плагина
Работать с WordPress Importer очень просто. Для начала вам потребуется инсталлировать плагин в CMS. Для этого авторизуйтесь в консоли управления блогом, перейдите во вкладку «Плагины» и кликните вверху по кнопке «Добавить новый». Затем на новой странице в поисковом окошке введите «Wordpress Importer» и нажмите ENTER.
По окончании поиска плагина нажмите «Установить». Плагин распространяется разработчиками самого движка, в связи с чем его автором будет wordpressdotorg. Обратите внимание, что данный плагин является одним из популярнейших расширений для WP (более миллиона установок).
После установки расширения активируйте его. Впрочем, сделать установку можно и другим способом. Достаточно перейти в раздел «Инструменты», затем в «Импорт» и нажать на ссылку «Wordpress». Если WP Importer не установлен, CMS сообщит вам об этом и потребует его инсталляции.
Экспорт и импорт данных
Чтобы импортировать готовый WXR-файл, достаточно открыть раздел «Импорт» в CMS, перейти по ссылке «Wordpress» и указать на расположение файла. После загрузки данных WP предложит вам создать нового автора или присвоить импортируемые статьи одному из текущих авторов. Укажите желаемый вариант и завершите процедуру импорта данных.
Возможные проблемы
При переносе данных нужно учесть, что у Вордпресс есть ограничение на объем загружаемого файла (обычно это 2 МБ) и если он будет больше этого размера, то не загрузится. К счастью есть способы, как увеличить размер загружаемых файлов.
И помните главное правило: делать бекапы сайта нужно всегда, вне зависимости существуют ли проблемы с переносом данных или нет!
Доброе время суток. Приветствую всех читателей этого форума.
В своей статье я поведаю о том, как можно с помощью ZennoPoster облегчить загрузку большого количества статей на сайт на движке Wordpress.
Для этого в Wordpress есть плагин под названием wordpress-importer. Он работает с Wordpress версия движка до 4.6.6. Если у Вас установлен WP большей версии- этот плагин можно не устанавливать, а пользоваться функциями импорта по пути Инструменты-импорт- WordPress Запустить импорт
Этот плагин позволяет импортировать в Wordpress записи, страницы, комментарии, произвольные поля,рубрики и метки посредством специального файла формата eXtended RSS который также называется WXR файл.
Для начала рассмотрим структуру этого файла.
Информация помещенная между тэгами <title>..</title> говорит сама за себя.Там размещается Заголовок записи.Между тэгами <dc:creator>. </dc:creator>
пишем имя(пвсевдоним) автора записи. Между тэгами <content:encoded><![CDATA[. ]]></content:encoded> размещаем текст записи.
Между тэгами <wp:post_id>. </wp:post_id> стоит номер записи.Между тэгами <wp:comment_status>. </wp:comment_status> ставим разрешение или запрет
на комментирование записи.Между тэгами <wp:status>. </wp:status> ставим статус записи (публиковать сразу или размещать как черновик).
Эти теги <category domain="category" nicename="Название категории"><![CDATA[Название категории]]></category> показывают в какой категории надо разместить нашу запись.
Ниже рассмотрим шаблон для формирования WXR файла. Исходным материалом будут файлы с заголовком записи, адреса картинки и текста записи. Их я заготовил в качестве
образца заранее, чтобы показать как работает наш шаблон.
В шаблоне задействованы кубики для работы с файлами (взять текст и положить в переменную), записать текст и указать название записываемого файла.
Здесь содержимое первого кубика записать файл:
Здесь содержимое второго кубика записать файл:
После выполнения шаблона в каталоге с проектом будет лежать файл import to wordpress.xml, который надо скормить нашему плагину в Wordpress.
Ниже на скриншотах можно посмотреть что у нас получилось.
Это записи со статусом черновик в админке блога.
Вот так выглядит публикуемая запись.
Upd. По образцу и подобию можно настроить отложенный постинг в Wordpress.
<wp:post_date>2017-05-26 04:52:56</wp:post_date>
<wp:post_date_gmt>2017-05-26 04:52:56</wp:post_date_gmt>
<wp:status>future</wp:status>
Вложения
Для запуска проектов требуется программа ZennoPoster или ZennoDroid.
Это основное приложение, предназначенное для выполнения автоматизированных шаблонов действий (ботов).
Подробнее.
Основная проблема, которая существует в WordPress – отсутствие переносимости (portability).
Функция экспорта/импорта в WordPress
WordPress поставляется вместе с возможностью экспорта контента в XML-формате (используя специфичный для WordPress формат WXR). Эта возможность неплохо подходит для создания быстрого бэкапа, однако в конечном счете она убивает то, что многие издатели ждут от «переносимого» приложения.
Файл WXR содержит слишком мало информации для восстановления сайта с нуля. Среди пропавших элементов можно назвать:
- Пользовательская мета-информация (включая хэшированные пароли) – все пользователи должны быть заново созданы на целевом сайте.
- Прикрепления – медиа-файлы могут быть скачаны и импортированы на новый сайт только в том случае, если исходный сайт по-прежнему функционирует онлайн, и к медиа-файлам есть доступ.
- Параметры сайта – теглайн, настройки обратных ссылок и уведомлений, настройки временной зоны и т.д.
Несмотря на нехватку некоторой важной информации, WXR-файлы зачастую имеют очень большой размер, если сайт существует длительное время и имеет много контента. К сожалению, зачастую это означает, что файл экспорта превышает допустимые размеры, чтобы быть безопасно импортированным в новое место.
Разработчики даже создали разделители WXR-файлов, чтобы ускорить процесс импорта/экспорта. Все эти инструменты являются хорошими, однако они явно показывают, что у нас есть одна проблема.
Дампы базы данных
Все чаще и чаще я сталкиваюсь с ситуациями, когда я вынужден переходить к низкоуровневым инструментам работы с базами данных, чтобы реализовать масштабную миграцию.
Я использую mysqldump для экспорта базы данных, копирую ее на целевой сервер, затем использую инструменты командной строки MySQL для повторного импорта той же самой базы данных. После этого с помощью WP-CLI я провожу замену всех поврежденных строк (т.е. измененные домены) в базе данных, что обычно выполняется вручную.
Данный процесс проходит гораздо быстрее, нежели разбиение файла WXR, поочередное импортирование его «кусков», а также ручное обновление параметров и других недостающих данных. Однако этот метод по-прежнему не является эффективным.
Некоторые сайты обладают относительно небольшими базами данных – дампы данных умещаются примерно в пару мегабайтов. На других сайтах стоят достаточно мощные системы – и дампы данных представляют собой файлы размерами по 1.5 Гб и выше. Одно дело – хранить такие объемы информации в базе данных; другое дело – переносить их.
Как это должно быть в идеале
Мне нравится, что MySQL заметно ускоряет поиск данных, помогая оптимизировать работу с отдельными объектами в базе данных. Мне не нравится то, что MySQL заметно усложняет перенос контента с одного сервера на другой.
В идеале WordPress должна быть отделенной от своего хранилища данных – позволяя, к примеру, заменить MySQL на YAML-документы для хранения данных. Возможность работы с различными системами передачи и обработки данных позволила бы администраторам сайта переводить свой контент из одного формата в другой и обратно без каких-либо потерь.
Формат WXR передает данные с потерями – он опускает некоторую важную информацию. Дампы MySQL идут без потерь, однако у них отсутствует гибкость – вы можете переносить MySQL только на MySQL, и только в том случае, если у вас есть прямой доступ к базе данных (если вы когда-либо пробовали вставить объемный дамп базы данных в phpMyAdmin, то вы понимаете, о чем я говорю).
Я хотел бы, чтобы у меня была возможность с помощью одного щелчка представить мой сайт в виде набора нескольких человеко-читаемых flat-файлов. Я хотел бы использовать те же самые flat-файлы для того, чтобы динамически воссоздавать весь сайт на другом сервере без потери данных.
Если когда-либо WordPress сможет достигнуть такого состояния, то продукт (а также контент, управляемый им) станет действительно переносимым.
Читайте также: