WordPressとOctoberCMSの詳細な比較

3か月前、WordPressはついにReactを搭載したGutenbergをリリースし、デフォルトのコンテンツ編集エクスペリエンスを強化しました。これにより、この変更に満足していない多くの人々が代替案を探すようになりました。 グーテンベルク以前のWordPressをフォークしてリリースすることを決めた人もいますが、15年分の技術的負債が残っているため、これはあまり意味がありません。 WordPressに代わるものを見つけたら、過去にとらわれることを避け、現代の基盤の上に構築された成熟したプラットフォームをきれいに切り抜けることを目指します。

この記事では、WordPressを、技術的トピックと非技術的トピックの両方について、ほぼ同じでありながら最新の10月のCMSと比較しています。 この記事の目的は、WordPressに固執したり、10月のCMSに切り替えたりするように人々を説得することではなく、別のプラットフォームへの移行を完了する前に考慮しなければならない側面を示すことです。 賢明な決定を下す前に、他のプラットフォームでも同じ比較を行うことができます（そして行う必要があります）。

なぜ10月のCMS

10月のCMSが受賞したことを知り、その後リサーチモードに入り、ユーザーと開発者の両方の観点から、このCMSを深く掘り下げました。 このCMSについての知識を得るにつれ、WordPressとは対照的にその機能の客観的な評価を提供できると確信しました。 次の理由から、Grav、Statamic、ButterCMS、Joomla、Drupal、Jekyll、Hugoなどの代替オプションとの比較のためにこのCMSを選択しました。

• 私はこのCMSがどのように機能するかを知っています（Gravとは異なります）。
• これは無料でオープンソースです（StatamicやButterCMSとは異なります）。
• 5年後、それは「比較的」新しいものです（JoomlaやDrupalとは異なります）。
• これは動的な（静的ではない）コンテンツジェネレーターであり、PHPに基づいています（JekyllやHugoとは異なります）。
  

10月のCMSは、最新のアプリケーションを構築するために使用されるフレームワークであるLaravelに基づいているため、良い候補だと思います。 7年間の存在後、開発者から肯定的な承認を受けており（その大きなコミュニティとエコシステムによって証明されています）、WordPressのコーディングとは明確に対照的です。つまり、WordPressはほとんど手続き型プログラミングであり、Laravelは明らかにオブジェクト指向プログラミングです。

2つの違いは何ですか？

以下では、WordPressとOctober CMSをさまざまなカテゴリで比較し、それらについて良い点と悪い点を強調します。 ただし、勝者は選びません。これは記事の目的ではなく、いずれの場合も「最良」または「より良い」CMSは存在しないためです。各CMSには、それを実現する独自の長所と短所があります。各タスク、プロジェクト、会社、チーム、およびその他すべてに多かれ少なかれ適しています。 さらに、プロジェクトでは、データの管理と提供に一部のCMSを使用し、ビューをレンダリングするために別のCMSを使用するなど、複数のCMSを使用することでメリットが得られる場合があります。 そこにある数十のCMSのどれがあなた自身のニーズに最も適しているかを決定することは、完全にあなた次第です。

さらに、この記事はすべての可能性のサブセットにのみ関係しているため、決定的な結論を引き出すことはできませんでした。 たとえば、「WordPress vs Drupal vs Joomla」、「WordPress vs Static Site Generators」、さらには「WordPressvsMedium」などのオンライン比較も見つけることができます。 これらの記事のいずれも全体像を把握していないため、これらの比較のいずれも決定的なものになることはなく、そのように扱われるべきではありません。

比較から始めましょう。

哲学とターゲットグループ

WordPressが3つのWebサイトのほぼ1つに電力を供給しているのは偶然ではありません。 創業以来、非常にユーザーフレンドリーであるように努力し、成功を収めてきました。教育や経済レベルに関係なく、技術ユーザーと非技術ユーザーの両方、およびあらゆるバックグラウンドの人々の摩擦を取り除きました。 WordPressの創設者であるMattMullenwegは、現在の時代のWordPressの「DemocratizePublishing」のモットーは次のことを意味すると述べました。

「すべてのバックグラウンド、興味、能力の人々は、オープンWebで自分自身を表現し、コンテンツを所有できるようにするFree-as-in-speechソフトウェアにアクセスできる必要があります。」

WordPressは誰にとっても使いやすく、その包括性は開発側でも証明されています。プログラミングのバックグラウンドを持たない人（マーケター、デザイナー、ブロガー、営業担当者など）が、WordPressのインストールをいじったり、設計したりすることは珍しくありません。独自のテーマと独自のウェブサイトの立ち上げに成功しました。 WordPressはユーザー中心であり、ユーザーのニーズは開発者のニーズよりも優先されます。 WordPressでは、ユーザーはキング（またはクイーン）です。

対照的に、10月のCMSは、最初のリリースから明示的に確立されたように、開発者を対象としています。

「10月は、大胆でありながら明白な仮定を1つ作成します。クライアントはウェブサイトを構築しませんが、開発者は構築します。 クライアントの役割は、Webサイトを管理し、ビジネス要件を伝えることです。 Web開発者、そして業界自体は、これらの要素を仲介することを中心に展開しています。」

創設者の言葉を借りれば、CMSの使命は、「ウェブサイトの作成がロケット科学ではないことを証明すること」です。 Laravelに基づいている10月のCMSは、適切に設計されたアプリケーションを生成でき、長期的に保守可能で、ハッキングを必要とせずに完全にカスタマイズできる、再利用可能なモジュラーコードの強力な基盤を備えていると主張できます。これは、真面目なプログラマーを魅了するタイプです。 10月のCMSも優れたユーザーエクスペリエンスを提供できますが、WordPressが提供するものほど単純でも摩擦もありません。 ユーザーは、特定の機能を使用する前に、その使用方法を説明する必要がある場合があります。 たとえば、いくつかのプラグインからフォームを埋め込むには、その方法について長い説明があります。これは、WordPressのいくつかのフォームプラグインによって提供される自明のドラッグアンドドロップ機能よりも面倒です。

