Vorbereitende Bewertung für ein großes Drupal 7 Forum

Migration
1

Hallo zusammen, ich besitze und verwalte eines der größten Drupal-basierten Foren im Internet mit fast 2 Millionen Beiträgen. Drupal 7 stirbt, und Drupal 8/9 entwickelt sich mehr zu einem Framework für Webprogrammierer als zu einem sofort einsatzbereiten Content-Management-System. Die neuen Drupal-Versionen bieten einfach nicht die Drittanbieter-Module, die ich für mein Forum benötige, um seine Grundfunktionen fortzusetzen, und dank der Freuden von PHP und vieler anderer Eigenheiten von Drupal wäre das Upgrade genauso höllisch wie die Migration zu einer völlig anderen Plattform. Also werde ich in den sauren Apfel beißen und zu etwas anderem migrieren müssen. Ich bin ziemlich sicher, dass es Discourse sein wird, aufgrund eines einzigartigen Aspekts des Stils meiner Foren-Community: Ich bin der einzige Moderator, und es ist nicht mein Vollzeitjob. Im Laufe der Jahre habe ich die flexiblen Rules- und Flag-Frameworks in Drupal verwendet, um ein Stückwerk-System zur Moderation von Spam und anstößigen Beiträgen durch die Community zu erstellen, mit automatischer Entfernung von Beiträgen und/oder Schließung von Benutzerkonten bei bestimmten Schwellenwerten, basierend darauf, wie neu der Benutzer ist und wie viele Benutzer ihn markiert haben, und unter Berücksichtigung der Neuheit und der jüngsten Markierungsaktivität der Benutzer, die ihn markieren. Mit anderen Worten, es ist fast genau das, was Discourse implementiert hat. Ich bin wirklich froh zu sehen, dass Discourse den Wert der Community-Moderation erkannt und ein solch umfassendes und gut durchdachtes System out-of-the-box implementiert hat. Drupal 7 war und ist immer noch das einzige CMS, das flexibel genug ist, um diese Art von benutzerdefinierter Funktionalität zu ermöglichen, ohne ein erfahrener Entwickler zu sein, was ich nicht bin. Es sieht also so aus, als würde ich zu Discourse wechseln. Ich habe jedoch einige Bedenken.

  1. Community-Moderationssystem: Unser Forum evaluiert derzeit eine Playground-Installation von Discourse. Ich bin beeindruckt, wie umfassend und gut durchdacht das gesamte System ist. Aber die Community hat einige Eigenheiten bemerkt:
    • Ich mag es überhaupt nicht, wie automatisch entfernte Beiträge hinter “Ignorierten Inhalt anzeigen” versteckt werden. Wenn ein Beitrag schlecht genug ist, um von der Community entfernt zu werden, ist er entweder stark anstößig oder reiner Spam, und ich möchte nicht, dass Besucher oder Benutzer überhaupt die Möglichkeit haben, ihn anzuzeigen. Dies ist besonders problematisch bei Themen, die Spam sind oder einen anstößigen Titel haben. Und würden Suchmaschinen-Crawler den versteckten Spam-Inhalt sehen? Ist es möglich, die Zeitspanne ohne Benutzereingriff zu konfigurieren, bevor ein automatisch versteckter Spam-Beitrag vollständig aus der öffentlichen Ansicht gelöscht wird? Und was ist mit Themen und Beiträgen, die von der Community als unangemessen markiert wurden?
    • Ich habe hier gelesen, dass “Hinweis: Alle oben genannten Werte sind die Standardeinstellungen. Sie können von Administratoren in den Site-Einstellungen geändert werden” bezüglich der Schwellenwerte, die zur Entfernung von Beiträgen und/oder zur Stummschaltung von Benutzern führen, aber ich sehe diese granularen Einstellungen in meiner Discourse-Testinstanz nicht. Alles, was ich finden kann, ist “Hide post sensitivity” und “Silence new user sensitivity”, aber ich verstehe nicht, worauf sich diese Sensibilität in konkreten Begriffen bezieht.
    • Ich möchte den Grund “off-topic” für die Markierung eines Beitrags entfernen. Unsere Foren-Community ist in dieser Hinsicht sehr entspannt und hat eine Forenkultur, in der Off-Topic-Beiträge sehr häufig und gut akzeptiert sind. Update: Es sieht so aus, als ob dies funktionieren könnte.
  2. Migration von privaten Nachrichten: Das aktuelle Forum hat fast eine Million private Nachrichten-Threads, die das Drupal 7 privatemsg-Modul verwenden, und das Drupal → Discourse-Migrationsskript behandelt dies nicht. Dies scheint eine große Lücke zu sein, denn obwohl es sich um ein Drittanbieter-Modul handelt (typisch für Drupal), ist es im Grunde die De-facto-Funktionalität für private Nachrichten, die Drupal 7-Administratoren verwenden.
  3. Konvertierung des Beitragsformats: Leider verwendet das aktuelle Forum eine Mischung aus reinem HTML und Textile-formatierten Beiträgen. Ich verstehe, dass das Migrationsskript reines HTML verarbeiten kann (bitte korrigieren Sie mich, wenn ich falsch liege), aber nicht Textile. Wenn möglich, möchte ich die Textile-Beiträge in HTML oder Markdown konvertieren, was auch immer einfacher ist. Mir wurde gesagt, dass Pandoc in das Migrationsskript integriert werden kann, aber dass dies auch die Migrationszeit erheblich verlängern würde. Ich habe nach Drupal-Modulen gesucht, um das Format bestehender Beiträge zu konvertieren, aber ich habe nur dieses gefunden, das keine Stapelverarbeitung für die riesige Menge an Beiträgen unterstützt und das Drupal “Kommentar”-Paradigma nicht unterstützt, das den Großteil der zu konvertierenden “Beiträge” ausmacht. Ich habe also darüber nachgedacht, einfach eine Art Offline-Suchen/Ersetzen in der Datenbank-Dump-Datei mit sed durchzuführen, ähnlich wie hier beschrieben. Vorschläge oder Lösungen wären willkommen. Ich bin ein erfahrener Linux-Benutzer und habe mit regulären Ausdrücken gearbeitet, aber ich bin immer noch nicht gut darin. Edit: Dies ist eine interessante Option zum Suchen/Ersetzen, sobald die Rohdaten in Discourse sind.
  4. Anzeigen: Ich bin wirklich froh zu sehen, dass das Anzeigen-Plugin für Discourse seit meinem letzten Blick darauf viel ausgereifter geworden ist. Ich verstehe, dass die In-House-Anzeigen es mir ermöglichen, Bildbanner an bestimmten Stellen mit einem Ziel-Link zu platzieren, und dass, wenn mehrere Anzeigen derselben Stelle zugewiesen sind, sie zufällig ausgewählt werden, richtig? Allerdings habe ich keine Ahnung, wie ich mit dem mobilen Paradigma umgehen soll. In meinem aktuellen Forum habe ich ein horizontales Banner oben und drei vertikale Banner in der linken Seitenleiste, die für mobile Benutzer in der responsiven Oberfläche von Discourse nicht praktikabel wären. Edit: Muss möglicherweise das Anzeigen-Plugin für meine Bedürfnisse modifizieren, bezahltes Angebot hier.
  5. Permalinks: Das URL-Schema von Drupal hat zwei Hauptkomponenten: /node/XXXXXXX und Links zu bestimmten Kommentaren innerhalb dieser Knoten /comment/YYYYYYY#comment-YYYYYYY (YYYYYYY ist in beiden Fällen gleich). Wird das Drupal 7 → Discourse-Migrationsskript diese Links automatisch beibehalten, damit Links in Beiträgen zu anderen Threads oder Beiträgen weiterhin funktionieren und SEO erhalten bleibt? Was ist mit einer sitemap.xml-Datei für die Suchmaschinen?
  6. Stapelverarbeitung: Wird sie während der Migration in Stapeln ausgeführt? Was passiert, wenn sie einen Fehler hat, wird sie nach der Behebung fortgesetzt oder muss sie von vorne beginnen?
  7. Benutzer alter Apple-Geräte: Ich verstehe natürlich die Gefahren der Verwendung veralteter Browser. Für Windows und alte Android-Geräte gibt es fast immer eine Möglichkeit, einen modernen Browser zu installieren, der mit Discourse kompatibel ist. Aber ich mache mir Sorgen um einen meiner Benutzer, der behauptet, einen Mac von 2015 zu haben, der keine Updates erhält und keine Möglichkeit hat, etwas anderes als die alte Version von Safari zu installieren, die ihm bei Discourse Deprecation Notices anzeigt. Ich weiß wirklich sehr wenig über Apple-Geräte, abgesehen davon, dass sie viel stärker eingeschränkt sind. Ist es wirklich so schwer, andere moderne Browser darauf zu installieren?
  8. Bild-/Upload-Speicher: Meine Benutzer und ich lieben die einfache Bild-Upload-Funktion in Discourse, aber ich mache mir ein wenig Sorgen um den Speicherplatz und die Kosten. Die beste Option für die Zukunft wäre wahrscheinlich, bei Bedarf ein Netzwerkspeicher-Volume an die VPS anzubinden. Wenn ich Discourse zunächst mit dem Standard-Upload-Speicherort einrichte, würde es Probleme bereiten, ihn später auf ein anderes Volume zu verschieben?
  9. Backups:
    • Ich wünschte, es gäbe ein System für differenzielle oder, noch besser, deduplizierte Backups. Ich benutze derzeit Duplicity mit Amazon S3 für mein Drupal-Forum, und die Kosten sind unglaublich niedrig für eine sehr lange Revisionshistorie. Weiß jemand aus dem Stegreif, wie schnell nach der Erstellung eines S3-Archivs eine Regel es in Glacier überführen kann?
    • Ermöglicht die Discourse-Backup-Oberfläche das Löschen von Archiven in Amazon S3? Ich weiß, das ist ein bisschen extrem, aber ich möchte diese Funktionalität deaktivieren, da ich meine S3-Buckets mit nur PUT- und GET- und LIST-Berechtigungen eingerichtet habe, um zu verhindern, dass ein Hacker auf dem kompromittierten System meine Remote-Backups löscht. Dann greift eine S3-Lifecycle-Regel und löscht die älteren Archive nach einer bestimmten Zeit serverseitig.
  10. Stop Forum Spam-Plugin: Ich möchte Akismet nicht verwenden, aber ich hatte immer gute Ergebnisse mit StopForumSpam.com, um die Erstellung vieler Spammer-Konten zu verhindern. Weiß jemand, ob das Plugin für Discourse konfigurierbare Schwellenwerte dafür hat, wie viele Treffer ein Benutzername, eine IP-Adresse oder eine E-Mail-Adresse in der Datenbank haben muss, damit sie abgelehnt werden? Edit: Nein, das hat es nicht. Angefragt hier. Außerdem greift es leider nicht ein, um die Erstellung von Konten tatsächlich zu verhindern, wenn sie genügend Treffer in der SFS-Datenbank haben, wie es in Drupal der Fall ist.

