ウェブサイトのコンテンツを、どう編集するか。
ファイルを Git に置くかどうかだけでなく、下書きの保存先、編集のしかた、公開時の動作も大切です。
まずは、この3つから。
- ウェブサイトはファイルからビルドしますか、API からコンテンツを取得しますか？
ファイルベースのサイトなら、下記の4つの Git エディターを比較しましょう。アプリや複数の配信先に API でコンテンツを届ける必要があるなら、Sanity や Payload も検討できます。
- 作業中の内容は、どこに置きますか？
保存時に Git がどう変わるか、下書きを誰が見られるか、レビューから公開へどう進むかを比較しましょう。実際の下書きを同僚と編集してから決めるのがおすすめです。
Git・ファイルベースの CMS
ファイルはそのまま。作業の流れを選ぶ。
これらのツールも、ファイルや Git でコンテンツを扱います。違いは導入方法、編集体験、下書きから公開までの流れにあります。
TinaCMSコンテンツスペースか、ウェブサイト内での編集か。
Git ベースのコンテンツ API と、サイトに組み込むビジュアル編集を備えた CMS。
比較を読む
Keystatic共有のコンテンツスペースか、コードで設定する CMS か。
ローカルや GitHub のファイルを読み書きする、設定可能なコンテンツエディター。
比較を読む
Decap CMS下書きはコンテンツスペースに置くか、Git のブランチで管理するか。
編集操作を Git 操作に対応させる、拡張可能なオープンソース CMS。
比較を読む
Pages CMSリポジトリを直接編集するか、公開前に下書きを挟むか。
GitHub の静的サイトに、軽量な編集画面を提供。
比較を読む
データベース型 CMS
Git のファイルか、API 経由のコンテンツか。
構造化コンテンツのプラットフォームには、別の用途があります。保存方式と、コンテンツ基盤の運用で担う範囲を比較しましょう。
ドキュメントの構造が分かるビジュアルエディター。
Markdown・MDX のビジュアル編集に加えて、Starlight、Fumadocs、Prosefly コンポーネントに個別対応。同じエディターで、対応するドキュメント用ブロックを扱えます。
Starlight注意書き、タブ、カード、ファイルツリーを編集。Starlight のコンポーネント構文と Expressive Code のメタデータに対応します。
FumadocsFumadocs のコンポーネント構文と対応するプロパティで、コールアウト、タブ、ステップ、アコーディオンを編集。
Prosefly コンポーネントLotus と Dahlia で使われる @prosefly/astro-components のコールアウト、タブ、カード、アコーディオンを編集。
対応範囲はコレクションのエディタープロファイルと、認識できる構文によって異なります。独自のコンポーネントや未対応の式はソースで編集でき、リポジトリのコードは実行しません。
ビジュアル編集を見る今のウェブサイトに、書く場所を。
リポジトリを接続して、ご自身のコンテンツで一連の操作を試せます。