Der letzte Commit am WP-Discourse-Plugin verursacht, dass alle benutzerdefinierten Beiträge (die über das EventON-Plugin erstellt wurden) dem Benutzer system zugeordnet werden, obwohl der Benutzer sowohl in Discourse als auch in WordPress existiert.
Wenn wir auf 2.3.7 zurückrollen, funktioniert es wie erwartet, aber ein Update auf 2.3.8 verursacht diesen Fehler.
Wir erhalten diese Fehlermeldung per E-Mail:
Grund für den Fehler:
Ein 400-Antwortcode wurde von Discourse zurückgegeben.
Parameter fehlt oder der Wert ist leer: post
Meinten Sie? post
post[raw]
controller
title
Ich dachte, das könnte bei der Identifizierung der wahrscheinlichen Ursache hilfreich sein.
Der Beitrag wurde mit 2.3.7 korrekt mit meinem Benutzerkonto auf WordPress und Discourse verknüpft.
v2.3.8:
[2022-02-21 08:10:15] publish.INFO: create_post.post_success {"wp_title":"[Bitte ignorieren] Eine weitere Testveranstaltung","wp_author_id":"3958","wp_post_id":126071,"discourse_post_id":""}
[2022-02-21 08:10:15] publish.INFO: create_post.body_valid {"wp_title":"[Bitte ignorieren] Eine weitere Testveranstaltung","wp_author_id":"3958","wp_post_id":126071,"discourse_post_id":""}
Der Beitrag wurde auf 2.3.8 mit meinem Benutzer auf WordPress und dem Systembenutzer auf Discourse verknüpft.
Ihre benutzerdefinierten Beitragstypen (d. h. die Veranstaltungen) werden erfolgreich in Discourse veröffentlicht.
Sie haben den 400-Fehler noch nie zuvor gesehen.
Welche Art von Benutzern (deren Discourse-Benutzernamen Sie erwarten zu verwenden) veröffentlichen Beiträge (d. h. sind sie Administratoren oder nicht)?
Welche Art von API-Schlüssel verwenden Sie, um WordPress mit Discourse zu verbinden?
Ja, die Beiträge werden erfolgreich veröffentlicht, aber dem falschen Benutzer (System) wird v2.3.8 zugeordnet.
Nein, wir haben keine 400-Fehler bei früheren Versionen des wp-discourse-Plugins gesehen.
Diese Benutzer sind nicht-admin registrierte Benutzer unter WordPress und bisher hat es für uns funktioniert. Jeder Benutzer wurde korrekt in Discourse verknüpft.
Danke, das wird behoben, wenn der PR zusammengeführt wird. Könnten Sie diese beiden Fragen auch bestätigen?
Welche Art von Benutzern (deren Discourse-Benutzernamen Sie erwarten zu verwenden) veröffentlichen Beiträge (d. h. sind sie Administratoren oder nicht)?
Welche Art von API-Schlüssel verwenden Sie, um WordPress mit Discourse zu verbinden?
Entschuldigung für die Störung, mein Problem scheint mit WordPress 5.9.1 & WP Discourse 2.3.9 behoben worden zu sein.
Es scheint jedoch, dass Discourse nun zusätzliche Arbeit an jedem veröffentlichten Beitrag leistet und die Eigentümerschaft nachträglich vom Systembenutzer auf den veröffentlichenden Benutzer übertragen wird?
Hallo @orenwolf, es tut mir leid zu hören, dass Sie immer noch ein Problem haben. Können Sie bestätigen, dass die Benutzer, von denen Sie erwarten, dass sie unter ihrem eigenen Namen veröffentlichen, einen Discourse Username in ihrem Wordpress-Profil haben?
Im Allgemeinen, Jungs, danke für Ihre Geduld. Bei meinen eigenen Tests auf verschiedenen Websites (und in den Unit-Tests des Plugins) funktioniert die Funktion Discourse Username jetzt wie erwartet unter 2.3.9. Wenn Sie immer noch ein Problem haben, bestätigen Sie bitte, dass Sie die neueste Version des Plugins verwenden und dass der Benutzer, von dem Sie erwarten, dass er der Autor des Beitrags ist, einen Discourse Username hat.
Sie fragen sich vielleicht, warum dieses Problem überhaupt aufgetreten ist. Ich denke, es wird hilfreich sein, wenn ich etwas Hintergrundinformationen gebe (die auch Ihre Frage @itsbhanusharma beantworten werden). Zuvor funktionierte diese Funktion so, dass sie verschiedene Benutzer im Api-Username-Header verwendete (siehe hier). Der Grund, warum dies als notwendig erachtet wurde, war, dass der relevante Endpunkt in Discourse das Festlegen eines Erstellers des Beitrags, der sich vom Benutzer, der die API-Anfrage durchführt, unterscheidet, nicht unterstützt.
Die Folge davon war, dass diese Funktion nur funktionierte, wenn Sie einen API-Schlüssel für “Alle Benutzer” mit einem “Globalen” Geltungsbereich haben. Ich werde darauf hinweisen, dass die Standardanweisungen zum Erstellen eines API-Schlüssels für das WP Discourse-Plugin seit einiger Zeit wie folgt lauten:
Wenn Sie noch keinen API-Schlüssel erstellt haben, klicken Sie auf “Neuen API-Schlüssel”, setzen Sie die Benutzerebene auf “Einzelbenutzer”, setzen Sie “Benutzer” auf ein Administratorkonto, wählen Sie “Globaler Schlüssel” und klicken Sie auf “Speichern”. Kopieren Sie den API-Schlüssel und fügen Sie ihn hier ein.
Die Befolgung dieser Anweisungen würde bedeuten, dass diese (undokumentierte) Funktion nicht funktioniert und zu Problemen auf verschiedenen Websites geführt hat.
Darüber hinaus habe ich aus verschiedenen Sicherheitsgründen schrittweise Änderungen am Plugin vorgenommen, um viel spezifischere API-Schlüssel zu ermöglichen. Dies erfordert eine Änderung in Discourse und wird (wenn es zusammengeführt wird) Plugin-Administratoren ermöglichen, sich selbst einen neuen, viel eingeschränkteren API-Schlüssel auszustellen. Ich werde dies ankündigen, wenn es soweit ist.
Ja, @itsbhanusharma, die Funktion funktioniert jetzt so, dass eine zweite Anfrage gestellt wird, um den Eigentümer des Beitrags zu ändern, nachdem er erstellt wurde (wenn ein Discourse Username vorhanden ist). Dies ist tatsächlich derzeit der einzige richtige Weg, um den Eigentümer eines Beitrags über die Discourse-API beliebig festzulegen (ohne die Api-Username und einen Global Key für alle Benutzer wie oben beschrieben verwenden zu müssen). Angesichts der Art dieses Vorgangs sollte dies kein Leistungsproblem darstellen.
Es ist kein Leistungsproblem, nur eine lästige Pflicht, weniger versierten Leuten zu erklären, dass das Bleistiftsymbol oben auf ihrem Beitrag normal ist und dass es so sein wird.
Es wird einige Zeit dauern, aber irgendwann werden wir uns daran gewöhnen.
Es ist etwas abschreckend, dass Beiträge als bearbeitet angezeigt werden, aber das ist in Ordnung, solange alles funktioniert.
Es ist jedoch ein Problem, dass Benachrichtigungen falsch sind. Sie zeigen an, dass der neue Beitrag vom Systembenutzer erstellt wurde.
Bisher fühlt sich das nur wie ein Hack an, nicht wie eine Lösung. Es ist sicherlich ein großer Rückschritt, nicht einfach automatisch als der richtige Benutzer posten zu können. Ich bin mir nicht sicher, was dazu geführt hat, dass dies überhaupt kaputt gegangen ist.
Kurz gesagt, ich habe die Art und Weise, wie das Plugin alle seine Anfragen an Discourse bearbeitet, aus verschiedenen Gründen langsam geändert, insbesondere aus Gründen der Prüfung und Sicherheit. Der vollständige Kontext und die Begründung für die Änderungen sind zu lang, um sie hier zu erörtern. Ich verstehe, dass es im Kontext dieser speziellen Funktion wie “wenn es nicht kaputt ist, repariere es nicht” erscheinen mag, aber es gibt hier einen breiteren Kontext.
Diese Änderungen laufen schon seit einiger Zeit (Monate), aber der Grund, warum sie jetzt an die Oberfläche kommen, ist, dass ich bei der Veröffentlichung von 2.3.8 einen Fehler gemacht habe. Daher habe ich die Änderung, die in dieser Veröffentlichung hätte enthalten sein sollen, in 2.3.9 aufgenommen.
Nichtsdestotrotz, @jtbayly@itsbhanusharma, höre ich Ihr Feedback zu dem anderen Ansatz für diese spezielle Funktion. Ich verstehe, dass es sich wie ein Hack anfühlen mag. Das ist es nicht. Dennoch werde ich angesichts Ihres Feedbacks den bestehenden Weg wieder in das Plugin einbauen, hinter einer Einstellung, die Sie verwenden können, wenn Sie möchten (er wird in 2.4.0 live gehen). Ich werde in den nächsten Tagen eine Notiz veröffentlichen, wenn dies zusammengeführt wurde.
Ich hoffe, diesen Ansatz vollständig entfernen zu können, wenn ich die von Ihnen beiden angesprochenen Probleme behoben habe, höchstwahrscheinlich mit weiteren Änderungen an discourse/discourse. Wie erwähnt, werde ich in den nächsten Monat eine größere Ankündigung über Änderungen an der Art und Weise, wie das Plugin API-Schlüssel verarbeitet, machen (abhängig davon, wann die Änderungen in discourse/discourse zusammengeführt werden), die Aspekte davon abdecken wird.
Als ich das sagte, wollte ich damit anerkennen, dass ich nicht sicher war, ob es überhaupt einen anderen Weg gab. Es war nicht als Kommentar gemeint: “Warum hast du es kaputt gemacht!”
Ich bin sehr dankbar für Ihre Arbeit, das WP-Plugin mit einem aktualisierten Discourse-Kern funktionsfähig zu halten. Und ich bin sehr froh, dass es (wahrscheinlich) kommende Änderungen im Kern geben wird, die Verbesserungen in diesem Bereich ermöglichen.
