Как работать с modx двум и более разработчикам одновременно?
Здравствуйте. Планируем работу с проектом, одновременно с товарищем. Встал вопрос, как мы это можем сделать правильно? Ресурсы, чанки, шаблоны, сниппеты мв MODX можно сделать статичными, и использовать для контроля версий git. Но есть один важный момент, который так просто разрешить не получается… Ресурсы, шаблоны, чанки, сниппеты в любом случае делают запись в бд о себе. Создали ресурс — создалась запись о нем в modx_site_content.Как поступать в данном случае?
02 мая 2019, 07:43
Комментарии: 18
Здравствуйте, создавать ресурсы, чанки, сниппеты, шаблоны через modExtra — делать свои собственные компоненты, которые потом на боевой сервер / stage сервер закидывать через собственный репозиторий или через загрузку пакета. (Можно даже собирать пакеты на боевом, а синхронизироваться через гит)
Держать весь код в статических шаблонах/чанках и не в коем случае в контенте ресурса. (но можно и в нем, но нужно будет подработать код modExtra)
Примеров тоже хватает — Tickets, pdoTools и так далее.
Держать весь код в статических шаблонах/чанках и не в коем случае в контенте ресурса. (но можно и в нем, но нужно будет подработать код modExtra)
Примеров тоже хватает — Tickets, pdoTools и так далее.
Ресурсы, чанки, шаблоны, сниппеты мв MODX можно сделать статичными, и использовать для контроля версий git.могу быть не прав, но в вашем случае это не поможет. Статичный ресурс все равно делает запись в базе данных, и даже если ваш напарник каким-то образом получит файл, то без синхронизации базы данных ничего не будет работать.
Посмотрите на компонент… ну это и не совсем компонент, в общем на gitmodx хотя и он не решает всех вопросов.
Может я чего-то не знаю о MODX, но мне лично очень не хватает в нем миграций для базы данных, как это сделано в yii2
могу быть не прав, но в вашем случае это не поможет. Статичный ресурс все равно делает запись в базе данных, и даже если ваш напарник каким-то образом получит файл, то без синхронизации базы данных ничего не будет работать.Да, тут вы не правы. Компонент при установке/сборке — создаст всё необходимое в БД.
Присмотритесь к modExtra, может быть это облегчит вам процесс разработки
Я так и подумал.
Раз уж зашла речь об modExtra и если у вас есть время — расскажите поподробнее, как используя компонент для создания компонентов разрабатывать сайт. А тем более не одному. Вот правда, у меня в голове не укладывается. Я воспринимаю компонент, как некий отдельный самостоятельный кусок кода, который решает конкретную задачу.
Как например modExtra поможет работать над функционалом того же минишопа? Вот правда, расскажите подробное, реально интересно. Как вести разработку вдвоем? Сайт должен где быть расположен? на удаленном сервере у которого доступ к файлам есть у обоих разработчиков и они оба через свои IDE скачивают файлы сайта и работают с ними? Как modExtra может помочь к примеру с редактированием шаблона почтового сообщения, который отправляется покупателю при оформлении заказа в магазине? Ведь этот шаблон устанавливается вместе с компонентом minishop и представляет из себя только запись в базе? Я задаю вопрос не чтобы показать, что вы не правы, не воспринимайте это в таком ключе — я просто не понимаю как это работает. Я еще понимаю когда Зернов в своем gitmodx написал скрипты, которые при запуске шерстят базу данных, вытаскивают оттуда сниппеты, чанки и так далее и создают из них файлы — это хотя бы мне понятно, а вот как moExtra может помочь разрабатывать новый сайт причем одновременно двумя тремя разработчиками — я не понимаю. Спасибо.
Раз уж зашла речь об modExtra и если у вас есть время — расскажите поподробнее, как используя компонент для создания компонентов разрабатывать сайт. А тем более не одному. Вот правда, у меня в голове не укладывается. Я воспринимаю компонент, как некий отдельный самостоятельный кусок кода, который решает конкретную задачу.
Как например modExtra поможет работать над функционалом того же минишопа? Вот правда, расскажите подробное, реально интересно. Как вести разработку вдвоем? Сайт должен где быть расположен? на удаленном сервере у которого доступ к файлам есть у обоих разработчиков и они оба через свои IDE скачивают файлы сайта и работают с ними? Как modExtra может помочь к примеру с редактированием шаблона почтового сообщения, который отправляется покупателю при оформлении заказа в магазине? Ведь этот шаблон устанавливается вместе с компонентом minishop и представляет из себя только запись в базе? Я задаю вопрос не чтобы показать, что вы не правы, не воспринимайте это в таком ключе — я просто не понимаю как это работает. Я еще понимаю когда Зернов в своем gitmodx написал скрипты, которые при запуске шерстят базу данных, вытаскивают оттуда сниппеты, чанки и так далее и создают из них файлы — это хотя бы мне понятно, а вот как moExtra может помочь разрабатывать новый сайт причем одновременно двумя тремя разработчиками — я не понимаю. Спасибо.
Процесс работы ничем не отличается от работы с yii2, у каждого разработчика своя dev версия сайта на локальной машине с modx и компонентом в корне сайта, где они вносят изменения в сниппеты, чанки, шаблоны, коммитят их, делают гит пулл (мержат если есть что мержить) и пушат.
Однако для того, что бы изменения отобразились на сайте — нужно компонент пересобирать, для этого есть `_build/build.transport.php` (но можно на dev машине через `ln -s` связать папку компонента с его же папкой в core/components, что бы не пересобирать каждый раз при изменении статичных сниппетов, чанков, шаблонов), но для системных настроек и ресурсов пересобирать всё-таки придется.
Релизить можно или загрузив zip файл из core/packages (который генерируется вызовом `_build/build.transport.php` ) в установщик пакетов.
Или же на боевом в корне сайта склонировать компонент и запустить билд.
Можно поднять свой репозиторий и обновлять на боевом через обновление компонента.
Однако для того, что бы изменения отобразились на сайте — нужно компонент пересобирать, для этого есть `_build/build.transport.php` (но можно на dev машине через `ln -s` связать папку компонента с его же папкой в core/components, что бы не пересобирать каждый раз при изменении статичных сниппетов, чанков, шаблонов), но для системных настроек и ресурсов пересобирать всё-таки придется.
Релизить можно или загрузив zip файл из core/packages (который генерируется вызовом `_build/build.transport.php` ) в установщик пакетов.
Или же на боевом в корне сайта склонировать компонент и запустить билд.
Можно поднять свой репозиторий и обновлять на боевом через обновление компонента.
Как например modExtra поможет работать над функционалом того же минишопа?Минишоп сам написан на базе modExtra. github, только на прошлой версии.
Как modExtra может помочь к примеру с редактированием шаблона почтового сообщения, который отправляется покупателю при оформлении заказа в магазине? Ведь этот шаблон устанавливается вместе с компонентом minishop и представляет из себя только запись в базе?Вот этот шаблон
а вот как moExtra может помочь разрабатывать новый сайт причем одновременно двумя тремя разработчикамиmodExtra позволяет создавать ресурсы, сниппеты, плагины, шаблоны, тв через код и держать код всего вышеперечисленного в файлах. А когда код в файлах, то тут гит в помощь.
расскажите поподробнее, как используя компонент для создания компонентов разрабатывать сайт.Можно создать один компонент с названием сайта, можно использовать несколько компонентов, поделив логику на части.
Порядок таков:
1. устанавливаем модикс
2. Ставим стандартный набор дополнений через админку
3. клонируем modExtra, переименовываем компонент запустив соответствующий скрипт (удаляем связь с репозиторием, инициализируем свой)
4. Комитим изменения — пушим
Здесь уже в принципе может подключиться несколько разработчиков, но лучше все таки накидать базовый шаблон.
5. Пишем код шаблонов, чанков, сниппетов, плагинов итд, не забываем вписать их название в соответсвующий файл тут
6. git commit / pull / push (merge при необходимости) дальше всё в таком духе
Я воспринимаю компонент, как некий отдельный самостоятельный кусок кода, который решает конкретную задачу.Да, можно разбивать компоненты под решение конкретной задачи — компонент поиска, компонент админки, но в любом случае это не такой компонент как во фронтенде, это скорее как composer package (просто в MODX они называются компонентами).
Как например modExtra поможет работать над функционалом того же минишопа?Подключив minishop2 через $modx->getService() можно получить доступ к функциям/моделям minishop2.
Более детально можно посмотреть на примере Tickets — где используется функционал pdoTools.
Как modExtra может помочь к примеру с редактированием шаблона почтового сообщения, который отправляется покупателю при оформлении заказа в магазине? Ведь этот шаблон устанавливается вместе с компонентом minishop и представляет из себя только запись в базе?Можно программно менять системные настройки, можно даже залезть в настройки minishop2 и поменять там всё. Вконце концов, можно сделать sql запрос в базу.
Или изменить чанки по умолчанию!
Тут уж как захотите, можете выбрать любой способ, что бы выстрелить себе в ногу =)
Шаблоны письма привязаны к статусам, а для статусов есть соответсвующая схема
по этому, сам объект статус можно получить через
$status = $modx->getObject('msOrderStatus'. $id)$object->setbody_userbody_managerЕсли что-то не понятно, пишите, постарался раскрыть тему максимально коротко.
Вы очень хорошо постарались. Прямо нет слов.
Но вопросов становится все больше и даже как-то совестно вас ими засыпать. Постараюсь кратко.
— у меня нет задачи как у автора этого вопроса вести разработку на двоих, но если бы была, я бы наверное использовал статичные файлы или возможности парсера pdoTools для работы с файлами и плюс дамп базы данных. Мне кажется это намного проще держать в системе контроля версий еще и sql файл, чем городить огород с modExtra. Но скорее всего это изза неумения с ним работать.
— Откуда вы берете информацию о том как работать с modExtra? На гитхабе лежит два варианта этого компонента. В ветке версия 1 более старый и в ветке мастер более новый. По версии один еще можно найти на сайте Василия Наумкина пример разработки. Но по новой версии ничего кроме 10 строчек в файле описании на гитхабе и нет. И ставить это в вину Василию нельзя, он писал его для себя и ему и так все понятно.
— как по мне, компонент созданный при помощи modExtra представляет собой прежде всего некий класс, объект которого мы можем получить и достучаться до его методов. Не могу понять как это можно использовать для разработки всего сайта, а не отдельного функционала. Вы не создаете класс, вернее не пользуетесь им (мне кажется нельзя собрать пакет не имея основного класса компонента), а только создаете чанки, сниппеты и так далее и пользуетесь тем, что в момент установки компонента все это автоматически регистрируется в базе?
— но тогда получается, что вам после каждого внесения изменения, после каждой новой строчки или созданного чанка нужно пересобирать компонент? Да я видел в учебнике Василия информацию о том, что систему можно «обмануть» и настроить системные настройки так, чтобы modx смотрел не в core/components а в директорию с разрабатываемым компонентом, но… это справедливо только для первой версии компонента. Я сегодня потратил время на первичное ознакомление с версией которая сейчас лежит в master и у меня возникла такая же проблема как и многих пользователей. После сборки компонента удаляется содержимое директории в которой велась разработка, а сам компонент раскладывается по core и assets.
— максимальное место на котором я туплю – вновь создаваемый компонент ведь никак не пересобирает уже имеющиеся. Он пересобирает только себя. А значит нет никакой возможности повлиять на стандартный чанк или сниппет того или иного компонента. Нужно будет переписывать отдельными файлами все чанки всех используемых на сайте компонентов, если мне нужно внести в них одно слово?
— К примеру мы создали файлик шаблона. Как modExtra позволит прикрепить к нему TV поля? Или придется писать отдельный плагин, чтобы он срабатывал в mgr и прикреплял TV?
— к примеру я создал некую конфигурацию MIGX, привязал ее к TV, TV к шаблону и заполнил данными. Как modExtra сможет передать эту информацию другому разработчику? Ведь и сама конфиграция migx и записанный там json лежит в отдельных таблицах базы данных, а компонент созданный на основе modExtra знает только об одной таблице (ну может и не об одной, но только о тех таблицах, чьи схемы в нем созданы)?
— Ну и в заключение, хочу заметить, что уделил сегодня немного времени modExtra и вот с чем столкнулся. Установил modx 2.7.1 склонировал modExtra, переименовал, запустил сборку и сразу получил установленный компонент. Скачал пакет и установил его на другой сайт, тоже 2,7,1, на том же сервере и… ничего. Файлы не создались, в логе установки куча ошибок. Насколько я понял, все ошибки связаны с тем, что сервер на windows. Поскольку даже путь к установке компонента был сгенерирован с прямым слешами для Linux, а не с обратным как для windows. Ну и плюс странная ошибка xPDOVehicle does not support resolvers of type. Скорее всего эта точка тоже означает linux указатель на текущую директорию.
Но в любом случае, спасибо за желание помочь.
Но вопросов становится все больше и даже как-то совестно вас ими засыпать. Постараюсь кратко.
— у меня нет задачи как у автора этого вопроса вести разработку на двоих, но если бы была, я бы наверное использовал статичные файлы или возможности парсера pdoTools для работы с файлами и плюс дамп базы данных. Мне кажется это намного проще держать в системе контроля версий еще и sql файл, чем городить огород с modExtra. Но скорее всего это изза неумения с ним работать.
— Откуда вы берете информацию о том как работать с modExtra? На гитхабе лежит два варианта этого компонента. В ветке версия 1 более старый и в ветке мастер более новый. По версии один еще можно найти на сайте Василия Наумкина пример разработки. Но по новой версии ничего кроме 10 строчек в файле описании на гитхабе и нет. И ставить это в вину Василию нельзя, он писал его для себя и ему и так все понятно.
— как по мне, компонент созданный при помощи modExtra представляет собой прежде всего некий класс, объект которого мы можем получить и достучаться до его методов. Не могу понять как это можно использовать для разработки всего сайта, а не отдельного функционала. Вы не создаете класс, вернее не пользуетесь им (мне кажется нельзя собрать пакет не имея основного класса компонента), а только создаете чанки, сниппеты и так далее и пользуетесь тем, что в момент установки компонента все это автоматически регистрируется в базе?
— но тогда получается, что вам после каждого внесения изменения, после каждой новой строчки или созданного чанка нужно пересобирать компонент? Да я видел в учебнике Василия информацию о том, что систему можно «обмануть» и настроить системные настройки так, чтобы modx смотрел не в core/components а в директорию с разрабатываемым компонентом, но… это справедливо только для первой версии компонента. Я сегодня потратил время на первичное ознакомление с версией которая сейчас лежит в master и у меня возникла такая же проблема как и многих пользователей. После сборки компонента удаляется содержимое директории в которой велась разработка, а сам компонент раскладывается по core и assets.
— максимальное место на котором я туплю – вновь создаваемый компонент ведь никак не пересобирает уже имеющиеся. Он пересобирает только себя. А значит нет никакой возможности повлиять на стандартный чанк или сниппет того или иного компонента. Нужно будет переписывать отдельными файлами все чанки всех используемых на сайте компонентов, если мне нужно внести в них одно слово?
— К примеру мы создали файлик шаблона. Как modExtra позволит прикрепить к нему TV поля? Или придется писать отдельный плагин, чтобы он срабатывал в mgr и прикреплял TV?
— к примеру я создал некую конфигурацию MIGX, привязал ее к TV, TV к шаблону и заполнил данными. Как modExtra сможет передать эту информацию другому разработчику? Ведь и сама конфиграция migx и записанный там json лежит в отдельных таблицах базы данных, а компонент созданный на основе modExtra знает только об одной таблице (ну может и не об одной, но только о тех таблицах, чьи схемы в нем созданы)?
— Ну и в заключение, хочу заметить, что уделил сегодня немного времени modExtra и вот с чем столкнулся. Установил modx 2.7.1 склонировал modExtra, переименовал, запустил сборку и сразу получил установленный компонент. Скачал пакет и установил его на другой сайт, тоже 2,7,1, на том же сервере и… ничего. Файлы не создались, в логе установки куча ошибок. Насколько я понял, все ошибки связаны с тем, что сервер на windows. Поскольку даже путь к установке компонента был сгенерирован с прямым слешами для Linux, а не с обратным как для windows. Ну и плюс странная ошибка xPDOVehicle does not support resolvers of type. Скорее всего эта точка тоже означает linux указатель на текущую директорию.
Загрузка рабочего пространства пакета...
Рабочее пространство загружено, сейчас устанавливаем пакет...
modAction support is deprecated since version 2.3.0. Support for modAction has been replaced with routing based on a namespace and action name. Please update the extra with the namespace collections to the routing based system.
Skipping vehicle object of class modChunk (data object exists and cannot be upgraded); criteria: Array ( [name] => tpl.sayhello.item )
Skipping vehicle object of class modChunk (data object exists and cannot be upgraded); criteria: Array ( [name] => tpl.sayhello.office )
xPDOVehicle does not support resolvers of type .
xPDOVehicle does not support resolvers of type .
Path specified for package sayhello is not a valid or accessible directory: C:/OSPanel/domains/garant/core/components/sayhello/model/
Успешно установлен пакет sayhello-2.0.0-plНо в любом случае, спасибо за желание помочь.
— С дампом намучаетесь — постоянно мержить изменения в БД, вместо кодинга плюс еще выгружать и импортировать нужно не забывать! Но каждому своё.
— Сначала урок по созданию Sendex от Василия, а потом тупо изучение исходного кода дополнений Василия =)
— Да у компонента есть свой класс, их может быть даже несколько. Какой-то общий функционал всех сниппетов лучше выносить в класс, а в снипетты делать своеобразными обертками над классом/классами. Посмотрите код того же pdoTools или Tickets — там всё как раз так и сделано. То есть — как раз таки нужно пользоваться классом/классами!
— Пересобирать компонент — да, нужно, можно настроить симлинки, в любое время можно пересобрать компонент, файлы не должны удалятся. Попробуйте воспроизвести на modstore.pro, но для начала попробуйте всё-таки старую версию, она попроще!
— Пересобирает свои чанки, сниппеты, плагины итд, но при желании можно залезть и в чужие (но лучше создавать свои), лезть в сниппеты чужого компонента это плохая идея, т.к. при обновлении его он перезапишет ваши изменения.
Я рекомендую не переписывать стандартные чанки того же minishop, а создавать свои дубли — с изменными значениями. Когда minishop был переписан на fenom — это очень помогло подсмотреть как там и сделать так же, а заодно и выучить fenom.
Да и сниппеты чаще всего имеют параметры, в которые передаются чанки, лучше создать свои и использовать их.
— Создать TV и прицепить её к шаблону можно по аналогии как создаются сниппеты, плагины, шаблоны — тыц
— С MIGX я не работал, врят ли буду, тут не подскажу.
— На счет openServer и Windows — подсказать не могу, все время использовал *nix для php разработки. Вполне вероятно, что ошибки связаны с путями.
Попробуйте сначала старую версию modExtra, с новой я не работал, при помощи старой собран minishop2/pdoTools.
— Сначала урок по созданию Sendex от Василия, а потом тупо изучение исходного кода дополнений Василия =)
— Да у компонента есть свой класс, их может быть даже несколько. Какой-то общий функционал всех сниппетов лучше выносить в класс, а в снипетты делать своеобразными обертками над классом/классами. Посмотрите код того же pdoTools или Tickets — там всё как раз так и сделано. То есть — как раз таки нужно пользоваться классом/классами!
— Пересобирать компонент — да, нужно, можно настроить симлинки, в любое время можно пересобрать компонент, файлы не должны удалятся. Попробуйте воспроизвести на modstore.pro, но для начала попробуйте всё-таки старую версию, она попроще!
— Пересобирает свои чанки, сниппеты, плагины итд, но при желании можно залезть и в чужие (но лучше создавать свои), лезть в сниппеты чужого компонента это плохая идея, т.к. при обновлении его он перезапишет ваши изменения.
Я рекомендую не переписывать стандартные чанки того же minishop, а создавать свои дубли — с изменными значениями. Когда minishop был переписан на fenom — это очень помогло подсмотреть как там и сделать так же, а заодно и выучить fenom.
Да и сниппеты чаще всего имеют параметры, в которые передаются чанки, лучше создать свои и использовать их.
— Создать TV и прицепить её к шаблону можно по аналогии как создаются сниппеты, плагины, шаблоны — тыц
— С MIGX я не работал, врят ли буду, тут не подскажу.
— На счет openServer и Windows — подсказать не могу, все время использовал *nix для php разработки. Вполне вероятно, что ошибки связаны с путями.
Попробуйте сначала старую версию modExtra, с новой я не работал, при помощи старой собран minishop2/pdoTools.
Не за что!
Обязательно попробуйте первую версию modExtra, попробуйте потом еще и Gitify, я по причине «исторически так сложилось» сижу на modExtra первой версии и вряд ли уже перейду на вторую или на Gitify.
Так же лучше брать первую версию у Василия, так как у первоисточника есть проблемы
Обязательно попробуйте первую версию modExtra, попробуйте потом еще и Gitify, я по причине «исторически так сложилось» сижу на modExtra первой версии и вряд ли уже перейду на вторую или на Gitify.
Так же лучше брать первую версию у Василия, так как у первоисточника есть проблемы
К примеру мы создали файлик шаблона. Как modExtra позволит прикрепить к нему TV поля? Или придется писать отдельный плагин, чтобы он срабатывал в mgr и прикреплял TV?Позволю себе вмешаться) modExtra это просто набор скриптов, которые пакуют сниппеты, чанки, файлы, системные настройки и т.д. в пакет, и устанавливают всё это в систему при установке. А также там описывается что нужно сделать при удалении пакета. Я сам недавно начал изучать modExtra, и пришёл к тому, что непонимая что делают конкретные скрипты в modExtra, вслепую смысла нет с этим работать. Поэтому, я решил сделать свой аналог, где каждый блок кода мне будет понятен, что он делает и зачем. Ведь для простой задачи потребуется всего несколько строчек, а какая-то специфическая может вообще не укладываться в рамки modExtra, или надо знать что там закомментить, а что дописать. А у вас похоже проблема в том, что вы запускаете скрипты modExtra, которые проделывают непонятные для вас действия, что приводит к непонятному результату) В справке описаны все методы и приведены примеры скриптов, например xPDOGenerator::parseSchema генерирует модель из xml-схемы. А modExtra просто использует эти скрипты так, как было удобно автору. У вас может быть совсем другая задача, и тогда нужно править исходники modExtra, или своё что-то писать.
Я воспринимаю компонент, как некий отдельный самостоятельный кусок кода, который решает конкретную задачу.Я сам ещё пока не специалист в этих делах, но думаю стоит отличать компонент и транспортный пакет. Компоненты хранятся в отдельных папках в core/components и assets/componens, в которых описана модель новых таблиц БД, классы для работы с этими таблицами, которые подключаются к системе. Они имеют своё пространство имён, может быть страничку в админке, логику работы, и т.д… Всё это можно сделать руками и безо всяких modExtra. А транспортный пакет, это по сути набор скриптов, которые позволяют траспортировать компоненты с одного сайта на другой. Но не только компонеты, а всё что угодно — отдельные чанки, сниппеты, системные настройки и т.д. Там можно описать что именно добавить в систему и как при установке. И какие действия проделать при деинсталляции. Т.е. транспортный пакет может вообще не создавать никаких компонентов, а к примеру, тупо прописать в системных настройках почту emailsender и всё. И при удалении ничего не делать вообще. Я так это всё понимаю. Если не прав, поправьте) Хотя с другой стороны пакет это дополнение, а компонент это синоним слову дополнение)) В общем, разница между компонентом, дополнением и пакетом не очевидная…
@Николай Можно использовать pdoTools для файловых элементов, которые уже загружать в гит как обычные файлы.
А базу можно использовать через Gitify, в сети есть много информации и на русском. С его помощью сможете любые изменения регулировать через командную строку.
Эта схема проверена и хорошо работает.
А базу можно использовать через Gitify, в сети есть много информации и на русском. С его помощью сможете любые изменения регулировать через командную строку.
Эта схема проверена и хорошо работает.
Добавлю свои 5 копеек:
1. Gitify — делает полный дамп БД и все на этом, по крайней мере то что касается БД, с файлами работает по другому. Это я сужу из исходников, самого не использовал.
2. Я не вчитывался и поэтому не совсем понял, для чего тебе тут все про компонент говорят, когда речь идет о сайте вцелом, предпологаю, modExtra позволяет хранить все в файликах (не пользовался) — тогда действительно имеет смысл его использовать как писали выше с контролем версий, но часть данных из БД все равно не проконтролируешь (процентов 90 так, но оно все и не нужно обычно).
3. Винда — ЗЛО для разработки! если это не C# или еще что-нить от мелкомягкого. Когда один программист будет отправлять данные в гит (не гитхаб — это разные вещи) из винды, а другой из линукса, то практически на втором пуше получите сообщение о различном CRLF и этот гемморой надо будет лечить на всех файликах. Идеально когда все сидят в одной платформе.
4. В команде где я работаю, мы используем феном и храним все в файликах, для контроля БД была написана эта штука, попробуй может пригодится.
1. Gitify — делает полный дамп БД и все на этом, по крайней мере то что касается БД, с файлами работает по другому. Это я сужу из исходников, самого не использовал.
2. Я не вчитывался и поэтому не совсем понял, для чего тебе тут все про компонент говорят, когда речь идет о сайте вцелом, предпологаю, modExtra позволяет хранить все в файликах (не пользовался) — тогда действительно имеет смысл его использовать как писали выше с контролем версий, но часть данных из БД все равно не проконтролируешь (процентов 90 так, но оно все и не нужно обычно).
3. Винда — ЗЛО для разработки! если это не C# или еще что-нить от мелкомягкого. Когда один программист будет отправлять данные в гит (не гитхаб — это разные вещи) из винды, а другой из линукса, то практически на втором пуше получите сообщение о различном CRLF и этот гемморой надо будет лечить на всех файликах. Идеально когда все сидят в одной платформе.
4. В команде где я работаю, мы используем феном и храним все в файликах, для контроля БД была написана эта штука, попробуй может пригодится.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
Здесь упомянуты:
| Компонент | Текущая версия | Закачки |
| Tickets | 1.13.0-pl от 10.03.2020 | 19 440 |
| pdoTools | 2.13.2-pl от 02.09.2021 | 53 738 |
| miniShop2 | 4.3.0-pl от 02.07.2023 | 25 490 |
| Office | 1.9.5-pl от 01.10.2021 | 6 971 |
| Sendex | 1.1.4-pl от 26.12.2022 | 3 652 |
27 минут назад
Давай попробуем вот так — youtu.be/BbyfFDARgZU
2 часа назад
Спасибо за помощь
22 апреля 2024, 17:19
Я нафигачил просто несколько условий
22 апреля 2024, 12:57
Данная ошибка в логе никак не связана с проверкой доступа по модификатору pasraccess.
Можете написать в ТГ в профиле.
20 апреля 2024, 16:08
Смотрите ошибки в консоли браузера.
20 апреля 2024, 15:47
{set $data = id_ресурса | resource : 'название_тв_migx' | fromJSON}
{foreach $data as $item}
{$item.name}
...
19 апреля 2024, 12:48
Постараюсь в свободное время это сделать, спасибо за предложение
