Plugins de base où une version dérivée (fork) d'un plugin fusionné était utilisée

Dev
1

Un peu en retard sur le sujet, mais concernant la migration des plugins populaires vers le cœur de Discourse, que faire si l’on utilisait une version modifiée d’un plugin qui a été fusionné ?

Pour référence Set up Discord notifications with the discourse-chat-integration plugin - #71 by skatefriday J’avais ajouté la possibilité de transmettre les messages signalés vers Discord car il est important que les modérateurs reçoivent immédiatement une notification qu’un utilisateur a signalé un message et que Discord est le support de communication à la latence la plus faible pour cela.

Le plugin d’intégration de chat Discourse existant ne possédait pas, et ne possède toujours pas, cette fonctionnalité.

Il y a quelque temps, un autre membre de mon équipe a mis à jour notre serveur Discourse et, après avoir remarqué que le plugin était désormais intégré nativement à Discourse, car la construction échouait lors de la mise à jour, il a simplement supprimé le clone de mon fork.

Et maintenant, j’ai remarqué que ma fonctionnalité a disparu.

Quelle est donc la meilleure pratique lorsqu’une installation auto-hébergée utilisait un plugin modifié pour restaurer les fonctionnalités du plugin modifié ?

4 « J'aime »
2

La meilleure chose à faire est d’écrire un plugin qui surcharge le plugin.

Une autre chose à faire est, sur la ligne avant de cloner votre fork, de faire un « rm -rf » du plugin fusionné.

Alors faites exactement cela dans votre nouveau plugin plutôt que de forker celui principal. Il devrait y avoir un hook pour faire cela.

3 « J'aime »
3

[quote=“pfaffman, post:2, topic:394718”]La meilleure chose à faire est d’écrire un plugin qui surcharge le plugin.

[/quote]
Écrire un tout nouveau plugin ? Cela semble excessif.

[quote=“pfaffman, post:2, topic:394718”]Une autre chose à faire est que, sur la ligne avant de cloner votre fork, vous « rm - rf » le plugin fusionné.

[/quote]
C’est probablement la réponse.

[quote=“pfaffman, post:2, topic:394718”]Alors faites simplement cela dans votre nouveau plugin plutôt que de forker celui principal. Il n’y aura pas de crochet pour faire cela.

[/quote]
Je ne comprends vraiment pas cela du tout. Je voulais la fonctionnalité du plugin existant avec l’ajout de pouvoir lui dire de transmettre les messages signalés vers le client de chat, dans mon cas Discord. Me suggérez-vous à nouveau d’écrire, à partir de zéro, un tout nouveau plugin qui reproduit une grande partie de la fonctionnalité du plugin existant et ajoute la nouvelle fonctionnalité que je voulais ? Encore une fois, cela semble excessif.

4

Dans une certaine mesure, vous pouvez remplacer/étendre la logique dans les classes existantes. Cela pourrait être une option pour étendre le plugin groupé. Vous écririez un nouveau plugin qui ajoute simplement la logique modifiée. En utilisant le module prepend.

enabled_site_setting :myoverridingplugin_enabled

module ::MyOverridingPlugin
	PLUGIN_NAME = "my-overriding-plugin"

	class Engine < ::Rails::Engine
		engine_name MyOverridingPlugin::PLUGIN_NAME
		isolate_namespace MyOverridingPlugin
	end

	module SomeClassOverrides
		def overriding_method(foo, bar)
			if foo == "something"
				# faire quelque chose de personnalisé
			else
				# cela appellera la logique originale
				super(f00, bar)
			end
		end
	end
end

after_initialize do
	SomeClass.prepend(MyOverridingPlugin::SomeClassOverrides)
end

J’ai utilisé ce constructeur pour limiter certains contrôleurs dans des conditions données.

1 « J'aime »
5

Je suis d’accord avec vous, et j’ai constaté que c’était l’une des complications techniques les plus importantes du « regroupement des plugins avec le cœur ». Nous avions quelques plugins bifurqués et il était très compliqué de les faire fonctionner sans supprimer le plugin regroupé.

Je ne pense pas que Jay suggère cela. Un plugin peut également remplacer des parties très spécifiques d’un autre plugin.

La meilleure approche serait de convaincre l’équipe que votre code mérite d’être fusionné dans le plugin officiel. Cela fonctionnera si votre modification est suffisamment générique ou flexible. Je vois que vous avez déjà fait une bifurcation et que vos modifications/ajouts sont assez propres. Peut-être que la chaîne de caractères codée en dur “Flagged” pourrait se trouver dans un fichier de traduction et si vous faites en sorte que :flagged soit faux par défaut, vous n’avez pas à modifier le gestionnaire d’événements d’origine avec un paramètre supplémentaire mais à part cela, cela semble valable. Si j’étais vous, je le mettrais à jour, j’ouvrirais une PR et j’en discuterais dans le sujet du plugin.

Si cette voie échoue, vous pourriez simplement créer un plugin qui remplace les trois fonctions que vous avez modifiées et ajoute le gestionnaire on(:reviewable_created).

2 « J'aime »
6

L’intérêt des plugins est que vous n’avez pas à forker Discourse. Ce n’est pas excessif, c’est la raison d’être des plugins.

Non. Votre plugin ajoutera simplement la nouvelle fonctionnalité pour envoyer les messages signalés sur Discord, et appellera le code existant pour le faire. C’est probablement dix lignes de code et ne vous obligera pas à fusionner les changements en amont dans votre plugin. EDIT : Comme les deux derniers messages que je n’ai pas lus avant de répondre l’ont suggéré. :person_shrugging: