Discourse と 私の個人的な使用経験

[Mister]

こんにちは。

これは meta.discourse での私の最初のトピックであり、私の意見と discourse との最初の出会いの結果について書きたいと思っています。

背景

まず、自分の目的に合ったフォーラムエンジンを探しているときに、偶然 discourse に出会ったことを言っておくべきでしょう。そして、その初期段階はかなり好意的に進みました。特に、私が要求する機能がうまく実装されていることに気づきました。

1. Webhook
2. 達成システム
3. 他のサービスとの統合のための豊富な機能
4. インターフェースの近代化、その他多数…

正直なところ、Discourse はその能力に私を驚かせました。そして、作者がこのプロジェクトをサポートし続けていることに感謝しています。

最初の問題

しかし残念ながら、私が自分で発見した欠点もあり、それらが原因で discourse とのやり取りを続けることができませんでした。順を追って説明すると、まず、私が適切だと考えるフォーラムエンジンには 3 つのルールを定義しました。

1. API 管理
2. 便利な管理
3. あらゆるインターフェースを自分のニーズに合わせてカスタマイズできる機能。

Discourse は API と管理パネルについては優れていますが… 近代化に深く入り込むと、行き詰まってしまいました。

私を襲った最初の「獣」は、Discourse のバージョンの違い、そしてそれに伴う Discourse コンポーネントとテーマの書き方の違いでした。一部はウィジェットを使用し、一部は Ember JS を使用し、一部は別のものを使用していました… これは私だけでなく、Discourse の学習を時々スピードアップするために使用していた AI にも混乱を引き起こしました。しかし、次の「獣」のために、AI は私をさらに混乱させるだけでした…

2番目の「獣」は、読みやすい形式で、かつ複数の言語での質の高い豊富なドキュメントの欠如です。管理者ができるだけ早くこれに注意を払ってくれることを強く願っています。はい、もちろん、Discourse コンポーネントとテーマの設定と作成に関するトピックを読みましたが、Discourse のアーキテクチャを理解するために必要な知識は得られませんでした。特に、このリンクを完全に偶然見つけました: Upcoming Header Changes - Preparing Themes and Plugins これにより、ベータ版でコードを常に間違って書いていた理由がわかりました 明確で詳細なドキュメントがないバージョンの違いは、Discourse にとって痛い問題です… それらの組み合わせは大きなマイナスの反動を生み出し、私が Discourse を最大限に活用することを妨げました。フォーラムの外観を深く近代化することが非常に必要ですが、残念ながら現在の「ドキュメント」ではそれができません。このため、私は一時的に Discourse に別れを告げる可能性が高いですが、その開発を追っていきます。

3番目の「獣」は、discourse に関する情報の相対的なカタログ化です。この情報や、この操作を行う方法を見つけるのは非常に困難です。運と英語の知識次第だと思います。そうでなければ、「幸運なイギリス人」でない場合は、一日以上苦労することになります。これは疲れます。

そして最後に、discourse に対する私の個人的な欠点は、Docker のみ（公式のインストール方法として）を使用していることです。この発言で憎悪の波を受ける可能性があることは承知していますが、それでも、そのような製品には回避策なしの代替インストール方法があるべきだと信じています。場合によっては、既存の Docker イメージファイルを近代化する必要さえあるかもしれませんが、コンテナコンストラクターのため、実装するのは非常に不便です。まあ、あるいは適切な方法を見つけられなかったのかもしれません…

結論

Discourse には、現時点でそれを選ばないだけの欠点が十分にありますが、将来的にそれを選んで自分の目的に使用できるようになると確信しています。このプロジェクトの開発者と管理者が discourse の欠点（このトピック/記事で述べたものを含む）に注意を払うことを期待しているからです。Discourse はすでに私の意見では非常に高品質なプロジェクトですが、まだ「一般的な」使用には成長していないようです。しかし、これは一時的なものです。

記事にご注意いただきありがとうございます。
追伸：AI「Manus」はロシア語から英語への翻訳に使用されました

[pfaffman (Jay Pfaffman)]

はい。10年前は機能していたものが、今は機能しないこともあります。新しいテーマ開発者ガイドがあります。これは非常に優れており、あなたの「多くの問題」に対処しています: Theme Developer Tutorial: 1. Introduction

[NateDhaliwal]

@Mister

そして最後に、Discourseに対する私の個人的な欠点は、Dockerのみを使用していることです（公式のインストール方法として）。

こんにちは。これは#unsupported-installですが、DockerなしでDiscourseをインストールするためのガイドがあります。

Deploy Discourse without Docker

Though it is more convenient and safer to deploy Discourse following the official install guide, I want to dive deeper into the container and see how it can be deployed in Linux without Docker. I want to share the steps just for your information. You adapt it and use it at your own risk. Dive into how Discourse is run in container prepare system FYI, I use Ubuntu 24.04 and zsh. Follow PG’s offical installation guide to install postgres from PostgreSQL Apt Repository. I installed the version…

[Mister]

その通りです。そのため、そのような公式なインストール方法はないことを明確にしました。

[tdperry]

私の最大の懸念は、多くのプラグインが最新のインストール環境ではインストールに失敗することです。

試さなかったわけではありません。最初のサイトのインストールは Ubuntu 24.04 LTS で Docker を使用して行いました。初期インストール後、いくつかのプラグイン（最新でサポートされているように見えましたが、実際はそうではありませんでした）を追加して再構築するたびに、Discourse アプリの再構築が頻繁に失敗しました。

