как переносятся настройки cms в базе? всякие включенные модули, настройки компонентов и т.п.?

куда переносятся? задача какая?

выдать нескольким разработчикам копию live-сайта, в виде докер-контейнера + гитлаба куда коммитить. по коммиту - stage + тесты, по коммиту в мастер - stage->prod.

выдать нескольким разработчикам копию live-сайта, в виде докер-контейнера + гитлаба куда коммитить. по коммиту - stage + тесты, по коммиту в мастер - stage->prod.

что разрабатывают разработчики?

расширение?

а вот не факт, любая кастомная задача. "этот блок поместить в другое место, прикрутить rss, настроить рассылку почты". такое.

разноплановое, связанное с проектом вообще а не с узким кодом одного компонента

выдать нескольким разработчикам копию live-сайта, в виде докер-контейнера + гитлаба куда коммитить. по коммиту - stage + тесты, по коммиту в мастер - stage->prod.

Давайте начнём, чуть более отдаленно. Какой сайт нужен? Какая структура тимы?

не совсем с этой точки зрения. допустим я хостер и предоставляю инфраструктуру. так чтобы по клику с работающего сайта получались некоторые готовые заготовки для тимы. вот live, сделаем вам stage + n dev.

нужно понимать есть ли примеры хороших кейсов и стандарты у сообщества той или иной cms.

нечто типо https://wodby.com/ , но wobdy про докеризацию, а я больше сейчас интересуюсь именно workflow по CI.

В целом. Сайты на joomla не стоит расценивать как одну единицу. Все разрабатывается отдельно. Отдельно расширения , отдельно шаблон, отдельно конент. Под расширения лучше по отдельному репозиторию. Плюс апдейт сервер чтобы было легко выпускать обновлять расширения. То бишь новую версию закончили. На бета отестировали на релизе обновили.

Если свалить весь сайт в одну кучу, получиться не очень хорошо и очень не удобно.

ммм. global git + git modules вариант?

целиком сайт мало пригоден для работы через гит

джумла как бы по другому устроена

например обновления расширений происходят по нажатию кнопки в админке

ммм. global git + git modules вариант?

Смысла нет. Как бы проще написать. Joomla не Symphony. А каждая часть сайта будь компонент модуль плагин или шаблон не зависимы. А ядро и вовсе не запихивается в проекты. Поэтому система если с git проста. Одно расширение или пакет связанных расширений отдельный проект. Ну а дальше разработчики работают кому как угодно. Например вот надо вам сделать модуль обратной связи. Для этого целиком весь сайт не нужен. Хватит и чистого ядра. Закончил модуль опубликовал релиз. Потом тот кто занимается шаблоном сделает его переопределение в проекте шаблона, чтобы выглядел красиво. Ну и т.д.

а как переносить настройки которые хранятся в базе? вот есть у меня условно https://extensions.joomla.org/extensions/extension/contacts-and-feedback/forms/breezing-forms-pro/ . он пишет какие-то настройки в базу в табличку __facileforms_forms. есть какой-либо способ, не давая разработчикам доступ к проду, обоим изменить эти настройки и смержить их (или хотя бы получить конфликт и заметить это).

Тобишь единого или главного git тут не бывает.

хороший пример с симфони - там все просто, есть миграции)

а как переносить настройки которые хранятся в базе? вот есть у меня условно https://extensions.joomla.org/extensions/extension/contacts-and-feedback/forms/breezing-forms-pro/ . он пишет какие-то настройки в базу в табличку __facileforms_forms. есть какой-либо способ, не давая разработчикам доступ к проду, обоим изменить эти настройки и смержить их (или хотя бы получить конфликт и заметить это).

А смысл. Настройки модуля бекенду не нужны он будет их тестировать одну за другой и заполнять самостоятельно.

есть какое-то общее соглашение? или это на уровне команды все для себя определяют?

есть какое-то общее соглашение? или это на уровне команды все для себя определяют?

Ну я когда в тиме работаю мы просто делим кому какой таск интереснее. Ну и кто за кем проверять будет. А контенщики сами по себе разве что багрепорты кидают.

А смысл. Настройки модуля бекенду не нужны он будет их тестировать одну за другой и заполнять самостоятельно.

ээм. кто-то что-то поменял в настройках. например девелопер решил задачу "изменить адрес отправления с формы". как ему эту настройку отправить на продакшн? вариант "зайти в админку продакшна и поменять" не предлагать.

ээм. кто-то что-то поменял в настройках. например девелопер решил задачу "изменить адрес отправления с формы". как ему эту настройку отправить на продакшн? вариант "зайти в админку продакшна и поменять" не предлагать.

Разработчик всегда вписывает свой email так тестить удобнее.

Настройки и содержимое это не разработка.

нет, я не про то. есть уже работающий сайт. там какой-то email. сайт большой, тяжелый. владелец сайта звонит и говорит "теперь заявки с этой формы принимает другой отдел, поменяйте на ...@...ru". а мы такие "окей, будет". и такое должно логироваться в vcs. кто изменил, на какую настройку и когда.

Если по примеру чтобы написать модуль отправки писем мне не нужно знать email на который они будут отправляется.

нет, я не про то. есть уже работающий сайт. там какой-то email. сайт большой, тяжелый. владелец сайта звонит и говорит "теперь заявки с этой формы принимает другой отдел, поменяйте на ...@...ru". а мы такие "окей, будет". и такое должно логироваться в vcs. кто изменил, на какую настройку и когда.

Зачем? Просто прям на продакшен меняется мыло в настройках и закрывается таск.

