он мне вообще перенес в джумла материалы из битрикса в количестве нескольких тысяч

Да это херня, по сравнению с мержем базы, когда они идентичны во всем, кроме мелких настроек

Перенести что-то не проблема. Проблема - работать на тестовым сайтом, и потом все изменения переносить на боевой, когда боевой тоже уже запущен. Например, создали вы несколько материалов, поменяли настройки на тестовом, а за это время на боевом были созданы другие материалы и изменены другие настройки. Банально - заказы в интернет магазине.

У нонамбера есть расширение, которое работает с бд

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

https://joomlaportal.ru/news/extensions/modules/3051-reliz-modulya-junewsultra-pro-6-7-3

да там 100500 настроек же

просто выводишь и все ))

Запиши видео о настройках в админ панеле😊

хотя подозреваю, что там именно то, что мне нужно, под новостник заточено

Товарищи, у кого был опыт мерджинга БД Joomla-сайта? Для файлов есть GIT, а как быть с базой? Например, есть у нас 2 копии одного сайта: тестовая и боевая - и там и там за некоторое время появляются разные изменения. Как накатить новый релиз и объединить все изменения в обеих базах? Был у кого-нибудь такой опыт? Может быть есть какой-то инструмент?

да и быть в принципе не может - это не такое очевидное сравнение как с текстом

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

можно поступить так - все изменения свои хранить в пакете joomla и его затем накатывать на prod

Но там в основном изменения структуры. Ну может иногда конфиг. Так что это все таки не совсем то.

Вообще задача с мержем базы из дев в прод не решаема. Потому что её не имеет смысл решать. Ладно статичные страницы вроде посадочных. Но динамика типа новостей на том же дев частенько создаётся ради тестирования.

Перенести что-то не проблема. Проблема - работать на тестовым сайтом, и потом все изменения переносить на боевой, когда боевой тоже уже запущен. Например, создали вы несколько материалов, поменяли настройки на тестовом, а за это время на боевом были созданы другие материалы и изменены другие настройки. Банально - заказы в интернет магазине.

Вообще задача с мержем базы из дев в прод не решаема. Потому что её не имеет смысл решать. Ладно статичные страницы вроде посадочных. Но динамика типа новостей на том же дев частенько создаётся ради тестирования.

Смотри, контент мерить и не нужно, но иногда ты делаешь какой-то дикий кастом для ком контент. Пусть это будет поле! Ты на деве создал поле, выполнил какие то настройки компонента, вывел где-то модуль, применил к модулю свой шаблон, где выводить созданное поле. Теперь тебе нужно все это повторить на проде. Гораздо проще было-бы, если бы твои изменения были сделаны из кода. Тогда он сам проверил бы и применил нужные настройки на проде

Смотри, контент мерить и не нужно, но иногда ты делаешь какой-то дикий кастом для ком контент. Пусть это будет поле! Ты на деве создал поле, выполнил какие то настройки компонента, вывел где-то модуль, применил к модулю свой шаблон, где выводить созданное поле. Теперь тебе нужно все это повторить на проде. Гораздо проще было-бы, если бы твои изменения были сделаны из кода. Тогда он сам проверил бы и применил нужные настройки на проде

Особенно весело - поменять один параметр, который хранится в сериализованных массиве. При этом, не задеть другие параметры

Ну так вписал это в скрипт и все. Я так давиче делал скрипт миграции. Где создавал категории менял пункты меню и даже типы модулей.

добро пожаловать

и заливается промежуточно этапа на бой

всё верно! Нет рабочего способа выполнить деплой изменений, которые сделаны в базе. Всегда есть куча "но" и-за которых городятся "велосипеды". Кто-то пишет скрипты, кто-то поднимает несколько серверов. Но чаще всего приходится просто 2 раза руками всё проделать

несколько серверов это нормально

ну ингогда ещё тестовый. Который не дублирует полностью прод, но уходит немного вперёд

Ну да. dev- для разработки, stage - для отладки и тестирования, master - в бою. Но я всё время без stage обходился