項目2 - 「ユーザーがアカウントの詳細を入力し、受信トレイにアクティベーションメールを受け取ります。」
ユーザーの承認を設定しましたが、サインアップ後に新規ユーザーの受信トレイにアクティベーションメールが送信されません。考えられる原因は何でしょうか？（ちなみに、新規ユーザーはサインアップの2日後にアカウントをアクティベートするためのフォローアップメールを受け取ることができました。）
@simon 様、ご意見をいただけると幸いです 
。ありがとうございます。
メールログに送信済みとして記録されていますか？ 
JammyDodgerさん、こんにちは。
初期設定時には新規メンバーが「サインアップ」メールを受け取ったのに、その後のテストでは、新規メンバーはサインアップから2日後に「アクティベーションリマインダー」メールのみを受け取ったというのは興味深いですね。何が原因でこのようなことが起こるのか、何か考えはありますか？どうぞよろしくお願いします。
念のため /skipped リストを確認することもできますが、サインアップメールがスキップされる理由がわかりません。
テストに使用しているユーザー/メールに特別なことはありますか？
スキップされたメールにログは見つかりませんでした。
メンバーシップのタイプでは、新しいメンバーがWishlist Memberの登録リンクからサインアップし、Discourseに新しいユーザーが自動的に作成されるため、技術的には同じになるはずです。新しいユーザーアカウントはこの時点ではまだアクティブではないため、次のステップは新しいメンバーがサインアップメールを受け取ることになります。しかし、何らかの理由で送信されていないようです…
/skipped ページは無理だろうと思っていました。
ユーザーを作成する方法に何か関係があるのかもしれません。Wishlist Member の登録リンクはどのように設定されていますか？
「いいね！」 1
@JammyDodger 様、洞察をありがとうございます。登録設定を確認いたします。近いうちに解決できることを願っています。
「いいね！」 2
推測ですが、WordPressとDiscourseの間でDiscourseConnectが有効になっていますか？もしそうであれば、ユーザーはサインアップを開始するためにDiscourseサイトの「ログイン」ボタンをクリックしており、「サインアップ」ボタンをクリックしていない可能性があります。
上記が正しいと仮定すると、WP DiscourseのDiscourseConnect Providerオプションタブで「ログイン時にDiscourseユーザーを作成または同期する」オプションが有効になっている場合、Wishlist Memberの登録リンクからサインアップするユーザーと、Discourseの「ログイン」ボタンをクリックしてサインアップするユーザーとでは、異なるログインフローが発生する可能性があります。ただし、設定がそのようになっていない場合は、的外れかもしれません。
「いいね！」 1
@simon 、DiscourseConnectの使用に賛成です。「サインアップボタン」をクリックするのではなく、「ログインボタン」をクリックするとおっしゃったことも正しいです。
これで、ユーザーがサインアップした直後に「サインアップ」メールを受け取るようにするにはどうすればよいでしょうか？それとも、設定方法によってはこれは不可能なのでしょうか？
Simon、ありがとうございます。
「いいね！」 1
これで納得がいきました。ユーザーが行っているのは、DiscourseではなくWordPressでアカウントを登録しているということです。DiscourseConnectを使用していると、ユーザー視点では少々混乱を招く可能性がありますが、それはおそらく別の問題でしょう。
現在、ユーザーはDiscourseの「ログイン」ボタンをクリックします。WordPressサイトのログインページにリダイレクトされます。そこからサイトの登録ページに移動する必要があります（ここが混乱の原因です）。サイトで登録した後、アカウントを有効化するように求めるメールが_WordPress_から送信されるはずです（これはWordPressサイトの設定によります）。WordPressサイトのデフォルトの登録設定がされている場合、ユーザーは有効化メール内のリンクをクリックし、WordPressアカウントを有効化してサイトにログインする手順を踏みます。
WP Discourseの「ログイン時にDiscourseユーザーを作成または同期する」オプションが有効になっている場合：
WordPressにログインすると、Discourseユーザーが自動的に作成されます。WordPressでこのオプションが有効になっていない場合、Discourseユーザーは、Discourseの「ログイン」ボタンを再度クリックするか、WordPressサイトに追加したDiscourseログインリンクをクリックするまで作成されません。
いずれの場合も、Discourseユーザーが作成されると、Discourseサイトに「承認待ち」のレビューエントリが作成されます：
Discourseサイトのスタッフは、承認待ちのユーザーがいることを通知されます。スタッフがユーザーを承認すると、Discourseから「承認されました」というメールがユーザーに送信されます。
これは、Discourseサイトへのユーザーアクセスを許可するための非常に複雑なアプローチのように思えます。ユーザー視点から見て、これを最も簡単に簡素化する方法は、Discourseの must approve users 設定を無効にすることです。WordPressサイトに、Discourseサイトへのアクセスを許可したくないユーザーがいる場合は、WordPressサイトにコードを追加して、一部のユーザーがDiscourseにログインできないようにする方が良いでしょう：How to prevent some WP users from being able to login to Discourse - #2 by simon
DiscourseConnectが有効になっている場合に must approve users 設定を有効にする良いユースケースはないと思います。ユーザー視点では非常に混乱します。
DiscourseConnectが有効になっている場合に、DiscourseまたはWordPressのいずれにもアカウントを持っていないユーザーがDiscourseの「ログイン」ボタンをクリックするという問題について、良い解決策を見つけたいと思います。おそらくDiscourseは discourse connect signup url 設定を追加するかもしれません。設定されていれば、ユーザーは認証プロバイダーのログインページではなく、認証プロバイダーのサインアップページにリダイレクトされるようになります。今のところ、最善の解決策は、認証プロバイダーのログインページで「登録」リンクをわかりやすくすることです。デフォルトのWordPressログインページでは、それほどわかりやすくありません：
@simon さん、いつも助かります。本当にありがとうございます。素晴らしいですね。すべてを解明しようとしていた時よりも、ずっと良いワークフローになりました。チームにも共有して検討してもらいます。
「いいね！」 1