но в целом я вроде понял подход, спасибо. если у кого на примете будут статейки про деплой с джумлой, накидайте плз.

Для настроек vcs не нужен.

но в целом я вроде понял подход, спасибо. если у кого на примете будут статейки про деплой с джумлой, накидайте плз.

А вот контент тут интереснее.

Зачем? Просто прям на продакшен меняется мыло в настройках и закрывается таск.

оу. это печально. но ладно, не буду спорить.

оу. это печально. но ладно, не буду спорить.

настройки хранятся в базе

в джумла это делается именно так

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

оу. это печально. но ладно, не буду спорить.

То есть вы каждую смену настройки сайта храните в vcs пароль адрес бд и т.д.?

ок, спасибо за участие. пошел думать.

@tsymbalmitia $this->values[] = JHTML::_('select.option', $key, ($characteristic_display != 'radio' && !empty($clean) ? $clean : $val) );

ок, спасибо за участие. пошел думать.

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

$this->values[] = JHTML::_('select.option', $key, ($characteristic_display != 'radio' && !empty($clean) ? $clean : $val) );

то есть здесь банально вызов JHTML

и он сцуко генерит код не очень хороший

<label for="hikashop_product_characteristic_12" id="hikashop_product_characteristic_12-lbl" class="radio"> <input name="hikashop_product_characteristic[1]" id="hikashop_product_characteristic_12" value="2" checked="checked" class="inputbox" size="1" onclick="return hikashopUpdateVariant(this);" type="radio">37 </label>

вот такой

суть в том что input завернут внутрь label

суть в том что input завернут внутрь label

Это поле?

ээм. кто-то что-то поменял в настройках. например девелопер решил задачу "изменить адрес отправления с формы". как ему эту настройку отправить на продакшн? вариант "зайти в админку продакшна и поменять" не предлагать.

миграции базы наверное не зря придумали))

когда я скрывают input чтобы он не портил собой все, у меня остается label, который не получает состояния checked

в этом беда

Это поле?

это в ядре хика

миграции базы наверное не зря придумали))

а есть где почитать про миграции в joomla?

миграции базы наверное не зря придумали))

Как часто ты таким пользуешься?

там же mysql

миграции базы наверное не зря придумали))

ну там типа аналог DoctrineMigrationsBundle с мануалом.

я просто не знаю даже куда копать, имя класса хотя бы)

Как часто ты таким пользуешься?

регулярно на проектах... которые подразумеват тестовый сервер и продакшен

там же mysql

Я сейчас через model делаю.

И да весь сайт лежит под гит))

ну там типа аналог DoctrineMigrationsBundle с мануалом.

если нужен continous deployment - надо смотреть в сторону zend server

регулярно на проектах... которые подразумеват тестовый сервер и продакшен

Я на продакшен так не гоняю. Ручками ручками) Если я с теста загоню базу в продакшен то продашен мигом рухнет и будет куча ааа xxx и lorem ipsum.

он умеет такие вещи

если нужен continous deployment - надо смотреть в сторону zend server

ммм, да почти все умеет. symfony, laravel, django, rails, expressjs... из фреймворков. из cms'ок пока нашел october и drupal. еще django-cms по понятным причинам.

ммм, да почти все умеет. symfony, laravel, django, rails, expressjs... из фреймворков. из cms'ок пока нашел october и drupal. еще django-cms по понятным причинам.

я про сервер а не про фреймворки

вообще то

я не говорю про zend framework

zend server

но в россии он не популярен

здесь редко его юзают

я думаю он про другое говорил

но в россии он не популярен

посмотрю что за зверь, tnx)

посмотрю что за зверь, tnx)

http://www.zend.com/en/products/server/features

вот

я его использовал

там есть возможность развернуть сайт, запустить тесты, если тесты не пройдут -откатиться

там можно туда завернуть джумла

то есть он работает с этим

но честно говоря, мне казалось что в таких масштабах в россии с джумла не работают

но честно говоря, мне казалось что в таких масштабах в россии с джумла не работают

Еще как работают =)

я думаю он про другое говорил

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

Докер для жумла есть

но честно говоря, мне казалось что в таких масштабах в россии с джумла не работают

имхо под любую из топ-5 cms есть милионные проекты которые надо как-то поддерживать.

есть, есть. и https://medium.com/@pierangelo1982/joomla-mysql-phpmyadmin-in-docker-8321ae02900 , и docker-compose я находил где-то готовые. не тестил еще правда.

К слову о git joomla и крупных проекта. У меня обычно два подхода: 1. Если в проекте множества пакетов, все отдельно. 2. Все в одном пакете. И update server для расширений. Но моя забота исключительно механика, так что как будут делать конетнт меня мало заботит. Помогал пару раз делать прямую загрзуку в бд через phing но не более. того. Кстати у joomla есть встоенная система версий для контента. https://docs.joomla.org/Help38:Components_Version_History

И да весь сайт лежит под гит))

Прям весь? с ядром?

Да

Оно используется как доп защита от вирусов )))

Оно используется как доп защита от вирусов )))

eyesite поставь если уж приперло все файлы на изминения чекать постоянно =)

А смысл?

Гит проще ))

Гит проще ))

Ну хз, не по мне это не торт. ядро держать в репозитории. Любой сайт на Joomla не более чем пакет расширений и работать проще ибо ядро под руками не путаеться, но каждому свое.

Да нет ни каких проблем )) не понимаю в чём проблема

Да нет ни каких проблем )) не понимаю в чём проблема

Слишком много лишних файлов проекта слева болтается с которыми ты не работаешь, как-то так...

Меня лично не парит