Entschuldigung für den langen Beitrag. Vielen Dank im Voraus an alle für ihre Einblicke und vielen Dank an das gesamte Discourse-Projekt für dieses ausgezeichnete Produkt.

2

Ich bin gerade auf Folgendes gestoßen:

Eine Reihe von regexp-basierten Transformationen anwenden, wie z. B. das Ersetzen von BBCode-Tags durch Markdown

Es wurde zuletzt 2016 aktualisiert, ich bin mir nicht sicher, ob es noch eine relevante Option ist.

Ist das noch relevant? Im Drupal-Importer-Skript sehe ich Code wie:

 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 '', 'creating permalinks...'

    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 „Gefällt mir“
3

Das Skript zieht normalerweise 1000 Beiträge auf einmal.

Es behält den Überblick darüber, was verarbeitet wurde, sodass nachfolgende Ausführungen bereits verarbeitete Daten überspringen können. Bei Skripten, die ich bearbeitet habe, füge ich auch eine Einstellung für import_after hinzu, die nachfolgende Ausführungen weiter beschleunigt, indem nur aktuelle Daten geladen werden (auch nützlich zum Testen mit nur einem kleinen Teil der Daten).

Ich müsste genauer nachsehen, ob Beiträge in Permalinks enthalten sind. Normalerweise sind sie das nicht, aber es kann gemacht werden.

