debryc
(Deborah Chang)
2020 年 10 月 28 日午後 8:20
1
技術スタックを簡素化するために、ウェブサイトとフォーラムを別々にホストするのではなく、Discourse を再構成して、ウェブサイトとフォーラムの両方を統合して運用すべきではないかと考えています。
@angus 氏の「Pavilion」も、Discourse をこのように活用しているようです。
ただし、私たちのウェブサイト要件はもう少し複雑です。現在のウェブサイトは以下の通りです。
Discourse のみで構築された他のウェブサイトを探索できるかどうか、あるいはこの実現方法に関するアイデアがあれば、ぜひ教えていただければ幸いです。
「いいね!」 5
IAmGav
(Gavin Perch)
2020 年 10 月 28 日午後 8:34
2
ええと、投稿以外のコンテンツには ページ公開 を利用することが可能です。
その後、ヘッダーサブメニュープラグイン を使ってサブメニュー付きのトップメニューを作成するか、別のプラグイン を使ってサブメニューなしのメニューを作成することもできます。
すべて、あなたの要件次第です。
「いいね!」 4
debryc
(Deborah Chang)
2020 年 10 月 28 日午後 9:02
3
はい!それらは素晴らしいスタートだと思います。
私たちの要件の一つは、ニュースレター登録フォームや 寄付フォーム などのものを埋め込めることです。
「いいね!」 4
debryc
(Deborah Chang)
2020 年 10 月 28 日午後 9:06
4
ページ公開におけるカスタムスタイリングの威力がどれほど大きいのか、私にもまだ完全には把握できていません。背景の異なるコンテンツブロックなど、より装飾性の高いページの実例は存在するのでしょうか。
「いいね!」 2
Stephen
(Stephen)
2020 年 10 月 29 日午前 6:14
5
この問題は、以下の 3 つに集約されます。
「公開コンテンツ」(a) とコミュニティ (b) の量
(a) と (b) へのアクセス数の割合
あなたの予算
適切なキャッシュと CDN を導入すれば、5 ドルの VPS で WordPress を動かして数百万回のページビューに対応することも可能です。同等の Discourse インスタンスであれば、はるかに、はるかに 高額になります。
トラフィックとアクティビティの大部分が Discourse 内で発生し、静的ページへの急激なトラフィック増加のリスクがない場合、すべてを Discourse 内でホストするのが合理的な選択肢となり得ます。それ以外の場合は、依然として適切な CMS が最善の選択です。
「いいね!」 11
merefield
(Robert)
2020 年 10 月 29 日午後 12:39
7
えーと、HTTPSと証明書の問題を解決したほうがいいかもしれませんね。
「いいね!」 4
osioke
(Osioke Itseuwa)
このトピックを分割しました:
2020 年 10 月 30 日午後 1:06
8
hawm
(Hawm)
2020 年 10 月 29 日午後 12:47
9
Discourse は Rails のバックエンドであり拡張可能です。Rails アプリでできることは何でもできると私は思っていますが、あなたは「魔法の弾丸」をお探しでしょうか?
「いいね!」 1
Falco
(Falco)
2020 年 10 月 29 日午後 4:36
12
確かにそれは可能であり、組織によっては理にかなっているかもしれませんが、Discourse ではメインのウェブサイトに別のソフトウェアを使用しています。
当社のメインのウェブサイトは https://jekyllrb.com/ によって生成された静的 HTML で、ブログはシンプルな WordPress インスタンスです。
これは、組織のエンジニアリング構造や、抱えるニーズや優先順位によって大きく異なります。
「いいね!」 7
pfaffman
(Jay Pfaffman)
2020 年 10 月 29 日午後 4:47
13
ラファエル、ありがとう。
WordPress から抜け出したいという思いは強いよ。最初は Discourse だけのソリューションにしようかと思っていたけど、今は www.literatecomputing.com にある静的な情報部分は Jekyll で運用し、収益化に関わる部分だけを Discourse と、これから登場する discourse-subscriptions プラグインに移行しようと考えている。インストール、アップグレード、その他のメンテナンスを行うツールをフロントエンドとして提供する Discourse プラグインを今、熱心に開発しているところだ。
「いいね!」 7
syl
2020 年 10 月 30 日午後 12:49
26
参考までに、Discourse を完全に使用して作成された 2 つのウェブサイトをご紹介します(最初のサイトは Docuss プラグインを使用していますが、現在は廃止されています。2 番目のサイトは DiscPage プラグインを使用しています):
http://www.docuss.org/
https://en.castafiore.org/
「いいね!」 7
debryc
(Deborah Chang)
2020 年 10 月 30 日午後 6:09
27
Stephen:
この問題は以下の 3 つに集約されます:
「公開コンテンツ」(a) とコミュニティ (b) の量
(a) と (b) へのアクセス数の割合
あなたの予算
適切なキャッシュと CDN を導入すれば、5 ドルの VPS で WordPress を動かして数百万のページビューを処理することも可能です。同等の Discourse インスタンスは、はるかに、はるかに 高価になります。
トラフィックやアクティビティの大部分が Discourse 内で発生し、静的ページへの急激なアクセス増加のリスクがない場合、すべてを Discourse 内でホストするのが合理的かもしれません。それ以外の場合は、依然として従来の CMS が最善の選択肢です。
意思決定のためのこのフレームワークをありがとうございます!
正直に申し上げますと、その意味がよくわかりませんので、ここで技術担当者にバトンを渡します。
@pfaffman についてもう少し詳しく教えていただけますか?どのような課題がおありなのでしょうか?私はまだ CMS を検討中で、WordPress も候補の上位にあります。
この件について情報交換させていただくことに非常に興味があります!
「いいね!」 3
debryc
(Deborah Chang)
2020 年 10 月 30 日午後 6:11
28
はい、まさに私が求めていたものです。ありがとうございます!
「いいね!」 5
pfaffman
(Jay Pfaffman)
2020 年 10 月 30 日午後 10:47
29
公平を期して言えば、私は PHP がその名前で呼ばれる前から学んでおり、現在のようにモダンな言語に進化した後の動向にはついていけていません。また、私のニーズは非常に特殊です(決済処理を行い、Digital Ocean の droplet を作成して Discourse をインストールする必要があるため)。
しかし、ここ数回、Discourse や WordPress の調整を「簡単で速い仕事」と思い込んで 500〜1000 ドルで請け負った際、後悔させられました。最も最近のケースでは、多くの時間を費やし、結局はお金を返金せざるを得ませんでした。もちろん、簡単な作業なら彼らも私を雇わなかったでしょう。また、別のクライアントには、無数の更新されずアップグレード不可能なプラグインを抱えた WordPress サイトがあります。これはまさに破滅的な状況で、どこかでハッキングされ、ポルノへのリンクが多数埋め込まれています。これは簡単に回避できる問題ですが。
他方、過去 1 年ほどは WooCommerce ではなく Gravity Forms を使用しており、ワンタイム決済やサブスクリプション型の決済(Discourse とは連携していませんが)において非常に満足しています。(ただし、Discourse のインストールを正確に希望するタイミングで実行させることができないのです!)
「標準的」な作業を行い、サポートの整ったプラグインに徹すれば、おそらく後悔はないでしょう(ただし、Discourse のサブスクリプション処理には discourse-subscriptions を使うことをお勧めします)。インターネット上のサイトの 4 分の 1 が WordPress を使用しており、それには確かな理由があります。
「いいね!」 7
debryc
(Deborah Chang)
2021 年 2 月 26 日午後 3:17
30
更新:当社のウェブサイトと Discourse では、それぞれ別々のシステムを採用することになりました。主な理由は、ウェブサイトコンテンツの更新が必要な人々が主に技術に詳しくない方々であり、非常に使いやすいコンテンツ管理システムを利用することで大きなメリットが得られるからです。当社は Weebly を利用して、誰でも簡単にコンテンツを更新できるようにしていますが、それ以上に優れているのは、寄付プラットフォームと連絡先管理システムを一元管理できる有料プラットフォームを採用している点です。このプラットフォームには専任の技術チームが付いており、ウェブサイトのテーマ、構成、埋め込み機能など、より高度な変更もメール一つで対応してもらえます。彼らは Weebly サイトの管理を担当しますが、Discourse は対象外です。
2 つのサイトを別々に運用することになった今、これらを一貫性のあるものにする方法を検討する必要があります。ここで @angus さんに感謝の意を表します。彼の会社が PianoGroove コミュニティをサポートしており、これまでに私が目にした中で最も美しい統合を実現しています(私は数多くの事例を見てきましたが!)。
PianoGroove ウェブサイト
PianoGroove コミュニティサイトのスクリーンショット
@angus さん、クライアントのために素晴らしい仕事をしてくださり、さらに作成したプラグインやテーマをオープンソースとして提供してくださるご厚意に心から感謝申し上げます。当社のウェブサイトと Discourse を完璧に機能させるまでにはまだ道のりは長いですが、何度も繰り返し感じるのは、Pavilion が手がける仕事が、まさに当社のオープンソース・草の根・コミュニティ組織に必要なものであるということです。
「いいね!」 16
angus
(Angus McLeod)
2021 年 3 月 1 日午前 1:25
31
@debryc さん、ありがとうございます
付け加えると、私たちの作業を維持しているのは私だけではなく、すべてのパビリオンメンバー です。私たちの協同組合はチームワークの賜物です。
また、Discourse インスタンスをバックエンドとして完全な独立ページを可能にするLanding Pages プラグイン をオープンソース化しました。これはこのトピックで議論されているニーズを満たすもう一つの手段です。このプラグインは、Discourse クライアント(つまり Discourse アプリの読み込み)とは別にページのフロントエンドを分離しつつ、共通のバックエンド(つまり Discourse サーバー)を通じて簡単な統合を可能にします。
私たちはすでに、ここで議論されているものと同様のニーズを満たすために、いくつかのクライアントでこのプラグインの使用を開始しています。また、コミュニティに関連する CMS の一般的なユースケースに基づいた、使いやすい汎用オープンソースのページパッケージの開発も検討しています。
現在、このアプローチを採用することを検討しているユースケースのリストは以下の通りです。
ブログ(現在、この作業に取り組んでいます)。Discourse でコンテンツを作成し、それを WordPress や Ghost のような実際のブログのようにテーマを設定できる、完全に独立したブログページとして表示します。
製品、サービス、または機能ページ( ours のようなもの)。Discourse インスタンスから取得したコンテンツやデータ(カテゴリ、タグ、トピック、ユーザーなど)を含む製品、サービス、または機能を表示します。
「チーム」ページ(ours のようなもの)。Discourse ユーザーグループのメンバーシップ(およびユーザーデータ)を使用した、チーム専用のページです。
イベントページ。Discourse インスタンスからのイベントデータをリスト表示し、スタイリングされたイベントランディングページで表示します。ここでいう「イベントデータ」とは、Discourse Calendar プラグインのデータ、カテゴリ、トピック、ユーザー(例:RSVP)、および Locations プラグインを使用した場所の組み合わせを指します。
私たちは、このアプローチが役立つと思われる他の汎用可能なユースケースにも関心があります。現時点で検討済みですが、この段階ではこのアプローチが適用される可能性が低いユースケースもいくつかあります。
ショップ。ストアの要素を統合するページはあるかもしれませんが、オンラインストアには WooCommerce や Shopify のような専用ソリューションを必要とする多様な機能が必要です。
ナレッジベース。このニーズは、Knowledge Explorer プラグイン などのソリューションですでに十分に満たされています。ランディングページはナレッジベースの一部を表示することはできますが、Knowledge Explorer プラグイン(または単に Discourse のトピックリスト)の機能を完全に再現することは非効率的です。
私たちは、そのようなページを開発したいと考えている方々と協力することに興味があります。それはスキル向上のための開発プロジェクトとして、あるいはコミュニティのために、あるいは販売目的であっても構いません。中期的(4〜6 ヶ月)には、各ユースケース向けの独自の無料オープンソースパッケージをリリースする予定です。
Landing Pages プラグインおよびパビリオン独自のページは、常に 100% オープンソースで無料です。ただし、これは HTML と CSS の知識があれば誰でも「ページパック」を開発できる汎用可能な構造です。近日中に、このプラグイン向けの「開発者ガイド」を knowledge docs に追加する予定です。
Landing Pages プラグインは、Discourse テーマシステムと同様に、プライベートリポジトリでのページホスティングをサポートしています(実際、裏側では Discourse テーマシステムをベースに拡張しています)。つまり、必要であればランディングページパックへのアクセスを販売することも既に可能です。これは他の開発者にとって、そのようなパックを作成する価値があるかもしれません。
このアプローチは、フォーラムに関連するすべてのコンテンツ管理のニーズに対応するものではありませんが、特に小規模で独立したコミュニティで定期的に目にするような特定のサブセットには非常に効果的です。なぜなら、独立したインスタンスの必要性、そして何より、認証プロトコル(ログイン時のユーザーデータの共有)、ウェブフック、または他のデータ共有方法を通じてそれらのインスタンス間でデータを共有する必要性を排除できるからです。
これにより、フォーラム alongside で比較的限定されたまたは特定のコンテンツ、あるいは静的ページを管理しようとする小規模なコミュニティにとって、コストと管理負担を軽減できます。これは WordPress や他の CMS システムの直接的な代替手段にはなりませんが、特定のユースケースを大幅に容易にすることを願っています。
「いいね!」 19
はい!そしてありがとうございます!
スクリプトの実行を許可するページ
Discourse ベースのコミュニティに参加してまだ 2 ヶ月半です。私が直面しているのは、スクリプトの埋め込みを必要とする特定のツールへのニーズです。
カレンダーの例:カレンダーやイベント管理のツールをページに埋め込むことはできます。しかし、それには \u003chead\u003e タグへのスクリプトの追加が必要であり、かつページに対してそれをトリガーする必要があります。
より一般的な SAS(ソフトウェア・アズ・ア・サービス)の場合:多くの場合、iframe は最適ではありません。例えば、メンバーが別のサイトに移動してオプトインする必要は避けたいのですが、私のオプトインサービスである ConvertBox には \u003chead\u003e スクリプトと \u003cdiv\u003e が必要です。
コミュニティの提供内容を強化するにあたり、明確になっていることは、スクリプトベースの埋め込みをより簡単に追加する機能を「解決」しない限り、OneBox がサポートする機能に依存するか、iframe を使用するしかないということです。もし、このようにスクリプトの制御やトリガーを可能にする拡張された「ページ」機能があれば、WordPress サイトを引退させることも夢ではありません。
コーディングはできませんが、コミュニティの利益のために、このような開発を金銭的に支援することはできると考えています。ありがとうございます!
「いいね!」 3
angus
(Angus McLeod)
2021 年 3 月 4 日午前 8:06
33
埋め込みは、テーマを使用して Discourse UI(例えばトピックリストの上)でも、ランディングページプラグイン でも可能です。後者については、この 小さなバージョンの恐竜ゲーム を使用した例を作成しました。こちらでプレイできます:Pavilion
この場合はコーディングは不要です。私が行ったのは、これらのアセットを CDN にアップロードすること(フォルダを DigitalOcean の「スペース」にドラッグ&ドロップ)、パス「dinosaur」を持つページを作成すること、そしてこの HTML をコピー&ペーストすること(どちらも管理画面から)でした。
HTML
<div class="landing page dinosaur">
<div class="container">
<h1>Dinosaur Game!</h1>
<canvas id="game" height="200" width="800"></canvas>
<p class="controls">スタートするにはスペースキーを押してください</p>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/helpers.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/objects/game-object.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/objects/cactus.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/objects/dinosaur.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/objects/background.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/objects/score.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/game.js"></script>
<script>
new Game({
el: document.getElementById("game")
});
window.onkeydown = function(e) {
return e.keyCode !== 32;
};
</script>
</div>
</div>
ランディングページプラグインは Discourse の CSP および CORS 設定を実装しており、これらはすでに CDN からのスクリプトを処理するように設定済みです(関連するサイト設定を通じて)。
来週、このプラグイン向けの完全な「アセットのホスティングと埋め込み方法」に関するナレッジベースのトピックを投稿して、このユースケースをカバーする予定です。
「いいね!」 8
ありがとうございます、出発点として役立ちました。
テーマ内でこれを行う方法が見つかりませんでした。例えば、各トピックの変更時に読み込まれる、またはトピックリストの上に配置されるタグを挿入する方法です。テーマをカスタマイズして、ヘッダーの後に配置する必要があるのでしょうか?
「いいね!」 2