Evaluación previa a la migración para un gran foro de Drupal 7

Migración
1

Hola a todos, soy propietario y administrador de lo que creo que es uno de los foros más grandes basados en Drupal en Internet, con cerca de 2 millones de publicaciones. Drupal 7 está muriendo, y Drupal 8/9 se está convirtiendo más en un framework para programadores web que en un sistema de gestión de contenido listo para usar. Las nuevas versiones de Drupal simplemente no ofrecen los módulos de terceros que necesito para que mi foro continúe con sus funciones básicas, y gracias a las maravillas de PHP y a las muchas otras peculiaridades de Drupal, la actualización sería tan infernal como migrar a una plataforma completamente diferente. Así que tendré que apretar los dientes y migrar a otra cosa. Estoy bastante seguro de que tendrá que ser Discourse debido a un aspecto único del estilo de mi comunidad de foros: soy el único moderador, y no es mi trabajo a tiempo completo. Así que a lo largo de los años he utilizado los flexibles frameworks Rules y Flag en Drupal para crear un sistema fragmentado de moderación comunitaria de spam y publicaciones ofensivas, con eliminación automática de publicaciones y/o cierre de cuentas de usuario en ciertos umbrales basados en la novedad del usuario y cuántos usuarios lo han marcado, y también teniendo en cuenta la novedad y la actividad reciente de marcado de los usuarios que lo marcan. En otras palabras, es casi exactamente lo que Discourse ha implementado. Me alegra mucho ver que Discourse ha reconocido el valor de la moderación comunitaria y ha implementado un sistema tan completo y bien pensado de fábrica. Drupal 7 fue y sigue siendo el único CMS lo suficientemente flexible como para permitir este tipo de funcionalidad personalizada sin ser un desarrollador experimentado, que no lo soy. Así que parece que me pasaré a Discourse. Sin embargo, tengo algunas preocupaciones.

  1. Sistema de moderación comunitaria: Nuestro foro está evaluando actualmente una instalación de prueba de Discourse. Me impresiona lo completo y bien pensado que es todo el sistema. Pero la comunidad ha notado algunas peculiaridades:
    • Realmente no me gusta cómo oculta las publicaciones eliminadas automáticamente detrás de “Ver contenido ignorado”. Si una publicación es lo suficientemente mala como para ser eliminada por la comunidad, es muy ofensiva o puro spam, y no quiero que los visitantes o usuarios tengan siquiera la opción de verla. Esto es especialmente problemático en el caso de temas que son spam o tienen un título ofensivo. ¿Y los rastreadores de motores de búsqueda no verían el contenido oculto de spam? ¿Es posible configurar el tiempo sin intervención del usuario antes de que una publicación de spam oculta automáticamente sea eliminada por completo de la vista pública? ¿Y qué pasa con los temas y las publicaciones que fueron marcados por la comunidad como inapropiados?
    • Leí aquí que “Nota: Todos los valores mencionados anteriormente son la configuración predeterminada. Los administradores pueden cambiarlos en la configuración del sitio” con respecto a los umbrales que conducen a la eliminación de publicaciones y/o al silencio de usuarios, pero no veo esas configuraciones granulares en mi instancia de prueba de Discourse. Todo lo que encuentro es “sensibilidad de ocultación de publicaciones” y “sensibilidad de silencio para usuarios nuevos”, pero no entiendo a qué se relaciona realmente esa sensibilidad en términos concretos.
    • Me gustaría eliminar la razón “fuera de tema” para marcar una publicación. Nuestra comunidad de foros es muy relajada en ese sentido y tiene una cultura de foro donde las publicaciones fuera de tema son muy comunes y bien aceptadas. Actualización: Parece que esto podría funcionar.
  2. Migración de mensajes privados: El foro actual tiene cerca de un millón de hilos de mensajes privados utilizando el módulo de Drupal 7 privatemsg, y el script de migración de Drupal a Discourse no lo maneja. Esto parece una omisión importante, porque a pesar de ser un módulo de terceros (al estilo típico de Drupal) es básicamente la funcionalidad de mensajería privada de facto que utilizan los administradores de Drupal 7.
  3. Conversión de formato de publicación: Desafortunadamente, el foro actual utiliza una mezcla de publicaciones en HTML puro y Textile. Entiendo que el script de migración puede manejar HTML puro (por favor, corríjame si me equivoco) pero no Textile. Si es posible, me gustaría convertir las publicaciones de Textile a HTML o Markdown, lo que sea más fácil. Me han dicho que Pandoc se puede integrar en el script de migración, pero que también aumentaría masivamente el tiempo de migración. He buscado módulos de Drupal para convertir el formato de las publicaciones existentes, pero solo encontré este, que no admite procesamiento por lotes para la gran cantidad de publicaciones, y no admite el paradigma de “comentarios” de Drupal, que constituyen la gran mayoría de las “publicaciones” que necesitan ser convertidas. Así que he pensado en hacer algún tipo de búsqueda/reemplazo sin conexión en el archivo de volcado de la base de datos con sed, similar a lo que se describe aquí. Se agradecen sugerencias o soluciones. Soy un usuario experimentado de Linux y he trabajado intermitentemente con expresiones regulares, pero todavía no soy bueno en ellas. Edición: Esto es una opción interesante para buscar/reemplazar una vez que los datos brutos están en Discourse.
  4. Anuncios: Me alegra mucho ver que el Plugin de Anuncios para Discourse parece haber madurado mucho desde la última vez que lo miré. Entiendo que los anuncios internos me permitirán colocar banners de imágenes en lugares específicos con un enlace de destino al hacer clic, y que si se asignan varios anuncios al mismo lugar, se seleccionarán al azar, ¿correcto? Sin embargo, no tengo idea de cómo lidiar con el paradigma móvil. En mi foro actual tengo un banner horizontal superior y tres banners verticales en la barra lateral izquierda, ninguno de los cuales sería factible para los usuarios móviles en la interfaz receptiva de Discourse. Edición: Es posible que tenga que modificar el Plugin de Anuncios para mis necesidades, oferta de pago aquí.
  5. Enlaces permanentes: El esquema de URL de Drupal tiene dos componentes principales: /node/XXXXXXX y enlaces a comentarios específicos dentro de esos nodos /comment/YYYYYYY#comment-YYYYYYY (YYYYYYY es el mismo en ambas ocurrencias). ¿Mantendrá automáticamente el script de migración de Drupal 7 a Discourse esos enlaces para que los enlaces en las publicaciones a otros hilos o publicaciones sigan funcionando y mantengan el SEO? ¿Qué pasa con un archivo sitemap.xml para los motores de búsqueda?
  6. Procesamiento por lotes: Durante la migración, ¿se ejecutará en lotes? ¿Qué sucede si encuentra un error, después de corregirlo continuará o requerirá comenzar desde el principio?
  7. Usuarios de dispositivos Apple antiguos: Por supuesto, entiendo los peligros de usar navegadores obsoletos. Para Windows y dispositivos Android antiguos, casi siempre hay una manera de instalar un navegador moderno compatible con Discourse. Pero me preocupa uno de mis usuarios que afirma tener una Mac de 2015 que no recibe actualizaciones y no tiene forma de instalar nada más que la vieja versión de Safari que le muestra avisos de depreciación con Discourse. Realmente sé muy poco sobre los dispositivos Apple aparte del hecho de que están mucho más bloqueados. ¿Es realmente tan difícil instalar otros navegadores modernos en ellos?
  8. Almacenamiento de imágenes/cargas: A mis usuarios y a mí nos encanta la facilidad de cargar imágenes en Discourse, pero me preocupa un poco el espacio de almacenamiento y los costos. La mejor opción a largo plazo probablemente sería montar un volumen de almacenamiento en red al VPS si es necesario. Si configuro inicialmente Discourse con la ubicación de carga predeterminada, ¿causaría problemas moverlo a un volumen diferente más tarde?
  9. Copias de seguridad:
    • Desearía que hubiera un sistema para copias de seguridad diferenciales, o mejor aún, deduplicadas. Actualmente uso Duplicity con Amazon S3 para mi foro de Drupal, y los costos son increíblemente bajos para un historial muy largo de revisiones. ¿Alguien sabe de inmediato cuánto tiempo después de la creación de un archivo S3 una regla puede hacer que transicione a Glacier?
    • ¿La interfaz de copias de seguridad de Discourse permite eliminar archivos en Amazon S3? Sé que es un poco extremo, pero querría deshabilitar esa funcionalidad, porque configuré mis buckets S3 con solo permisos PUT, GET y LIST para evitar que un hacker en el sistema comprometido elimine mis copias de seguridad remotas. Luego, una regla de ciclo de vida de S3 entra en vigor y el servidor elimina los archivos más antiguos después de un cierto período de tiempo.
  10. Plugin Stop Forum Spam: No quiero usar Akismet, pero siempre he tenido buenos resultados con StopForumSpam.com para prevenir la creación de muchas cuentas de spam. ¿Alguien sabe si el plugin para Discourse tiene umbrales configurables para cuántos aciertos debe tener un nombre de usuario, IP o dirección de correo electrónico en la base de datos para ser rechazado? Edición: No, no los tiene. Solicitado aquí. Lamentablemente, tampoco interviene para evitar la creación de cuentas si tienen suficientes aciertos en la base de datos de SFS, como lo hace en Drupal.

