Что такое хороший способ настроить рабочий процесс разработки, организации и производства с помощью WordPress?

Question

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

На какие другие проблемы стоит обратить внимание?

Каким был ваш рабочий процесс?

Answer 1

У меня есть одна установка WordPress, настроенная для питания нескольких доменов на моем сервере разработки. Файлы плагинов и тем также являются общими, поэтому обновление выполняется в один клик для всех блогов.

Я использую Apache VirtualHosts для сопоставления нескольких доменов с одним и тем же корнем документа и добавляю немного магии в основной wp-config.php для динамической установки DB_NAME, основываясь на текущем хосте (я могу опубликовать код, если хотите).

Для локальной работы у меня просто есть пользователь MySQL с привилегиями root и я использую его для всех своих баз данных (не рекомендуется на производственном сервере!).

Мои локальные домены названы соответствующими реальным доменам, но с поддельным TLD. Поэтому, работая с example.com, я настроил VirtualHost example.dev.

Когда я готов начать работу, я использую HeidiSQL , чтобы сделать копию базы данных разработки, а затем заменить все вхождения из example.dev на example.com.

Скопированная база данных теперь готова к производственной установке. Зеркально отразите локальную установку WordPress на производственном сервере (копирование над плагинами, загрузками и темами) и используйте либо HeidiSQL (рекомендуется), либо phpMyAdmin для импорта подготовленной базы данных.

UPDATE

Естественно, если вы сделаете изменения в одном, а затем скопируете все в другое, то вы потеряете все изменения , сделанные вами в другом. Это касается не только WordPress, но и всего остального в жизни!

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

Answer 2

Этот же вопрос был задан и получен ответ WordPress.stackexchange . Он содержит подробную информацию и рекомендации для быстрого развертывания от разработки до производства.

Редактировать

Это тот же ответ, который я добавил на WordPress.

Возможно, есть и другие способы, которых мне не хватает, но я дам вам 2 варианта:

1.Используйте экспорт XML для экспорта новых сообщений и комментариев. Затем используйте импортер WordPress для импорта новых сообщений и комментариев обратно в базу данных разработчиков

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

Тем временем производство изменилось (новые сообщения, новые комментарии и т. Д.)

Это решит вашу проблему с внесением любого измененного контента.

2. Используйте команду INSERT IGNORE INTO MySql, чтобы добавить новые таблицы из dev. или команду REPLACE, чтобы перезаписать повторяющиеся строки в одной и той же таблице.

Перед использованием MySql создайте резервную копию обеих баз данных, переместите базу данных gz на рабочий сервер и загрузите дамп (измените имя dev, если оно совпадает с рабочим.

INSERT IGNORE INTO `_wp_production_db`.`wp_cool_plugin_options`
SELECT *
FROM `_wp_dev_db`.`wp_cool_plugin_options`

Мне не удобны команды MySql, поэтому я бы выбрал вариант 1.

Answer 3

У меня есть Сайт разработки на моем Локальном компьютере, и я изменяю файл локальных хостов таким образом, чтобы обращения к работающему серверу (www.example.com) указывали на локальный хост. Таким образом, все вызовы внешних файлов (jquery и т. Д.) По-прежнему работают, и мне не нужно беспокоиться, просматривая БД, чтобы что-то изменить. Экс- и импорт контента через WordPress XML дал мне лучшие результаты.

UPDATE: Я использовал http://www.mertyazicioglu.com/projects/wordpress-move/ и получил хорошие результаты.

JD

Answer 4

Если у вас установлен phpMyAdmin, перенос сайтов WordPress с сервера на сервер вообще не должен быть проблемой. Просто экспортируйте базу данных в файл tar.gz и скопируйте свою пользовательскую тему (если она у вас есть) через FTP, а затем, после создания новой БД и нового дампа WordPress, повторно загрузите их на новый сервер. 2 изменения в home и blog url в базе данных и 2 изменения в файле wp-config и все готово.

Одна вещь, с которой я столкнулся, это плагины сторонних разработчиков. Я в конечном итоге сам кодирую множество галерей и виджетов JavaScript, потому что сторонние плагины либо выглядят как дерьмо, работают медленно или не работают так, как я хочу. Слава богу за JQuery.