Il est évident que le sujet a maintenant complètement dévié de son cours, comme cela arrive toujours dans tout fil qui va à l’encontre du courant. Je n’ai même pas l’intention de discuter de la question de l’utilisation d’un composant de thème, mais merci à tous quand même.
Je suis partiellement d’accord avec l’OP que les « opinions » ont glissé vers la « moquerie de l’OP pour ce qu’il souhaite ».
Je ne pense pas que cela doive être débattu davantage. Donc, sauf si quelqu’un a une autre solution à proposer sur ce sujet, nous pouvons mettre fin à la discussion ici, à mon avis.
Je suis d’accord pour dire que certains messages font preuve d’une agressivité inutile.
Je n’ai mentionné un TC que par rapport à ton ajout d’un bouton sur la page d’accueil. Cela a déjà été démontré par plusieurs composants. S’il ne s’agit pas d’un problème de sécurité, le TC est la meilleure option.
En revanche, je serais intéressé de savoir quels problèmes tu rencontres avec les Thèmes et les composants de Thèmes ? Les plugins sont plutôt destinés à la sécurité et aux fonctionnalités qui ne peuvent pas être réalisées dans un TC, comme la modification du comportement des fonctions principales. Si tu préfères, nous pouvons en discuter amicalement par message privé.
Un autre avantage du TC est que tu peux modifier ton code directement via l’interface web du site si nécessaire.
Le problème que je vois avec l’approche par plugins est que même les plugins officiels intégrés au code principal utilisent Git pour mettre à jour les plugins et Discourse lui-même.
Vous pouvez utiliser n’importe quelle méthode pour copier votre code source, où que vous le conserviez, vers le répertoire discourse/plugins. Si vous n’aimez pas git clone, vous pouvez utiliser rsync ou cp -a. Copiez simplement votre plugin dans votre VM comme vous le souhaitez, puis ajoutez une commande qui effectue la copie de la même manière que git clone le ferait.
C’est assurément la bonne réponse ici. Elle respecte les paramètres initiaux de la question. Ce fil n’a pas été très positif pour montrer une communauté bienveillante et solidaire.
Je laisse ici ma configuration app.yml au cas où elle serait utile à quelqu’un qui essaierait de charger des plugins locaux dans Discourse depuis la machine hôte.
## Le conteneur Docker est sans état ; toutes les données sont stockées dans /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
## Les plugins vont ici
## voir https://meta.discourse.org/t/19157 pour plus de détails
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
- cp -a /var/plugins/. $home/plugins/
Dans ma configuration, je conserve tous les plugins personnalisés dans /var/discourse/plugins sur la machine hôte.
Le répertoire monté devient disponible à l’intérieur du conteneur sous /var/plugins, et pendant l’accroche after_code, la commande :
cp -a /var/plugins/. $home/plugins/
copie tous les plugins montés dans le répertoire des plugins natifs de Discourse ($home/plugins, généralement /var/www/discourse/plugins).
Cela permet de gérer les plugins directement depuis la machine hôte sans utiliser l’installation de plugins basée sur Git ou dépendre de services d’hébergement tiers.
Super. Content que cela ait fonctionné pour vous !
Vous pourriez également créer des liens symboliques vers les plugins au lieu de les copier. Et si vous le faisiez, les modifications apportées à ceux-ci pourraient être appliquées (du moins dans certains cas où vous n’avez pas besoin de migrer ou de compiler les assets) en redémarrant le conteneur.