WP-Discourse 플러그인의 최신 커밋으로 인해, Discourse와 WordPress 양쪽에 사용자가 존재함에도 불구하고 EventON 플러그인을 통해 생성된 모든 커스텀 게시물이 system 사용자에게 귀속되는 문제가 발생하고 있습니다.
2.3.7로 롤백하면 정상적으로 작동하지만, 2.3.8로 업데이트하면 이 버그가 발생합니다.
다음과 같은 오류를 이메일로 수신하고 있습니다:
Reason for failure:
A 400 response code was returned from Discourse.
param is missing or the value is empty: post
Did you mean? post
post[raw]
controller
title
이 오류 메시지가 원인을 파악하는 데 도움이 될 것 같아 공유합니다.
안녕하세요, 말씀하신 플러그인에 대한 링크를 공유해 주시겠어요? 또한 WP Discourse 로그에서 무언가 확인되고 계신가요?
가능하다면 둘 다 해주세요. Verbose Publication Logs를 켜주세요.
v2.3.7:
[2022-02-21 08:07:11] publish.INFO: create_post.post_success {"wp_title":"[Please Ignore] Test Event","wp_author_id":"3958","wp_post_id":126070,"discourse_post_id":""}
[2022-02-21 08:07:11] publish.INFO: create_post.body_valid {"wp_title":"[Please Ignore] Test Event","wp_author_id":"3958","wp_post_id":126070,"discourse_post_id":""}
2.3.7에서는 게시글이 WordPress와 Discourse 모두에서 내 사용자 계정에 올바르게 연결되었습니다.
v2.3.8:
[2022-02-21 08:10:15] publish.INFO: create_post.post_success {"wp_title":"[Please Ignore] Another test event","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":"[Please Ignore] Another test event","wp_author_id":"3958","wp_post_id":126071,"discourse_post_id":""}
2.3.8에서는 게시글이 WordPress에서는 내 사용자에게, Discourse에서는 시스템 사용자에게 연결되었습니다.
몇 가지 사항을 확인해 주실 수 있을까요?
이 PR이 병합되고(버전이 Wordpress.org에 배포되면) 해당 기능이 예상대로 작동합니다.
저도 동일한 오류를 경험하고 있으며, WP Discourse를 2.3.8 버전으로 업그레이드한 이후부터 발생하기 시작했음을 확인했습니다.
이 버전에서는 주제가 생성되지만, 기본 사용자로 생성됩니다.
확인하기 위해 WP Discourse를 2.3.7 버전으로 되돌렸더니 다시 정상적으로 작동합니다.
감사합니다. PR이 병합될 때 처리될 예정입니다. 다음 두 가지 질문도 확인해 주시겠어요?
- 어떤 유형의 사용자(사용자의 Discourse 사용자 이름이 사용될 것으로 예상되는)가 게시물을 게시하고 있나요(즉, 관리자입니까, 아니면 아닙니다)?
- WordPress를 Discourse에 연결하는 데 어떤 유형의 API 키를 사용 중입니까?
여기서도 같은 문제입니다. 커스텀 포스트 타입이 아닙니다.
관리자가 아니라 모더레이터입니다.
"모든 사용자"용 API 키입니다.
여러분, 해당 문제를 수정한 2.3.9 버전이 이제 배포되었습니다. 업데이트 후 결과를 알려주세요.
2.3.9에서도 동일한 문제가 발생하고 있으며, 2.3.7로 롤백하고 향후 이 플러그인의 자동 업데이트를 비활성화할 예정입니다.
안녕하세요 @angus
소란을 끼쳐 죄송합니다. 제 문제는 WordPress 5.9.1 및 WP Discourse 2.3.9에서 해결된 것 같습니다.
하지만, 현재 discourse가 각 게시된 게시물에 대해 추가 작업을 수행하고 있으며, 소유권이 시스템 사용자에서 게시 사용자로 사후에 이전되는 것 같습니다.
Hey @orenwolf, 여전히 문제가 발생하고 있다는 소식에 죄송합니다. 본인이 작성한 이름으로 게시물을 게시할 것으로 예상되는 사용자의 Wordpress 프로필에 Discourse Username이 설정되어 있는지 확인해 주시겠습니까?
여러분, 이 문제로 인내심을 가져주셔서 감사합니다. 여러 사이트(그리고 플러그인 자체의 단위 테스트)에서 직접 테스트해 본 결과, Discourse Username 기능은 현재 2.3.9 버전에서 의도대로 정상 작동하고 있습니다. 여전히 문제가 발생하고 있다면 플러그인의 최신 버전을 사용 중인지, 그리고 게시물의 작성자로 예상되는 사용자에게 Discourse Username이 설정되어 있는지 확인해 주십시오.
이 문제가 왜 발생했는지 궁금해하실 수 있을 것입니다. 배경 설명을 조금 드리는 것이 도움이 될 것 같아 공유드립니다(이것은 @itsbhanusharma 님의 질문에 대한 답변이기도 합니다). 이전에는 이 기능이 Api-Username 헤더에 다른 사용자를 사용하여 작동했습니다(여기 참조). 이렇게 해야 했던 이유는 Discourse의 관련 엔드포인트가 API 요청을 수행하는 사용자와는 다른 게시물의 생성자를 설정하는 것을 지원하지 않기 때문이었습니다.
그 결과, 이 기능이 작동하려면 “All Users” API 키와 “Global” 범위가 있어야만 했습니다. 참고로 WP Discourse 플러그인을 위한 API 키 생성에 대한 표준 지침은 오랫동안 다음과 같았습니다.
아직 API 키를 생성하지 않았다면, 'New API Key’를 클릭하고, User Level을 'Single User’로 설정한 뒤, 'User’를 관리자 계정으로 설정하고, 'Global Key’를 선택한 후 'Save’를 클릭하세요. 그리고 API 키를 복사하여 여기에 붙여넣으세요.
이 지침을 따를 경우 이(문서화되지 않은) 기능은 작동하지 않았으며, 이로 인해 여러 사이트에서 문제가 발생했습니다.
또한 다양한 보안상의 이유로, 플러그인에 대해 점진적으로 변경을 가해 훨씬 더 구체적인 API 키를 사용할 수 있도록 하고 있습니다. 이를 위해서는 Discourse 측의 변경이 필요하며(병합될 때), 플러그인 관리자가 자신에게 훨씬 제한적인 새로운 API 키를 발급할 수 있게 될 것입니다. 해당 시기가 되면 이에 대한 공지사항을 발표할 예정입니다.
네, @itsbhanusharma 님, 현재 이 기능이 작동하는 방식은 게시물이 생성된 후 (Discourse Username이 존재하는 경우) 게시물의 소유자를 변경하기 위해 두 번째 요청을 보내는 것입니다. 실제로 이는 위에서 설명한 Api-Username과 All Users Global Key를 사용하지 않고 Discourse API를 통해 게시물의 소유자를 임의로 설정하는 유일한 적절한 방법입니다. 이러한 유형의 작업인 점을 고려할 때, 이는 성능 문제가 되지 않아야 합니다.
성능 문제는 아니고, 그냥 게시물 상단의 연필 아이콘이 정상적인 것이며 앞으로도 그렇게 될 것이라고 설명하는 것이 좀 번거로운 것뿐입니다.
시간이 좀 걸리겠지만, 결국 익숙해지겠지요.
게시물이 수정된 것으로 표시되는 점은 다소 불쾌하지만, 모든 기능이 정상적으로 작동한다면 큰 문제는 아닙니다.
그러나 알림이 잘못 표시되는 것은 문제가 됩니다. 시스템 사용자가 새 게시물을 작성한 것으로 표시됩니다.
지금까지는 이 방식이 해결책이라기보다는 임시방편처럼 느껴집니다. 적절한 사용자로 자동으로 게시물을 작성할 수 없게 된 것은 분명히 큰 퇴보입니다. 처음에 이것이 왜 깨졌는지에 대해서는 정확히 이해하지 못하고 있습니다.
간단히 말하면, 다양한 이유, 특히 테스트와 보안을 위해 플러그인이 discourse에 보내는 모든 요청을 처리하는 방식을 서서히 변경해 왔습니다. 변경 사항의 전체 맥락과 근거는 여기에서 자세히 다루기엔 너무 깁니다. 이 특정 기능의 맥락에서는 "고장나지 않은 건 고칠 필요 없다"는 느낌이 들 수 있다는 점은 이해하지만, 여기에는 더 넓은 맥락이 있습니다.
이러한 변경 사항은 수개월에 걸쳐 진행되어 왔으며, 이제야 표면으로 드러난 이유는 2.3.8 릴리스에서 실수를 저질렀기 때문입니다. 따라서 해당 릴리스에 포함되어야 했던 변경 사항을 2.3.9에 포함시켰습니다.
그럼에도 불구하고, @jtbayly @itsbhanusharma 님, 이 특정 기능에 대한 다른 접근 방식에 대해 주신 피드백을 잘 듣고 있습니다. 해킹처럼 느껴질 수 있다는 점도 이해합니다. 그렇지 않습니다. 그럼에도 불구하고, 주신 피드백을 고려하여 원하시는 경우 사용할 수 있도록 기존 방식을 설정 옵션 뒤에 플러그인에 다시 추가할 것입니다(이는 2.4.0에서 적용될 것입니다). 해당 사항이 병합되면 향후 며칠 내에 후속 공지사항을 올리겠습니다.
두 분께서 제기하신 문제들을 해결할 수 있을 때, 아마도 discourse/discourse에 대한 추가 변경 사항과 함께 이 접근 방식을 완전히 제거할 수 있기를 바랍니다. 앞서 언급했듯이, 향후 한 달 안에 플러그인이 API 키를 처리하는 방식에 대한 변경 사항에 대해 더 큰 발표를 할 예정이며(이는 discourse/discourse에 변경 사항이 병합되는 시기에 따라 달라질 수 있음), 이는 이 사안의 여러 측면을 다루게 될 것입니다.
제가 그 말을 한 것은, 다른 진행 방법이 있었는지 확신이 서지 않는다는 점을 인정하기 위해서였습니다. “왜 고장을 일으켰나요?”라는 비판적인 의도는 아니었습니다.
WP 플러그인이 업데이트된 코어 Discourse와 함께 작동하도록 유지해 주신 노고에 진심으로 감사드립니다. 또한, 이 영역의 개선을 가능하게 할 코어 변경 사항이 (아마도) 곧 도입될 것이라는 점에 매우 기쁩니다.