インストール

WordPressは5分間のインストールで有名ですが、多くの人が（インストールする必要のあるすべてのプラグインを考慮すると）通常のインストールには15分以上かかると指摘しています。 さらに、WordPressはマルチサイト機能も提供しており、1回のインストールで複数の仮想サイトのネットワークを作成できます。 この機能により、代理店は他のユーザーケースの中でも特に複数のクライアントのサイトを簡単に管理できます。

10月のCMSのインストールも非常にスムーズです。ウィザードのインストール自体は5分もかからず、コンソールのインストールからインストールするとさらに高速になります。 後者は、ターゲットディレクトリに移動し、 curl -s https://octobercms.com/api/installer | phpを実行するだけで実行できます。 curl -s https://octobercms.com/api/installer | php （その後、データベース構成を入力する必要があります。そうしないと、フラットファイルCMSとして動作します）。 インストールが完了すると、完全に機能するWebサイトが作成されますが、それでもかなりの状態になります（必要なプラグインのインストールと構成に必要な時間を追加すると、少なくとも15分かかることが予想されます）。

安全

WordPressは、絶えず発見されている大量の脆弱性のために安全ではないと非難されてきました。 これにより、セキュリティの悪用を回避するために、ユーザーはCMS用のソフトウェアとインストールされているすべてのプラグインを常に最新の状態にする必要があります。 主な問題の中には、PHP開発コミュニティでサポートされなくなった古いバージョンのPHPに対するWordPressのサポートがあります（WordPressは現在PHP 5.2.4をサポートしていますが、最新の完全にサポートされているPHPバージョンは5.6です）。 ただし、この問題は、WordPressがPHPバージョン5.6以降のサポートを正式に開始する2019年4月に解決する必要があります。

それ以外の場合、WordPressはそれ自体が原因で必ずしも安全ではありませんが、人気が高いため、ハッカーの主な標的になります。 ただし、これは両方の方法で機能します。WordPressのユビキタスとは、セキュリティチームが常にエクスプロイトを探してできるだけ早く修正することで、真剣に仕事をしなければならないことを意味します。そうしないと、Webの最大3分の1が危険にさらされます。 賭け金は高すぎます。

一方、10月のCMSは、安全ではないという評判はありません。 ただし、WordPressの数百万と比較して10月を使用するライブサイトは約27,000あるため、2つを同じ条件で判断することはできません。 それにもかかわらず、10月のCMSの背後にあるチームは、ハッカーがサイトを標的にすることをより困難にするために、デフォルトで/backendとして設定されているが、他のものに変更可能なCMSバックエンドURLを入力するウィザードインストールのプロンプトによって証明されるように、セキュリティを真剣に受け止めています。 対照的に、WordPressのログインURLとバックエンドURLをそれぞれ/wp-login.phpと/wp-adminから別のURLに変更するには、プラグインを使用する必要があります。 さらに、October CMSはフラットファイルCMSとして（つまりデータベースなしで）機能し、SQLインジェクションなどのデータベース関連の脆弱性を回避できます。

テクノロジースタック

WordPressとOctoberCMSはどちらも、従来のLAMPスタック（Linux、Apache、MySQL、PHP）で実行されます。 （ただし、PHPのみが修正されています。Windows、Nginx、MariaDBなども使用できます。）10月のCMSはフラットファイルCMSとしても動作できます。つまり、データベースがなくても実行できます。多くの機能（ブログ投稿やユーザーなど）が保証される唯一の機能はページです。これは、コンテンツの作成と公開の基本単位と見なされ、コア機能として出荷されます。

言語スタックに関しては、WordPressとOctober CMSの両方で構築されたサイトはHTML、CSS、およびJavaScriptに基づいています（HTMLの生成にはPHPが使用されていることに注意してください）。 10月のCMSでは、LESSファイルとSASSファイルも簡単に使用できます。

プログラミングパラダイム

WordPressは、アプリケーションの状態がない関数を呼び出すことによって計算を計算することに基づいて、関数型プログラミングパラダイムに従います。 WordPress開発者は関数型プログラミング（たとえば、テーマやプラグインのコーディング）に固執する必要はありませんが、WordPressコアコードは、WordPressの成功の柱の1つである下位互換性を15年間維持してきたこのパラダイムを継承しています。しかし、これは技術的負債を蓄積するという意図しない結果をもたらします。

一方、October CMSは、オブジェクトの状態を操作して計算を計算することに基づいて、命令型プログラミングパラダイムに従います。 10月CMSは、オブジェクト指向プログラミングの原則に完全に基づいたWebフレームワークであるLaravelの上に位置し、Model-View-Controllerなどの概念に基づいてモジュラーアプリケーションを作成し、ユーザーインターフェイスをアプリケーションデータから切り離すことができます。とりわけ、クラスの依存関係、およびフレームワークによって提供されるコアサービスを定義するためのインターフェイス分離原則を構成します。

フック/イベント

WordPressでのプログラミングは、「フック駆動型開発」の略であるHDDとして特徴付けることができます。 フックは、デフォルトの動作または値を変更し、他のコードが関連する機能を実行できるようにするメカニズムです。 フックは、追加機能の実行を可能にする「アクション」と、値の変更を可能にする「フィルター」によってトリガーされます。

WordPressコードベース全体に普及しているフックは、WordPressでのコーディングで私が最も気に入っている概念の1つです。 プラグインが他のプラグイン（またはコアやテーマ）とクリーンな方法で対話できるようにし、アスペクト指向プログラミングの基本的なサポートを提供します。

