Финансовая поддержка VPS, бесплатные дополнения и docs Донаты оплачивают сервер и двигают бесплатные дополнения MODX и документацию. Поддержать

Всего 126 129 комментариев

Наумов Алексей
Наумов Алексей
$_modx->resource['tv-name']
Или в чанках где-то внутри pdoResources
$_pls['tv-name']
но лучше избегать дефис в названиях TV. Дефис нельзя использовать в названиях переменных в php, из-за этого возникают трудности в Fenom. Замените на подчеркивание.
Андрей Степаненко
Андрей Степаненко
С расположение пакетов это одна из проблем которую на мой взгляд нормально не решишь, всегда на измене что то то можешь затереть
По этому и придумал схему с :ro который защищает файл в Extras
Хоть сколько раз переустанавливай свой пакет
Если нужен собранный пакет то он будет в target в сборке с docker
Наумов Алексей
Наумов Алексей
Дима Касаткин
Дима Касаткин
Это путь от корня на сервере?
Вот я
форкнул один из пакетов, хочу подправить код и собрать новую версию для теста. Предполагается что я всё это заливаю в корень установленного MODX. Папка _build сразу содержит установочные скрипты, из-за чего я не могу использовать готовую установку MODX, где поддерживаю другие пакеты.

Вот этот путь /Extras/ModxExtraName/ откуда берется? Корень / перед /Extras/ где смонтирован? У меня это примерно так на хостинге /home/user/data/www/modx.test.ru/ и вот отсюда уже идут ...modx.test.ru/_build/ и так далее.
Андрей Степаненко
Андрей Степаненко
windows — страшная тема для docker) кто смог настроить docker под window, респект

Папка с build в 3 категории попадает

volumes:
    - "./Extras:/var/www/html/Extras"
    # Package
    - "./Extras/${PACKAGE_NAME}/core/components/${PACKAGE_NAME}:/var/www/html/core/components/${PACKAGE_NAME}:ro"
    - "./Extras/${PACKAGE_NAME}/assets/components/${PACKAGE_NAME}:/var/www/html/public/assets/components/${PACKAGE_NAME}:ro"
Директория для хранения самого пакета
/var/www/html/Extras

В нее затем уже с помощью команд обращаешься
#######################
# Extras package
#######################
package-build:
	docker compose exec app bash -c "export PACKAGE_DEPLOY=False && php Extras/${PACKAGE_NAME}/_build/build.php"

package-install:
	docker compose exec app bash -c "php ./docker/app/scripts/checking-add-ons.php"
	@make cache-clear

package-build-deploy:
	docker compose exec app bash -c "export PACKAGE_DEPLOY=True && php Extras/${PACKAGE_NAME}/_build/build.php"

package-target-clear:
	docker compose exec app bash -c 'rm -rf target/*'

package-deploy:
	@make package-target-clear
	@make package-build
	@make package-build-deploy

Volume core и assets

# Package
    - "./Extras/${PACKAGE_NAME}/core/components/${PACKAGE_NAME}:/var/www/html/core/components/${PACKAGE_NAME}:ro"
    - "./Extras/${PACKAGE_NAME}/assets/components/${PACKAGE_NAME}:/var/www/html/public/assets/components/${PACKAGE_NAME}:ro"
Эти volume прокидываются чтобы можно было редактировать код из Extras/${PACKAGE_NAME}
Wassi Wassinen
Wassi Wassinen
В таком формате для одной формы будет работать (если вставить в чанк формы)?

<script>
document.addEventListener('fetchit:success', (e) => {
  const { form } = e.detail;

  if (form.getAttribute('id') === 'main_form') {
      
    yaCounter96827878.reachGoal('course_main_form');

    
  }
});  
</script>
Дима Касаткин
Дима Касаткин
А вообще, есть предложение ко всем, кто собирает MODX-пакеты!

Давайте в билдерах в папку ./_build/ вкладывать ещё подпапку с названием пакета
Сейчас структура папок:
./_build/build.config.php
./_build/…
./core/components/ModxExtraName/…
./assets/components/ModxExtraName/…

Предлагаю делать так:
./_build/ModxExtraName/build.config.php
./_build/ModxExtraName/…
./core/components/ModxExtraName/…
./assets/components/ModxExtraName/…

Это позволит не вычищать каждый раз _build перезаливкой другого пакета. Ведь организовать подпапку — это логично и красиво.

И даже не обязательно использовать
modx-build-environment-gui, он просто сканирует папку _build, парсит версии для сборки и даёт список ссылок (гордо именуемый тем самым GUI), чтобы поменьше клавиатуру пальцами полировать :) но сам ничего больше и не делает. Даже ссылку на скачивание собранного транспортника уже выдаёт билдер самого пакета, если поддерживает согласно инструкции…

В общем так или иначе, круто что наконец мы добрались улучшать Developer Expierence! Чем проще создавать и поддерживать компоненты, тем лучше для экосистемы, и для сайтов, которые на поддержке, и для наших нервов ;)

P.S. Может перенести в заметки и раскрыть тему, есть желающие? Ставьте лайк, если интересно :)
Дима Касаткин
Дима Касаткин
Так и я не сравниваю, ты ведь в своём решении в Докер-ом предлагаешь вообще типа в режиме одноразовой копии запускать движок MODX для работы с пакетом, а файлы во внешней среде хранить как я понял. Это здорово! Но одно другому не мешает =)

Ну это к слову… А теперь к твоей теме: я сам на windows работаю, и докер локально не использую, но изучаю тему и поюзываю на серверах (как минимум потому что иногда другого не предлагается...). И вот читаю конфиги твои и есть вопрос: а почему ты не монтируешь в локальную папку директорию _build? Тебе же не только правки в код вносить, но и собрать надо пакет, или другой у тебя workflow?