Как проходит разработка на Wordpress?

Как это обычно?
Вот код, рядом кучка статики, рядом миграции. Все это пушится в репозиторий, там тестится/собирается докер образ и выливается в прод или тестовое окружение. Причём конечные редакторы могут менять только данные в базе данных и медиа файлы. (Вроде ничего не упустил?)

Как это происходит с wp?
Ядро системы тоже в репозитории хранить?
А плагины?
Или в репозитории хранить только тему и кастомные плагины?
А что делать, с тем, что изрядная часть настроек хранится в базе данных? На проде редактор поставил какую-то важную настройку одного из плагинов. Локально работает, на тесте работает, на проде нет. Значит состояние базы данных нужно регулярно забирать с прода?
А что если на вроде редактор возьмёт и обновит wp? Или плагин? Или отредактирует тему? Есть ли плагин, который запрещает все изменения? Можно было бы и просто запретить запись файлов, но мне кажется, что живые люди будут не очень довольны - хотел плагин - ошибка, хотел исправить опечатку в теме- ошибка, лучше это как-то скрывать.
  • Вопрос задан
  • 544 просмотра
Решения вопроса 1
HeadOnFire
@HeadOnFire Куратор тега WordPress
WordPress & Laravel Evangelist
Дополню ответы Владимир Дружаев, Дмитрий и Денис Янчевский своим личным примером. Для начала скриншот:

5cef96d679ef6822748214.jpeg

Внимательно посмотрите структуру проекта слева. А теперь разберем подробнее:

1. WordPress и плагины - это зависимости проекта, а не сам проект. Весь проект построен на базе Composer, ядро WP - "черная коробочка" которая устанавливается как и любая другая composer dependency, лежит в папке core и туда вообще никто и никогда не заглядывает. Она в .gitignore, на всех environments ставится/обновляется все тем же Composer.

2. Все плагины - бесплатные из .org, платные с разных источников и свои собственные - тоже Composer dependencies.

3. Ни ядро WP, ни плагины, ни другие зависимости никакие редактора обновлять или ставить права не имеют - для этого существуют разработчики и контракт на поддержку проекта. Или in-house разработчик(и) на стороне клиента которые это дальше подхватят. Админский аккаунт клиента тоже порезан по возможностям, у главного разраба (то есть у меня) кастомная роль Super Admin, которая может все то, что дефолтный Administrator + еще дополнительные права (в каждом проекте свои нюансы). WordPress тоже сам себя не обновляет. Если клиенту нужна фича (не плагин, а именно фича) - ставится задача разрабам и уже они ее решают, не важно как - бесплатным плагином, платным плагином или кастомным решением.

4. Критический код выполнен в виде MU плагинов. Чтобы даже суперадмин не смог выключить.

5. Функциональная часть сайта реализована в виде плагинов (mu и обычных) или обычных php-библиотек, управляемых Composer. В этом случае лежат в папке vendor, как и положено. Она, естественно, вне git.

6. Обратите внимание на папку deploy. Скрипт pipeline.sh - это процедуры деплоймента на разные environments с помощью BitBucket Pipelines. Они же с помощью WP-CLI на конечном сервере выполняют ряд post-deploy задач - например очистка transients и сброс кешей, принудительное выполнение cron-задач и вообще всего что может понадобится в конкретном проекте. В данном проекте все написано на Bash/Shell, но бывает на PHP (CLI-приложение), и/или на Golang. Скрипт sync.sh - это синхронизация базы и медиафайлов с одного environment на другой. Чаще всего используется для pull с прода на dev или staging, иногда для push с dev на staging. Все с бекапами и rollback'ом. Под капотом там активно используется WP-CLI. Всегда выполняется на dev перед началом работы, чтобы база и загрузки были актуальны. Пример работы / вывода скрипта в терминале:

5cef9fb474621776796677.jpeg

7. Тема, разумеется, находится в папке app/themes/theme-name. Тема отвечает исключительно за внешний вид. Там внутри своя сборка - webpack, gulp, babel, sass, скандальный node_modules (в .gitignore) и вот это все. Я лично занимаюсь только PHP-файлами, для фронтенд-части есть отдельный специалист, я же пользуюсь уже готовыми билдами от него. В некоторых проектах вместо стандартных шаблонов WP может использовать Twig путем установки Timber. Тоже через Composer.