幸いなことに、Laravel（および結果として10月のCMS）は、「イベント」と呼ばれるフックの概念もサポートしています。 イベントは単純なオブザーバーの実装を提供し、コードがアプリケーションで発生するイベントをサブスクライブしてリッスンし、必要に応じて反応できるようにします。 イベントを使用すると、複雑な機能をコンポーネントに分割できます。コンポーネントは、独立してインストールしながら相互に連携できるため、モジュラーアプリケーションの作成が可能になります。

JavaScriptライブラリへの依存

WordPressの最新バージョンには、デフォルトのコンテンツ作成エクスペリエンスのためにReactを利用したGutenbergが組み込まれています。 したがって、WordPressの開発は、他のフレームワークやライブラリを使用することも可能ですが（Marionetteに基づくGutenbergのElementor Blocksで証明されているように）、JavaScriptに大きく依存しています（主にReactを介して）。 さらに、WordPressは依然としてBackbone.js（Media Manager用）とjQuery（レガシーコード）に依存していますが、Gutenbergが新しい標準として統合されるため、これらのライブラリへの依存はなくなると予想されます。

10月CMSはjQueryに依存しています。jQueryは、オプションのAJAXフレームワークを実装して、ブラウザーページを更新せずにサーバーからデータをロードするために使用します。

ページ、テーマ、プラグイン

WordPressとOctoberCMSはどちらも、ページをコンテンツの作成と公開の基本単位として扱い（WordPressの場合、投稿に加えて）、テーマによるサイトのルックアンドフィールの変更をサポートし、プラグインを介してサイトの機能をインストールおよび拡張できるようにします。 概念は両方のCMSで同じですが、実装にはいくつかの違いがあり、動作が多少異なります。

WordPressでは、ページはコンテンツとして定義され、データベースに保存されます。 その結果、ページコンテンツはCMSを介してのみ作成でき（ダッシュボード領域など）、あるテーマから別のテーマに切り替えても、既存のページが使用できなくなることはありません。 これにより、全体的に摩擦のないエクスペリエンスが実現します。

一方、10月のCMSでは、ページはテーマディレクトリの下に保存された静的ファイルです。 このアーキテクチャ上の決定の良い面として、ページコンテンツは、SublimeやVisual StudioCodeなどのテキストエディターなどの外部アプリケーションから作成できます。 マイナス面として、あるテーマから別のテーマに切り替える場合は、現在のテーマから新しいテーマにページを手動で再作成またはコピーする必要があります。そうしないと、ページが表示されなくなります。

重要なことに、10月のCMSはページを介したルーティングを解決するため、ページはコンテンツのコンテナとしてだけでなく、機能のコンテナとしても使用されます。 たとえば、ブログ用のプラグインは、選択したURLの下にブログ投稿のリストを表示するためのページ、別の選択したURLの下に単一のブログ投稿を表示するための別のページなどに依存します。 これらのページのいずれかが消えると、プラグインの関連機能が使用できなくなり、そのURLによって404が生成されます。したがって、10月にCMSテーマとプラグインが完全に分離されないため、テーマの切り替えは慎重に行う必要があります。

コアとプラグインの機能

WordPressは、プラグインによって強化された最小限のコア機能を提供しようとします。 _WordPressは、「 ^80⁄20ルール」に基づいて、コアエクスペリエンスに一部の機能を含めるかどうかを決定します。 それが入るユーザーの80％に利益をもたらす場合、そうでない場合、それはプラグインランドに属します。 プラグインをサイトに追加するときに、インストールされているプラ​​グインが多すぎると、肥大化する可能性があります。 プラグインは、相互にうまく機能しないか、同様のコードを実行したり、同様のアセットをロードしたりして、パフォーマンスが最適化されない場合があります。 したがって、WordPressサイトの立ち上げは比較的簡単ですが、より大きな課題は、その一般的なメンテナンスと、新しい機能を追加するときに最適でパフォーマンスの高い状態を維持できることです。

同様に、October CMSも最小限のコア機能を提供しようとしますが、ステロイドについてです。保証されている機能はページの作成と公開だけです。それ以外の場合は、プラグインをインストールする必要があります。これは次のように表されます。

「必要なものはすべて、不要なものはありません。」

目的は明確です。ほとんどの単純なサイトはページのみで構成されており、ブログの投稿、ユーザー、ログイン領域はない可能性があります。 では、アプリケーションがこれらのリソースを必要としないのにロードする必要があるのはなぜですか？ 結果として、ブログ、ユーザー管理、翻訳、およびその他のいくつかの機能は、プラグインディレクトリを介してリリースされます。

10月のCMSのコアには、（常に必要とは限りませんが）アプリケーションを大幅に強化できる特定の機能も含まれています。 たとえば、メディアファイルをAmazon S3にアップロードし、RackspaceCDNを介してそれらにアクセスするためのすぐに使用可能なサポートを提供します。 また、ブログ投稿に画像を追加する場合など、プラグインを介して主に使用されるMediaManagerも含まれています。 （ページはメディアマネージャーを使用してメディアファイルを埋め込むこともできますが、CMSにはアセットセクションが付属しており、これらのメディアファイルをアップロードする方が適しているようです。）

