Discourse がサポートする広告ネットワークには満足していませんが、当社のブログでは完璧に動作するものを見つけました。フォーラムでも同様に導入したいと考えていますが、そのためにはコードをコピーして当社のサイトの HTML に貼り付ける必要があります。具体的にどこに貼り付ければよいのでしょうか？また、正常に機能するでしょうか？
そのためにはテーマコンポーネントを使用してください
ありがとうございます。でも、私は開発者ではありません。私の知識は、Discordのセットアップ（1週間かかりました）とサイトの設定変更までです。
では、ここから始めましょう。
あなたの目的は、テーマコンポーネントを作成し、/head タブに広告の <script> を追加し、メインテーマでそのテーマコンポーネントを有効化することです。
テーマコンポーネントを有効化したら、以下の手順に従ってスクリプトの URL をホワイトリストに登録する必要があります。
クラブへようこそ、私たちも同じ状況です。ただし、一点だけお伝えしておくと、これはテーマコンポーネントでは機能しません。そのため、提案された回答は適用できません。私たちもこの道を進んできましたし、他のユーザーも同様です（これに関するトピックをご覧ください）。テーマコンポーネントを使用すると、広告スクリプトが本来表示されるべきボディ部分に表示されません。/head にスクリプトを使用することを提案したコメント投稿者は、広告スクリプトの実装方法について十分に理解していない可能性があります。私たちはテーマコンポーネントを試しましたが、テーマコンポーネントには制限があるため、実現できませんでした。
最終的には、他の広告ネットワークからの を表示するために必要なことを行うには、プラグインが必要になります。残念ながら、現時点ではこれに対応するプラグインは存在しません。唯一の望みは、Discuss が Ads プラグインに汎用の広告スクリプトを追加し、広告領域に注入する必要があるサードパーティの広告スクリプトをサポートすることです。現在では基本的に Google DFP しか使用できませんが、他の広告プロバイダーを使用する場合、困ってしまい、フォーラムの収益化が不可能になります。これは残念なことです。Adbutler や Openx など、他にも優れた広告ネットワークは多数存在し、Google DFP を使用して広告を提供することを強要されるべきではないからです。
Discourse が Ads プラグインに汎用の広告スクリプトを追加することを願っています。これが難しいとは思いませんが、正直なところ Ruby や Ember のプログラミングについては詳しくないため、どのように実装すればよいか分かりません。理論的には、プラグイン内でスクリプトタグを受け入れるテキストエリアを用意し、それをプラグインが既に指定している広告領域に注入すれば十分です。特定の広告ネットワークごとに個別の実装を行う必要なく、純粋な HTML しか受け付けない入力欄ではなく、汎用のスクリプト入力欄を用意することで、事実上すべての広告ネットワークに対応できるはずです。
ケイレブさん、興味深いのですが、ブログでどのサービスを使っていますか？
文脈がないとご指摘の点に回答するのは少し難しいですね。どの広告ネットワークを指しているのか、具体的にどのように機能しなかったのか、より詳細な情報をいただけると非常に助かります。
それは完全に正しいわけではありません。使用する広告ネットワークによって状況は異なります。広告ネットワークのスクリプトを <body> タグの直下に配置することが厳密な要件である場合（それはあまり考えられませんが）、そのように厳格で不合理な要件を課しているのは広告ネットワーク側の問題です。
テーマに追加されたスクリプトは theme.js ファイルに読み込まれ、その後、ドキュメントの <head> タグに注入されます。
これにより、ある程度の制御が可能になり、壊れたテーマがサイト全体をダウンさせるのを防ぐなどの便利な機能を実装できるようになります。
これも部分的にしか正しくありません。テーマはクライアントサイドのあらゆるものを変更できます。つまり、Discourse で JavaScript で記述されたものはすべてテーマからアクセス可能です。
実際、公式広告プラグイン 全体をテーマコンポーネントに変換しても動作します。唯一欠けるのは ads.txt ファイルを追加する機能ですが、これはバックエンドへのアクセスが必要になるためです。私たちがそうしていない理由は、プラグインの方がこの目的にはよりクリーンな実装であるためです。具体的には、複数のプロバイダーを含むためです。つまり、テーマには制限がありますが、それが今回の主な点ではありません。
ここで非常に重要な点があります。Discourse はシングルページアプリケーション（SPA）です。つまり、初期ページ表示時にアプリをロードした後、その後のすべてのナビゲーションはブラウザではなく Discourse によって処理されます。
これは重要です。なぜなら、広告ネットワークは、シングルページアプリケーションがページ情報を更新し、新しい広告を提供するために必要なフックを提供する必要があるからです。Adbutler や Openx については詳しく知りませんが、どちらのプロバイダーもシングルページアプリケーション対応に関するドキュメントは見つけられませんでした。
つまり、広告ネットワークが必要なフックを提供しない場合、それがサポートされていないのは本当に Discourse の責任なのでしょうか？
DFP を使用することを強制されているわけではありません。公式広告プラグインで利用可能な 6 つのオプションの 1 つに過ぎません。参考までにリストします。
- DFP
- AdSense
- Google ads
- Amazon advertizing
- Codefund
- Carbon Ads
繰り返しになりますが、Discourse はシングルページアプリケーションであるため、「汎用的」なスクリプトでは機能しません。
もちろん、テーマ内で好きな広告スクリプトを読み込むことはできますが、それらは初期ページ表示時のみ発火します。その後に行われることは、広告ネットワークのスクリプトによって検知されません。ただし、広告ネットワークが必要なフックを提供する場合を除きます。
以下は、シングルページアプリケーションをサポートする広告ネットワークでの統合の例です。
実際には、各広告ネットワークごとに具体的なコード実装が必要です。
また、社内広告と広告ネットワークからの広告を混同されているように思われます。ボックスが HTML のみである理由は、そこで独自の社内広告を作成することを想定しているためです。これは非常にシンプルな実装であり、すでにプラグイン内で連携されているため、自社の広告を配信したい場合、シングルページフックについて悩む必要はありません。
さらに、他の広告ネットワークを広告プラグインに含めたい場合は、コミュニティからの貢献に基づいて新しい広告ネットワークを追加する前例があります。
最近の例として、Carbon Ads の統合があります。
ただし、すべてを正しく連携させる負担はあなたにあります。
そのような実装が難しすぎると思われる場合は、それまでです。私は車のタイヤ交換やオイル交換は得意ですが、トランスミッションのメンテナンスが必要であれば、私よりも詳しい人を探して報酬を支払い、やってもらいます。
言いたいことは、もし本当に他の広告ネットワークを使いたいのに自分でうまくいかない場合は、Marketplace でトピックを作成することをお勧めします。適切な予算があれば、きっと開発者の注意を引くことができるでしょう。
詳細な回答とご支援をいただき、ありがとうございます。消化すべき内容が非常に多いです。
しかし、ここで誤解があるように思います。AdButler は Google DFP と同様の「アドサーバー」の一種です。これらのプロバイダーは、広告主と連携して自社の広告を管理するお手伝いをします。一方、Adsense（および Carbon）は「アドネットワーク」に分類されます。アドネットワークはアドサーバーとはやや異なる仕組みで動作します。私たちの課題はアドネットワークではなく、アドサーバーに関するものです。混乱させてしまい申し訳ありません。
事業を継続するためにはウェブサイトから収益を得る必要があり、そのためには広告主を管理するためのアドサーバーが必要です。そのために Ad Butler を利用しています。Discourse の「社内広告」機能では、必要な機能のほんの一部しかカバーできていません。私が知る限り、Discourse の広告プラグインがサポートしているアドサーバーは Google DFP のみです。私個人の見解では、Google DFP は様々な理由からあまり優れていませんが、その点は本議論とは無関係です。もちろん、他のアドサーバーがサポートされていないため、やむを得ず Google DFP を使用する必要があるなら、そうします。Discourse には他にも多くの利点があり、それらが Google DFP を使用する際の面倒さを上回っているからです。
Google DFP 以外のアドサーバーに対応するプラグインを開発するのは私たちの責任であり、Discourse がすべてのニーズに応えることはできないこと、特に標準機能として非常に優れた機能を多数備えていることを十分に理解しています。この件についてはマーケットプレイスにも投稿しましたが、Discourse に詳しい経験豊富な開発者からは、プラグインなしでは実装不可能であり、一見単純な問題にもかかわらず、作業には多額の費用と時間を要すると教えていただきました。
私がまだ Discourse の仕組みを把握していないのはご指摘の通りで、私たちは Discourse の導入と Ruby、Ember の学習を始めたばかりです。しかし、例えば WordPress の場合、Ad Butler の広告スクリプトをウィジェットボックスに配置するだけで、何もプログラミングすることなく動作します。そのため、Ad Butler を Discourse で動作させるのがこれほど手間がかかることに少し驚きました。Discourse は WordPress と明らかに異なり、はるかに複雑であることは理解していますが、なぜこのような単純な機能がこれほど大規模なコーディングを必要とするのかが依然として理解できません。
まとめますと、私たちは引き続き挑戦し、Ad Butler 自体に連絡して支援を仰ぐ予定です。Ad Butler にとっても Discourse 向け機能の開発を支援することは自社の利益にかなうはずです（Ad Butler を一度使えば、もう DFP には戻らないでしょうから）。また、Carbon Ads の統合についても調査し、仕組みを理解して自社のニーズに合わせて修正できないか検討します。
改めてありがとうございます。
Quick follow up, I did look at the code for Carbon Ads in the Ad Plugin, and I have a conceptual understanding of how this was done, so hopefully we can use this a springboard to implement Ad Butler. Thanks for the heads up on Carbon Ads.
こんにちは @sfoster さん、AdButler 統合の最新情報はいかがでしょうか？
いいえ。数人のプログラマーに連絡しましたが、まだ確実な見積もりとスケジュールは出ていません。WordPress では、コードをウィジェットに埋め込んで完了です。Discourse のプログラミングがこれほど複雑になるとは驚きました。とにかく、もう少し検討しますから、進捗は随時お知らせします。ただ、コアプラグインでサポートされている DFP へ移行する方向で傾いています。それが本当に望ましいことではないものの、やむを得ない状況です。