(Кстати, @Heliosurge, думаю, это обсуждалось ранее):
Ещё проще, если вы не хотите устанавливать гем discourse_theme: темы можно загружать в виде zip-файла, и вы можете создать довольно много прямо в интерфейсе администратора.
(Кстати, @Heliosurge, думаю, это обсуждалось ранее):
Ещё проще, если вы не хотите устанавливать гем discourse_theme: темы можно загружать в виде zip-файла, и вы можете создать довольно много прямо в интерфейсе администратора.
Очевидно, что тема теперь полностью ушла в сторону, как это всегда бывает в любых обсуждениях, идущих вразрез с общепринятым мнением. Я даже не планировал обсуждать вопрос использования компонента темы, но всё равно спасибо всем.
Как это пошло не так? Вы задали вопрос, и люди высказали своё мнение. Мне это кажется вполне по теме.
У вас теперь есть вся необходимая информация для настройки того, что вы хотите?
Как это пошло не по тому пути?
Я отчасти согласен с автором темы (OP), что «мнения» начали перерастать в «осмеивание OP за то, чего он хочет».
Я не думаю, что это стоит обсуждать дальше. Поэтому, если никто не предлагает другого решения для этой темы, я считаю, что можем завершить дискуссию здесь.
Я согласен, что в некоторых сообщениях есть излишняя агрессия.
Я упомянул TC (тематический компонент) в связи с вашим предложением добавить кнопку на главную страницу. Это уже было продемонстрировано несколькими компонентами. Если это не вопрос безопасности, то TC — правильный путь.
Хотя мне самому было бы интересно узнать, с какими проблемами вы сталкиваетесь при работе с темами и компонентами тем? Плагины больше подходят для обеспечения безопасности и реализации функций, которые невозможно выполнить в рамках TC, например, изменение работы основных функций. Если вам так удобнее, мы можем обсудить это в дружеском личном сообщении.
Еще одно преимущество TC заключается в том, что вы сможете редактировать свой код непосредственно через веб-интерфейс сайта при необходимости.
Проблема, которую я вижу в подходе с плагинами, заключается в том, что даже официальные плагины, включенные в ядро, все равно используют Git для обновления как самих плагинов, так и Discourse.
Есть ли вообще способ сделать это?
Вы можете использовать поддержку томов в app.yml для монтирования папки на хосте в папку плагинов внутри контейнера.
Вы можете использовать любой удобный способ копирования исходного кода из любого места в директорию discourse/plugins. Если вам не нравится git clone, вы можете использовать rsync или cp -a. Просто скопируйте свой плагин в вашу виртуальную машину любым способом и добавьте команду для копирования таким образом, как это делает git clone.
Вы можете использовать любой удобный способ, чтобы скопировать свой исходный код из того места, где он хранится, в каталог discourse/plugins
Это, безусловно, правильный ответ. Он учитывает исходные условия вопроса. Эта тема не очень хорошо демонстрирует позитивную и поддерживающую атмосферу сообщества.
@Falco @pfaffman Спасибо, ваши ответы разрешили мои сомнения.
Оставляю здесь свою конфигурацию app.yml, на случай, если она будет полезна кому-то, кто пытается загрузить локальные плагины в Discourse с хост-машины.
## Контейнер Docker не сохраняет состояние; все данные хранятся в /shared
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log
- volume:
host: /var/discourse/plugins
guest: /var/plugins
## Плагины находятся здесь
## подробности см. https://meta.discourse.org/t/19157
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
- cp -a /var/plugins/. $home/plugins/
В моей настройке я храню все пользовательские плагины в /var/discourse/plugins на хосте.
Привязанная директория становится доступной внутри контейнера как /var/plugins, и во время хука after_code команда:
cp -a /var/plugins/. $home/plugins/
копирует все привязанные плагины в стандартную директорию плагинов Discourse ($home/plugins, обычно /var/www/discourse/plugins).
Это позволяет управлять плагинами напрямую с хоста, не используя установку плагинов через git или полагаясь на сторонние хостинг-сервисы.
Отлично. Рады, что это сработало для вас!
Вы также можете создать символическую ссылку на плагины вместо их копирования. В этом случае изменения в них могут применяться (по крайней мере, в некоторых случаях, когда не требуется миграция или компиляция ресурсов) путем перезапуска контейнера.
Привет! Просто интересно, как вы справляетесь с миграциями и изменениями в базе данных?
Это не зависит от способа установки плагина. Если плагин присутствует, миграции будут обработаны.
как вы обрабатываете миграции и изменения в БД?
Я пересоздаю контейнер, за исключением некоторых особых случаев. Но вы можете выполнить
rake db:migrate
а также предварительно скомпилировать ассеты. Я не рекомендую это делать, если у вас нет конкретной необходимости и вы хорошо знакомы с Rails.