10月の意見は、ほとんどが単純なサイトに関して、可能な限り無駄のないアプリケーションを作成するのに完全に役立つと思います。 ただし、必要なものとそうでないものの線は任意のものであり、CMSによって事前に設定することは困難であるため、逆効果になり、膨満感を助長する可能性もあります。 この難しさは、「ユーザー」の概念を検討するときに理解できます。WordPressでは、WebサイトユーザーとWebサイト管理者は同じユーザーエンティティに属します（ロールと特権を通じて、ユーザーを管理者にすることができます）。 10月のCMSでは、これら2つは別々に実装され、バックエンド領域にログインして設定を変更できるWebサイト管理者向けの実装と、プラグインを介したWebサイトユーザーの実装をコアとして出荷します。 これらの2つのタイプのユーザーは、データを格納するための異なるログインプロセスと異なるデータベーステーブルを持っているため、おそらくDRY（Do n't Repeat Yourself）の原則に違反しています。

この問題は、エンティティの動作だけでなく、エンティティに含まれている必要のあるデータフィールドに関しても発生します。 たとえば、Webサイトのユーザーデータフィールドを事前に定義する必要がありますか？ 電話フィールドは必要ですか？ Instagramが最近クールになったと考えると、InstagramのURLフィールドはどうですか？ しかし、プロのWebサイトを構築するときは、代わりにLinkedInのURLフィールドを使用するべきではありませんか？ これらの決定は明らかにアプリケーションに依存し、CMSまたはプラグインのいずれかによって決定することはできません。

Userと呼ばれる10月のCMSプラグインはユーザーを実装しますが、ユーザーフィールドはありません。その上に、プラグインUser Plusはいくつかの任意のユーザーフィールドを追加しますが、これでは不十分な場合があるため、プラグインUser Plus +はさらに他のユーザーフィールドを追加します。 このプロセスをいつ、どこで、どのように停止しますか？

もう1つの問題は、エンティティに新しい機能を追加する余地がない場合です。これにより、必要な機能をサポートするためだけに、非常に類似した別のエンティティが作成されます。 たとえば、October CMSにはページが付属しており、プラグインを介して「静的ページ」を作成できます。 それらの性質は同じです。ページと静的ページの両方が静的ファイルとして保存されます。 それらの唯一の違いは（私が知る限り）、静的ページはHTMLエディターではなくビジュアルエディターで編集され、メニューに追加できることです。 私の意見では、一方のエンティティを静的ファイルとして保存し、もう一方のエンティティをデータベースに保存するなどの構造上の違いだけが、ページの2番目のエンティティを作成することを正当化できます（これを行うためのプルリクエストがあります）が、単純な場合現在のように、機能は開発の肥大化を構成します。

要約すると、適切に実装された10月のCMSアプリケーションは、非常に無駄がなく効率的です（たとえば、不要なときにデータベースを削除することにより）が、逆に、不必要に肥大化する可能性があり、開発者は同様のエンティティに対していくつかのソリューションを実装する必要があります。使用するのが非常に混乱します（「ページまたは静的ページのどちらを使用する必要がありますか？」）。 WordPressもOctoberCMSも肥大化を取り除くための完璧なソリューションを見つけられなかったため、将来の苦痛を避けるように注意してどちらかのアプリケーションアーキテクチャを設計する必要があります。

コンテンツの作成

グーテンベルクはWordPressに2つの重要な貢献をしています。サイトを構築するためのユニットとしてコンポーネントを使用し（HTMLのブロブをコーディングするよりもいくつかの利点があります）、グーテンベルクフェーズ2が完了すると（おそらく2019）は、コンテンツをサイトに組み込むための統一された方法を提供します。これにより、ショートコード、TinyMCEボタン、メニュー、ウィジェットなどを介してコンテンツを追加するというより混沌としたプロセスとは対照的に、よりシンプルなユーザーエクスペリエンスが可能になります。

Gutenbergブロックは、ブログ投稿の一部として静的HTMLを生成および保存できるため、多くのGutenbergブロックをインストールしても、必ずしもユーザー側のWebサイトで肥大化するわけではありませんが、管理者側に制限することができます。 したがって、グーテンベルクは、コンテンツを作成するためのシンプルでありながら強力なユーザーエクスペリエンスを備えた、モジュール方式でWebサイトを作成するための優れたアプローチとほぼ間違いなく見なすことができます。 おそらく最大の欠点は、学習曲線がかなり急なReactを学習するための（避けられないが、簡単ではない）要件です。

ReactコンポーネントがWordPressでコンテンツを作成するための基本単位である場合、10月のCMSは、古き良きHTMLを知っていればサイトを構築するのに十分であるという前提に基づいています。 実際、ページを作成すると、HTML（マークアップ）エディターが表示されます。

ページが静的HTMLのみの場合、CMSは必要ありません。 代わりに、10月のCMSページは、単純に最適化されたPHPコードにコンパイルされたTwigテンプレートを使用して記述されています。 ページのスキャフォールディング（つまり、ヘッダー、フッターなどの反復要素）を含めるようにレイアウトを選択したり、ページがコンテンツをカスタマイズできるようにレイアウトで定義されたプレースホルダーを実装したりできます。パーシャル。再利用可能なコードのチャンクです。 さらに、ページにはコンテンツブロックを含めることができます。コンテンツブロックは、テキスト、HTML、またはMarkdownファイルのいずれかであり、独自に編集でき、プラグインを介して実装された機能であるコンポーネントを添付できます。 そして最後に、HTMLが十分でなく、動的コードを生成する必要がある場合はいつでも、PHP関数を追加できます。

エディターはすべてHTMLに関するものです。 視覚的な方法でコンテンツを追加するためのTinyMCE textareaはありません—少なくともデフォルトのエクスペリエンスではありません（この機能はプラグインランドに属しています）。 したがって、HTMLの知識を持つことは、OctoberCMSを使用するための必須事項と見なすことができます。 さらに、コンテンツを作成するためのいくつかの異なる入力（ページ、レイアウト、プレースホルダー、パーシャル、コンテンツブロック、コンポーネント、およびPHP関数）は非常に効果的ですが、WordPressの統合ブロックインターフェイスを使用する場合ほど単純ではありません。 他の要素（静的ページやメニュー、スニペットなど）も追加できるため、さらに複雑になる可能性があります。また、ページや静的ページなどの一部の要素は同じ機能を提供しているように見え、いつ行うかを決めるのが混乱します。どちらか一方を使用してください。

