Intenta reproducir el problema utilizando la versión móvil de Google Chrome o la versión móvil de Firefox (o cualquier otro navegador móvil).
2 Me gusta
¡Borrar la caché funcionó! ¡Gracias! EDIT: O no. 
1 me gusta
Disculpa la negligencia aquí, he estado ocupado con otro trabajo. Pronto volveré a revisar este complemento.
@DaleKramer @Hifihedgehog Si tienes un problema urgente, házmelo saber y lo revisaré esta semana.
4 Me gusta
En realidad, después de actualizar el servidor, el problema volvió a aparecer. También ocurre en todos mis navegadores móviles:
He vuelto a añadir los mensajes rápidos a thepavilion.io. ¿Puedes reproducir el problema allí?
1 me gusta
Quizás podrías investigar este problema que tuve y que parecía apuntar a este complemento como el culpable…
En la versión más reciente, los mensajes rápidos están rotos; en cada mensaje recibo este mensaje:
Lo sentimos, no puedes crear un MP en un tema existente.
Verdad, estoy obteniendo el mismo error: Lo siento, no puedes crear un MP en un tema existente.
1 me gusta
Obtengo el mismo error de “no se puede crear un MP”. ¿Podría ser por este commit?
Gracias por los informes. Lo revisaré lo antes posible.
1 me gusta
este era el problema. La solución es sobrescribir la función valid? sin los cambios de este commit
así que en plugin.rb o algo similar haz
require_dependency ‘post_creator’
class ::PostCreator
def valid?
reescríbela aquí menos 4 líneas
Podría hacer un PR para esto si nadie más lo hace mañana, ya que estuve revisándolo toda la mañana.
4 Me gusta
Eso sería muy apreciado. Las cosas están bastante ocupadas en este momento 
. ¡Gracias!
1 me gusta
1 me gusta
Aunque me encantaría tener una solución lo antes posible, también me preocupa la usabilidad a largo plazo de esta corrección. ¿Qué pasa si la lógica dentro de esa implementación central de la función cambia?
1 me gusta
Sí, estoy de acuerdo, esta no es la forma de hacerlo… especialmente con un método valid?, esto solo está esperando una vulnerabilidad de seguridad… y no queremos que Discourse sea el próximo WordPress en ese aspecto… pero, ¿cuál sería una buena alternativa?
También he estado luchando con este tipo de cosas últimamente, donde hay un método largo lleno de comprobaciones y quiero eludir una sola comprobación, justo en medio del método.
No puedes simplemente comprobar si :create_pm_on_existing_topic fue el único error, porque el código devuelve inmediatamente cuando se establece, y podría haber fallado en otra comprobación después de eso también.
Al menos, debería preponer este módulo y luego comprobar si se trata de un escenario de mensaje rápido en el nuevo método valid?. Si lo es, ejecutar el código de validación modificado, pero si no se trata de un mensaje rápido, simplemente return super en su lugar, llamando al código principal. Cuando la función principal cambie, solo romperás la funcionalidad del plugin y no el resto del software del foro.
Tuve que comparar las dos funciones línea por línea para descubrir que la comprobación eliminada 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 comentario no habría hecho daño 
¿Alguien conoce una mejor manera de asegurarse de que este tipo de parches de mono sigan siendo mantenibles?
(¿Realmente usé “parche de mono” y “mantenible” en una sola oración? 
)
En realidad, todavía no estoy seguro de por qué los mensajes rápidos se han roto con [FIX: aseguramos que no intentemos crear un nuevo mensaje privado en un tema existente #9029]. La corrección de 9029 funciona para mensajes privados y temas, entonces, ¿por qué se rompen los mensajes rápidos? ¿Se debe a alguna forma específica en que los mensajes rápidos publican un nuevo mensaje privado que entra en conflicto con 9029?
Sí, creo que es eso. Y el #9029 añadió esa verificación específica.
Acabo de aplicar una corrección para este plugin. Avísame cómo funciona.
@Oliver_Walker gracias por la PR. Como otros han mencionado, lo mejor es no sobrescribir métodos grandes, pero gracias por intentarlo 
Corriendo el riesgo de sonar como una galleta de la fortuna pasada de moda, en el 95% de los casos en que estés considerando sobrescribir parte de un método grande del lado del servidor, estarás luchando contra la lógica del framework (quizás haya unas pocas excepciones a esto).
En este caso, lo primero que hay que preguntarse es: ¿cómo se agregan normalmente los mensajes privados (PM) a los temas de PM normales existentes? Resulta que el problema era que el plugin intentaba asignar el arquetipo private_message a cada publicación, en lugar de solo a la primera publicación que crea el tema.
5 Me gusta
Gracias @angus. Asumo que pudiste probar esto, ¿verdad? Además, ¿solo debo pedirle a nuestro socio de alojamiento (Communiteq (anteriormente DiscourseHosting)) que vuelva a cargar el plugin por nosotros?