Sie möchten, dass alle Ihre Uploads auf S3 sind, sodass Ihr Backup nur den Datenbank-Dump enthält. Daran können Sie nichts optimieren. Sie können entweder zulassen, dass Discourse eine bestimmte Anzahl behält, oder ihm sagen, es nicht zu tun (oder einfach die Anzahl der Backups auf eine große Zahl setzen) und Ihre Regeln damit umgehen lassen.

1 „Gefällt mir“
4

Oh, das ist ein sehr guter Punkt. Wenn ich darüber nachdenke, werde ich sowieso für den Upload-Speicher auf S3 berechnet, egal ob die Uploads direkt (und ausschließlich) auf S3 gehen oder ob sie sich in mehreren Tarballs aus dem Discourse-Backup befinden.

Und was ist mit der Verwendung eines Buckets ohne Löschberechtigungen für die Discourse-Backups?

5

Aber wenn sie auf S3 sind, haben Sie nur eine einzige Kopie.

Ich vermute, dass es funktionieren wird, wenn Discourse keine Berechtigung zum Löschen hat, obwohl ich es nicht weiß.

6

Richtig, und bei S3s wahnsinnig hohen Datenredundanzstufen würde das im Allgemeinen als verantwortungsvolle Art der Speicherung von Uploads angesehen werden? Ich habe mich kürzlich nicht mit den S3-Optionen beschäftigt, aber ich glaube, sie haben auch Lebenszyklusregeln, um gelöschte Dateien für einen bestimmten Zeitraum wiederherzustellen? Ich denke an den Fall, dass die Uploads irgendwie aufgrund eines versehentlichen Aufrufs von Discourse gelöscht wurden, sei es ein (unwahrscheinlicher und massiver) Programmierfehler oder ein Benutzerfehler. Oder ein Hacking-Ereignis, das zu meiner ursprünglichen Sorge über die Löschberechtigungen für den Bucket zurückführt.

