¿Pasar de una estructura de Wordpress + Discourse a solo un sitio de Discourse?

Antes de leer lo que sigue, puedes echar un vistazo a Moved from PluXml and phpBB to Wordpress and Discourse, my all-new experience 🎉, pero no es obligatorio, haré un resumen.

¿Qué tenemos ahora?

• Un sitio web de WP: https://monocycle.info (Tema Colormag).

• Un foro de Discourse: https://forum.monocycle.info

WP está conectado a Discourse a través de WP Discourse. WP es también el Cliente DiscourseConnect, y las noticias de WP se publican automáticamente en Discourse en una categoría dedicada. Eso es todo lo que hace el plugin por nosotros.

• El sitio web de WP se centra principalmente en las noticias y las páginas de información estática.

• El foro de Discourse es… Un foro. Donde la comunidad se reúne, habla y organiza cosas a veces.

La Pregunta

Me pregunté: “¿Cuál es realmente el propósito del sitio web? El valor añadido es bajo, y muchas de las funciones del sitio podrían hacerse en Discourse. Entonces, ¿por qué molestarse con dos plataformas?”

Tenga en cuenta que estoy al principio de mi reflexión. Pero estoy empezando a pensar que podría ser una buena idea deshacernos de WordPress en nuestro caso.

Entonces, ¿cuáles son los beneficios del sitio web? Tiene un diseño limpio y centrado en las noticias. Tiene pequeñas funciones que parecen agradables pero que quizás sean inútiles. El iframe de Facebook de la federación deportiva. Un botón de revista. La actividad reciente del foro. El calendario de eventos (una solución personalizada). Y muchas páginas estáticas de información sobre cosas de monociclo.

¿Qué de eso no se puede hacer en Discourse? Prácticamente nada.

La principal preocupación sería cómo hacer que las noticias sean más visibles en nuestro foro. No hay información nueva cada semana, pero son importantes en la comunidad francesa de monociclo y deberían ser visibles.

Discutí esto con dos personas involucradas en este foro/sitio. Piensan que deshacerse de WP podría ser una buena idea si no perdemos nada importante que nos dé el sitio web.

Las cosas técnicas.

• El encabezado personalizado de Discourse permanecería como está.

• Las noticias podrían usar News Plugin 📰. No como página principal, porque el contenido del foro no estaría disponible hasta que hiciéramos clic en algún botón de “foro” (como Elektronauts) y queremos enfatizar también la actividad de la comunidad en línea. Sin embargo, aún no he probado el plugin de noticias.

• Sin embargo, nos gustaría tener algunas noticias en la página de inicio del foro. Recuerdo haber visto un plugin o un componente de tema que mostraba algunas publicaciones en un banner en la parte superior de los temas, pero puedo estar equivocado. ¿Existe una solución existente para esto? El mejor uso para nosotros, creo, sería tener algo como las 3 últimas noticias con una miniatura y un extracto en la parte superior de la página de inicio, debajo del encabezado, y que pudiéramos activar/desactivar este banner para que no nos moleste si ya hemos leído esos temas.

• Las páginas estáticas del sitio web podrían ser temas o páginas publicadas.

• El wiki podría usar la función wiki de Discourse.

• No necesitamos el boletín (el resumen de Discourse lo reemplazaría), y mi coadministrador no ve ningún propósito real en el flujo de publicaciones incrustadas de Facebook de la federación deportiva, así como en otras cosas.

• Tenemos una categoría de eventos (solución personalizada), que está un poco vacía estos días, pero tiene su utilidad, y nos gustaría mantener el tipo de categoría de eventos con características específicas.

He visto y probado varios plugins de eventos/calendario en el pasado:

• Creating and managing events

• Events Plugin 📅

• Discourse Calendar (and Event)

Algunos eran un poco difíciles de entender o configurar, y mis necesidades eran un poco diferentes cuando los probé, así que debería intentarlo de nuevo.

Pros y contras de mantener solo Discourse

Pros

• No más problemas potenciales con WP, sus muchas extensiones/temas/código torpe personalizado ^[1] y la compatibilidad WP/Discourse al publicar.

