ну для этого можно написать обертку, типа
1. создать тв,
2. привязать к шаблону

Ну в реале там скорее всего 2-3 человека на проект. Но они тоже как-то синхронизируются, не на одном же компе они это все фигачат... или все же на одном?

я так и делал, могу даже набросок скинуть, просто не обкатал

с вп не приходилось работать

Да я пока общий принцип пытаюсь понять, как вообще эта синхонизация разработки делается. Если с файлами понятно, то с БД пока темный лес.

Ну не вп, так drupal. Там вообще такая уема таблиц по сравненю с ЭВО... не знаю. как это там работает, но конвертеры данных с друпала на ЭВО писал - так уже офигеваешь от количества связей в таблицах, из кторых надо данные забрать. А вед эти связи там тоже как-то создаются при создании сущностей. То есть та же хрень, что и с Эво.

У Друпала есть конфигурации. Их выгружают утилиткой специальной, drush
Т.е. натыкал чего в админке, галочки там всякие поставил, создал что-то этакое -- оно в конфиге.
И файлы синхронизируются.
Т.е. на деве сделал drush config:export
Сделал всякое с гитом, синхронизировал.
На проде пишешь drush config:import
И все настройки сайтов одинаковы.

А вот с БД толком и не знаю. Лью ручками туда-сюда. Но у меня и бд на деве почти пустая, нафиг там мне данные живые не нужны.
А все настройки и всё изменение сайта попадает только в файлы, в бд нет ничего, что бы нужно было сохранять и перезаливать.

после обновления с v2 до v3 возникла ошибка в KCFinder - Unknown error. SimpleGallery также не работает. Ктото знает в чем проблема?

Пиздежь все эти ваши миграции в реальной жизни потому что 😁

А если про Лару говорить, то там подход похожий, имхо.
Само создание таблицы в БД делается миграцией. Не, можно и ручками, никто не запрещает. Но по сути делается файл, в котором описывается, какая таблица с какими полями должна быть создана.
Соответственно, на прод выполняются миграции -- и таблица летит туда.
Данные, опять же, в миграции не входят, посему хер его знать, как их туда-сюда тягать.
И надо ли... Мне кажется, там именно подход такой -- структуру сохранить, данные нахер. Типа нечего с тестового сайта таскать. Могу ошибаться, обсуждаемо.

Когда параллельно 5 человек насоздавали тв и ресурсов с одинаковыми айдишниками и их назаполняли - никакие миграции как описание СТРУКТУРЫ БД ничего не разрулят

artisan make:pizdov -vsem

еееее

😄

Сами ресурсы еще можно перекинуть выгружая в какой-нибудь json через getDocumentObject и создавая их в другом месте через modResource. Но когда там еще и шаблоны с тв создаются несколькими людьми - тут и настает черная дыра 😁

Это всё касается только подхода к планированию разработки и автоматизации проекта. Мне, однажды, приходилось писать автоматическую сборку для джумлы на 200+ серверов. Было весело.
В дешевом случае да, один разработчик - один проект в случае с ВП и подобными CMS. Не нужно тянуть избыточность технологий туда где оно не нужно и только замедляет.
Есть разные подходы в таких случаях:
1. Использовать сторонние специализированные инструменты контроля версий БД, такой себе git для БД. Или написать свой.
2. Использовать одну БД с постоянным бекапом перед внесением данных. Т.е. все работают с одной БД и знают правила (или автоматизировать их).
3. Делать дампы и знать как с ними работать.

Это на вскидку, думаю еще можно придумать варианты.

Использовать миграции удобнее. В рамках Эво остается решить вопрос с "обязательными данными" типа id ТВ, шаблонов. Тут тоже не все так прям плохо, хоть и гиморно. Основное это договариваться о нужных процессах. Тогда через время можно будет написать тесты и автоматизировать.

Это да, треш лютый. Я у себя для этого пишу скрипт, который запускаю перед тем, как что-либо сравнивать. Он тупо в нужную папку скидывает содержимое сниппетов. шаблонов. чанков, тв, плагинов, модулей, и все помещает в отдельные текстовые файлики, название которых совпадает с нзваниями шаблонов/тв/сниппетов и т.д. Потом соответственно делаю kdiff для папки локального сайта и серверного. И там хотя бы видно все различия, какой файл куда надо влить. Но это ручной режим и достаточно кропотливый труд. Поэтому думаю о какой-то автоматизации через git или еще что-то.

В теории это нужно к каждой таблице (тв, шаблоны, категории, права и т.п.) еще тянуть уникальную связку id создавшего запись - id самой записи. И уже используя эту связку СОЗДАВАТЬ НОВЫЕ данные с НОВЫМИ айдишниками