Ho aperto una nuova richiesta Support multiple-reactions per post (Retort style) su reazioni multiple per post, poiché l’altro link è solo per offrire più opzioni di reazione per l’unica reazione che Discourse Reactions consente.
Il plugin Retort non è uno ufficiale, quindi non abbiamo voce in capitolo su quando smetterà di essere attivamente sviluppato e mantenuto dalla community.
Il massimo che possiamo fare è cercare di tenere le persone informate dove possibile in modo che abbiano il tempo di trovare un’alternativa (o almeno avvisare i loro membri per cercare di attenuare la delusione).
Speriamo che queste due richieste di funzionalità vengano adottate nel plugin reactions a un certo punto, ma finora sono ancora nella fase di ‘belle idee’. Ma incrocio le dita. ![]()
Capisco il tuo punto di vista. La realtà è che né io né James abbiamo avuto il tempo di supportare adeguatamente Retort per un po’ di tempo. Noterai che l’ultimo commit nel repository risale a oltre un anno fa (da parte mia il 21 luglio 2021). È fantastico che il plugin abbia continuato a funzionare così a lungo ed è una testimonianza della qualità del lavoro che James ha dedicato alla sua creazione.
Quando dico che non ho tempo, credimi, vorrei averlo! Mi rattrista ogni volta che devo prendere una di queste decisioni (come con il Landing Pages Plugin). Non ho creato Retort, ma ci ho investito tempo. Quando decidi di ritirare qualcosa, è come accettare che qualcosa che hai creato o amato, e con cui hai passato molte ore, giorni e settimane della tua vita, debba morire. So che è stata una decisione difficile per James quando ha sentito di dover passare ad altro.
Al contrario, il Reactions Plugin è mantenuto da Discourse.org, un’organizzazione di oltre 60 persone, su base attiva. È in uso su diversi server utilizzati dai clienti di Discourse.org. Sì, non ha ancora le stesse funzionalità di Retort, ma ti esorto a perseguire lo sviluppo di queste funzionalità come un’opzione. Forse potresti convincere qualcuno come me, o un altro membro di Pavilion, a fare una PR per aggiungere una funzionalità mancante al plugin. Sarebbe un modo intelligente per raggiungere i tuoi obiettivi a lungo termine qui.
C’è sempre Marketplace se vuoi pagare uno sviluppatore per riportarlo in vita nel frattempo. Ma potresti finire per doverlo fare più volte o concordare un contratto di manutenzione.
Immagino che la risposta sia No? Vorrei migrare alle reazioni e provare a trovare quelle più popolari…
Immagino sarebbe possibile dato che saranno memorizzati da qualche parte nel database. Sfortunatamente non ho questo plugin installato sul mio sito di test per verificare i dettagli. Esiste una tabella discourse-retort-retorts o simile?
Ecco come ottenere una stringa separata da | per i retort che stai attualmente utilizzando:
# ./launcher enter app
# rails c
retorts = {}
PostDetail.where(extra: 'retort').each do |p|
retort = p.key.split('|').first
(retorts[retort] ||= []) << p
end
retorts.length
retorts.keys.join('|')
Questo ti darà:
- Per prima cosa il numero di emoji uniche utilizzate nei retort
- Poi i retort in un formato che potresti incollare nella configurazione delle Reazioni, magari dopo averli troncati se sono troppo lunghi per l’interfaccia delle Reazioni.
Per me, ottengo questa stringa:
tada|rage|money_with_wings|face_vomiting|crossed_fingers|grin|vulcan_salute|worried|slightly_smiling_face|dart|+1|relaxed|star_struck|upside_down_face|sweat_drops|astonished|frowning_face|champagne|heavy_plus_sign|bulb|joy|fireworks|zap|smile|fast_forward|grinning|clap|sandwich|heart_eyes|rofl|smiley|wave|ice_cream|sob|mortar_board|open_mouth|pray|grimacing|roll_eyes|arrow_right_hook|brain|wink|cry|nerd_face|slight_smile|confused|ok|thinking|it|heart|smirk|sleepy|eyes|disappointed|question|laughing|man_shrugging|drum|shushing_face|herb|man_facepalming|ear|scream|ok_hand|mantelpiece_clock|smiling_face_with_three_hearts|confetti_ball|sunglasses|nose|pirate_flag|neutral_face|sweat_smile|gift|pensive|dark_sunglasses|exclamation|call_me_hand|green_heart|face_with_monocle|blush|boom|hugs|stuck_out_tongue|zipper_mouth_face|slightly_frowning_face|face_with_raised_eyebrow|exploding_head|information_source|sailboat|fire|gun|carousel_horse|sparkles|hearts|pizza|frowning|drooling_face|-1|100|metal|partying_face|four_leaf_clover|grinning_face_with_smiling_eyes|scream_cat|person_shrugging|deciduous_tree|sunflower|see_no_evil|hear_no_evil|speak_no_evil|微笑|top|face_with_peeking_eye|face_with_hand_over_mouth|stethoscope|money_mouth_face
Se desideri copiare un elenco di retort esistenti in un post su Discourse per discutere quali conservare durante la migrazione alle Reazioni, potresti invece usare questo:
":" + retorts.keys.join(': :') + ':'
Per me, questo è attualmente questo set:
“
:微笑:
”
Per ottenere un elenco puntato di emoji con il numero di istanze di ciascuna:
retorts.keys.sort.each do |k|
puts "* :#{k}: #{retorts[k].length}"
end
Non incollerò l’intero elenco puntato di emoji, ma inizia così:
161
1
1
1
9
2
2
23
3
Se vuoi vedere ogni post esistente per ogni emoji:
retorts.keys.sort.each do |k|
puts "* :#{k}: #{retorts[k].length}"
retorts[k].each do |r|
p = Post.find_by(id: r.post_id)
next if p.nil?
puts " * #{p.full_url}"
end
end
È troppo lungo per incollarlo qui!
Quello che non so è come migrare tutti — o alcuni — di quei retort alle reazioni. Non c’è menzione di retort nel plugin delle reazioni, quindi non lo fa automaticamente. Ho 927 reazioni con 116 emoji uniche che vorrei migrare alle reazioni.
Mi aspetto che dovrò affrontare questo problema a un certo punto, preferibilmente prima che Retort smetta semplicemente di funzionare; se implementerò la migrazione, ho intenzione di documentarla qui. Ma almeno sapere cosa hai potrebbe aiutarti.
Nella scrittura di codice sperimentale per migrare Retort a Reactions, ho scoperto che i Retort non vengono aggiornati quando i nomi utente vengono modificati.
Penso che questo non sarà vero con Reactions perché PostActions si collega ai record utente effettivi, piuttosto che registrare i nomi utente in un blob JSON in PostDetail.
In generale, se qualcuno decidesse di adottare e mantenere Retort, dovrebbe considerare la migrazione da PostDetail a PostActions seguendo come è stato fatto Reactions.
Allo stesso modo, non riconosce quando i post vengono eliminati.
Il mio https://meta.discourse.org/t/script-framework-to-rearrange-topics-and-categories/241964?u=mcdanlj ha una nuova funzione che va un po’ oltre la riorganizzazione di argomenti e categorie!
Di solito ricordo di avvisare che non conosco ruby o ruby on rails, quindi il mio codice è più idiosincratico che idiomatico. Ma finora sembra funzionare nei miei test!
def migrateRetortToReactions(allowed:, likes: nil, emojimap: nil)
# migra dove possibile senza sovrascrivere alcun like esistente
# questa è una conversione necessariamente con perdita di dati, ed è coerente solo per l'ordine di PostDetail
# non si tenta di preferire un record PostDetail rispetto a un altro
emojimap = {} if emojimap.nil?
allowed.each do |a|
emojimap[a] = a
end
retort = "retort".freeze
emojiType = "emoji".freeze
usermap = Hash.new { |hash, username| hash[username] = User.find_by_username(username) }
postmap = Hash.new { |hash, post_id| hash[post_id] = Post.find(post_id) }
likeType = PostActionType.where(name_key: "like").pluck(:id).first
PostDetail.where(extra: retort).each do |pd|
begin
p = postmap[pd.post_id]
rescue
# PostDetail non coerente rispetto all'eliminazione
$stderr.puts sprintf("Impossibile trovare il post per %d: %s / %s", pd.post_id, pd.key, pd.value)
next
end
emoji = pd.key.split('|').first
users = JSON.parse(pd.value)
users.each do |user|
u = usermap[user]
next if u.nil? # il nome utente è cambiato o un utente eliminato lascia Retort orfani
if likes.include?(emoji)
pa = PostAction.where(post_id: p.id, user_id: u.id, post_action_type_id: likeType).first
next unless pa.nil?
$stderr.puts sprintf("Aggiunta di like per Retort %s per l'utente %s in %s", emoji, user, p.url)
PostActionCreator.create(u, p, :like, created_at: pd.created_at, silent: true)
elsif emojimap.has_key?(emoji)
e = emojimap[emoji]
r = DiscourseReactions::Reaction.where(post_id: p.id, reaction_type: emojiType, reaction_value: e).first_or_create
ru = DiscourseReactions::ReactionUser.where(user_id: u.id, post_id: p.id).first
next unless ru.nil?
$stderr.puts sprintf("Conversione di Retort %s in Reaction %s per l'utente %s in %s", emoji, e, user, p.url)
DiscourseReactions::ReactionUser.create(reaction_id: r.id, user_id: u.id, post_id: p.id, created_at: pd.created_at)
else
$stderr.puts sprintf("Ignorata Retort non mappata %s per l'utente %s in %s", emoji, user, p.url)
end
end
end
end
Utilizzo il framework che ho costruito per fornire una configurazione yaml che appare così:
- migrateRetortToReactions:
allowed:
- rofl
- astonished
- crossed_fingers
- sob
- thinking
- grimacing
- frowning_face
- drum
likes:
- dart
- +1
- joy
- "100"
- brain
- heart
- heart_eyes
- hearts
emojimap:
rage: sob
four_leaf_clover: crossed_fingers
cry: sob
open_mouth: astonished
scream: frowning_face
Tuttavia, potresti semplicemente impacchettare il tutto in uno script ruby, inclusa la trasformazione di quegli argomenti in codice ruby letterale, inserirlo nella directory script/ ed eseguirlo.
Ciao ragazzi, come discusso nell’argomento sopra, ho già scritto una funzionalità di migrazione da Retort a Reactions, inclusa un’interfaccia utente amministrativa.
Affinché sia pronto per la produzione, i manutentori di Reactions dovranno apportare una piccola modifica per migliorare l’astrazione del codice nel plugin Reactions.
Il supporto per una migrazione a livello di produzione tra due plugin come questo richiede un’assicurazione di qualità significativa, altrimenti problemi come questo possono verificarsi facilmente.
Mi dispiace! Avevo perso quei post e avevo guardato solo nel ramo principale. È un thread lungo…
Sono d’accordo. L’ho completamente aggirato. È più di un semplice ReactionManager.toggle! però, deve davvero passare attraverso created_at, non credi?
Il passaggio a Reactions cambia davvero la semantica di “mi piace” perché non puoi tornare indietro quando qualcuno modifica il suo post. Non avrei fatto la stessa scelta di implementazione. ![]()
In ogni caso, quello che voglio fare è guidarlo da uno script e non ho alcun interesse a guidarlo da un’interfaccia utente. Non sono il pubblico di destinazione per l’interfaccia utente, quindi forse il mio hack disponibile non fa male.
Certamente, non intendevo scoraggiarti dallo scriverlo per i tuoi scopi, ma non consiglierei ad altri siti di utilizzarlo a meno che non abbiano familiarità con il codice e la struttura dei dati.
La conclusione è che il plugin Reactions non è attualmente scritto in un modo che favorisca una migrazione stabile che funzioni in modo affidabile in diversi ambienti.
Se qualcuno desidera migrare da Retort a Reactions, Pavilion si occupa di queste migrazioni manualmente su base contrattuale (inviare un’e-mail a contact@pavilion.tech o inviare un messaggio privato). Se il plugin Reactions verrà aggiornato per consentire migrazioni generalizzate, completeremo il lavoro di migrazione per renderlo liberamente disponibile.
Aha. Questo risponde ad alcune domande che avevo. È difficile dare un senso a 450 post in 7 anni.
Quindi, capisco che ciò che “deve” accadere (chiunque è il benvenuto a fornire la propria definizione di “deve”) è estendere in qualche modo Reactions in modo che possa gestire in modo più pulito la migrazione dei dati verso di esso e fornire anche funzionalità che gli mancano?
Quanto è grande un lavoro in qualche stima selvaggia di ore o dollari?
Questo è ancora ampiamente accurato.

