É óbvio que o tópico agora desviou completamente do rumo, como sempre acontece em qualquer discussão que vai contra a corrente. Nem mesmo pretendo discutir a questão do uso de um componente de tema, mas agradeço a todos de qualquer forma.
Concordo em parte com o autor do tópico de que as “opiniões” começaram a escorregar para o “ridicularizar o OP pelo que ele quer”.
Acho que isto não precisa de ser debatido mais. Por isso, a menos que alguém tenha outra solução a contribuir para este tópico, podemos dar por encerrada a discussão, na minha opinião.
Concordo que algumas das postagens têm uma agressividade desnecessária.
Mencionei apenas um TC em relação à sua adição de um botão na página inicial. Isso já foi demonstrado por vários componentes. Se não for um problema de segurança, o TC é o caminho a seguir.
Embora eu mesmo esteja interessado em saber quais problemas você tem com os Temas e componentes de Temas? Os plugins são mais para segurança e coisas que não podem ser feitas dentro de um TC, como alterar como as funções principais são executadas. Se você estiver mais confortável, podemos discutir isso em uma mensagem privada amigável.
Outro benefício do TC é que você pode editar seu código quando necessário dentro da interface web do site.
O problema que vejo com a rota do plugin é que até mesmo os plugins oficiais mesclados no núcleo ainda usam Git para atualizar os plugins e o próprio discourse.
Você pode usar qualquer método para copiar seu código-fonte de onde quer que ele esteja armazenado para o diretório discourse/plugins. Se você não gosta de git clone, pode usar rsync ou cp -a. Basta copiar seu plugin para sua VM da maneira que preferir e inserir um comando para copiá-lo da forma que o git clone faria.
Esta é, com certeza, a resposta correta aqui. Ela respeita os parâmetros originais da pergunta. Este não tem sido um ótimo tópico do ponto de vista de mostrar uma comunidade positiva e solidária.
@Falco@pfaffman Obrigado, as suas respostas tiraram as minhas dúvidas.
Deixo aqui a minha configuração do app.yml caso seja útil para alguém que esteja a tentar carregar plugins locais para o Discourse a partir da máquina anfitriã.
## O contentor Docker é sem estado; todos os dados são armazenados em /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
## Os plugins vão aqui
## consulte https://meta.discourse.org/t/19157 para mais detalhes
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
- cp -a /var/plugins/. $home/plugins/
Na minha configuração, mantenho todos os plugins personalizados em /var/discourse/plugins no anfitrião.
O diretório montado fica disponível dentro do contentor como /var/plugins e, durante o gancho after_code, o comando:
cp -a /var/plugins/. $home/plugins/
copia todos os plugins montados para o diretório nativo de plugins do Discourse ($home/plugins, tipicamente /var/www/discourse/plugins).
Isto torna possível gerir plugins diretamente a partir do anfitrião sem utilizar a instalação de plugins baseada em git ou depender de serviços de alojamento de terceiros.
Você também poderia criar links simbólicos para os plugins em vez de copiá-los. E, se fizesse isso, as alterações neles poderiam ser aplicadas (pelo menos em alguns casos onde você não precisa migrar ou compilar ativos) reiniciando o contêiner.