Marco de scripts para reordenar temas y categorías

Para escribir un script que reorganice un Discourse grande trabajando con el liderazgo de mi sitio, escribí un framework simple para empaquetar un montón de pequeños scripts de Ruby que se controlan desde un archivo de configuración YAML. De esta manera, puedo restaurar una copia de seguridad en un sitio de staging, ejecutar mi script, obtener comentarios, cambiar algunas líneas de YAML, restaurar la copia de seguridad, ejecutar el script con la nueva configuración y repetir hasta estar satisfecho.

Tengo casi 600 líneas de configuración para mi sitio, y hacerlo manualmente a través de la UI simplemente no sería posible. Ni una sola vez, y mucho menos muchas veces para hacerlo bien. Lo sé porque la última vez que propuse hacer cambios drásticos, literalmente me di por vencido intentándolo. Por el contrario, con este script ahora puedo completar todo el ciclo en solo unos minutos por iteración, aunque el sitio tenga alrededor de medio millón de publicaciones y más de 100 categorías. Esto me permite obtener comentarios rápidos de los líderes de mi sitio y estaré preparado para migrar mi sitio rápidamente.

La documentación más detallada se encuentra en el archivo README en el repositorio con el código:

:warning: Este script no realiza ninguna comprobación de errores. Es una locura ejecutarlo en tu sitio en vivo. Está diseñado para ejecutarse en un sitio de staging, validar el resultado y luego pasarlo a producción. Como autor, todavía pretendo ejecutarlo de esta manera. Si lo ejecutas directamente en un sitio en vivo, te quedarás con todas las piezas cuando se rompa. :warning:

Según la documentación, un archivo de configuración podría verse así:

---
- describe:
    context: Old Name
    category: 7
    name: New Name
    description: New description of category
    slug: new-slug
- movePosts:
    context: move only faq posts from the Support category to the Documentation category
    source: 3 # Support category ID
    target: 6 # Documentation category ID
    withTag: faq
    hide: false # do not hide the Support category when done
- movePosts:
    context: consolidate How-To category into documentation with how-to tag
    source: 8 # How-To category ID
    target: 6 # Documentation category ID
    addTag: how-to
    hide: true # hide the old How-To category, visible only to Admin

La salida del progreso mientras se ejecuta podría verse así.

==========
Move hidden categories out of the way so they don't clutter admin view
setHiddenCategory: {:category=>11}
==========
Rename Old Name to New Name
describe: {:category=>7, :name=>"New Name", :description=>"New description of category", :slug=>"new-slug"}
==========
move only faq posts from the Support category to the Documentation category
movePosts: {:source=>3, :withTag=>"faq", :target=>6}
==========

Para usar esto, coloca tu archivo YAML en /var/discourse/shared/app/tmp/rearrange.yaml y luego:

cd /var/discourse
./launcher enter app
git clone https://github.com/johnsonm/discourse-site-rearranger.git script/discourse-site-rearranger
ruby script/discourse-site-rearranger/rearrange.rb /shared/tmp/rearrange.yaml

Sin embargo, es razonablemente probable que este script no haga exactamente todo lo que necesitas. Es realmente un framework que hace muy fácil añadir nuevas acciones que automaticen más aspectos de una modificación de sitio con script con solo unas pocas líneas de código. Todo lo que necesitas hacer es definir un método con unas pocas líneas de código, y podrás invocarlo correctamente desde el archivo YAML.

¿Has estado pensando en mejorar la organización de tu sitio, pero te echas atrás al usar la UI, o te preguntas cómo confiar en que podrás replicar tus pruebas en un sitio de staging para hacer cambios en vivo? ¡Échale un vistazo y dime qué piensas!

5 Me gusta

Estoy usando este script para crear un sitio de prueba, como un clon de mi sitio principal. La alta fidelidad visual es parte del objetivo, pero podría facilitar la publicación accidental en el sitio equivocado al revisar los cambios, y que esas publicaciones accidentales se eliminen la próxima vez que actualice el sitio de prueba.

Primero hice que mi sitio de prueba fuera de solo lectura cuando solicité comentarios públicos. Pero el inicio de sesión está deshabilitado mientras el sitio está en modo de solo lectura, por lo que no pudieron iniciar sesión cuando se lo pedí.

He agregado una nueva acción publicCategoriesReadonly que hace que las categorías visibles anónimamente sean escribibles solo por :admins y de :readonly por :everyone para permitir que las personas inicien sesión y exploren, pero ayuden a evitar publicar accidentalmente en el sitio equivocado. Ahora el sitio en su conjunto no está en modo de solo lectura, pero las categorías públicas sí lo están.

Es posible hacer referencia a las categorías como hashtags mediante slugs. Este script permite mover el contenido de las categorías juntas y cambiar los slugs, lo que haría que las publicaciones anteriores dejaran de enlazar después de un rebake. (Antes de un rebake, las redirecciones de permalink harían que los enlaces funcionaran).

Ahora he actualizado el script para rastrear las etiquetas antes y después de la migración y reasignar las referencias a las categorías cambiadas en las publicaciones.

He agregado una acción migrateRetortToReactions al framework para aquellos de nosotros que hemos tenido Retort instalado y queremos pasar a un plugin compatible.

2 Me gusta

¡Guau! Esa es una gran noticia. Sería genial si alguien pudiera convertirlo en una tarea de rake y enviarlo al plugin de reacciones.

Le echaré un vistazo pronto.

1 me gusta

Me parece inteligente tenerlo como una tarea de rake en el plugin.

He firmado el CLA de CDCK, por lo que cualquier interés de derechos de autor de mi parte en el trabajo resultante no se interpondrá, y puede incluirse bajo la misma licencia que el plugin.

Además, podría imaginar que me he equivocado en algo; si encuentra algo incorrecto, me encantaría saberlo porque planeo ejecutar ese script en mi propio sitio en las próximas semanas. :smiley:

A mayor escala, si encuentra que este framework es útil para su propio trabajo de soporte de instalaciones de Discourse pero desearía un mayor manejo de errores, aceptaría PRs. Simplemente quiero asegurarme de que cualquier PR provenga de alguien que haya firmado el CLA y esté de acuerdo en que cualquier pieza útil pueda incorporarse a Discourse oficial, lo cual sé que es cierto para usted…

2 Me gusta

Descubrí en el tema Retort que @angus tiene una rama con conversión impulsada por la interfaz de usuario, que me había pasado por completo.

Mi script se adentra en los detalles internos que, teóricamente, podrían cambiar algún día, y una vez que haya realizado mis conversiones con este script, no me daré cuenta si esos detalles internos cambian. Primero intenté hacerlo “de la manera correcta”, pero descubrí que el plugin Reactions no expone una interfaz que lo permita. @angus tiene una visión a largo plazo:

@pfaffman, si creas una tarea rake, podrías incluirla en una PR que también realice los cambios en las interfaces para que, por ejemplo, se pueda pasar created_by, además de silencioso, en lugar de usar la “puerta trasera” que utilicé. En ese momento, la tarea rake estaría allí para las migraciones de línea de comandos y, al mismo tiempo, permitiría a @angus realizar una migración impulsada por la interfaz de usuario.