Disculpen la publicación larga. Gracias de antemano a todos por sus ideas, y muchas gracias a todo el proyecto Discourse por este excelente producto.

2

Me acabo de encontrar con esto:

aplicar un conjunto de transformaciones basadas en expresiones regulares, como reemplazar las etiquetas BBCode por Markdown

Se actualizó por última vez en 2016, no estoy seguro de si sigue siendo una opción relevante.

¿Sigue siendo esto relevante? En el script del importador de Drupal, veo código como:

 create_posts(results, total: total_count, offset: offset) do |row|
        topic_mapping = topic_lookup_from_imported_post_id("nid:#{row['nid']}")
      end

 def create_permalinks
    puts '', 'creando enlaces permanentes...'

    Topic.listable_topics.find_each do |topic|
      begin
        tcf = topic.custom_fields
        if tcf && tcf['import_id']
          node_id = tcf['import_id'][/nid:(\d+)/, 1]
          slug = "/topic/#{node_id}"
          Permalink.create(url: slug, topic_id: topic.id)
        end
1 me gusta
3

El script normalmente extrae 1000 publicaciones a la vez.

Lleva un registro de lo que se ha procesado, por lo que las ejecuciones posteriores pueden omitir los datos que ya se ejecutaron. En los scripts que he tocado, también incluyo una configuración import_after que acelera aún más las ejecuciones posteriores cargando solo datos recientes (también útil para probar con solo un subconjunto de los datos).