• Solo una plataforma a considerar y en la que centrarse

• Todos los datos estarán organizados en una única base de datos, lo que simplificará las cosas si necesitamos mover todas nuestras cosas algún día (incluso Discourse no es eterno… ¿O sí? )

Contras

• Un poco de trabajo para “mover” algunas cosas de WP a Discourse

• Necesidad de encontrar soluciones adecuadas para algunas características

• Necesidad de configurar redirecciones 301

Tu opinión, pensamientos, consejos

Creo que he explicado bien lo que pretendo. Me alegraría escuchar cualquier sugerencia, consejo, etc., sobre esta posible transición de WP+D a D.

1. no quieres mirarlo; ni siquiera intentes pensar en ello, ya me da vergüenza ↩︎

Creo que esto probablemente se reduciría a la cantidad de tráfico que genera cada sitio y a su presupuesto.

Discourse puede hacer absolutamente todo lo anterior, pero si está sirviendo una tonelada de contenido a usuarios anónimos en el sitio de WordPress, su costo por vista de página es significativamente menor.
Un VPS de $5 configurado correctamente puede servir millones de vistas de página de solo lectura sin esfuerzo, ahí es donde WordPress sobresale. El mismo tráfico necesitaría considerablemente más recursos si se sirviera a través de Discourse. WordPress sigue siendo una herramienta increíblemente efectiva si te preocupan esas cosas. Configurado correctamente, también es bastante excelente para curar el contenido que se muestra a los motores de búsqueda.
Tengo un cliente que actualmente paga a DO alrededor de $100/mes por los dos. Cuando investigamos la posibilidad de trasladar las cosas por completo a Discourse, los costos operativos habrían sido un orden de magnitud mayor, es seguro decir que ese trabajo no se llevó a cabo.

Grandes preocupaciones. Debería haber mencionado información al respecto.

Este es un sitio web muy específico. El tráfico es bajo por esencia. No cuesta nada en ancho de banda, espacio en disco ni nada. Ambos sitios funcionan sin problemas en mi VPS junto con otras cosas web y estoy haciendo todo esto como trabajo voluntario.

El aspecto SEO sería interesante de estudiar. No había pensado en eso.

actualmente utiliza un backend CMS headless de Strapi + frontend Next.js alojado en Vercel.

También tiene un foro de Discourse adjunto:
https://forum.monerochan.news/
También estoy pensando en deshacerme por completo del backend de Strapi y simplemente usar Discourse como un CMS headless.

así que este problema podría resolverse alojando la “página de destino” / las páginas más visitadas de forma headless en algo como Vercel.
Incluso en su forma actual, Discourse casi podría funcionar como un CMS headless: simplemente podemos adjuntar .json a la URL del tema y obtener los datos de markdown/publicación sin procesar.

El único problema serían los enlaces permanentes, las listas de temas curadas y un sistema de publicación + permisos para autores y editores. Parte de ello se podría hacer con grupos y categorías, pero sería bueno si hubiera solo una categoría de artículo / artículo de vista previa.

Quizás deberíamos crear un plugin para eso

@Canapin ¡gracias por el tema! Gran lectura

Eso asume que solo la página principal sirve contenido semiestático. En mi ejemplo anterior, el sitio tiene más de 10.000 publicaciones y páginas.

export const getStaticProps: GetStaticProps = async ({params}) => {
  // Ejecutar llamadas a la API en paralelo
  const id = params?.id

  if (!id) {
    return {
      redirect: {
        destination: '/',
        permanent: false,
        // statusCode: 301
      },
    }
  }
  const qs = require('qs');
  const query = qs.stringify({
    populate: '*',
  }, {
    encodeValuesOnly: true, // prettify URL
  });
  const article = await fetchAPI("/api/articles/" + params.id + "?" + query)
  if (!article.data) {
    return {
      redirect: {
        destination: '/',
        permanent: false,
        // statusCode: 301
      },
    }
  }

  return {
    props: { article },
    revalidate: 1,
  }
}

