Во вступительной части этой серии я упоминал, что «инструменты WordPress» не могут быть определены на одном конкретном носителе: инструмент WordPress может быть в форме плагина WordPress, отдельного файла PHP, веб-сайта или даже настольного приложения ,
В этой части серии «Инструментарий разработчика Smart WordPress» мы рассмотрим два разных инструмента в двух разных типах среды: WXR File Splitter (как настольное приложение) и WP Serialized Search & Replace (как Файл PHP).
Разделение больших файлов резервных копий
Если вы независимый веб-дизайнер или работаете в агентстве веб-дизайна и читаете эту статью, скорее всего, вы регулярно устанавливаете WordPress на серверы, так что вы немного (или много ) знаете о миграции WordPress. И если вы один из немногих разработчиков WordPress, у вас может быть клиент с огромным веб-сайтом, который необходимо перенести между двумя серверами.
Несмотря на то, что существуют десятки различных методов и опций для перемещения установок WordPress, в некоторых случаях у нас может быть только самое надежное: резервные копии WordPress Extended RSS (WXR).
Что если ваш клиент предоставит вам учетные данные WP-Admin старого, дрянного общего сервера и ничего больше? Что, если этот новый плагин WordPress не может мигрировать со старого сервера на новый? Когда наступают темные времена, вы должны быть готовы и подготовлены.
Если резервная копия WXR огромна (а я имею в виду гигантские гигабайты), то WXR File Splitter будет тем, кто смоет ваши слезы.
Работа с WXR File Splitter
Сначала плохие новости: этот инструмент, который работает в Windows, старый. Супер старый. И это не работает. Я имею в виду, что он не работает с более новыми версиями WordPress (возможно, последние два года). Я не шучу.
Но, конечно, я не собираюсь писать об инструменте, который совершенно бесполезен. Хорошая новость заключается в том, что заставить работать чрезвычайно легко — настолько просто, что вам просто нужно быстро выполнить поиск и замену в файле резервной копии.
Давайте пройдемся по шагам:
- Загрузите инструмент здесь (до того, как этот сайт также отключится).
- Загрузите файл резервной копии с панели инструментов « Инструменты»> «Экспорт» .
- Откройте файл резервной копии и сделайте все свои теги
<item>заглавными (путем поиска и замены только открывающих тегов — не нужно делать то же самое с тегами</item>) и сохраните файл. - Откройте файл
WXRsplit.exe. - Установите размер выходных файлов (и количество файлов будет рассчитано автоматически ).
- Нажмите на кнопку Split Files .
Ordeal? Что ж, так и должно быть: если ваш клиент передает административную панель веб-сайта, размещенного на серверах, используемых во Второй мировой войне, решение вашей проблемы миграции не должно быть простым. Правильно?
О, и есть версия для Mac OS X, разработанная сторонним разработчиком, но у меня не было возможности попробовать ее (и у меня был нервный срыв из-за этого), потому что у меня нет Mac.
Теперь перейдем к нашему второму инструменту: WP Serialized Search & Replace.
Безопасный поиск и замена операций в вашей базе данных WordPress с WP Serialized Search & Replace
Однажды, в 2012 году, я работал в агентстве веб-дизайна. В первый же день я просмотрел несколько прошлых проектов, чтобы узнать, как мы работали с нашими клиентами. Я увидел, что когда мы нашли клиента, мы начали создавать его веб-сайт в поддомене нашего собственного домена бренда и при необходимости показывали свою работу клиенту; и когда все было установлено (включая получение последнего платежа), мы переместили веб-сайт в домен клиента.
В тот день я сразу предложил изменить этот рабочий процесс с нашими клиентами, потому что это замедлило нашу работу; но начальник отклонил мое предложение из-за «финансовых причин». Он объяснил, что в прошлом некоторые клиенты пытались украсть нашу работу прямо перед последним платежом, и именно поэтому мы работали так. «Чепуха», — подумал я, но в конце концов он был боссом.
Моей первой работой был высокоприоритетный клиент, которому нужен сайт как можно быстрее. (К счастью, контент был отправлен заранее.) Я быстро установил WordPress на поддомен нашего сайта и активировал тему (выбранную клиентом) вместе с некоторыми плагинами. Я настроил все настройки ядра, темы и плагинов, а затем начал работать с контентом.
Когда я закончил (и поразил босса быстрой раскраской всего сайта менее чем за четыре часа), мы показали его клиенту и сразу же получили одобрение и сообщение о том, что сайт должен быть запущен завтра, так как они собирались посетить выставку.
С уверенностью я решил сделать немного сверхурочных и перенести сайт в тот день. Я загрузил все файлы с FTP и вместо быстрого резервного копирования WXR я сделал резервную копию SQL в phpMyAdmin. После изменения URL-адресов веб-сайтов в таблице wp_options я загрузил файлы и отправил SQL-запрос в базу данных веб-сайта клиента. О, и я быстро удалил все в поддомене разработки.
Когда я заметил, что избранные изображения были повреждены, я просмотрел файл SQL и увидел, что у них все еще есть URL-адреса с субдомена нашего собственного сайта. Я сделал быстрый поиск и замену, сохранил изменения в резервной копии и переписал базу данных новым SQL. Когда я посетил веб-сайт, я увидел не только то, что изображения все еще были повреждены, но также и то, что все сообщения исчезли, хотя они все еще были в базе данных.
Это день, когда я узнал о «сериализованных записях». (Я также вернулся домой в полночь, потому что всю оставшуюся часть дня я работал над созданием того же веб-сайта на сервере клиента.) Из этого опыта я узнал, что сериализованные записи хранятся с количеством символов, и если число символов не не согласуется со строкой, WordPress пропускает запись вообще.
Итак, как нам выполнить поиск и замену в WordPress, включая сериализованные записи? С WP Serialized Search & Replace, конечно.
Использование WP Serialized Search & Replace
WP Serialized Search & Replace больше похож на портативный инструмент: вы просто загружаете папку (в каталог установки WordPress) и запускаете файл index.php . Итак, если ваши файлы WordPress находятся в mywebsite.com/wp/ , вам следует запустить инструмент с mywebsite.com/wp/srtool/index.php (имя папки инструмента не имеет значения, поэтому вы можете изменить папку имя, если хотите).
После запуска инструмента вы увидите пять разделов:
- Поиск / замена. Имеет два поля ввода для полей «поиск» и «замена», а также флажок для включения регулярных выражений.
- База данных: имеет четыре поля ввода для ваших учетных данных базы данных. Инструмент автоматически заполняет эти поля, проверяя файл
wp-config.php. - Таблицы: по умолчанию инструмент будет работать во всех таблицах базы данных, но при желании вы можете выбрать отдельные таблицы, щелкнув переключатель «Выбрать таблицы», или заполнив два поля ввода, чтобы исключить или включить таблицы.
- Действия: в этом разделе есть пять действий: «Сведения об обновлении» повторно подключаются к базе данных, если вы изменяете учетные данные базы данных, «Пробный запуск» имитирует процесс поиска и замены, «Живой запуск» фактически запускает процесс поиска и замены, «Преобразовать в InnoDB «преобразует ядро базы данных в InnoDB, а» Convert to UTF8 Unicode «преобразует наборы символов таблиц базы данных в Unicode.
- Удалить: удаляет инструмент, всю папку.
Должен сказать, мне очень понравился дизайн, но я считаю, что этот инструмент будет работать лучше в качестве плагина WordPress.
Подведение итогов на сегодня
Мы немного увеличили темп только для этой части и рассмотрели два небольших инструмента WordPress в одном посте. Я полагаю, что оба они заслуживают похвалы, несмотря на то, что они немного не замечают сообщество WordPress.
Что вы думаете об этих инструментах? Знаете ли вы лучшие альтернативы? Поделитесь своими мыслями и опытом с нами в разделе комментариев ниже. И если вам понравилась статья, не забудьте поделиться ею с друзьями!
До встречи в следующей части, где мы поговорим о плагине WordPress GitHub Plugin Updater, отличном инструменте для управления процессом обновления плагинов WordPress, размещенных на GitHub.