Prova a riprodurre il problema utilizzando la versione mobile di Google Chrome o la versione mobile di Firefox (o qualsiasi altro browser mobile).
2 Mi Piace
La pulizia della cache ha risolto il problema! Grazie! EDIT: O forse no. 
1 Mi Piace
Scusa per la negligenza qui, sono stato impegnato con altri lavori. Presto darò un’occhiata di nuovo a questo plugin.
@DaleKramer @Hifihedgehog Se avete un problema urgente, fatemelo sapere e lo esaminerò questa settimana.
4 Mi Piace
In realtà, dopo aver aggiornato il server, il problema è ripresentato. Si verifica anche su tutti i miei browser per dispositivi mobili:
Ho ripristinato i messaggi rapidi su thepavilion.io. Riesci a riprodurre il problema lì?
1 Mi Piace
Forse potresti dare un’occhiata a questo problema che ho avuto e che sembrava indicare questo plugin come responsabile…
Nell’ultima versione i messaggi rapidi non funzionano: su ogni messaggio ricevo questo messaggio:
Mi dispiace, non puoi creare un messaggio privato in un argomento esistente.
Vero, sto ricevendo lo stesso errore: Spiacenti, non puoi creare un messaggio privato in un argomento esistente.
1 Mi Piace
Sto ricevendo lo stesso errore “impossibile creare un MP”. Potrebbe essere a causa di questo commit?
Grazie per le segnalazioni. Ci darò un’occhiata il prima possibile.
1 Mi Piace
Questo era il problema. La soluzione consiste nel sovrascrivere la funzione valid? senza le modifiche introdotte in questo commit. Quindi, in plugin.rb o in un file simile, esegui:
require_dependency ‘post_creator’
class ::PostCreator
def valid?
riscrivila qui rimuovendo 4 righe
potrei fare una PR per questo se domani nessuno lo fa, dato che ci ho lavorato tutta la mattina
4 Mi Piace
Sarebbe molto apprezzato. Al momento le cose sono piuttosto caotiche 
. Grazie!
1 Mi Piace
1 Mi Piace
Anche se mi farebbe molto piacere avere una soluzione il prima possibile, sono anche preoccupato per la sua utilizzabilità a lungo termine. E se la logica all’interno dell’implementazione principale di quella funzione cambiasse?
1 Mi Piace
Sì, sono d’accordo, non è il modo giusto di farlo… specialmente con un metodo valid?, è solo una questione di tempo prima che si verifichi una vulnerabilità di sicurezza… e non vogliamo che Discourse diventi il prossimo WordPress sotto questo aspetto… ma quale potrebbe essere una buona alternativa?
Ultimamente ho avuto difficoltà anche io con cose del genere, dove c’è un metodo lungo pieno di controlli e voglio aggirare un singolo controllo, proprio nel mezzo del metodo.
Non puoi semplicemente verificare se :create_pm_on_existing_topic è stato l’unico errore, perché il codice restituisce immediatamente quando viene impostato, e potrebbe aver fallito anche un altro controllo dopo quello.
Almeno potresti premettere questo modulo, poi verificare se si tratta di uno scenario di messaggio rapido nel nuovo metodo valid?. Se lo è, esegui il codice di validazione modificato, ma se non riguarda un messaggio rapido, fai semplicemente return super invece, chiamando il codice principale. Quando la funzione principale cambia, romperai solo la funzionalità del plugin e non il resto del software del forum.
Ho dovuto confrontare le due funzioni riga per riga per scoprire che il controllo rimosso era:
if new_topic?
...
else
if @topic.present? && @opts[:archetype] == Archetype.private_message
errors.add(:base, I18n.t(:create_pm_on_existing_topic))
return false
end
...
un commento non avrebbe fatto male 
Qualcuno conosce un modo migliore per assicurarsi che questo tipo di monkey patch rimanga manutenibile?
(Ho davvero usato “monkey patch” e “manutenibile” nella stessa frase? 
)
In realtà non sono ancora sicuro del motivo per cui i messaggi rapidi siano rotti da [FIX: assicura che non tentiamo di creare un nuovo PM su un argomento esistente #9029]. La correzione 9029 funziona per i PM e gli argomenti, allora perché i messaggi rapidi sono rotti? È dovuto a un modo specifico in cui i messaggi rapidi pubblicano un nuovo PM che entra in conflitto con la correzione 9029?
Sì, penso di sì. E il #9029 ha aggiunto quel controllo specifico.
Ho appena applicato una correzione per questo plugin. Fammi sapere come va.
@Oliver_Walker grazie per la PR. Come hanno già detto gli altri, è meglio non sovrascrivere metodi di grandi dimensioni, ma grazie per averci provato 
A rischio di sembrare una fesseria da biscotto della fortuna, nel 95% dei casi in cui stai valutando di sovrascrivere parte di un grande metodo lato server, stai combattendo contro la logica del framework (ci sono forse poche eccezioni a questo).
In questo caso, la prima cosa da chiedersi è: come vengono aggiunti i normali messaggi privati (PM) agli argomenti PM esistenti? Si scopre che il problema era che il plugin stava cercando di assegnare l’archetipo private_message a ogni post, invece che solo al primo post che crea l’argomento.
5 Mi Piace
Grazie @angus. Immagino tu sia riuscito a testarlo? Inoltre, devo solo chiedere al nostro partner di hosting (Communiteq (ex DiscourseHosting)) di ricaricare il plugin per noi?