Как работать с modx двум и более разработчикам одновременно?
Здравствуйте. Планируем работу с проектом, одновременно с товарищем. Встал вопрос, как мы это можем сделать правильно?
Ресурсы, чанки, шаблоны, сниппеты мв MODX можно сделать статичными, и использовать для контроля версий git. Но есть один важный момент, который так просто разрешить не получается… Ресурсы, шаблоны, чанки, сниппеты в любом случае делают запись в бд о себе. Создали ресурс — создалась запись о нем в modx_site_content.Как поступать в данном случае?
Ресурсы, чанки, шаблоны, сниппеты мв MODX можно сделать статичными, и использовать для контроля версий git. Но есть один важный момент, который так просто разрешить не получается… Ресурсы, шаблоны, чанки, сниппеты в любом случае делают запись в бд о себе. Создали ресурс — создалась запись о нем в modx_site_content.Как поступать в данном случае?
Комментарии: 18
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
Держать весь код в статических шаблонах/чанках и не в коем случае в контенте ресурса. (но можно и в нем, но нужно будет подработать код modExtra)
Примеров тоже хватает — Tickets, pdoTools и так далее.
Посмотрите на компонент… ну это и не совсем компонент, в общем на gitmodx хотя и он не решает всех вопросов.
Может я чего-то не знаю о MODX, но мне лично очень не хватает в нем миграций для базы данных, как это сделано в yii2
Присмотритесь к modExtra, может быть это облегчит вам процесс разработки
Автор этого вопроса говорил просто о возможности работать с чанками, шаблонами и сниппетами как с статичными файлами и эта возможность заложена в сам modx без всяких компонентов.
Раз уж зашла речь об modExtra и если у вас есть время — расскажите поподробнее, как используя компонент для создания компонентов разрабатывать сайт. А тем более не одному. Вот правда, у меня в голове не укладывается. Я воспринимаю компонент, как некий отдельный самостоятельный кусок кода, который решает конкретную задачу.
Как например modExtra поможет работать над функционалом того же минишопа? Вот правда, расскажите подробное, реально интересно. Как вести разработку вдвоем? Сайт должен где быть расположен? на удаленном сервере у которого доступ к файлам есть у обоих разработчиков и они оба через свои IDE скачивают файлы сайта и работают с ними? Как modExtra может помочь к примеру с редактированием шаблона почтового сообщения, который отправляется покупателю при оформлении заказа в магазине? Ведь этот шаблон устанавливается вместе с компонентом minishop и представляет из себя только запись в базе? Я задаю вопрос не чтобы показать, что вы не правы, не воспринимайте это в таком ключе — я просто не понимаю как это работает. Я еще понимаю когда Зернов в своем gitmodx написал скрипты, которые при запуске шерстят базу данных, вытаскивают оттуда сниппеты, чанки и так далее и создают из них файлы — это хотя бы мне понятно, а вот как moExtra может помочь разрабатывать новый сайт причем одновременно двумя тремя разработчиками — я не понимаю. Спасибо.
Однако для того, что бы изменения отобразились на сайте — нужно компонент пересобирать, для этого есть `_build/build.transport.php` (но можно на dev машине через `ln -s` связать папку компонента с его же папкой в core/components, что бы не пересобирать каждый раз при изменении статичных сниппетов, чанков, шаблонов), но для системных настроек и ресурсов пересобирать всё-таки придется.
Релизить можно или загрузив zip файл из core/packages (который генерируется вызовом `_build/build.transport.php` ) в установщик пакетов.
Или же на боевом в корне сайта склонировать компонент и запустить билд.
Можно поднять свой репозиторий и обновлять на боевом через обновление компонента.
Минишоп сам написан на базе modExtra. github, только на прошлой версии.
Вот этот шаблон
modExtra позволяет создавать ресурсы, сниппеты, плагины, шаблоны, тв через код и держать код всего вышеперечисленного в файлах. А когда код в файлах, то тут гит в помощь.
Порядок таков:
1. устанавливаем модикс
2. Ставим стандартный набор дополнений через админку
3. клонируем modExtra, переименовываем компонент запустив соответствующий скрипт (удаляем связь с репозиторием, инициализируем свой)
4. Комитим изменения — пушим
Здесь уже в принципе может подключиться несколько разработчиков, но лучше все таки накидать базовый шаблон.
5. Пишем код шаблонов, чанков, сниппетов, плагинов итд, не забываем вписать их название в соответсвующий файл тут
6. git commit / pull / push (merge при необходимости) дальше всё в таком духе
Да, можно разбивать компоненты под решение конкретной задачи — компонент поиска, компонент админки, но в любом случае это не такой компонент как во фронтенде, это скорее как composer package (просто в MODX они называются компонентами).
Подключив minishop2 через $modx->getService() можно получить доступ к функциям/моделям minishop2.
Более детально можно посмотреть на примере Tickets — где используется функционал pdoTools.
Можно программно менять системные настройки, можно даже залезть в настройки minishop2 и поменять там всё. Вконце концов, можно сделать sql запрос в базу.
Или изменить чанки по умолчанию!
Тут уж как захотите, можете выбрать любой способ, что бы выстрелить себе в ногу =)
Шаблоны письма привязаны к статусам, а для статусов есть соответсвующая схема
по этому, сам объект статус можно получить через , а после через поменять нужные поля, а именно или Так в самом минишопе и происходит github
Если что-то не понятно, пишите, постарался раскрыть тему максимально коротко.
Но вопросов становится все больше и даже как-то совестно вас ими засыпать. Постараюсь кратко.
— у меня нет задачи как у автора этого вопроса вести разработку на двоих, но если бы была, я бы наверное использовал статичные файлы или возможности парсера 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 указатель на текущую директорию.
И получается, что созданный на основании modExtra компонент и собранный в пакет, никто не сможет установить на openServer. А кто бы что не говорил, я лично видел что многие из уважаемых посетителей этого сайта им пользуются. Хотя все снова может поясняться исключительно моей криворукостью, ведь собирают же люди пакеты и устанавливаются они у меня.
Но в любом случае, спасибо за желание помочь.
— Сначала урок по созданию Sendex от Василия, а потом тупо изучение исходного кода дополнений Василия =)
— Да у компонента есть свой класс, их может быть даже несколько. Какой-то общий функционал всех сниппетов лучше выносить в класс, а в снипетты делать своеобразными обертками над классом/классами. Посмотрите код того же pdoTools или Tickets — там всё как раз так и сделано. То есть — как раз таки нужно пользоваться классом/классами!
— Пересобирать компонент — да, нужно, можно настроить симлинки, в любое время можно пересобрать компонент, файлы не должны удалятся. Попробуйте воспроизвести на modstore.pro, но для начала попробуйте всё-таки старую версию, она попроще!
— Пересобирает свои чанки, сниппеты, плагины итд, но при желании можно залезть и в чужие (но лучше создавать свои), лезть в сниппеты чужого компонента это плохая идея, т.к. при обновлении его он перезапишет ваши изменения.
Я рекомендую не переписывать стандартные чанки того же minishop, а создавать свои дубли — с изменными значениями. Когда minishop был переписан на fenom — это очень помогло подсмотреть как там и сделать так же, а заодно и выучить fenom.
Да и сниппеты чаще всего имеют параметры, в которые передаются чанки, лучше создать свои и использовать их.
— Создать TV и прицепить её к шаблону можно по аналогии как создаются сниппеты, плагины, шаблоны — тыц
— С MIGX я не работал, врят ли буду, тут не подскажу.
— На счет openServer и Windows — подсказать не могу, все время использовал *nix для php разработки. Вполне вероятно, что ошибки связаны с путями.
Попробуйте сначала старую версию modExtra, с новой я не работал, при помощи старой собран minishop2/pdoTools.
Обязательно попробуйте первую версию modExtra, попробуйте потом еще и Gitify, я по причине «исторически так сложилось» сижу на modExtra первой версии и вряд ли уже перейду на вторую или на Gitify.
Так же лучше брать первую версию у Василия, так как у первоисточника есть проблемы
А базу можно использовать через Gitify, в сети есть много информации и на русском. С его помощью сможете любые изменения регулировать через командную строку.
Эта схема проверена и хорошо работает.
1. Gitify — делает полный дамп БД и все на этом, по крайней мере то что касается БД, с файлами работает по другому. Это я сужу из исходников, самого не использовал.
2. Я не вчитывался и поэтому не совсем понял, для чего тебе тут все про компонент говорят, когда речь идет о сайте вцелом, предпологаю, modExtra позволяет хранить все в файликах (не пользовался) — тогда действительно имеет смысл его использовать как писали выше с контролем версий, но часть данных из БД все равно не проконтролируешь (процентов 90 так, но оно все и не нужно обычно).
3. Винда — ЗЛО для разработки! если это не C# или еще что-нить от мелкомягкого. Когда один программист будет отправлять данные в гит (не гитхаб — это разные вещи) из винды, а другой из линукса, то практически на втором пуше получите сообщение о различном CRLF и этот гемморой надо будет лечить на всех файликах. Идеально когда все сидят в одной платформе.
4. В команде где я работаю, мы используем феном и храним все в файликах, для контроля БД была написана эта штука, попробуй может пригодится.