8. Там вы можете увидеть даже папочку tests. Да, в серьезных проектах на WordPress пишутся тесты. Впрочем, в данном конкретном проекте в этом не было необходимости (и бюджета) :)

9. Конфиги построены на environmental variables, в стандартном wp-config.php вообще все не так, как многие привыкли. Все credentials, ключи - в .env, остальное в зависимости от среды в config/{environment}.php.

10. Немножко про git и CI. Пушится все в ветки по фичам/фиксам и тд. Мердж пулл реквеста в ветку develop запускает деплой на staging. Мердж в master - на продакшн. Мерджит только тимлид (в нашем случае это я) после code review. Пулл реквесты, разумеется, проходят билд и тесты. Зеленый pull request я проверяю сначала локально у себя, потом мерджу в develop и проверяю на staging. Если все ок - релизится на прод. Но это в условиях команды, часто же приходится работать только на пару с фронтендером, в этом случае понятно что цепочка немного упрощается и code review сам себе не делаю.

11. По поводу каких-то настроек которые редактора могут поставить на проде и это хранится в базе. В большинстве случаев достаточно deploy/sync.sh pull и менее чем за минуту получить свежую базу и загрузки (инкрементальный rsync). Если делаются какие-то фичи локально, которые хранят свои настройки тоже в опциях, их много и их потом надо залить на прод, чтобы ручками не мучаться - для этого есть миграции.

Update
12. Забыл еще один важный момент, который часто ставит в ступор тех, кто только начинает идти по этому пути. Плагин Advanced Custom Fields (Pro) и настройка его полей. Если он используется, то каждая нова фича, каждый релиз сопровождается созданием или изменением новых полей, и вот тут надо тоже как-то синхронизироваться, писать миграции и тд? Решаемо. У ACF есть функция синхронизации полей в JSON-формате, и еще лучше - возможность конфигурации групп и полей с помощью PHP-кода. Именно последнее позволяет все поля описывать в коде, код держать под VCS и деплоить с соответствующим релизом, а поверх накатить миграцию с default контентом для этих полей (если нужно). Такой подход, кстати, устраняет еще одну проблему ACF - снижение производительности. Поскольку все поля и их настройки больше не хранятся в БД, это сразу минус очень много запросов к БД. Плюс, поскольку они описаны в коде, это означает оптимизацию и opcache. Ну и reusability повышается существенно. Например вот так выглядит файл с описанием полей в виде массива:

5cefb04e9de4f827142327.jpeg

13. Разворачивается проект (на любом из серверов, у нового разработчика, на новом компе и тд) быстро и удобно:

git clone адрес_репозитория && cd склонированная_папка_проекта

# Одной командой качаем и устанавливаем все зависимости, включая
# WordPress и все-все плагины, здесь же запускается post-install скрипт
# который генерит .env файлы из образцов, задавая вопросы и получая
# от вас ответы, генерит salts и выполняет другую рутинную работу. 
# Последнюю команду по идее можно даже включить в этот скрипт.
composer install 

# И напоследок берем с прода свежую базу и папку uploads.
deploy/sync.sh pull


Подождали несколько минут, ответили на пару вопросов - и у вас развернут проект с последним стабильным кодом и актуальным контентом с прода. Скорость выполнения данной процедуры зависит только от того, есть ли в кеше Composer WP, плагины и другие зависимости ну и от размера базы на проде и веса папки uploads - если она большая, то первая установка может занять некоторое время. В дальнейшем будут качаться только обновленные и новые файлы - pull под капотом использует rsync в режиме incremental.

