Wordpress, современные технологии?

Всем доброго!

Целый набор вопросов, многие явно холиварные, но очень хочется, а, возможно, при этом колется.

И один, основной вопрос для всех пунктов:

А как относятся заказчики (или, скажем, [их] эксперты по WP, в том числе эксперты в кавычка) к тому, что их любимый сайт будет сдаваться не в виде

1. Распакуйте архив
2. Залейте дамп БД

а

1. git clone ...
2. composer install
3. some-script-to-restore-db-and-media-uploads

(вопрос доступности на хостинге git/composer/... в рамках данного вопрос неважен, считаем, что хостер это позволяет)

1. Composer
1.1. Смущает, что это всё на базе "левого" форка johnpbloch/wordpress. Насколько этому форку можно верить?
1.2. Некоторые плагины можно установить через composer. Некоторые? Т.е. можно нарваться на нужный плагин, который через composer Ы? И тогда что? копировать его код руками в папочку?
1.3. А как тогда разрабатывать кастомный функционал конкретного сайта? Делать плагин, упаковывать его в пакет для Composer? И тема сайта - тоже как пакет?

2. Git
Для Git вопросы по Composer, кажется, в основном актуальны, если иметь в виду, что таки Git != Composer, в обе стороны.
Но для Git ещё вопрос
2.4. Кажется, в мануалах по WP+Git путают функционал с контентом.
Т.е. кастомный программный код в Git-е - понятно, хотя вопрос про тему против плагина остаётся.
Но контент.. это же явно не про Git? (Или, скорее, Git не про бекап контента).

3. Twig
Опять же, повторяется вопрос отделения оформления от функционала, т.е. тема против плагина.
Как основной вопрос для всех пунктов - принимается ли такое?
Но
3.5. А насколько это (тема на Twig-е) будет а-ля "вырезать аппендицит через задний проход"?
Стоит ли чистота view таких заморочек?
  • Вопрос задан
  • 82 просмотра
Пригласить эксперта
Ответы на вопрос 1
@its2easyy
Можете посмотреть в сторону bedrock и sage, детали будут отличаться, но в целом вроде то же чего вы хотите добиться, только уже собранное вместе.
Вместо гита на сервере лучше настроить ci/cd, чтобы билдил и копировал то что нужно.
Контент почти всегда не совпадает в дев и прод версиях, поэтому обычно его нет смысла синхронизировать, разработчик тестирует локально (верстка, кастомные поля, контент в редакторе и т.д), коммитит изменения, они применяются на сервере, потом уже реальный контент заполняется в прод версии.
Ответ написан
Комментировать
Ваш ответ на вопрос

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

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