その結果、ほとんどの人が管理者側からWordPressサイトを使用できますが、October CMSは技術的でないユーザーフレンドリーよりも開発者フレンドリーであるため、プログラマーはそれを使用するのが楽しいと感じるかもしれませんが、他の特定の役割（マーケター、営業担当者など）は、直感的ではないと感じる場合があります。

メディアマネージャー

WordPressとOctoberCMSの両方にMediaManagerが付属しており、メディアファイルをサイトに簡単に追加でき、ドラッグアンドドロップインターフェイスを介して複数のファイルを同時に追加し、コンテンツ領域内に画像を表示できます。 見た目も動作も同じです。 私が見つけた唯一の顕著な違いは、WordPressのMedia Managerでは画像ギャラリーを埋め込むことができ、OctoberのMediaManagerではアップロードされたファイルを配置するフォルダー構造を手動で作成できることです。

ただし、グーテンベルクの導入以来、WordPressのメディア機能は大幅に強化され、TinyMCE textarea内と比較して、ビデオ、写真、フォトギャラリーを所定の位置に埋め込むことができます（これは、どのように見えるかについての不正確なバージョンのみを提供します）このビデオに示されているように、強力でありながら使いやすい機能のロックを解除します。

国際化

WordPressコアはgettextを使用して、テーマとプラグインの翻訳を有効にします。 翻訳するすべての文字列を含む.potファイルから始めて、対応する言語/ロケールへの翻訳を含む.poファイルを作成する必要があります。次に、このファイルは、高速翻訳抽出に適したバイナリ.moファイルにコンパイルされます。 これらのタスクを実行するためのツールには、GlotPress（オンライン）とPoedit（ダウンロード可能なアプリケーション）が含まれます。 便利なことに、このメカニズムは、グーテンベルクのクライアント側のローカリゼーションでも機能します。

WordPressは現在、コンテンツを翻訳するためのソリューションをコアで出荷しておらず、Gutenbergのフェーズ4（2020年以降を対象）まで出荷しません。 それまでは、この機能は、翻訳されたコンテンツを保存および管理するためのさまざまな戦略を提供するプラグインによって提供されます。 たとえば、PolylangやWPMLなどのプラグインは、カスタムデータベーステーブルからの各行に各翻訳を保存します（コンテンツを混合しないためクリーンですが、クエリを実行するときに2つのテーブルの追加のINNER JOINが必要になるため低速です。 database）、plugin qTranslate Xは、元のデータベーステーブルの同じフィールドにすべての翻訳を保存します（データのクエリは高速ですが、コンテンツがすべて混在していると、プラグインを無効にするとサイトに残骸が発生する可能性があります）。 したがって、私たちは買い物をして、私たちのニーズに最も適した戦略を決定することができます。

October CMSは、そのコアを介して多言語機能を出荷しませんが、October CMSチームによって作成されたプラグインとして、システムへの完全な統合を保証します。 機能的な観点から、このプラグインはそれが約束するものを提供します。 開発の観点からは、このプラグインが実際にどのように機能するかは理想的ではありません。 WordPressでは、ページは投稿タイプが「ページ」の投稿であり、単一の翻訳メカニズムがありますが、10月のCMSには、エンティティ「ページ」、「静的ページ」、「ブログ投稿」があります。非常によく似ており、翻訳には3つの異なる実装が必要です。 次に、「ページ」のコンテンツにメッセージコード（ nav.content 、 header.titleなどと呼ばれるコード）を含めることができます。各コードには、データベーステーブルrainlab_translate_messagesのシリアル化されたJSONオブジェクトとしてすべてのロケールの翻訳が含まれています。 「静的ページ」のコンテンツは、ロケールごとに新しい静的ファイルに作成されますが、すべてのロケールのすべての翻訳済みURLは、対応するファイルではなく、デフォルトの言語のファイルに保存されます。 「ブログ投稿」のコンテンツは、データベーステーブルrainlab_translate_attributesのロケールごとに1行でシリアル化されたJSONオブジェクトとして保存され、翻訳されたURLはデータベーステーブルrainlab_translate_indexesのロケールごとに1行で保存されます。 この複雑さがプラグインの実装方法によるものなのか、それとも10月のCMSのアーキテクチャによるものなのかはわかりません。 いずれにせよ、これは開発側での望ましくない肥大化のもう1つの例です。

プラグイン管理

WordPressとOctoberCMSはどちらも、プラグインの検索、新しいプラグインのインストール、現在インストールされているプラ​​グインの最新バージョンへの更新をすべてバックエンド内から実行できる高度なプラグインマネージャーを提供します。

依存関係の管理

10月CMSはComposerを最適なパッケージマネージャーとして使用し、プラグインがインストール時に依存関係をダウンロードしてインストールできるようにすることで、苦痛のないエクスペリエンスを提供します。

反対側のWordPressは、WordPressがサイトであるかサイト依存関係であるかをコミュニティが同意できないため、Composer（またはPHP依存関係マネージャー）を正式に採用していません。 したがって、プロジェクトにComposerが必要な場合、開発者は自分でComposerを追加する必要があります。 Gutenbergへの切り替えにより、npmは優先されるJavaScript依存関係マネージャーになり、それに依存する人気のある開発者ツールキットがあり、クライアント側のライブラリはnpmレジストリで自律パッケージとして着実にリリースされています。

データベースとの相互作用