И еще, если не хочется качать всю папку загрузок и держать ее локально (актуально для крупных проектов), то можно внести в конфиги скриптов небольшие изменения, чтобы файлы не качались а их урлы/пути в базе не заменялись. После этого достаточно добавить в корень проекта кастомный драйвер для Valet (мы используем Laravel/Valet в качестве локального сервера для разработки) который будет проксировать все запросы на медиа-файлы на продакшн или стейджинг (драйверу указывается базовый URL и он будет вместо https://project.test обращаться к https://staging.project.com например).
/Update

Справедливости ради - не на каждом проекте такая схема нужна. Не на каждом она вообще возможна. Данный подход предполагает командную работу, использование какой-нибудь связки типа Jira, Confluence, BitBucket, Strava/Slack. Или хотя бы Skype+Notion с клиентом. Эта схема предполагает адекватный (не маленький) бюджет, поддержку и развитие проекта в дальнейшем.

Из опыта - по очень похожей схеме я работаю и с WordPress, и с Laravel. Заметных неудобств из-за того что WP это устаревший legacy код не испытываю. Все по современным, удобным и эффективным практикам. Клиентам, которые у нас уже по несколько лет на поддержке и развитии своих проектов по такой схеме - все нравится. За последние 4 года не вспомню ни одного существенного incident, вызванного проблемами в коде на проде или что-то сломанное в процессе деплоя. Сама схема и процессы со временем конечно же меняются, адаптируются, улучшаются.

Надеюсь мой опыт немного прольет свет на то, как все можно делать. Если есть уточняющие вопросы - задавайте, с удовольствием отвечу.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
dimasmagadan
@dimasmagadan
на практике делают кто как. я бы советовал так:
1. база идет вниз, код вверх
база никогда не копируется с стейджа/локальных машин на проду (разве что при первом деплое). все правки, которые нужно делать в базе, тестируются вначале на стейдже, потом так же повторяются на проде
код правится локально/на стейдже, потом идет на проду (фтп/гит/дженкинс или прочий CI, смотря как настроено)

2. в репе может быть как только кастомный код темы/плагинов, так и полностью весь сайт с движком (за исключением uploads)
вариант с хранением движка в репе мне нравится больше.
как вам пишут выше "Мусор в виде файлов движка" - спорный минус. движок на самом деле занимает крайне мало места и вы за это место не платите.
плюсов хранения больше:
в корне есть некоторые файлы, которые так же нужно отслеживать - тот же htaccess, иногда нужно положить туда еще какие-то сторонние php/html/js скрипты.
при разворачивании на новой машине достаточно склонировать реп (на самом деле это легко решается с помощью wp-cli или докера с офф.образами, но если ими не пользуетесь - "сколнировать реп и все готово" намного проще, чем клонировать+качать отдельно движок/все плагины)

3. права админа должны быть только у админа
ситуации "На проде редактор поставил какую-то важную настройку" быть не должно. чтоб минимизировать такой риск - урезать права + бэкапы каждый день

это все имеет смысл, если вы действительно пишете код, а не "делаете сайт" через плагины и их настройку
Ответ написан
OtshelnikFm
@OtshelnikFm Куратор тега WordPress
Мои работы: otshelnik-fm.ru
90% - фигачат сразу на боевой все правки.
9% используют dev сервер - но фигачат по ftp на боевой руками
1% делают как надо

вероятность что 1% вам напишет в подробностях (а не как про картинку "как нарисовать сову") на тостере - мала

я из 9-ти процентов

1 плагин - 1 проект в ide (так же с темой - 1 тема - 1 проект). Мусор в виде файлов движка там не нужен.
Идет все в гит или битбакет
Как только на тестовом все проходит норм - бекап боевого и по ftp заливаю на него. Про вебхуки знаю, но лень))

что изрядная часть настроек хранится в базе данных?
какая изрядная? От чего? От темы? От самого ВП? Да и фиг с ними - один раз дев сервер настраивается также как и боевой. Или вы часто меняете все глобальные опции?
На проде редактор поставил какую-то важную настройку одного из плагинов
- покажите какую. Обычно все работает и так.

А что если на вроде редактор возьмёт и обновит wp? Или плагин? Или отредактирует тему? Есть ли плагин, который запрещает все изменения?

объясните ему что так делать на живом сайте нельзя. Вы там главный разраб? Все изменения должны проходить через вас.
хотел исправить опечатку в теме- ошибка,
ну вот и дошли до того момента когда ситуации высосаны из пальца. Зря писал все это вам. Вы сказки придумываете.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы