Hallo, ich poste ein Update dazu, da sich einige Dinge bei meiner Untersuchung dieses Problems geändert haben. Das Problem besteht seit dem Update auf 3.0.4; alle neu erstellten Artikel haben Probleme bei der Anzeige des eingebetteten Discourse-Codes. Alle Artikel, die vor diesem Update erstellt wurden, weisen keine Probleme auf, sodass keine IP-Adressensperre die Ursache dafür ist.
Es scheint, dass Discourse in der neuesten Version die Logik geändert hat, wie Beiträge automatisch durch den Einbettungscode erstellt werden, sodass der neue Code nun die kanonische URL benötigt. Siehe das zuvor verlinkte Thema:
Dies beeinträchtigt jedoch die Einbettungsfunktionalität auf Websites wie meiner vollständig. Ich habe zuvor die Node-ID in Drupal zum Einbetten verwendet, siehe den unten stehenden Code:
discourseEmbedUrl = "http://sitename.com/node/' . $nid . '";
Dieser neue Discourse-Code erfordert stattdessen die Verwendung der kanonischen URL, was zur Erstellung doppelter Themen führt, wenn jemand einfach den Artikelnamen umbenennt. Deshalb habe ich die Node-ID verwendet, da sie sich nicht ändert.
Wäre es möglich, diese neue kanonische URL optional zu machen? Ich habe versucht, meinen Einbettungscode zu ändern, um sie zu verwenden, aber das Lade-Problem trat für alle mit dem alten Einbettungscode erstellten Beiträge wieder auf.
Mit dem neuen Discourse-Code, der auf meiner Produktionsseite läuft, stecke ich also entweder in einer der folgenden beiden Optionen fest:
- Neu erstellte Artikel in Drupal zeigen “Laden…” an, laden aber nie den Kommentare-Einbettungsblock; alte Artikel, die vor Discourse 3.0.4 erstellt wurden, laden einwandfrei.
Oder,
- Neu erstellte Artikel in Drupal laden den Kommentare-Einbettungsblock einwandfrei, aber alle alten Artikel, die vor Discourse 3.0.4 erstellt wurden, zeigen “Laden…” an, laden aber nie den Kommentare-Einbettungsblock.
Gibt es eine Möglichkeit, diese neue Funktion optional zu machen? Die Wahl zwischen diesen beiden Optionen bringt mich in eine Art Lose-Lose-Situation.