7

Ja, Sie können die Versionierung aktivieren, damit Dateien nicht gelöscht werden, wenn sie als gelöscht markiert sind. Wenn es Ihnen egal ist, wie viel Speicherplatz Sie bezahlen, können Sie das tun. Wenn Discourse eine Datei löscht, weil sie nicht mehr verwendet wird, verschiebt es sie vorübergehend in einen Tombstone-Ordner, bevor sie endgültig gelöscht wird. Ich empfehle Ihnen, Discourse die Verwaltung der Dateien anzuvertrauen. Ich weiß nicht, ob das Verweigern des Löschzugriffs etwas kaputt machen wird.

Sie können Backups auf einem separaten Bucket mit anderen Berechtigungen (aber denselben Anmeldeinformationen) ablegen, wenn Sie möchten.

1 „Gefällt mir“
8

Frage an @pfaffman oder alle anderen, die Uploads auf S3 hochladen – Ich weiß, dass es von einer Million Faktoren abhängt, aber habt ihr zumindest anekdotische Informationen über die Kosten für Bandbreite und S3-Anfragen für ein mittelgroßes bis großes Forum mit seinen Uploads auf S3? Vielen Dank!

1 „Gefällt mir“
9

Kleines Update hier: Ich denke, ich werde meine Uploads lokal behalten; ich sollte vorerst genügend lokalen Speicherplatz haben und die Möglichkeit, ihn mit zusätzlichen Speicher-Volumes zu erweitern, falls nötig. Ich möchte einfach nicht mit der Komplexität und den Kosten eines CDN und den unvorhersehbaren Gebühren für Objektspeicher und vor allem den Übertragungskosten für die Live-Webseiten-Bildauslieferung zu tun haben. Dann werde ich automatische S3-Backups nach Backblaze B2 durchführen, einschließlich Uploads und der Option s3 disable cleanup. Die Preise von Backblaze sind so günstig, dass es kein Problem sein sollte, ein paar Wochen täglicher Backups aufzubewahren, selbst mit den redundanten Uploads. Es stellt sich heraus, dass Backblaze B2 zwei sehr einfache Optionen für Buckets hat, die genau das sind, was ich brauche: 1) automatische Lebenszyklusregeln zum Löschen von Dateien nach X Tagen und 2) Verhindern des Löschens oder Modifizierens von Dateien für N Tage (um die geringe Möglichkeit zu verhindern, dass der Server gehackt wird und der Hacker die gespeicherten Anmeldeinformationen verwendet, um meine Remote-Backups zu löschen). Ich habe dies getestet und es scheint gut zu funktionieren; ich habe versucht, ein Backup-Archiv aus der Discourse-GUI zu löschen, dessen Löschung von Backblaze verboten wurde, und es tat einfach nichts.

Nur zur Klarstellung für mich und für andere: Es ist möglich, Uploads auf lokalem Speicher automatisch auf S3 zu sichern, wenn die Option backup with uploads aktiviert ist (Standard), richtig?

1 „Gefällt mir“
10

Ja. Standardmäßig sind lokale Uploads in der Sicherungsdatei enthalten.

1 „Gefällt mir“