WordPressは、データベースデータ（ get_postsなど）を取得して保存する関数（ wp_insert_postやwp_update_postなど）を提供します。 データを取得するときに、結果をクラスのインスタンスとして渡す必要があるのか​​、プロパティなどの配列として渡す必要があるのか​​を示すために、結果をフィルタリング、制限、および順序付けするためのパラメーターを渡すことができます。 関数が要件を完全に満たしていない場合（たとえば、カスタムテーブルを使用してINNER JOINを実行する必要がある場合）、グローバル変数$wpdbを介してデータベースに直接クエリを実行できます。 カスタム投稿タイプでプラグインを作成する場合、コードはほとんどの場合、カスタムSQLクエリを実行して、データを取得したり、カスタムテーブルに保存したりします。 要約すると、WordPressは、第1段階では汎用機能を介して、第2段階ではデータベースへの低レベルのアクセスを介してデータベースへのアクセスを提供しようとします。

10月CMSは別のアプローチを採用しています。アプリケーションはデータベースにすぐに接続する代わりに、LaravelのEloquent ORMを使用して、Modelsと呼ばれるクラスのインスタンスを介してデータベースデータにアクセスして操作し、データベースとの対話もオブジェクト指向プログラミングに基づいて行うことができます。 。 これは高レベルのアクセスです。 テーブルの作成方法とエンティティ間の関係の設定方法に関するルールに従うだけで、プラグインはSQL行を記述せずにデータを取得および/または保存できます。 たとえば、次のコードは、モデルFlightを介してデータベースからオブジェクトを取得し、プロパティを変更して、再度保存します。

 $flight = Flight::find(1); $flight->name = 'Darwin to Adelaide'; $flight->save();

データモデルのアップグレード

WordPressが成功したもう1つの理由は（下位互換性を壊さないことに加えて）、アプリケーションが時間の経過とともに成長できるように設計されたデータベースアーキテクチャです。 この目的は、「メタ」プロパティ、つまりデータベースオブジェクトにいつでも大まかに追加できるプロパティによって実現されます。 これらのプロパティは、対応するエンティティテーブル（ wp_posts 、 wp_users 、 wp_comments 、またはwp_terms ）の列に格納されるのではなく、対応する「メタ」テーブル（ wp_postmeta 、 wp_usermeta 、 wp_commentmeta 、またはwp_termmeta ）の行として格納され、 INNER JOINを実行して取得されます。 INNER JOIN 。 したがって、これらのメタ値の取得は遅くなりますが、無制限の柔軟性が提供され、新しい機能を実装するためにアプリケーションのデータモデルを最初から再構築する必要はほとんどありません。

10月のCMSはメタプロパティを使用しませんが、代わりに、データベーステーブルの列として直接マップされないいくつかの任意の値をシリアル化されたJSONオブジェクトとして格納できます。 Otherwise, when an object needs some new property, we need to add a new column on the corresponding table (which is the reason behind plugins User Plus and User Plus+, mentioned earlier on). To update the application's database schema, October CMS relies on Laravel's Migrations, which are sets of instructions to execute against the schema (such as add or drop a column, rename an index, etc) and which are executed when upgrading the software (eg when installing a plugin's new version).

Headless Capabilities

Both WordPress and October CMS can be used as headless, ie treating the CMS as a content management system that makes content accessible through APIs, which allows to render the website on the client-side and can power other applications (such as mobile apps). Indeed, WordPress is steadily heading towards headless, since the Gutenberg content editor itself treats WordPress as a headless CMS (and, as a consequence, Gutenberg can also work with any other CMS too, as Drupal Gutenberg demonstrates).

A headless system needs to implement some API to return the data, such as REST and GraphQL. WordPress supports REST through WP REST API (merged in core), exposing endpoints under some predefined route /wp-json/wp/v2/... ; October CMS supports REST through plugins RESTful and API Generator, which allow to create custom endpoints and, as a consequence, support versioning as part of the endpoint URL and can offer a better security against bots. Concerning GraphQL, WordPress supports it through WPGraphQL, while October CMS currently has no implementations for it.

Quite importantly, a headless system needs to offer powerful content management capabilities. As mentioned earlier on, WordPress has a very solid database architecture, offering a plethora of data entities (users, posts and custom posts, pages, categories, tags and custom taxonomies, comments) over which the application can be reasonably well modelled, meta properties to extend these data entities (enabling the application to upgrade its data model accordingly and without major changes), and with plugin Advanced Custom Fields filling the gap to construct relationships among the data entities. In addition, plugin VersionPress allows to version control the database content using Git. Hence, WordPress is undoubtedly a good fit for managing content, as demonstrated in several projects in the wild.

On its part, and as mentioned earlier on, October CMS can omit the database and behave as a flat-file system, or it can have a database and behave as a hybrid, storing the content from pages as static files and blog posts (and others) on the database. As a consequence, content is not centralized, and its management involves a different approach. For instance, while we can use Git to version control pages, there is no support to version control the database per se; the solution to this is to populate data into the database through Seeders which, being code, can be put under version control and executed upon deployment. In addition, October CMS doesn't offer a baked-in database model featuring predefined data entities that can support the needs of most applications. Hence, more likely than not the application will need custom development to implement its data model, which means more work, but also means that it can be more efficient (eg accessing a property from a column is faster than from a row in another table through an INNER JOIN , which is the case with WordPress' meta properties).

CLIサポート

Both WordPress and October CMS can be interacted with from the console through a Command Line Interface (CLI): WordPress through WP-CLI and October CMS through Laravel's Artisan. In addition to Laravel's commands, October CMS implements several custom commands for updating the system, migrating the database, and others. These tools make it very convenient to access the site from outside a browser, for instance for testing purposes.

