よく見つけられましたね 
あなたがなさった作業の価値を損なうつもりはありませんが、私の最初の考えとしては、この段階で外部認証サービス（okta.com や auth0.com など）の利用を検討すべきだと考えます。パトレオン、ワードプレス、ディスコースという 3 つの異なるサービスを連携させて、一度に単一の認証を実現しようとする時点で、専用の認証ソリューションを検討すべきサインです。何らかの方法で実現できたとしても、そのソリューションが機能しなくなったり、すべてのケースで動作しなかったりする可能性という、それなりの長期的なリスクが存在します。
もしそれでもこの方向に進みたいのであれば、いくつかの提案があります。ただし、ここからは少し技術的な内容になります。同じ問題に直面してさらに進めたいと考えている他の人のためにも、ここに記しておきます。
Patreon Wordpress Plugin のコードを簡単に確認しましたが、OAuth フローにおいて state パラメータに final_redirect_uri というキー/バリューを受け付けるようです。これにより、パトレオンの認証からディスコースの SSO へ直接遷移することが可能になり、前述の Members プラグインや Redirect プラグインの必要性がなくなり、そのアプローチに伴う問題も回避できます。
多くの認証サービスには、final_redirect_uri パラメータのバージョン、つまり認証後にユーザーをどこへ送るかを指定できるパラメータが存在します。もしあなたが同じ問題を解決しようとしていて、パトレオン以外のサービスを使用している場合、かつ「3 つの異なるサービスを接続することへの警告」が当てはまらないと判断しているなら、そこが注目すべきポイントです。
つまり、パトレオンログインボタンを生成するショートコードが final_redirect_uri を引数として受け付け、それがパトレオンが使用する最終的なログイン URL に渡されるようにする必要があります。Patreon Wordpress Plugin のコードを見ると、これは実現可能な提案です。参考までに、パトレオンの URL を生成する関連関数は以下のようになります。
Patreon_Frontend::patreonMakeLoginLink(false, array( 'final_redirect_uri' => # ) );
基本的には、このコードはすでにカスタム final_redirect_uri を処理するよう部分的に設定されています。Patreon Wordpress Plugin の開発者がこれを追加したくない理由は理解できますが、ここで私が説明した内容を明確に表現できる自信があるなら、彼らの GitHub リポジトリで issue を作成する価値があるかもしれません。それが難しい場合は、上記で参照した関数を使って自分でリンクを生成し、独自のボタンを作成するか（またはそのためにワードプレス開発者を雇う）、という方法もあります。
SSO URL の構築に関する小さな注意点ですが、以下のように記述する方が少し明確です。
https://discourse.example.com/session/sso?return_path=/
これは以下の URL の代わりに使用します。
https://discourse.example.com/session/sso?return_path=%2F
最後の部分である return_path は、ログイン後にユーザーがディスコース内で送られるパスです。/ の場合、ユーザーはフォーラムのホームページへ送られます。SSO URL の構築の詳細については、WP Discourse Tips and Tricks をご覧ください。