discourse(prod)> TopicEmbed.find_by(topic_id: 157441).as_json
Serializing ActiveRecord models (TopicEmbed) without specifying fields is not allowed. Use a Serializer, or pass the :only option to #serializable_hash. More info: ``https://meta.discourse.org/t/-/314495
=>
{“id”=>56685,
“topic_id”=>157441,
“post_id”=>483289,
“embed_url”=>
“``https://tecnoblog.net/noticias/paramount-oferece-us-108-bilhoes-em-dinheiro-para-tomar-warner-da-netflix”``,
“content_sha1”=>nil,
“created_at”=>“2025-12-08T17:54:07.585Z”,
“updated_at”=>“2025-12-09T18:04:33.539Z”,
“deleted_at”=>nil,
“deleted_by_id”=>nil,
“embed_content_cache”=>“”}
discourse(prod)>
Könnten Sie denselben Befehl einfach noch einmal ausführen, aber dieses Mal:
./launcher enter app
rails c
TopicEmbed.find_by(topic_id: 157441).embed_url
Wenn das, was Sie geteilt haben, tatsächlich der Wert von embed_url in Ihrer Datenbank ist, dann ist das das Problem, und ich werde einen kleinen PR an discourse/discourse erstellen, um Randfälle wie diesen zu behandeln, bei denen die embed_url in einem fehlerhaften Zustand gelandet ist.
Das ganze Problem hier ist also, weil der obige PR im Januar dieses Jahres begonnen hat, abschließende Schrägstriche aus TopicEmbed zu entfernen? Ich bin wegen dieser Änderung zwiegespalten. Ehrlich gesagt wäre es mir lieber, wenn wir respektieren würden, was der Admin uns sendet.
Es folgt den Weiterleitungen tatsächlich nicht. Läuft das Forum auf demselben Server-/IP-Bereich wie der Blog? Dies könnte unsere SSRF-Schutzfunktion auslösen.
Falls dies der Fall ist, müssen Sie es über die Einstellung allowed_internal_hosts zulassen.
Der Grund, warum wir diese Änderung vorgenommen haben, ist, dass es eine Inkonsistenz zwischen der Funktionsweise von WP Discourse Embeds und Javascript Embeds gab. Javascript Embeds haben die URL schon immer normalisiert. WP Discourse Embeds kamen über einen anderen Weg herein und normalisierten die URL nicht (bis wir die Änderung vorgenommen haben). Das führte zu einigen anderen Inkonsistenzen.
Nein, es befindet sich auf einem dedizierten VPS. Die Maschine des Blogs leitet den Traffic (nginx) des Unterverzeichnisses an den Discourse-VPS weiter.
Ein weiteres Problem ist, dass ich, wenn ich einen Curl-Befehl an die API sende, um nach der Topic-ID einer Embed-URL zu suchen, diese aufgrund des abschließenden Schrägstrichs nicht finden kann. Discourse gibt eine 404-Seite zurück.
Aber wenn ich den abschließenden Schrägstrich entferne, wird der Wert zurückgegeben:
Um es zum Laufen zu bringen, müsste ich in WordPress einen String-Ersatz durchführen, um den abschließenden Schrägstrich der Permalink-URL zu entfernen, bevor ich prüfe. Aber das ergibt keinen Sinn, da die kanonische URL den abschließenden Schrägstrich hat…
In der Praxis normalisiert Discourse den Permalink auf eine URL, die nicht existiert… die normalisierte Version sollte die mit einem abschließenden Schrägstrich sein.
Aber ich mache mir immer noch Sorgen wegen der URLs ohne den abschließenden Schrägstrich, aus den Gründen, die ich in meinem vorherigen Beitrag erwähnt habe. Soll ich dazu ein neues Thema eröffnen, @angus?
Sicher! Es wird die Funktion „Vollständiger Beitrag“ nicht beeinträchtigen, da wir jetzt Weiterleitungen auf Websites derselben Domain wie das Forum verfolgen können, aber du kannst in einem neuen Thema für andere Bedenken nachhaken.