Ce plugin est conçu pour rendre extrêmement simple l’installation de nouveaux plugins sans se connecter au serveur. Il ajoute un écran sous /admin/plugins/procourse-installer qui ressemble à ceci :
À partir de là, vous pouvez entrer l’URL (avec ou sans .git) du dépôt Git du plugin et cliquer sur Installer le plugin. Attendez quelques minutes (environ 5 minutes) que l’installation se termine et vous êtes prêt à partir.
Pour voir tous les plugins que vous avez installés via l’installateur ou pour supprimer un plugin, rendez-vous simplement sur Plugins installés.
Ces plugins restent bien après une reconstruction ou un démarrage (bootstrap) de app ou web_only.
Il n’a pas encore été testé sur les instances multisites et échouera probablement dans ces scénarios, car le plugin nécessite un accès au répertoire /plugins de l’application pour fonctionner.
Les plugins installés s’afficheront bien sous /admin/plugins.
Vous POUVEZ mettre à jour ces plugins normalement depuis /admin/upgrade.
Lors du développement de ce plugin, nous avons détecté une erreur potentielle lors de la suppression de traductions dans les plugins. Cela peut provoquer l’affichage d’une erreur sur le site si l’utilisateur visite une page où la traduction est utilisée. Cela semble se produire même si vous utilisez admin/upgrade pour mettre à jour un plugin spécifique et que celui-ci a supprimé une traduction. Nous travaillons actuellement à trouver une solution à ce problème.
Prérequis :
Vous devez exécuter une installation Docker prise en charge.
I have to admit that I’m conflicted on this one. It would really cool to be in core but if it’s in core, installing plugins will only work on Docker installs and non-multisite installs. That would cause problems for a quite a lot of instances.
Technically, it doesn’t matter. They end up being installed in exactly the same way. This just makes it easier to do.
I assume the challenges associated with getting it to work with multisite are far more complex then getting to set up multisite (which none of my clients have deployed) and I’m saying that from managing over 2 dozen active discourse installations.
It should be easier to include this in the standard app.yml on bootstrap for the standalone installs and not including the same in a multisite/multi container/HA setup.
The main challenge is precompiling assets and such. We’re effectively adding the repo to the /plugins and then running an docker manager upgrade on that specific plugin. That handles the magic side of it.
But in a multisite, you run into issues because you don’t want one instance to be able to make edits for all instances in the multisite.
I think the installer is working fine but I saw this in my error log, not sure if it’s anything but thought I’d might as well bring it up:
NameError (uninitialized class variable @@install_state in ProcourseInstaller::InstallController)
/var/www/discourse/plugins/procourse-installer/app/controllers/procourse_installer/install_controller.rb:4:in `status'
Il y a une vingtaine de jours, j’ai installé ce plugin Procourse, ainsi qu’un autre plugin (j’ai oublié lequel) via l’interface de gestion des plugins.
Quelques jours plus tard, j’ai constaté que mon site devenait extrêmement lent à plusieurs reprises (par exemple, une fois tous les quelques jours). À ces moments-là, même l’ouverture en mode sans échec était tout aussi lente. Au bout de 20 à 30 minutes, la vitesse de mon site revenait à la normale.
Bien que je ne possède pas les compétences nécessaires pour analyser les journaux d’activité, comme la section d’avertissement des logs (ou était-ce Sidekiq ?) contenait à de nombreuses reprises le terme « Procourse », j’ai pensé que cela était lié à ce plugin installé via ou dans le plugin Procourse. J’ai donc désinstallé ce plugin depuis l’interface de Procourse.
Cependant, hier, le site a de nouveau (presque) planté.
J’ai vérifié et j’ai à nouveau trouvé le mot « Procourse » mentionné dans de très nombreux avertissements dans les logs.
Alors aujourd’hui, j’ai pris la décision de désinstaller Procourse également.