Uso este código en el frontend de nextjs para obtener los artículos. Por lo tanto, almacenará en caché el artículo durante 1 segundo y luego lo volverá a validar. Por lo tanto, la instancia de discourse solo recibiría 1 solicitud por segundo si usáramos este método.

Es imaginable hacer esto no solo para una categoría especial que es administrada por un grupo especial de usuarios de autores y editores.
Podría hacerse para todo el contenido. El backend de strapi de monerochan.news también proporciona markdown (al igual que discourse). Por lo tanto, podríamos usar exactamente el mismo código para obtener los datos de la publicación (simplemente adjunte .json a la URL normal del tema) y mostrarlo.
Obviamente, las características interactivas de discourse faltarían en este caso. Pero podríamos poner un botón que diga algo como: ¡comentar! y esto redirigirá a la página de discourse. Las páginas de Nextjs también se cargan súper rápido y son amigables con el SEO.

Así que supongo que hay dos situaciones: 1. Un sitio de noticias con una categoría especial que es curada por autores y editores. 2. Un foro de discourse normal con contenido generado por el usuario.
También podría haber una mezcla de los dos casos.

En ambos casos, la construcción de un frontend headless podría tener muchos beneficios.

Si tienes problemas para hacer algo de lo anterior usando el Plugin de Noticias, el Plugin de Páginas de Destino o el Plugin de Eventos, siempre puedes avisarme. Estaré encantado de ayudarte.

Con respecto al plugin de eventos, deberías contactarnos porque actualmente estamos buscando más casos de uso para implementar en nuestra v2, que se lanzará pronto. Completa este asistente:

Esta es una idea interesante si la entiendo bien. Básicamente, mantendrías tu foro tal como está, y además tendrías un sitio web casero en el que el contenido provendría de los datos del foro a través de la API de Discourse. ¿Es así?

@Stephen, WordPress tiene efectivamente puntos válidos.

WP carga muy rápido, especialmente si usas un sistema de caché, mientras que Discourse necesita cargar toda la aplicación, lo que siempre lleva un tiempo al abrirla.

Mi sitio https://monocycle.info carga rápido y la navegación de página a página es casi instantánea.

La idea de eliminar WordPress es por varias razones que enumeré, pero olvidé añadir que me gustaría hacer el foro más visible y obvio. Quiero que la gente vea que hay una comunidad activa tan pronto como aterriza en el sitio.
Registrarse y publicar en Discourse es una experiencia agradable y sin problemas tanto en escritorio como en móvil.

Podría mantener WP solo para la página de inicio (o no mucho más), y mover la mayor parte del contenido a los temas/páginas publicadas de Discourse.

¡Genial! Necesito echar otro vistazo a tu plugin antes de rellenar tu asistente para saber exactamente qué características proporciona y cómo funciona en general.

¿Qué tal traer más contenido de la comunidad al sitio de WordPress? Aumentar la visibilidad de esa manera.

¿Alguna idea más específica? Cuando aterrizamos en la página principal, tenemos un enlace de “Discusiones” y una lista de los últimos temas creados.

image1173×1128 379 KB

¡Sí! ¡Esto es exactamente lo que quiero decir! Tampoco hay mucho que hacer por el lado de Discourse. Si adjuntas .json a cualquier enlace de tema, ¡ya tienes la API!
Echa un vistazo a este tema del que estamos hablando ahora mismo, por ejemplo:
https://meta.discourse.org/t/go-from-a-wordpress-discourse-structure-to-a-discourse-site-only/247273/8.json?include_raw=true

Observa el .json y el include_raw=true al final. Así es como puedes obtener incluso el markdown de la publicación además del HTML “cocinado”.

Strapi también utiliza un editor de markdown, por lo que puedo usar literalmente el mismo código que antes.

Screenshot 2022-12-12 at 13-05-29 https __meta.discourse.org1315×933 138 KB

Eso me hizo literalmente saltar de la silla. Por lo que entendí al usar: .json y include_raw=true con una especie de automatización (n8n) podríamos redirigir técnicamente todo Discourse a Hugo insertando la metaetiqueta y el markdown directamente en un repositorio git??