Estou um pouco atrasado aqui, mas em relação à migração de plugins populares para o núcleo do Discourse, o que se deve fazer se alguém estava usando um fork modificado de um plugin que foi mesclado?
O plugin de integração de chat do Discourse existente não tinha, e ainda não tem, esse recurso.
Há algum tempo, outro membro da minha equipe atualizou nosso servidor Discourse e, ao notar que o plugin agora estava nativamente incluído no Discourse, porque a compilação falhou na atualização, ele simplesmente removeu o clone do meu fork.
E agora percebi que meu recurso desapareceu.
Então, qual é a melhor prática quando uma instalação auto-hospedada estava usando um plugin modificado para restaurar os recursos do plugin modificado?
[quote=“pfaffman, post:2, topic:394718”]A melhor coisa a fazer é escrever um plugin que substitua o plugin.
[/quote]
Escrever um plugin completamente novo? Isso parece excessivo.
[quote=“pfaffman, post:2, topic:394718”]Outra coisa a fazer é, na linha antes de você clonar seu fork, você usa “rm - rf” no plugin mesclado.
[/quote]
Esta é provavelmente a resposta.
[quote=“pfaffman, post:2, topic:394718”]Então faça exatamente isso no seu novo plugin em vez de fazer um fork do principal. Não haverá um hook para fazer isso.
[/quote]
Eu realmente não entendo nada disso. Eu queria a funcionalidade do plugin existente com a adição de poder dizer a ele para enviar posts sinalizados para o cliente de chat, no meu caso o Discord. Você está sugerindo novamente que eu escreva, do zero, um plugin completamente novo que duplique grande parte da funcionalidade do plugin existente e adicione o novo recurso que eu queria? Novamente, parece excessivo.
Em certa medida, você pode substituir/estender a lógica em classes existentes. Esta pode ser uma opção para estender o plugin empacotado. Você escreveria um novo plugin que apenas adiciona a lógica modificada. Usando 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"
# faz algo personalizado
else
# isso chamará a lógica original
super(f00, bar)
end
end
end
end
after_initialize do
SomeClass.prepend(MyOverridingPlugin::SomeClassOverrides)
end
Eu usei este construtor para limitar alguns controladores sob certas condições.
Eu concordo, e descobri que esta é uma das complicações técnicas mais impactantes do “empacotamento de plugins com o núcleo” também. Tínhamos alguns plugins ramificados (forked) e era muito complicado fazê-los funcionar sem remover o plugin empacotado.
Eu não acho que Jay esteja sugerindo isso. Um plugin também pode sobrescrever partes muito específicas de outro plugin.
A melhor abordagem seria convencer a equipe de que seu código vale a pena ser mesclado (merged) no plugin oficial. Isso funcionará se sua modificação for genérica ou flexível o suficiente. Vejo que você já criou um fork e suas alterações/adições estão bem limpas. Talvez a string “Flagged” codificada pudesse estar em um arquivo de tradução e, se você fizer com que :flagged seja false por padrão, você não precisará modificar o manipulador de eventos original com um parâmetro extra, mas fora isso, parece válido. Se eu fosse você, eu o atualizaria, abriria um PR e discutiria isso no tópico do plugin.
Se esse caminho falhar, você pode simplesmente criar um plugin que sobrescreva as três funções que você alterou e adicione o manipulador on(:reviewable_created).
O objetivo dos plugins é que você não precise fazer um fork do Discourse. Não é excessivo, é para isso que os plugins existem.
Não. Seu plugin simplesmente adicionará o novo recurso para enviar posts sinalizados para o Discord e chamará o código existente para fazer isso. Provavelmente são dez linhas de código e não exigirá que você mescle alterações upstream no seu plugin. ED: Como as últimas duas postagens que eu não li antes de responder sugeriram.
