Actualmente, los comentarios de Discourse y WordPress están sincronizados. Sería genial tener una sincronización bidireccional entre el contenido principal para que la comunidad de Discourse pueda editar (modificar y enriquecer significativamente) el contenido de la instancia de Discourse. De este modo, la comunidad podría participar en la mejora del sitio de WP (que es para lo que está diseñado la comunidad: participar en la creación y mejora de contenido), y no solo los editores a tiempo completo. Los artículos serían mejores y la información más precisa y actualizada, sin involucrar personal adicional. Para ello, es necesario introducir una tercera configuración: sincronizar temas entre instancias.
Hola Volanar:
Si tu sitio de Discourse va a reflejar tu sitio de WordPress, ¿necesitas ambos necesariamente?
La forma en que está redactada su solicitud, así es como veo su flujo:
flowchart
WP <--> Post
Discourse <--> Post
Community --> Discourse
Editors --> WP
De acuerdo, pero ¿cuál es el beneficio de tener dos interfaces de edición para el mismo contenido?
Si bien WordPress puede manejar y maneja markdown, no es el predeterminado para la mayoría de los sitios y, a menos que el comportamiento haya cambiado, markdown se convierte en html cuando se guarda la publicación. Cualquier estilo CSS específico también se pierde. El resultado es que las publicaciones de WordPress de buena apariencia pierden parte de su fidelidad visual cuando se ven en un sitio de Discourse.
Permitir que Discourse sobrescriba el contenido de una publicación de WordPress paralizaría muchas de las funciones de presentación dentro de WordPress. También está el problema de las versiones y los cambios simultáneos, ¿presumiblemente el último en escribir gana?
Si desea que los editores y los miembros de la comunidad contribuyan a la calidad de las mismas piezas de contenido, ¿por qué no editarlas en el mismo lugar?
Porque controlar quién ve qué y no puede hacer otras cosas se controla mucho mejor en Discourse, pero en el lado de WordPress pueden existir otras publicaciones.
Esa podría ser una razón. No tomo partido si ese es un caso bueno, malo o neutral.
(Para mí, al menos) suena a que no quieren añadir a todos de su comunidad a la instancia de WP:
Aunque tienes razón, editar en un lado o en el otro es probablemente mejor que editar en ambos.
Hola @volanar, puedo ver lo que intentas lograr.
Esto no formará parte del plugin WP Discourse en el futuro previsible, en parte porque ese plugin se centra en sincronizar comentarios de Wordpress en lugar de publicaciones de contenido de Wordpress, y en parte porque hacer que el plugin WP Discourse sea bidireccional plantea desafíos difíciles de resolver dentro del marco de ese plugin y la forma en que funciona con Discourse. @Stephen mencionó algunos de esos desafíos. Hay otros.
Dicho esto, es potencialmente posible que logres tu objetivo a través del uso del Plugin ActivityPub de WordPress y el Plugin ActivityPub de Discourse, que, combinados, podrían, en teoría, hacer lo que deseas, es decir, la sincronización bidireccional de contenido (publicaciones de WordPress y publicaciones de Discourse).
Hay dos grandes advertencias. Las funciones bidireccionales del plugin ActivityPub de Discourse aún no se han fusionado en la rama principal del plugin (la PR está actualmente en revisión), y nunca he probado ese plugin con el plugin ActivityPub de WordPress. Pero lo que sugieres es potencialmente posible combinando los dos.
De hecho, el escenario que has descrito es para lo que se desarrolló el protocolo ActivityPub. ¿Por qué es más posible en ese contexto en lugar del contexto de WP Discourse? Hay muchas razones que no entraré en detalles aquí, pero basta decir que si ese es tu objetivo, esa es la vía que deberías considerar.
Porque WordPress soporta WPML y el contenido se traduce a varios idiomas. WPML es bueno para rastrear el contenido modificado. A continuación, WP publica contenido en el blog y la aplicación móvil. Es decir, WP se puede utilizar como un CMS headless.
El tema principal se creará en WP, pero la comunidad podrá realizar correcciones y adiciones al contenido. Esta es información técnica y la belleza del contenido no es importante, por lo que puedes instalar el plugin de markdown en WP por defecto para un único formato de contenido. Idealmente, es mejor usar ghost, strapi, squidex u otra plataforma, pero costará dinero y no se adaptará a todos. La solución debe ser universal para todos.
Se me ocurrió una buena opción. Al final del tema, especifique un enlace para editar en el lado del frontend en WP. De esta manera, los usuarios podrán editar el contenido ellos mismos y el moderador podrá aceptar o rechazar los cambios.