Tendría que examinarlo más de cerca para ver si las publicaciones se incluyen en los permalinks. Normalmente no lo están, pero se puede hacer.

Querrás todas tus cargas en S3, por lo que tu copia de seguridad incluirá solo el volcado de la base de datos. Realmente no puedes hacer nada para optimizar eso. Puedes dejar que Discourse conserve un cierto número o decirle que no lo haga (o simplemente establecer el número de copias de seguridad en un número grande) y dejar que tus reglas se encarguen de ello.

1 me gusta
4

Oh, ese es un muy buen punto. Ahora que lo pienso, se me cobrará de todos modos por el almacenamiento de carga en S3, ya sea que las cargas vayan directamente (y solo) a S3, o si están dentro de múltiples tarballs de la copia de seguridad de Discourse.

¿Y qué hay de usar un bucket sin permisos de eliminación para las copias de seguridad de Discourse?

5

Pero si están en S3, entonces solo tienes una copia.

Sospecho que funcionará si Discourse no tiene permiso para eliminar, aunque no lo sé.

6

Correcto, y con los niveles de redundancia de datos insanos de S3, ¿eso se consideraría generalmente una forma responsable de almacenar cargas? No he jugado con las opciones de S3 recientemente, pero creo que también tienen reglas de ciclo de vida para recuperar archivos eliminados durante un período de tiempo. Estoy pensando en el caso de que las cargas se eliminaran de alguna manera debido a una llamada errónea de Discourse, ya sea un error de codificación (improbable y masivo) o un error del usuario. O un evento de piratería, volviendo a mi preocupación original sobre los permisos de eliminación en el bucket.

7

Sí, puedes activar el control de versiones para que los archivos no se eliminen cuando se marcan como eliminados. Si no te importa cuánto espacio estás pagando, puedes hacerlo. Cuando Discourse elimina un archivo porque ya no se utiliza, lo mueve a una carpeta de “tombstone” (marcado como eliminado) durante un tiempo antes de eliminarlo definitivamente. Recomiendo que confíes en Discourse para administrar los archivos. No sé si deshabilitar el acceso de eliminación romperá algo.

Puedes poner las copias de seguridad en un bucket separado con permisos diferentes (pero las mismas credenciales) si lo deseas.

1 me gusta
8

Pregunta para @pfaffman o cualquier otra persona que suba contenido a S3: sé que depende de un millón de factores, pero ¿tienen al menos información anecdótica sobre los cargos por ancho de banda y las solicitudes de S3 para un foro mediano-grande con sus cargas en S3? ¡Muchas gracias!

1 me gusta
9

Pequeña actualización aquí: Así que, lo que creo que voy a hacer es mantener mis cargas de forma local; tendré suficiente almacenamiento local por ahora y la opción de expandirlo con volúmenes de almacenamiento adicionales si es necesario. Simplemente no quiero lidiar con la complejidad y el gasto de una CDN y los cargos impredecibles del almacenamiento de objetos y, sobre todo, los costos de transferencia para servir imágenes del sitio web en vivo. Luego, haré copias de seguridad automáticas de S3 en Backblaze B2, incluidas las cargas y la opción s3 disable cleanup. El precio de Backblaze es tan barato que no debería ser un problema mantener unas pocas semanas de copias de seguridad diarias, incluso con las cargas redundantes. Resulta que Backblaze B2 tiene dos opciones muy sencillas para los buckets que son justo lo que necesito: 1) reglas automáticas de ciclo de vida para eliminar archivos después de X días, y 2) evitar la eliminación o modificación de archivos durante N días (para evitar la pequeña posibilidad de que el servidor sea hackeado y el hacker use las credenciales almacenadas para eliminar mis copias de seguridad remotas). Probé esto y parece que funciona bien; intenté eliminar un archivo de copia de seguridad de la GUI de Discourse que Backblaze prohibió eliminar, y simplemente no hizo nada.

Solo para aclarar para mí y para otros: Es posible hacer una copia de seguridad automática de las cargas en almacenamiento local a S3 si la opción backup with uploads está habilitada (por defecto), ¿verdad?

1 me gusta
10

Sí. Por defecto, las cargas locales se incluyen en el archivo de copia de seguridad.

1 me gusta