マネージドホスティング

It is not a problem finding a managed hosting provider for a WordPress site: given WordPress' market share, there are dozens (if not hundreds) of providers out there vying with each other for the business, constituting a very dynamic market. The only problem is finding the most suitable provider for our specific sites based on all of their offerings, which can vary based on price, quality, type (shared or dedicated services), bandwidth and storage size, customer support, location, frequency of renewal of equipment, and other variables which we can navigate mainly through reviews comparing them (such as this one, this one or this one).

Even though nothing near as many as WordPress, October CMS still enjoys the offering from several hosting providers, which allows for some consideration and selection. Many of them are listed as October Partners, and several others are found DuckDuckGoing, but since I haven't found any independent review of them or article comparing them, the task of finding out the most suitable one will take some effort.

Marketplace, Ecosystem And Cost

WordPress' commercial ecosystem is estimated to be USD $10 billion/year, evidencing how many people and companies have managed to make a living by offering WordPress products and services, such as the creation of sites, hosting, theme and plugin development, support, security, and others. Indeed, its size is so big it is even bloated, meaning that it is very common to find different plugins solving the same problem, plugins that underdeliver, underperform or have not been updated for years, and themes which seem to look-alike each other. However, when creating a new site, the size and variety of the ecosystem also means that we will most likely find at least one plugin implementing each of the required functionalities, enabling us to save money by not having to develop the functionality ourselves, and the availability of customizable themes enables to produce a reasonably distinctive-looking site with minimal effort. As a consequence, we can easily create and launch a WordPress site for less than USD $100, making WordPress a sensible option for projects of any budget.

Being relatively new (only five years so far), OctoberCMS certainly doesn't enjoy anything near WordPress' marketplace and ecosystem sizes, however, it has been growing steadily so its size is bound to become bigger. Currently, its marketplace boasts 600+ plugins, and only a handful of themes. Concerning plugins, the October CMS team is requesting the community to put their effort into the creation of original plugins, delivering functionality not yet provided by any other plugin.

Hence, even though 600+ plugins doesn't sound like much, at least these translate into 600+ different functionalities. This way, even though it is not possible to choose among several vendors, at least we can expect to have those basic website features (such as blogging, comments, forum, integration with social media, e-commerce, and others) to be covered. Also, since October's founders are personally reviewing all submitted plugins and judging them according to quality guidelines, we can expect these plugins to perform as expected. As another plus, October plugins can incorporate elements from Laravel packages (even though not all of them are compatible with October, at least not without some hacks). Concerning themes, the low number of offerings implies we will most likely need to develop our own theme by hiring a developer for the task. In fact, I dare say that the theme in October CMS will most likely be a custom development, since themes and plugins are not thoroughly decoupled (as explained earlier), with the consequence that a market for easily-swappable themes is more difficult to arise. (This is a temporary problem though: once this pull request is resolved, pages will be able to be stored in the database, and swapping themes should not disrupt functionality.)

In my opinion, because of the smaller offerings of themes and plugins, creating a simple site with OctoberCMS will be more expensive than creating a simple WordPress site. For complex sites, however, October's better architecture (Object-Oriented Programming and Model-View-Controller paradigms) makes the software more maintainable and, as a consequence, potentially cheaper.

コミュニティ

Being a part of and having access, WordPress' community represents one of the most compelling reasons for using WordPress. This is not simply as a matter of size (powering nearly one third of all websites in the world, there are so many stakeholders involved with WordPress, and its community is representatively big) but also as a matter of diversity. The WordPress community involves people from many different professions (developers, marketers, designers, bloggers, sales people, and so on), from all continents and countries, speaking countless languages, from different social, educational and economic backgrounds, with or without disabilities, from corporate, not-for-profit and governmental organizations, and others. Hence, it is quite likely that, for whatever problem we encounter, somebody will be able to help on any of the support forums. And contributing to WordPress is pretty straightforward too: The Make WordPress group congregates stakeholders interested in supporting different projects (accessibility, design, internationalization, and many others) and organizes how and how regularly they communicate — mostly through some dedicated channel on its Slack workspace.

Furthermore, the WordPress community is real and tangible: it doesn't exist just online, but it gathers offline in WordCamps and meetups all over the world; in 2018, there were a total of 145 WordCamps in 48 countries with over 45,000 tickets sold, and a total of 5,400 meetup events from 687 meetup groups. Hence, it is likely that there is a local chapter nearby which anyone can join to ask for help, learn how to use the platform, keep learning on a regular basis, and teach others as well. In this sense, WordPress is not just a CMS but, more importantly, it's also people, and considering to leave WordPress should never be done only on its technical merits but on the power of its community, too.

October CMS' community is nothing near in size or diversity as WordPress', even though it has been growing steadily following the increasing popularity of the software. October provides a support forum to ask for help, however, it is not very active. A Slack workspace exists which is pretty active and where, quite importantly, October's founders participate regularly, helping make sure that all enquiries are properly addressed. This channel is a great source for learning low-level tips and tricks about the software, however, it is geared towards developers mainly: There are no channels concerning accessibility, design, internationalization, and other topics as in the WordPress community, at least not yet. Currently, there are no conferences concerning October CMS, but there is Laracon, the conference for the Laravel community.

Maintainers And Governance

Can we trust that the software will be maintained in the long term, so that if we decide to start a project today, we will not need to migrate to some other platform down the road? How many people are taking care of developing the software? And who is deciding in what direction the software moves towards?

