(Por cierto, @Heliosurge, creo que esto se mencionó antes):
Es obvio que el tema se ha desviado completamente del rumbo, como siempre ocurre en cualquier hilo que va en contra de la corriente. Ni siquiera tengo la intención de discutir el asunto de usar un componente de tema, pero gracias a todos de todos modos.
¿Cómo se desvió del tema? Preguntaste algo y la gente expresó sus opiniones. ¡A mí me parece completamente en tema!
¿Ya tienes toda la información que necesitas para implementar la configuración que quieras?
Estoy algo de acuerdo con el OP en que las «opiniones» empezaron a deslizarse hacia «ridiculizar al OP por lo que quiere».
No creo que esto necesite seguir debatiéndose. Así que, a menos que alguien tenga otra solución que aportar a este tema, podemos terminar la discusión aquí, en mi opinión.
Estoy de acuerdo en que algunos de los mensajes tienen una agresividad innecesaria.
Solo mencioné un TC en relación con tu propuesta de añadir un botón en la página principal. Esto ya ha sido demostrado por varios componentes. Si no se trata de un problema de seguridad, un TC es la mejor opción.
Aunque, personalmente, me gustaría saber qué problemas tienes con los Temas y los componentes de Temas. Los plugins son más adecuados para la seguridad y para aquellas cosas que no se pueden lograr dentro de un TC, como modificar cómo funcionan las funciones principales. Si te sientes más cómodo, podríamos discutir esto en un mensaje privado amigable.
Otro beneficio del TC es que podrías editar tu código cuando sea necesario directamente desde la interfaz web del sitio.
El problema que veo con la ruta de los plugins es que incluso los plugins oficiales integrados en el núcleo siguen utilizando Git para actualizar los plugins y el propio Discourse.
Puedes usar la compatibilidad de volúmenes en app.yml para montar una carpeta del host en la carpeta de plugins del contenedor.
Puedes usar cualquier método que prefieras para copiar tu código fuente desde donde lo tengas guardado al directorio discourse/plugins. Si no te gusta git clone, puedes usar rsync o cp -a. Simplemente copia tu plugin en tu máquina virtual como quieras e inserta un comando que realice la copia de la misma manera que lo haría git clone.
Sin duda, esta es la respuesta correcta. Respeta los parámetros originales de la pregunta. Este hilo no ha sido muy bueno desde la perspectiva de mostrar una comunidad positiva y solidaria.
@Falco @pfaffman Gracias, sus respuestas resolvieron mis dudas.
Dejo aquí mi configuración de app.yml por si resulta útil para alguien que intente cargar plugins locales en Discourse desde la máquina anfitriona.
## El contenedor Docker es sin estado; todos los datos se almacenan en /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
## Los plugins van aquí
## consulte https://meta.discourse.org/t/19157 para más detalles
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
- cp -a /var/plugins/. $home/plugins/
En mi configuración, mantengo todos los plugins personalizados en /var/discourse/plugins en la máquina anfitriona.
El directorio montado queda disponible dentro del contenedor como /var/plugins, y durante el gancho after_code, el comando:
cp -a /var/plugins/. $home/plugins/
copia todos los plugins montados en el directorio nativo de plugins de Discourse ($home/plugins, normalmente /var/www/discourse/plugins).
Esto permite gestionar los plugins directamente desde la máquina anfitriona sin usar instalación de plugins basada en git ni depender de servicios de alojamiento de terceros.
Genial. ¡Me alegra que te haya funcionado!
También podrías usar enlaces simbólicos a los plugins en lugar de copiarlos. Y si lo hicieras, los cambios en ellos podrían aplicarse (al menos en algunos casos donde no necesites migrar ni compilar activos) reiniciando el contenedor.
Hola, solo por curiosidad, ¿cómo manejan las migraciones y los cambios en la base de datos?
Estos son independientes de la forma en que se instala un plugin. Si el plugin está presente, las migraciones serán gestionadas.
Reconstruyo el contenedor, salvo en circunstancias inusuales. Pero puedes ejecutar
rake db:migrate
Y también precompilar los activos. No lo recomiendo a menos que tengas una necesidad específica y estés familiarizado con Rails.