Per passare, modifica semplicemente la tua configurazione e sostituisci il repository babble esistente con: https://github.com/PuttyTribe/babble.git, quindi ricompila.
Che tempismo! Niente attività per una settimana e poi due soluzioni a 20 minuti di distanza!
Inizialmente avevo scelto quella soluzione, ma ho deciso di optare per una soluzione generica, dato che il parametro non viene utilizzato in nessun caso.
Ho unito la PR di @merefield che risolve il problema qui.
@ti0 Grazie anche per la tua PR. L’argomento viene effettivamente utilizzato Se chiami super senza argomenti (cioè invece di super()), gli argomenti della sottoclasse vengono passati automaticamente a super. Se dai un’occhiata al metodo che viene sovrascritto, vedrai dove viene utilizzato l’argomento: discourse/lib/search.rb at main · discourse/discourse · GitHub.
@ti0@merefield A margine, dovremmo creare una PR nel core di Discourse per aggiungere un hook per inserire nuovi type_filters nella classe Search da un plugin. Sarebbe più performante e stabile rispetto all’applicare una patch al metodo execute. Potrebbe essere un piccolo progetto interessante se riuscissi a convincere il team di Discourse che ne vale la pena come aggiunta.
@justin Sei riuscito a risolvere? Ho riscontrato lo stesso problema fino a quando non ho modificato il modo in cui Babble carica il suo engine nel mio ramo. Sospetto che sia legato a come ambienti diversi gestiscono il metodo di @gdpelican per caricare i file nell’inizializzatore, ovvero:
È difficile individuarlo con precisione. Potrei creare una PR per aggiornare il metodo di caricamento dei file di Babble e vedere se @gdpelican è d’accordo nel passare dal metodo standard dei plugin Discourse, utilizzando load con File.expand_path invece di require con Rails.root.
modifica Ho anche aggiunto Babble a try.thepavilion.io in modo che tu possa testarlo in un ambiente aggiornato ogni 24 ore.
In futuro, se c’è un bug critico in Babble (cioè non funziona affatto) e James non è disponibile, per favore taggate @angus o @merefield e lo risolveremo (o revisioneremo una PR :)).
Intendevo che il parametro non viene utilizzato all’interno del metodo sovrascritto che abbiamo modificato. In base a quanto dici, il mio codice dovrebbe comunque funzionare, perché la chiamata a super passerebbe semplicemente **args, che raccoglie gli argomenti con nome, ed è più stabile se in futuro verranno aggiunti altri parametri. Ha senso? O mi sto perdendo qualcosa?
Ho appena fatto un piccolo test e il tuo approccio sembra funzionare anche per lo scopo immediato (ovvero, preserva la funzionalità di readonly_mode). È un po’ concettualmente strano se ci pensi, dato che teoricamente **args dovrebbe essere impostato prima ancora di chiamare la superclasse. Personalmente (e forse James avrebbe un’opinione diversa) preferisco ancora il metodo più esplicito, poiché stiamo già passando gli argomenti implicitamente semplicemente chiamando super; aggiungere un’ulteriore implicitità con **args sembra diventare un po’ troppo complesso.
Anche se capisco a cosa vuoi arrivare, nel complesso, ritengo che la strada migliore da seguire in queste situazioni sia cercare un modo esplicito per evitare conflitti con il codice principale, piuttosto che affidarsi a metodi impliciti generici. Questo approccio tende a portare ad altri problemi in futuro. Come accennato sopra, preferirei che fossimo in grado di rifattorizzare questo codice aggiungendo un nuovo type_filter nel codice sorgente principale. Sarebbe un ottimo piccolo progetto, a mio avviso.
Qualcuno ha integrato Memberful e poi ha visto il nome reale dei propri utenti apparire sotto il nome dell’account nella chat?
Vorrei nascondere il loro nome reale, se possibile.
Modifica: Ho una soluzione temporanea; chiedo ai membri di utilizzare il loro nome visualizzato come nome completo durante la registrazione, oppure modifico manualmente il loro nome completo in modo che corrisponda al nome visualizzato dopo l’iscrizione.
@angus, al momento potresti essere l’assistente di Babble più disponibile. Quindi ti segnalo una richiesta di aggiornamento del codice, anche se sarei felice che chiunque altro se ne occupasse.
Ho appena aggiornato la nostra versione di Discourse alla 2.6.0beta2 (in particolare questa versione del commit su GitHub) e ora il selettore di emoji non funziona più.
@itsbhanusharma si occupa della nostra installazione di Discourse e la sua prima ipotesi è un problema di compatibilità con l’aggiornamento del selettore di emoji nel nucleo di Discourse.
Problema con il selettore di emoji
Ambiente:
Browser: Firefox o Chrome (ultima build)
Visualizzazione: Desktop, tablet e mobile
Possibilità di riprodurre il problema: 100%
@angus o chiunque altro abbia le competenze tecniche per aiutare con Babble in questi giorni: hai qualche speranza di risolvere i due problemi che ho segnalato tre settimane fa in questa risposta del forum?
Ciao @angus, grazie per il tuo duro lavoro su questo plugin!
Il mio sistema Discourse funziona con un URL di base per il polling personalizzato. Poiché ho appena aggiunto Babble, ho notato che non aggiunge alcun header di controllo degli accessi (CORS), causando il fallimento di diverse richieste.
Potrei eventualmente scrivere una correzione, se mi indichi la direzione giusta nel codice.
Dopo aver installato gli ultimi aggiornamenti di Discourse e l’ultima versione di Babble (qualche giorno fa e di nuovo ieri per verificare se il problema fosse stato risolto), ho riscontrato problemi nell’invio dei messaggi e l’indicatore di lettura rimane bloccato a mostrare che ci sono nuovi messaggi.
Proprio ora, quando non sono riuscito a inviare un messaggio, ho visto una serie di questo errore nella console del browser:
Uncaught Error: No Reason Phrase
jQuery 13
error _application-49dab3118e527975ea48703627a0152cbe26663b7fde8423c667b094d716ae08.js:8967
jQuery 4
_ember_jquery-865569b174cc91f4563f3552f437b32c6eadf9f6c3d49eae02cfe50e5a8c7dfa.js:38573:14
jQuery 13
u self-hosted:1177
error _application-49dab3118e527975ea48703627a0152cbe26663b7fde8423c667b094d716ae08.js:8967
jQuery 4