WordPressは、世界のすべてのサイトの3分の1を支えており、ソフトウェアに貢献している利害関係者が不足していません。 したがって、ソフトウェアが崩壊することを恐れる必要はありません。 ただし、WordPressはガバナンスモデルに関する内部審議を行っており、コミュニティの多くのメンバーは、WordPressの方向性に関する決定はWordPress.comを運営しているAutomatticによって一方的に行われていると表明しています。 この認識の中心的な段階は、多くのメンバーが反対し、プロジェクトの開発とリリースの間にプロジェクトリーダーによる適切なコミュニケーションの欠如に苦しんだグーテンベルクを立ち上げるという決定でした。 その結果、多くのコミュニティメンバーは、WordPressの創設者でAutomatticのCEOであるMatt Mullenwegに歴史的に与えられてきた「良性の独裁者」の役割に疑問を投げかけ、WordPressの将来により適したものを見つけるためにさまざまなガバナンスモデルを研究しています。 このクエストが何らかの結果をもたらすかどうか、または現状が続くかどうかはまだわかりません。

10月のCMSの方向性に関する決定は、主に創設者のAlexeyBobkovとSamuelGeorges、および開発者兼コミュニティマネージャーのLuke Towersによって行われ、プロジェクトを強力に進めています。 10月のCMSには、ガバナンスの問題を抱える余裕はまだありません。現在の懸念は、コアソフトウェアのメンテナに収入をもたらすことでプロジェクトを持続可能にする方法です。

ドキュメンテーション

独自のサイトにあるWordPressのドキュメントは、それほど包括的ではありませんが、かなりうまく機能します。 ただし、WordPressに関するすべてのドキュメントを、一般的なサイト（Smashing Magazine、CSSトリック、その他多数）、専門サイト（WPShout、WPBeginner、その他多数）、個人ブログ、オンラインコースなど、すべてのソースから考慮に入れる場合、などなど、まだカバーされていないWordPressを扱う側面は事実上ありません。

10月のCMSは、WordPressほど多くのサードパーティのコース、チュートリアル、ブログ投稿の近くでは何も楽しんでいませんが、そのサイトのドキュメントはかなり包括的で、コーディングを開始するのに十分です。 10月の創設者は、チュートリアルを通じて定期的に新しいドキュメントを追加しています。 私が個人的に楽しんだ1つの側面は、関連性のすべてについてLaravelのドキュメントをOctoberのドキュメントに複製することです。したがって、読者は自分でギャップを埋めてはならず、OctoberのドメインとLaravelのドメインを推測する必要があります。 ただし、これは100％完全ではありません。 10月のドキュメントでは、ミドルウェア、サービスコンテナ、ファサード、契約など、Laravelに由来する用語を使用していますが、これらが何であるかを適切に説明していません。 次に、Laravelのドキュメントを事前に読むと役立ちます（幸い、Laravelのドキュメントは明らかに包括的であり、LaravelのスクリーンキャストであるLaracastは、Laravelだけでなく、Web開発全般に関するもう1つの優れた学習ソースです）。

結論

私は、WordPressを、PHPに基づいて動的コンテンツを生成する無料のオープンソースであると定義した同様のCMSと比較し、一部のコミュニティからのサポートを享受することで、WordPressの代替を探している開発者にとって魅力的な機能を見つけることに着手しました。 。 これらの条件を満たすCMSから、比較のために10月のCMSを選択しました。これは、それについて得た知識と、Laravelが提供するクリーンでモジュール式のコーディングアプローチを高く評価したためです。

この記事は勝者を選ぶことを意図したものではなく、どちらか一方のCMSを選択することが理にかなっている場合を分析し、その長所と短所を強調しています。 「最良の」CMSはありません。特定の状況に最も適したCMSのみです。 さらに、特定のチームの特定のプロジェクトで使用するCMSを探していて、特定の予算が与えられている場合は、調査を行い、すべての製品を比較して、特定のコンテキストに最適なものを見つける必要があります。 この記事でここで行ったように、いくつかのCMSに制限するのではなく、すべてのCMSにチャンスを与えることが重要です。

個人的な話ですが、開発者として、10月にCMSで見つけたものは、私にとって本当に魅力的です。主に、Laravelを通じて提供されるモジュラーアプリケーションを構築する能力です。 私は確かにこのCMSを新しいウェブサイトと見なします。 しかし、この記事を書く過程で、私はWordPressも「再発見」しました。 非常に人気があるため、WordPressは、主に古いコードベースと、最近からGutenbergの導入に関して、かなりの批判を受けています。 ただし、WordPressには、ほとんど賞賛されないが考慮に入れる必要のある特定の優れた機能（スーパースケーラブルなデータベースモデルなど）もあります。 そして最も重要なことは、WordPressはその技術的側面だけで考慮されるべきではありません。特に、そのコミュニティとエコシステムのサイズは、WordPressを他の選択肢よりも1〜2レベル上に置いています。 一言で言えば、WordPressに固執することで恩恵を受けるプロジェクトもあれば、OctoberCMSまたは別のプラットフォームに依存するプロジェクトもあります。

最後に、別のCMSがどのように機能するかを調査することは、その特定のCMSを使用するかどうかに関する決定とは関係なく、それ自体が非常にやりがいのある活動であることを指摘しておきます。 私の場合、私はWordPressだけで何年も働いていましたが、10月のCMSを掘り下げることは、WordPressでは触れられなかった多くのこと（PHP Standards Recommendationsの存在など）を教えてくれたので、とても新鮮でした。 私は今、CMSを切り替えるか、より良いコードを作成する方法を知っているWordPressに固執することを決定するかもしれません。

SmashingMagの詳細：

• グーテンベルクの時代に賢くキャッシング
• 最新のPHPによるWordPressコードの改善
• WordPressプラグインの開発中に学んだ教訓
• ヒートマップを使用してWordPressWebサイトのクリックを追跡する方法
• 注意してください：あなたのサイトを安全でなくする可能性のあるPHPとWordPressの機能