Markdown sollte auch funktionieren, aber ich schätze, die Verwendung von <strong> könnte noch mehr Ausnahmefälle umgehen. Beachten Sie, dass die Mischung von HTML und Markdown auch ihre Tücken hat… Hier ist eine einfache Markdown-Lösung:
**mehrzeiliger\n\nText**
Ich bin neugierig, aus welcher Version von phpBB Sie importieren? Die Konvertierung von BBCode in Markdown ist für 3.2 besser als für frühere Versionen. Idealerweise sollten Sie in importierten Beiträgen keine [b] mehr sehen.
Ich schätze, du hast Recht, ich weiß nicht, warum ich zuerst nicht daran gedacht habe…
Ich migriere von phpBB 3.0.7-PL1.
Sie tun sich selbst einen großen Gefallen, wenn Sie vor dem Import auf 3.2 upgraden. 
Stellen Sie sicher, dass die BBCodes in allen Beiträgen in das neue Speicherformat migriert werden, indem Sie den phpBB-Reparser ausführen: https://www.phpbb.com/support/docs/en/3.3/kb/article/phpbb-32%2B-text-reparser/
Ich habe am Anfang darüber nachgedacht, aber… ich hasse Computerzeugs 
Ich kenne phpBB nicht gut und wollte keine Fehler behandeln müssen, die bei einem Update von einer so alten Version auftreten könnten.
Da das Discourse-Migrationsskript mit phpBB 3.0 kompatibel ist, habe ich mich entschieden, phpBB nicht zu aktualisieren…
Vielleicht wären einige von mir aufgetretene bbcode-Probleme mit einem phpBB-Upgrade vermieden worden. Dinge wie verschachtelte Listen, [b] mit Zeilenumbrüchen usw.
Aber da ich im Dezember mit dem Import begonnen habe, bin ich kurz davor, einen gut funktionierenden Import zu haben (idealerweise wäre das neue Forum vielleicht in zwei Wochen online) und ich bin mir nicht sicher, ob ich jetzt ein phpBB-Update ausprobieren möchte, besonders wenn ich alle benutzerdefinierten Importkorrekturen überprüfen muss, um zu sehen, ob der phpBB 3.2-Importer diese Dinge besser handhabt . Das wäre zeitaufwendig.
Das gesagt… Ich könnte Zeug dieses Wochenendes Nachmittags ausprobieren, wenn ich genug gelangweilt bin!
Bearbeitung: Ich habe es versucht; der Umzug auf einen neuen Server und dann das Upgrade auf pbpBB 3.2 ist eine Plackerei. HTTPS-Probleme. Cache-Probleme. Andere Probleme. Verschlungene und frustrierende Verfahren. Das offizielle Tutorial rät zur Verwendung von Tools, die eine veraltete PHP-Version erfordern (hallo, PHP 5, lange nicht gesehen…). Anscheinend bin ich manchmal gelangweilt, aber nicht verrückt - zumindest nicht genug, um so etwas zu tun.
Gerhard! Du führst in die Irre! Ein Upgrade auf 3.2 ist kein großer Gefallen! 
Aber genug über phpBB selbst… Und lobt das Ein-Klick-Upgrade von Discourse.
Hallo,
Ich versuche, WordPress-Benutzer nach Discourse zu migrieren. Ich konnte die Anweisungen befolgen, um eine Verbindung zu unserer WP-Datenbank herzustellen und Benutzer im Docker-Container zu importieren. Ich wollte sicherstellen, dass während oder nach der Migration keine E-Mails gesendet werden, da wir das SSO-WordPress-Plugin verwenden.
Ich habe den E-Mails das Präfix “import_” vorangestellt, damit sie keine E-Mails erhalten, falls Hintergrundaufgaben nach Abschluss der Migration E-Mail-Bestätigungen senden.
Ich sehe, dass nach der Migration die Spalte last_emailed_at gesetzt ist:
Ich weiß, dass dies durch opts[:last_emailed_at] = opts.fetch(:last_emailed_at, Time.now) in ImportScripts::Base::create_user() gesetzt wird.
Gibt es eine ähnliche Funktion wie admin.email_tokens.update_all(confirmed: true), die in ImportScripts::Base::create_admin verwendet wird, um die E-Mail zu bestätigen?
Ich sehe keine Protokolle, die gesendete E-Mails anzeigen. Wurden tatsächlich E-Mails gesendet? Wird Discourse versuchen, E-Mails zu senden, nachdem ich die E-Mails in gültige geändert habe?
Das gehört nicht zum Thema, da es hier um die Migration von phpBB3 geht…
Ich empfehle die Verwendung einer .invalid-Domain, wenn Sie sicherstellen möchten, dass einige Benutzer niemals E-Mails erhalten (z. B. foo@mywpimport.invalid). Wenn Sie jedoch nur ausgehende E-Mails deaktivieren möchten, bis Sie bereit sind, ist die Einstellung der Website-Einstellung disable_emails auf „yes“ oder „non-staff“ Ihre beste Option!
Ausgehende E-Mails werden während eines Imports automatisch deaktiviert. Die Werte des Attributs last_emailed_at stammen wahrscheinlich von Discourse, das versucht hat, eine E-Mail zu senden, bevor es feststellte, dass es dazu nicht berechtigt ist.
Discourse wird definitiv versuchen, E-Mails nach der Migration zu senden.
Danke, ich habe zuerst einen leeren String für das E-Mail-Feld versucht und die Basisklasse ImportScript hat gefälschte E-Mails mit der ungültigen Domain generiert. Sie haben auch das Attribut last_emailed_at gesetzt.
Sie sagen also, sobald ich die E-Mail aus der Datenbank korrigiert habe, wird Discourse versuchen, die E-Mail zu senden? Aber eine normale Anmeldung, die von WordPress authentifiziert wird, erfordert keine E-Mail-Bestätigung. Gibt es mit dem ImportScript keinen Ausweg?
Meine Migration ist abgeschlossen und erfolgreich.
Ich stoße jedoch auf zwei Probleme. Lassen Sie mich wissen, ob es themenfremd ist.
Einige Beitragsinhalte enthalten diese Art von Inhalt:
[url=https://www.casimages.com/i/1907271141431956116331631.jpg.html][
[img]https://nsm09.casimages.com/img/2019/07/27//1907271141431956116331631.jpg[/img][/url]
Die Bilder werden in der Vorschau angezeigt, sind aber im Beitrag selbst defekt, selbst nach dem Neuerstellen der HTML:
Die generierte HTML für jedes Bild ist:
<p><a href="https://www.casimages.com/i/1907271151181956116331666.jpg.html" data-bbcode="true"><span alt="" class="broken-image" title="Dieses Bild ist defekt">
<svg class="fa d-icon d-icon-unlink svg-icon" aria-hidden="true">
<use href="#unlink">
</use>
</svg></span></a></p>
Ich stoße bei vielen Beiträgen auf dieses Problem. Haben Sie eine Idee, wie man das global beheben kann?
Wie bei vielen alten Foren sind alte Imageshack-Links seit langem und für immer defekt. Aber einige Links zeigen jetzt eine ukrainische Flagge anstelle von nichts:
Wie würden Sie dieses Verhalten handhaben?
Ich bin offen für jede Idee, aber ein Administrator des Forums hat eine statische Sicherung des gesamten Forums auf einer alten Festplatte, auf der die meisten alten Bilder gültig sind (da sie lokal heruntergeladen und gespeichert wurden). Ich denke, dass ich in Zukunft vielleicht ein Skript erstellen könnte, das alle Imageshack-“toten” Links durch die gültigen Bilder aus der statischen Version ersetzt. Es scheint sehr schwierig zu sein, aber aus diesem Grund bin ich mir nicht sicher, ob ich einfach alle Imageshack-Links aus dem Forum entfernen möchte, indem ich sie durch einen leeren String oder etwas Ähnliches ersetze.
Ist der Zeilenumbruch das Problem? Das wäre meine Vermutung. Sie müssen diese BBCodes neu zuordnen, um den Zeilenumbruch zu entfernen. Replace a string in all posts sollte hilfreich sein.
Vielleicht vorerst in HTML-Kommentare umwandeln? Sie könnten sie später durch die gespeicherten Bilder ersetzen.
Es scheint nicht, dass dies das Problem ist:
Ich habe Zeilenumbrüche hinzugefügt, damit der Inhalt so aussieht:
[url=https://www.casimages.com/i/1907271141431956116331631.jpg.html]
[img]https://nsm09.casimages.com/img/2019/07/27//1907271141431956116331631.jpg[/img]
[/url]
Und das Ergebnis:
Beispiel-Posts:
Ja, das ist eine gute Idee! 
Also im Grunde die Strings (aus dem von Ihnen verlinkten Thema) mit Regexes ersetzen, um nur Imageshack-Links anzusprechen, richtig?
Das ist also nicht das Problem, nachdem ich mit neuen Zeilen experimentiert habe.
Aber wenn ich den Beitragsinhalt in einen neuen Beitrag im selben Forum kopiere und einfüge, wird der Inhalt korrekt angezeigt 
:
Vs:
Ich habe versucht, den Beitrag mit den kaputten Bildern (die in der Nachrichtenvorschau korrekt angezeigt werden, siehe meinen vorherigen Beitrag) neu zu backen, aber das hat nichts behoben.
Soweit ich weiß, ist der Rohinhalt beider Beiträge exakt derselbe.
Aber der gekochte Inhalt des ersten Beitrags (zweite Zeile) führt zu kaputten Bildern:
Ich bin ratlos.
Seltsames Verhalten:
Wenn ich versuche, das HTML von jedem beliebigen Beitrag neu zu erstellen, erhalte ich einen Fehler 500:
Die Logs zeigen einen fatalen Fehler und eine Warnung:
ArgumentError (wrong number of arguments (given 0, expected 1)) lib/guardian/ensure_magic.rb:11:in 'method_missing' app/controllers/posts_controller.rb:570:in 'rebake' app/controllers/application_cont
plugins/discourse-chat/lib/guardian_extensions.rb:71:in `can_rebake?'
lib/guardian/ensure_magic.rb:11:in `method_missing'
app/controllers/posts_controller.rb:570:in `rebake'
actionpack (6.1.4.1) lib/action_controller/metal/basic_implicit_render.rb:6:in `send_action'
actionpack (6.1.4.1) lib/abstract_controller/base.rb:228:in `process_action'
actionpack (6.1.4.1) lib/action_controller/metal/rendering.rb:30:in `process_action'
actionpack (6.1.4.1) lib/abstract_controller/callbacks.rb:42:in `block in process_action'
activesupport (6.1.4.1) lib/active_support/callbacks.rb:117:in `block in run_callbacks'
app/controllers/application_controller.rb:397:in `block in with_resolved_locale'
i18n (1.10.0) lib/i18n.rb:328:in `with_locale'
app/controllers/application_controller.rb:397:in `with_resolved_locale'
activesupport (6.1.4.1) lib/active_support/callbacks.rb:126:in `block in run_callbacks'
activesupport (6.1.4.1) lib/active_support/callbacks.rb:137:in `run_callbacks'
actionpack (6.1.4.1) lib/abstract_controller/callbacks.rb:41:in `process_action'
actionpack (6.1.4.1) lib/action_controller/metal/rescue.rb:22:in `process_action'
actionpack (6.1.4.1) lib/action_controller/metal/instrumentation.rb:34:in `block in process_action'
activesupport (6.1.4.1) lib/active_support/notifications.rb:203:in `block in instrument'
activesupport (6.1.4.1) lib/active_support/notifications/instrumenter.rb:24:in `instrument'
activesupport (6.1.4.1) lib/active_support/notifications.rb:203:in `instrument'
actionpack (6.1.4.1) lib/action_controller/metal/instrumentation.rb:33:in `process_action'
actionpack (6.1.4.1) lib/action_controller/metal/params_wrapper.rb:249:in `process_action'
activerecord (6.1.4.1) lib/active_record/railties/controller_runtime.rb:27:in `process_action'
actionpack (6.1.4.1) lib/abstract_controller/base.rb:165:in `process'
actionview (6.1.4.1) lib/action_view/rendering.rb:39:in `process'
rack-mini-profiler (3.0.0) lib/mini_profiler/profiling_methods.rb:85:in `block in profile_method'
actionpack (6.1.4.1) lib/action_controller/metal.rb:190:in `dispatch'
actionpack (6.1.4.1) lib/action_controller/metal.rb:254:in `dispatch'
actionpack (6.1.4.1) lib/action_dispatch/routing/route_set.rb:50:in `dispatch'
actionpack (6.1.4.1) lib/action_dispatch/routing/route_set.rb:33:in `serve'
actionpack (6.1.4.1) lib/action_dispatch/journey/router.rb:50:in `block in serve'
actionpack (6.1.4.1) lib/action_dispatch/journey/router.rb:32:in `each'
actionpack (6.1.4.1) lib/action_dispatch/journey/router.rb:32:in `serve'
actionpack (6.1.4.1) lib/action_dispatch/routing/route_set.rb:842:in `call'
lib/middleware/omniauth_bypass_middleware.rb:71:in `call'
rack (2.2.3) lib/rack/tempfile_reaper.rb:15:in `call'
rack (2.2.3) lib/rack/conditional_get.rb:40:in `call'
rack (2.2.3) lib/rack/head.rb:12:in `call'
actionpack (6.1.4.1) lib/action_dispatch/http/permissions_policy.rb:22:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:358:in `call'
rack (2.2.3) lib/rack/session/abstract/id.rb:266:in `context'
rack (2.2.3) lib/rack/session/abstract/id.rb:260:in `call'
actionpack (6.1.4.1) lib/action_dispatch/middleware/cookies.rb:689:in `call'
actionpack (6.1.4.1) lib/action_dispatch/middleware/callbacks.rb:27:in `block in call'
activesupport (6.1.4.1) lib/active_support/callbacks.rb:98:in `run_callbacks'
actionpack (6.1.4.1) lib/action_dispatch/middleware/callbacks.rb:26:in `call'
actionpack (6.1.4.1) lib/action_dispatch/middleware/actionable_exceptions.rb:18:in `call'
actionpack (6.1.4.1) lib/action_dispatch/middleware/debug_exceptions.rb:29:in `call'
actionpack (6.1.4.1) lib/action_dispatch/middleware/show_exceptions.rb:33:in `call'
logster (2.10.1) lib/logster/middleware/reporter.rb:43:in `call'
railties (6.1.4.1) lib/rails/rack/logger.rb:37:in `call_app'
railties (6.1.4.1) lib/rails/rack/logger.rb:28:in `call'
config/initializers/100-quiet_logger.rb:23:in `call'
config/initializers/100-silence_logger.rb:31:in `call'
actionpack (6.1.4.1) lib/action_dispatch/middleware/remote_ip.rb:81:in `call'
actionpack (6.1.4.1) lib/action_dispatch/middleware/request_id.rb:26:in `call'
lib/middleware/enforce_hostname.rb:23:in `call'
rack (2.2.3) lib/rack/method_override.rb:24:in `call'
actionpack (6.1.4.1) lib/action_dispatch/middleware/executor.rb:14:in `call'
rack (2.2.3) lib/rack/sendfile.rb:110:in `call'
actionpack (6.1.4.1) lib/action_dispatch/middleware/host_authorization.rb:92:in `call'
rack-mini-profiler (3.0.0) lib/mini_profiler/profiler.rb:249:in `call'
message_bus (4.2.0) lib/message_bus/rack/middleware.rb:60:in `call'
lib/middleware/request_tracker.rb:202:in `call'
railties (6.1.4.1) lib/rails/engine.rb:539:in `call'
railties (6.1.4.1) lib/rails/railtie.rb:207:in `public_send'
railties (6.1.4.1) lib/rails/railtie.rb:207:in `method_missing'
rack (2.2.3) lib/rack/urlmap.rb:74:in `block in call'
rack (2.2.3) lib/rack/urlmap.rb:58:in `each'
rack (2.2.3) lib/rack/urlmap.rb:58:in `call'
unicorn (6.1.0) lib/unicorn/http_server.rb:634:in `process_client'
unicorn (6.1.0) lib/unicorn/http_server.rb:739:in `worker_loop'
unicorn (6.1.0) lib/unicorn/http_server.rb:547:in `spawn_missing_workers'
unicorn (6.1.0) lib/unicorn/http_server.rb:143:in `start'
unicorn (6.1.0) bin/unicorn:128:in `<top (required)>'
vendor/bundle/ruby/2.7.0/bin/unicorn:25:in `load'
vendor/bundle/ruby/2.7.0/bin/unicorn:25:in `<main>'
Es war im Safe-Modus mit allen Themes und Plugins deaktiviert, aber dieser Codeblock erwähnt in der ersten Zeile:
plugins/discourse-chat/lib/guardian_extensions.rb:71:in 'can_rebake?'
Failed to handle exception in exception app middleware : ArgumentError : wrong number of arguments (given 0, expected 1)
/var/www/discourse/plugins/discourse-chat/lib/guardian_extensions.rb:71:in `can_rebake?'
/var/www/discourse/lib/guardian/ensure_magic.rb:11:in `method_missing'
/var/www/discourse/app/controllers/posts_controller.rb:570:in `rebake'
actionpack-6.1.4.1/lib/action_controller/metal/basic_implicit_render.rb:6:in `send_action'
actionpack-6.1.4.1/lib/abstract_controller/base.rb:228:in `process_action'
actionpack-6.1.4.1/lib/action_controller/metal/rendering.rb:30:in `process_action'
actionpack-6.1.4.1/lib/abstract_controller/callbacks.rb:42:in `block in process_action'
activesupport-6.1.4.1/lib/active_support/callbacks.rb:117:in `block in run_callbacks'
/var/www/discourse/app/controllers/application_controller.rb:397:in `block in with_resolved_locale'
i18n-1.10.0/lib/i18n.rb:328:in `with_locale'
/var/www/discourse/app/controllers/application_controller.rb:397:in `with_resolved_locale'
activesupport-6.1.4.1/lib/active_support/callbacks.rb:126:in `block in run_callbacks'
activesupport-6.1.4.1/lib/active_support/callbacks.rb:137:in `run_callbacks'
actionpack-6.1.4.1/lib/abstract_controller/callbacks.rb:41:in `process_action'
actionpack-6.1.4.1/lib/action_controller/metal/rescue.rb:22:in `process_action'
actionpack-6.1.4.1/lib/action_controller/metal/instrumentation.rb:34:in `block in process_action'
activesupport-6.1.4.1/lib/active_support/notifications.rb:203:in `block in instrument'
activesupport-6.1.4.1/lib/active_support/notifications/instrumenter.rb:24:in `instrument'
activesupport-6.1.4.1/lib/active_support/notifications.rb:203:in `instrument'
actionpack-6.1.4.1/lib/action_controller/metal/instrumentation.rb:33:in `process_action'
actionpack-6.1.4.1/lib/action_controller/metal/params_wrapper.rb:249:in `process_action'
activerecord-6.1.4.1/lib/active_record/railties/controller_runtime.rb:27:in `process_action'
actionpack-6.1.4.1/lib/abstract_controller/base.rb:165:in `process'
actionview-6.1.4.1/lib/action_view/rendering.rb:39:in `process'
rack-mini-profiler-3.0.0/lib/mini_profiler/profiling_methods.rb:85:in `block in profile_method'
actionpack-6.1.4.1/lib/action_controller/metal.rb:190:in `dispatch'
actionpack-6.1.4.1/lib/action_controller/metal.rb:254:in `dispatch'
actionpack-6.1.4.1/lib/action_dispatch/routing/route_set.rb:50:in `dispatch'
actionpack-6.1.4.1/lib/action_dispatch/routing/route_set.rb:33:in `serve'
actionpack-6.1.4.1/lib/action_dispatch/journey/router.rb:50:in `block in serve'
actionpack-6.1.4.1/lib/action_dispatch/journey/router.rb:32:in `each'
actionpack-6.1.4.1/lib/action_dispatch/journey/router.rb:32:in `serve'
actionpack-6.1.4.1/lib/action_dispatch/routing/route_set.rb:842:in `call'
/var/www/discourse/lib/middleware/omniauth_bypass_middleware.rb:71:in `call'
rack-2.2.3/lib/rack/tempfile_reaper.rb:15:in `call'
rack-2.2.3/lib/rack/conditional_get.rb:40:in `call'
rack-2.2.3/lib/rack/head.rb:12:in `call'
actionpack-6.1.4.1/lib/action_dispatch/http/permissions_policy.rb:22:in `call'
/var/www/discourse/lib/content_security_policy/middleware.rb:12:in `call'
/var/www/discourse/lib/middleware/anonymous_cache.rb:358:in `call'
rack-2.2.3/lib/rack/session/abstract/id.rb:266:in `context'
rack-2.2.3/lib/rack/session/abstract/id.rb:260:in `call'
actionpack-6.1.4.1/lib/action_dispatch/middleware/cookies.rb:689:in `call'
actionpack-6.1.4.1/lib/action_dispatch/middleware/callbacks.rb:27:in `block in call'
activesupport-6.1.4.1/lib/active_support/callbacks.rb:98:in `run_callbacks'
actionpack-6.1.4.1/lib/action_dispatch/middleware/callbacks.rb:26:in `call'
actionpack-6.1.4.1/lib/action_dispatch/middleware/actionable_exceptions.rb:18:in `call'
actionpack-6.1.4.1/lib/action_dispatch/middleware/debug_exceptions.rb:29:in `call'
actionpack-6.1.4.1/lib/action_dispatch/middleware/show_exceptions.rb:33:in `call'
logster-2.10.1/lib/logster/middleware/reporter.rb:43:in `call'
railties-6.1.4.1/lib/rails/rack/logger.rb:37:in `call_app'
railties-6.1.4.1/lib/rails/rack/logger.rb:28:in `call'
/var/www/discourse/config/initializers/100-quiet_logger.rb:23:in `call'
/var/www/discourse/config/initializers/100-silence_logger.rb:31:in `call'
actionpack-6.1.4.1/lib/action_dispatch/middleware/remote_ip.rb:81:in `call'
actionpack-6.1.4.1/lib/action_dispatch/middleware/request_id.rb:26:in `call'
/var/www/discourse/lib/middleware/enforce_hostname.rb:23:in `call'
rack-2.2.3/lib/rack/method_override.rb:24:in `call'
actionpack-6.1.4.1/lib/action_dispatch/middleware/executor.rb:14:in `call'
rack-2.2.3/lib/rack/sendfile.rb:110:in `call'
actionpack-6.1.4.1/lib/action_dispatch/middleware/host_authorization.rb:92:in `call'
rack-mini-profiler-3.0.0/lib/mini_profiler/profiler.rb:249:in `call'
message_bus-4.2.0/lib/message_bus/rack/middleware.rb:60:in `call'
/var/www/discourse/lib/middleware/request_tracker.rb:202:in `call'
railties-6.1.4.1/lib/rails/engine.rb:539:in `call'
railties-6.1.4.1/lib/rails/railtie.rb:207:in `public_send'
railties-6.1.4.1/lib/rails/railtie.rb:207:in `method_missing'
rack-2.2.3/lib/rack/urlmap.rb:74:in `block in call'
rack-2.2.3/lib/rack/urlmap.rb:58:in `each'
rack-2.2.3/lib/rack/urlmap.rb:58:in `call'
unicorn-6.1.0/lib/unicorn/http_server.rb:634:in `process_client'
unicorn-6.1.0/lib/unicorn/http_server.rb:739:in `worker_loop'
unicorn-6.1.0/lib/unicorn/http_server.rb:547:in `spawn_missing_workers'
unicorn-6.1.0/lib/unicorn/http_server.rb:143:in `start'
unicorn-6.1.0/bin/unicorn:128:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/bin/unicorn:25:in `load'
/var/www/discourse/vendor/bundle/ruby/2.7.0/bin/unicorn:25:in `<main>'
Helfen diese Informationen weiter?
Ich tue, was ich kann, um diese Beiträge zu reparieren, aber ich beginne zu glauben, dass dies etwas mit Discourse selbst zu tun hat und nicht mit etwas auf meiner Seite, oder? 
Edit: Siehe den automatisch verlinkten Beitrag unten.
Problem gelöst:
Jetzt muss ich nur noch alle meine Beiträge neu erstellen.
Noch eine Edit:
Das hätte sicher funktioniert, und zwar für Bilder, die noch ihre alte einfache URL haben, aber:
Da alle alten, defekten Imageshack-Links durch gültige Bilder ersetzt wurden, die von Imageshack selbst eine ukrainische Flagge anzeigen, wurden sie automatisch auf Discourse hochgeladen, wodurch sich ihre URL in einen lokalen Markdown-Bildlink geändert hat.
Glücklicherweise wurden alle diese Flaggen mit identischen Links auf Discourse hochgeladen ( in meinem Fall – übrigens hervorragendes Verhalten von Discourse ), was bedeutet, dass sie sehr einfach zu finden und zu entfernen/ersetzen sind. 
Ich schreibe dies nur, um Leute zu informieren, die nach einer Migration auf dasselbe Problem stoßen könnten wie ich.
Es scheint, dass der Wert poll_option_total manchmal falsch ist. Ich sehe mehr nicht-anonyme Stimmen pro Option als den Wert von poll_option_total. Und all diese Benutzer existieren.
Die Verwendung von GREATEST(..., 0) behebt das Problem. Zumindest stürzt es nicht ab.
SELECT o.poll_option_id, o.poll_option_text, o.poll_option_total AS total_votes,
GREATEST(CAST(o.poll_option_total AS SIGNED) - (
SELECT COUNT(DISTINCT v.vote_user_id)
FROM #{@table_prefix}poll_votes v
JOIN #{@table_prefix}users u ON (v.vote_user_id = u.user_id)
JOIN #{@table_prefix}topics t ON (v.topic_id = t.topic_id)
WHERE v.poll_option_id = o.poll_option_id AND v.topic_id = o.topic_id
),0) AS anonymous_votes
FROM #{@table_prefix}poll_options o
WHERE o.topic_id = #{topic_id}
ORDER BY o.poll_option_id
Ich möchte wirklich mein phpBB 3.3 Forum von meinem Unternehmen nach Discourse migrieren. Hat jemand eine Ahnung, wann das unterstützt wird?
Oh wow, das ist großartig! Danke!
Wenn ich einen neuen Thread für dieses Thema beginnen sollte, entschuldige ich mich im Voraus.
Ich habe ein phpBB-Forum in einem Unterordner:
thedomain.com/forum/
Ich plane, das Import-Skript zu verwenden, um von phpBB auf Discourse in einer Subdomain zu migrieren; d. h.:
forum.thedomain.com
Es scheint also, dass alles, was ich tun muss – für die Domain und die Permalinks – darin besteht, die folgenden Einstellungen in settings.yml mit HTTPS auf der neuen Seite vorzunehmen:
site_prefix:
# this is needed for rewriting internal links in posts
original: thdomain.com/forum # without http(s)://
new: https://forum.thedomain.com # with http:// or https://
# Enable this, if you want to redirect old forum links to the the new locations.
permalinks:
categories: true # redirects /viewforum.php?f=1 to /c/category-name
topics: true # redirects /viewtopic.php?f=6&t=43 to /t/topic-name/81
posts: true # redirects /viewtopic.php?p=2455#p2455 to /t/topic-name/81/4
# Append a prefix to each type of link, e.g. 'forum' to redirect /forum/viewtopic.php?f=6&t=43 to /t/topic-name/81
# Leave it empty if your forum wasn't installed in a subfolder.
prefix: forum
Und dann, auf dem ursprünglichen Server, auf dem Apache läuft, im .htaccess mit bereits aktiviertem RewriteEngine, benötige ich:
RewriteCond %{HTTP_HOST} ^thedomain.com
RewriteRule ^forum/(.*)$ https://forum.thedomain.com/$1 [L,R=301]
Wenn es wirklich so einfach ist, ist dieses Skript großartig! 
Ich habe noch ein paar zusätzliche Fragen:
Es wird den Import geringfügig verlangsamen, aber Sie sollten sich darüber keine Sorgen machen. Es ist meistens standardmäßig deaktiviert, weil es selten benötigt wird.
Ja, das ist in Ordnung.
Ich bin bei der Vorbereitung dieses Imports auf ein Problem gestoßen.
Das phpBB-Forum, das ich migrieren möchte, verwendet einen benutzerdefinierten BBcode, der HTML-img-Tags für Bilder erstellt, die in Ordnern nach Jahr in einem Verzeichnis außerhalb von phpBB, aber unter demselben Benutzerkonto auf dem Server gespeichert sind. Der BBcode hat das folgende Format:
[Gallery]{NUMBER1}|{NUMBER2}|{NUMBER3}|{SIMPLETEXT}[/Gallery]
Die {NUMBER1} und {NUMBER2} sind Ganzzahlen für die Breite und Höhe des Bildes. Die {NUMBER3} ist eine Ganzzahl für den Jahresordner, in dem sich das Bild befindet, und {SIMPLETEXT} ist der Dateiname des Bildes. Die HTML-Ersetzung für den BBcode sieht wie folgt aus:
<img class="postimage gallery-image" src="/gallery/files/{NUMBER3}/{SIMPLETEXT}" width="{NUMBER1}" height="{NUMBER2}" />
Ich muss herausfinden, wie ich diesen benutzerdefinierten BBcode für das Migrationsskript handhaben kann, sowohl um den benutzerdefinierten BBcode in etwas umzuwandeln, das Discourse verwenden kann, als auch um herauszufinden, wo die Bilddateien im Dateisystem für den Import abgelegt werden sollen.
Ich habe mir Ruby-BBcode-to-MD angesehen, das besagt, dass es “ermöglicht, diese Menge durch Bearbeiten von tags.rb einfach mit benutzerdefinierten Tags zu erweitern”. Ich habe mir tags.rb angesehen, aber da ich zum ersten Mal Ruby-Code sehe, bin ich ratlos, wie ich mit meinem benutzerdefinierten BBcode umgehen soll, da sein Pipe-getrenntes Format von allen offiziellen BBcodes abweicht, die die Datei tags.rb enthält und die ich als Leitfaden hätte verwenden können.
Ich habe templates/import/phpbb3.template.yml noch nicht geladen, also gehe ich davon aus, dass dies die Ruby-BBcode-zu-MD-Gem hinzufügt?
Daher habe ich Fragen:
Dieses Gem wird nicht mehr wirklich verwendet. Aus welcher Version von phpBB importieren Sie? Wenn es v3.1 oder niedriger ist, müssen Sie etwas Regex-Magie in discourse/script/import_scripts/phpbb3/support/text_processor.rb at ea2fd75d10e81687334f8d29e0d3e786dbdb4a53 · discourse/discourse · GitHub anwenden.
Für v3.2 können Sie die BBCode-Verarbeitung in discourse/script/import_scripts/phpbb3/support/bbcode/xml_to_markdown.rb at a71b219c9a18ad418e330282fde511bcb79ba7c4 · discourse/discourse · GitHub hinzufügen.