Sono un po’ in ritardo sulla questione, ma riguardo alla migrazione dei plugin popolari nel core di Discourse, cosa si fa se si utilizzava un fork modificato di un plugin che è stato unito?
Il plugin di integrazione chat di Discourse esistente non aveva, e ancora non ha, questa funzionalità.
Tempo fa, un altro membro del mio team ha aggiornato il nostro server Discourse e, notando che il plugin era ora incluso nativamente con Discourse, poiché la build falliva durante l’aggiornamento, ha semplicemente rimosso il clone del mio fork.
E ora ho notato che la mia funzionalità è scomparsa.
Quindi qual è la best practice quando un’installazione self-hosted utilizzava un plugin modificato per ripristinare le funzionalità del plugin modificato?
Scrivere un plugin completamente nuovo? Sembra eccessivo.
Questa è probabilmente la risposta.
Non capisco affatto questo. Volevo la funzionalità del plugin esistente con l’aggiunta della possibilità di dirgli di inviare i post contrassegnati alla chat client, nel mio caso Discord. Stai di nuovo suggerendo che scriva, da zero, un plugin completamente nuovo che duplichi gran parte della funzionalità del plugin esistente e aggiunga la nuova funzionalità che desideravo? Di nuovo, sembra eccessivo.
In una certa misura è possibile sostituire/estendere la logica nelle classi esistenti. Questa potrebbe essere un’opzione per estendere il plugin raggruppato. Si scriverebbe un nuovo plugin che aggiunge semplicemente la logica modificata. Utilizzando 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"
# fai qualcosa di personalizzato
else
# questo chiamerà la logica originale
super(f00, bar)
end
end
end
end
after_initialize do
SomeClass.prepend(MyOverridingPlugin::SomeClassOverrides)
end
Ho usato questo costruttore per limitare alcuni controller in determinate condizioni.
Capisco, e anche io ho riscontrato che questa è una delle complicazioni tecniche più significative del “raggruppare i plugin con il core”. Avevamo alcuni plugin biforcuti ed era molto complicato farli funzionare senza rimuovere il plugin raggruppato.
Non credo che Jay stia suggerendo questo. Un plugin può anche sovrascrivere parti molto specifiche di un altro plugin.
L’approccio migliore sarebbe convincere il team che il tuo codice merita di essere unito al plugin ufficiale. Funzionerà se la tua modifica è generica o sufficientemente flessibile. Vedo che hai già creato un fork e le tue modifiche/aggiunte sono piuttosto pulite. Forse la stringa “Flagged” codificata potrebbe essere in un file di traduzione e se fai in modo che :flagged sia false per impostazione predefinita, non devi modificare l’handler di evento originale con un parametro aggiuntivo, ma a parte questo, sembra degno. Se fossi in te, lo aggiornerei, aprirei una Pull Request (PR) e ne discuterei nell’argomento del plugin.
Se questa strada fallisce, potresti semplicemente creare un plugin che sovrascriva le tre funzioni che hai modificato e aggiunga l’handler on(:reviewable_created).
Il punto dei plugin è che non devi fare un fork di Discourse. Non è eccessivo, è il motivo per cui esistono i plugin.
No. Il tuo plugin aggiungerà semplicemente la nuova funzionalità per inviare i post segnalati a Discord e richiamerà il codice esistente per farlo. Saranno probabilmente dieci righe di codice e non richiederà di unire le modifiche upstream nel tuo plugin.