Essayez de reproduire le problème en utilisant la version mobile de Google Chrome ou la version mobile de Firefox (ou tout autre navigateur mobile).
2 « J'aime »
Un nettoyage du cache a fait l’affaire ! Merci ! ÉDIT : Ou pas. 
1 « J'aime »
Désolé pour le manque d’attention ici, j’ai été occupé par d’autres travaux. Je reviendrai sur ce plugin sous peu.
@DaleKramer @Hifihedgehog Si vous avez un problème urgent, faites-le-moi savoir et je m’en occuperai cette semaine.
4 « J'aime »
En fait, après la mise à jour du serveur, le problème est revenu. Il se produit également sur tous mes navigateurs mobiles :
J’ai réintégré les messages rapides sur thepavilion.io. Pouvez-vous reproduire le problème là-bas ?
1 « J'aime »
Peut-être pourriez-vous examiner ce problème que j’ai rencontré et qui semblait pointer vers ce plugin comme étant le coupable…
Dans la dernière version, les messages rapides sont cassés. À chaque message, j’obtiens ce message :
Désolé, vous ne pouvez pas créer de MP dans un sujet existant.
Vrai, je reçois la même erreur : Désolé, vous ne pouvez pas créer un MP dans un sujet existant.
1 « J'aime »
Je rencontre toujours l’erreur « impossible de créer un MP ». Serait-ce à cause de ce commit ?
Merci pour les rapports. Je vais jeter un coup d’œil à cela dès que possible.
1 « J'aime »
C’était le problème. La solution consiste à écraser la fonction valid? sans les modifications de ce commit.
Donc, dans plugin.rb ou autre, faites :
require_dependency ‘post_creator’
class ::PostCreator
def valid?
réécrivez-le ici moins 4 lignes
Je ferai peut-être une PR pour cela si personne d’autre ne le fait demain, car j’y ai passé toute la matinée.
4 « J'aime »
Ce serait très apprécié. Les choses sont assez occupées en ce moment 
. Merci !
1 « J'aime »
1 « J'aime »
J’aimerais beaucoup obtenir une correction au plus vite, mais je m’inquiète aussi de l’utilisabilité à long terme de cette solution. Que se passerait-il si la logique au sein de cette implémentation de base de la fonction changeait ?
1 « J'aime »
Oui, je suis d’accord, ce n’est pas la bonne approche… surtout avec une méthode valid?, cela invite carrément à une faille de sécurité… et nous ne voulons pas que Discourse devienne le prochain WordPress à cet égard… mais quelle serait une bonne alternative ?
Je lutte moi aussi récemment avec ce genre de problèmes, où l’on a une longue méthode remplie de vérifications et où l’on souhaite contourner une seule vérification, juste au milieu de la méthode.
On ne peut pas simplement vérifier si :create_pm_on_existing_topic était la seule erreur, car le code retourne immédiatement lorsqu’elle est définie, et il est possible qu’une autre vérification ait échoué après cela.
Je commencerais par préfixer ce module, puis je vérifierais si c’est un scénario de message rapide dans la nouvelle méthode valid?. Si c’est le cas, j’exécuterais le code de validation modifié ; sinon, je ferais simplement return super, en appelant le code principal. Lorsque la fonction principale changera, vous ne casserez que la fonctionnalité du plugin et non le reste du logiciel de forum.
J’ai dû comparer les deux fonctions ligne par ligne pour découvrir que la vérification supprimée était :
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 commentaire n’aurait pas fait de mal 
Quelqu’un connaît-il une meilleure façon de s’assurer que ce genre de monkey patch reste maintenable ?
(Ai-je vraiment utilisé « monkey patch » et « maintenable » dans une même phrase ? 
)
En fait, je ne suis toujours pas sûr de savoir pourquoi les messages rapides sont cassés par [FIX : assure que nous n’essayons pas de créer un nouveau MP sur un sujet existant #9029]. La correction 9029 fonctionne pour les MP et les sujets — alors pourquoi les messages rapides sont-ils cassés ? Est-ce dû à une manière spécifique dont les messages rapides publient un nouveau MP qui entre en conflit avec 9029 ?
Oui, je pense que c’est ça. Et le #9029 a ajouté cette vérification spécifique.
Je viens de pousser une correction pour ce plugin. Tenez-moi au courant de l’évolution.
@Oliver_Walker merci pour la PR. Comme d’autres l’ont mentionné, il est préférable de ne pas surcharger de grosses méthodes, mais merci d’avoir essayé 
Au risque de ressembler à un cookie de la fortune périmé, dans 95 % des cas où vous envisagez de surcharger une partie d’une grosse méthode côté serveur, vous combattez la logique du framework (il existe peut-être quelques exceptions à cela).
Dans ce cas, la première chose à se demander est : comment les MP normaux sont-ils ajoutés aux sujets de MP normaux existants ? Il s’avère que le problème vient du fait que le plugin tentait d’attribuer l’archétype private_message à chaque publication, au lieu de seulement la première publication qui crée le sujet.
5 « J'aime »
Merci @angus. Je suppose que vous avez pu tester cela ? Aussi - dois-je simplement demander à notre partenaire d’hébergement (Communiteq (anciennement DiscourseHosting)) de recharger le plugin pour nous ?