Para cambiar, simplemente modifica tu configuración y reemplaza el repositorio babble existente por: https://github.com/PuttyTribe/babble.git y vuelve a compilar.
¡Qué coincidencia de tiempos! Sin actividad durante una semana y luego dos soluciones con solo 20 minutos de diferencia.
Originalmente elegí esa solución, pero decidí optar por una opción general, ya que el parámetro no se utiliza en ningún caso.
He fusionado el PR de @merefield que soluciona este problema.
@ti0 Gracias también por tu PR. El argumento se utiliza de hecho Si llamas a super sin argumentos (es decir, en lugar de super()), los argumentos de la subclase se pasan automáticamente a super. Si revisas el método que se está sobrescribiendo, verás dónde se utiliza el argumento: discourse/lib/search.rb at main · discourse/discourse · GitHub.
@ti0@merefield Como nota al margen, deberíamos crear un PR en el núcleo de Discourse para agregar un hook que permita añadir nuevos type_filters a la clase Search desde un plugin. Sería más eficiente y estable que parchear el método execute. Podría ser un proyecto interesante si logras convencer al equipo de Discourse de que vale la pena incluirlo.
@justin ¿Lograste resolver esto? Encontré el mismo problema hasta que simplemente cambié la forma en que Babble carga su motor en mi propia rama. Sospecho que tiene que ver con cómo diferentes entornos tratan el método de @gdpelican para cargar archivos en el inicializador, es decir:
Es difícil determinar exactamente. Podría crear un PR para actualizar el método de carga de archivos de Babble y ver si @gdpelican está de acuerdo en cambiarlo al método estándar de plugins de Discourse, usando load con File.expand_path en lugar de require con Rails.root.
edición: También he agregado Babble a try.thepavilion.io para que puedas probarlo en un entorno que se actualiza cada 24 horas.
En el futuro, si hay un error crítico con Babble (es decir, si no funciona en absoluto) y James no está disponible, por favor @angus o @merefield y lo solucionaremos (o revisaremos un PR :)).
Me refería a que el parámetro no se usa dentro del método sobrescrito que modificamos. Según lo que dices, mi código debería seguir funcionando, porque la llamada a super simplemente pasaría **args, que recopila los argumentos nombrados, y sería más estable si se añaden otros parámetros en el futuro. ¿Tiene sentido? ¿O me estoy perdiendo algo?
Acabo de hacer una pequeña prueba y tu método también parece funcionar para los propósitos inmediatos (es decir, preserva la funcionalidad de readonly_mode). Es un poco conceptualmente extraño si lo piensas, ya que teóricamente **args debería establecerse antes de llamar a la superclase en absoluto. Personalmente (y quizás James tendría una opinión diferente), creo que todavía prefiero la forma más explícita, ya que ya estamos pasando argumentos implícitamente simplemente llamando a super; añadir algo más de implícito con **args parece que se está volviendo un poco demasiado complejo.
Aunque entiendo a lo que te refieres, en conjunto, considero que la mejor vía de acción en estas situaciones es buscar una forma explícita de evitar conflictos con el código principal, en lugar de recurrir a métodos implícitos de captura general. Ese enfoque tiende a derivar en otros problemas más adelante. Como se mencionó anteriormente, preferiría que pudiéramos refactorizar esto buscando agregar un nuevo type_filter en la base de código principal. Creo que sería un buen pequeño proyecto.
¿Alguien ha integrado con Memberful y ha visto que el nombre real de sus usuarios aparezca debajo de su nombre de cuenta en el chat?
Me gustaría ocultar su nombre real si es posible.
Edición: Tengo una solución temporal: que los miembros usen su nombre de pantalla como nombre completo al registrarse, o edito manualmente su nombre completo para que coincida con el nombre de pantalla después de que se unan.
@angus, es posible que seas el ayudante de Babble más disponible en este momento. Por eso te estoy notificando con una solicitud de actualización de código, aunque estaré encantado de que cualquiera pueda abordar esto.
Acabo de actualizar nuestra versión de Discourse a 2.6.0beta2 (específicamente esta versión de commit en GitHub) y ahora el selector de emojis está roto.
@itsbhanusharma nos ayuda con nuestra instalación de Discourse y su primera impresión es que se trata de un problema de compatibilidad con la actualización del selector de emojis en el núcleo de Discourse.
Problema con el selector de emojis
Entorno:
Navegador: Firefox o Chrome (versión más reciente)
Vista: Escritorio, tableta y móvil
Posibilidad de reproducir el problema: 100%
No ocurre nada. No se abre ninguna ventana del selector de emojis.
Si no complica las cosas, quien solucione el problema del selector de emojis también podría arreglar una traducción faltante.
Cuando haces clic en el icono “…” junto a un mensaje de chat, la opción “Denunciar” se muestra como “[en_US.post.actions.flag]” en lugar de “Denunciar”.
@angus o cualquier otra persona que tenga las habilidades técnicas para ayudar con Babble en estos días: ¿tienes alguna esperanza de solucionar los dos problemas que reporté hace tres semanas en esta respuesta del foro?
¡Hola @angus, gracias por tu arduo trabajo en este plugin!
Mi sistema de Discourse funciona con una URL base de sondeo largo personalizada. Acabo de agregar Babble y veo que no agrega ninguna cabecera de Control de Acceso (CORS), lo que hace que varias solicitudes fallen.
Podría escribir una solución si me indicas la dirección correcta en el código.
Después de instalar las últimas actualizaciones de Discourse y la última versión de Babble (hace un par de días, y nuevamente ayer para ver si se había solucionado), tengo problemas para enviar mensajes y el indicador de lectura se queda atascado mostrando que hay mensajes nuevos.
Justo ahora, cuando no pude enviar un mensaje, apareció un montón de este error en la consola del navegador:
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
Sin actividad durante una semana y luego dos soluciones con solo 20 minutos de diferencia.