Se l’opportunità per una PR è realisticamente presente, probabilmente lo farei per una buona bottiglia di rosso. È venerdì sera, dopotutto.
Ma, più seriamente, di cosa stiamo parlando qui è un refactor minore del plugin Reactions ReactionManager. Quel tipo di lavoro di solito non viene accettato tramite PR. Ci dovrebbe essere il consenso dei manutentori di Reactions.
Penso che vorresti anche assicurarti che i “like” siano silent e che created_at venga gestito per i “like” e le reazioni; altrimenti gli utenti verranno sommersi da notifiche a causa della migrazione. (Ho visto questo sul mio sito di test per il mio accesso.)
Per qualche motivo, anche con created_by gestito, attivo ancora il limite massimo di “out of love” per i “like”, e non ho indagato ulteriormente, perché mi sono liberato di tutte le altre notifiche.
@joffreyjaffeux c’è qualche motivo per non esporre la funzionalità necessaria per una migrazione pulita?
Mi sono appena trasferito a Reactions (perché immagino sia ufficiale e tutto il resto…) ma odierei perdere tutti i dati precedenti di retort.
Mi dispiace, ma al momento non è possibile fornire una migrazione stabile per i motivi sopra menzionati.
Beh, è successo, non sono riuscito ad aggiornare discourse a causa del plugin retort.
Questo è l’errore di migrazione del database che ho ricevuto:
impossibile creare l'indice univoco "index_post_details_on_post_id_and_key_ccnew_ccnew" DETAIL: La chiave (post_id, key)=(30297, +1|retort) è duplicata.
Ho usato questo script come base per il mio codice di migrazione. Ecco cosa ho fatto.
- Per far funzionare di nuovo discourse, ho dovuto sovrascrivere la “versione” nel file template .yml con un commit di circa due settimane fa nel repository di discourse
- Ricostruisci con il plugin delle reazioni aggiunto per riportare il sito online
- Ho configurato il plugin delle reazioni con lo stesso set di reazioni di retort. Non uso alcuna reazione che possa essere interpretata come un like
- Ho usato lo script di @mcdanlj leggermente modificato con i seguenti passaggi (poiché volevo migrare tutti i retort e avevo già una mappatura 1-a-1 tra retort e reazioni):
- Esegui
./launcher enter app - Esegui
rails c - Incolla quanto segue (sembra che la console rails ripeta il codice con modifiche errate alle righe, ho aggiunto doppie interruzioni di riga ma ciò non ha realmente modificato l’output, ma se qualcuno ottiene un errore di sintassi con il codice seguente, aggiungi una riga extra dopo ogni riga):
def migrateRetortToReactions()
retort = "retort".freeze
emojiType = "emoji".freeze
usermap = Hash.new { |hash, username| hash[username] = User.find_by_username(username) }
postmap = Hash.new { |hash, post_id| hash[post_id] = Post.find(post_id) }
likeType = PostActionType.where(name_key: "like").pluck(:id).first
PostDetail.where(extra: retort).each do |pd|
begin
p = postmap[pd.post_id]
rescue
# PostDetail non coerente rispetto all'eliminazione
$stderr.puts sprintf("Impossibile trovare il post per %d: %s / %s", pd.post_id, pd.key, pd.value)
next
end
emoji = pd.key.split('|').first
users = JSON.parse(pd.value)
users.each do |user|
u = usermap[user]
next if u.nil? # nome utente modificato o utente eliminato lascia Retort orfani
e = emoji
r = DiscourseReactions::Reaction.where(post_id: p.id, reaction_type: emojiType, reaction_value: e).first_or_create
ru = DiscourseReactions::ReactionUser.where(user_id: u.id, post_id: p.id).first
next unless ru.nil?
$stderr.puts sprintf("Conversione di Retort %s in Reaction %s per l'utente %s in %s", emoji, e, user, p.url)
DiscourseReactions::ReactionUser.create(reaction_id: r.id, user_id: u.id, post_id: p.id, created_at: pd.created_at)
end
end
end
- A questo punto ho fatto un backup del sito per sicurezza
- Quindi esegui
migrateRetortToReactionsche dovrebbe richiedere un po’ di tempo. Per me non ho visto né riscontrato problemi. Dopo l’esecuzione la console sembra mostrare tutti gli oggetti modificati, quindi premiqper uscire - Ora sul sito i dati dovrebbero essere migrati correttamente
- Come ultimo passaggio devi eseguire:
PostDetail.where(extra: "retort").destroy_allche eliminerà i dati di retort - Ora sono stato in grado di ricostruire il mio sito con l’ultima versione di discourse e senza il plugin retort
Quindi, tutto sommato, non è stato così difficile da migrare, ma è stato piuttosto spaventoso, e come discusso in precedenza, questo sovrascrive i like con le reazioni sui post che avevano sia like che retort dallo stesso utente.
Concordo! Reações múltiplas e a possibilidade de escolher entre todas as reações são essenciais para a minha comunidade. As pessoas passaram a esperar isso do mundo dos servidores de chat do Discord, então reverter essa funcionalidade na minha comunidade é inaceitável. Felizmente, este plugin ainda não quebrou para mim, mas estou resignado à realidade de que estou lentamente contando os dias. Espero que a solução desejada venha da comunidade de terceiros ou oficialmente do Discourse nos próximos seis meses. Caso contrário, serei forçado a manter meu fórum em uma versão de build mais antiga indefinidamente se acabar sendo que este plugin quebra atualizações futuras.
Con le nuove modifiche a Ember 5, Retort è ora morto. Sto esplorando opzioni per preservarne la funzionalità.