プラグインを削除して再構築しようとしても、失敗しました。

最終的な解決策は、AlmaLinux のインストール環境に Docker を使用することでした。少なくとも今では、現在のバージョンが好まないプラグインを追加した場合、Ubuntu のインストール環境とは異なり、app.yml から削除することでアプリを再構築できます。

また、私はウェブサイトを運営する新しい管理者ではありません。Woltlab、Xenforo、Invision、SMF、phpBB、myBB、NodeBB など、10 年以上にわたりフォーラムベースのウェブサイトを運営してきました。MS-DOS/DesqView の時代やマルチノード BBS（最終的には OS/2 Maximus/2 マルチノードシステムで、4 つのノードがあり、そのうち 3 つはユーザーが直接アクセスでき、4 つすべてが FidoNet メールを処理できるようになっていました）まで遡ります。ですから、この分野は初めてではありません。

Discourse の 私のサイト で見られるものは気に入っています。現在、Xenforo と NodeBB も複数のサイトで実行しています。正直なところ、マルチサイトシステムの場合、NodeBB のセットアップの方が Discourse の提供するものよりもはるかに扱いやすいです。VPS インスタンスで NodeBB を 4 つのノード実行した場合の影響が、VPS インストールで 1 つの Discourse ノードを実行した場合よりも少ないことについては触れません。はい、マルチサイトの使用についても調査しましたが、現在はそれだけの価値がある以上の手間がかかります。はい、さまざまなスクリプトを試すのが好きです。見つけた欠点を指摘することに問題はありません。

Discourse はしっかりした基盤を持っていますが、管理者が現在の手間をかけずに複数のサイトをセルフホストで簡単に実行できるようにする必要があります。

[Heliosurge (Dan DeMontmorency)]

Telegard Hack BBSESのDOS時代、最も人気があったのはRenegade BBSでした。PCBoardには独自のスクリプトプログラミング言語があり、AmigaやCommodore 63のBBSもありました。楽しい日々でした。

幸いなことに、Ubuntu LTSでDiscourseを実行しています。プラグインのインストールがうまくいかなかった場合、通常はプラグイン行を削除/コメントアウトするだけで済み、問題は最小限で済みます…時折、失敗した場合は2回再構築する必要があることもありました。

[tdperry]

@Heliosurge

私はUbuntu LTSでDiscourseを実行して幸運でした。プラグインのインストールがうまくいかなかった場合、通常はプラグインの行を削除/コメントアウトするだけで最小限の問題で済みます…時々、失敗した場合は2回再構築する必要があるかもしれません。

私が抱えていた問題は、それらがリストされていると決して再構築されなかったことでした。
しかし、追加の問題も見つけたようです。設定ファイルが正確でない場合（新しい行に余分なスペースやタブがある場合）、プラグインを追加する際にうまく機能しないようです。プラグインリストの下のすべての空行を削除したので、それらは本来あるべきようにビルドされているようです。
ほとんどの人がUbuntuを使用しており、それはまともなOS（私が使用している天体写真キャプチャソフトウェアのベースです）であることを知っていますが、私はしばらくの間AlmaLinuxを使用しており、それを好んでおり、それは正常に動作しているようです。

[Heliosurge (Dan DeMontmorency)]

そうですね、YMLファイルはレイアウトに非常に細かいです。

[tdperry]

ええ…それはわかっています。そして正直なところ…それは多くの点でスクリプトの提供における弱点です。
私は有料スクリプトを使用しており、プラグイン（アドオン）のインストールがより統合されています…そしてそのスクリプトは残念ながら、それに対して大金を支払ったライセンス所有者に提供すべきものよりもさらに遅れています。
Discourseの開発者が、テキストベースの設定ファイルを編集する必要なく、スクリプト自体から直接アドオンをインストールできるように統合できれば、それは大きな改善になるでしょう。しかし残念ながら、他のいくつかのスクリプトと同様に、開発者は自分のやり方に固執しており、多くの人が前進と見なすものを見ようとしないようです。

私は、人々に最適なスクリプトを紹介することに問題はありません。しかし、初心者にとっては…Discourseは、特に1つのサーバーインスタンスで複数のサイトを実行したい場合、セルフホスティングにはまだ十分ではありません。
私は1つのサイトで使い続けます…しかし、それはまた、1つのサーバーでDiscourseをマルチホームすることにおいて、依然として大きな手間です。NodeBBでさえ、多くの側面でDiscourseが提供するものExceedsしています。

[Heliosurge (Dan DeMontmorency)]

ええ、あまりユーザーフレンドリーに作られているわけではありません。@pfaffman は、プラグインのインストールやその他のさまざまな特典を自動化できるWebインターフェイスも提供しています。ただし、これは年間料金ですが、個人的には追加される機能に対してはかなりリーズナブルな価格だと思います。

[tdperry]

ありがとうございます。XenForoとNodeBBの両方で、ACPから直接インストールできることに慣れていました。
その一つの癖がわかった今、その機能のためにわざわざお金を払う価値はあまりないですね。
私はすでに、収入のないサイト/サーバーで年間約2800ドルを費やしています。それらは私にとって趣味のようなものです。
スクリプトに投資するつもりなら、基本的なフォーラムにいくつかの調整を加えた以上のことをしたいと思っています。それが私が運営しているアストロサイトの理由です。