ブロブではなくブロックで考えることの意味

公開: 2022-03-10
簡単な要約↬グーテンベルクはWordPressの未来に何をもたらしますか？ この記事では、Leonardo Losovizが、コンポーネントベースのアーキテクチャ（コンセプトとして）およびGutenberg（実装として）を介してサイトを構築することの多くの影響を共有します。ウェブサイトの開発動向。

GutenbergはJavaScriptベースのエディター（より具体的には、Reactベースのエディター）であり、WordPressのコンテンツ作成のエクスペリエンスと、（Gutenbergがサイトビルダーに変換される次の段階で）作成のエクスペリエンスを間もなく変換します。 WordPressサイト。

サイトビルダーであるグーテンベルクは、ウェブサイトの基礎を築く方法について別の考え方を要求するでしょう。 すでに「古い」モデルと呼ぶことができるものでは、WordPressサイトは、テンプレート（ header.php 、 index.php 、 sidebar.php 、 footer.php ）を介して構造を与え、単一のBLOBからページ上のコンテンツをフェッチすることによって作成されます。 HTMLコードの。 新しいモデルでは、ページには（React）コンポーネントがページ全体に配置されており、各コンポーネントは独自のロジックを制御し、独自のデータをロードし、自己レンダリングします。

今後の変更を視覚的に評価するために、WordPressはこれから移行しています：

このページには、HTMLコードを含むテンプレートが含まれています
現在、ページはPHPテンプレートを使用して作成されています。 （大プレビュー）

…これに：

このページには自律コンポーネントが含まれています
近い将来、ページは自己レンダリングコンポーネントをページに配置して作成される予定です。 （大プレビュー）

HTMLコードのブロブからサイトを構築するためのコンポーネントに切り替えることは、パラダイムシフトにほかなりません。 グーテンベルクの影響は、PHPからJavaScriptへの切り替え以上のものです。過去に実行できた可能性があり、もはや意味をなさないことがあります。 同様に、リッチで強力なユーザーインタラクションなど、可能性の新しい世界が開かれます。 Web開発者は、サイトが同じではなくなるため、ある言語でサイトを作成することから別の言語でサイトを作成することはありません。 構築されるのは完全に異なるサイトになります。

推奨読書：グーテンベルクワードプレスエディターの完全な解剖学

ジャンプした後もっと！ 以下を読み続けてください↓

グーテンベルクは、多くの理由から、まだWordPressコミュニティに完全には受け入れられていません。 1つは、新しいアーキテクチャは多数のツールとテクノロジー（React、NPM、Webpack、Reduxなど）に基づいており、古いPHPベースのアーキテクチャよりも習得と習得がはるかに困難です。 新しい機能を提供する新しいスタックを学ぶ価値があるかもしれませんが、すべてのmom＆popサイトがこれらの新しい光沢のある機能を必要としているわけではありません。

結局のところ、世界中のすべてのサイトの30％がWordPressサイトであるのは偶然ではありません。これらのほとんどは、Facebookのような動的なソーシャルネットワークではなく、ブログのような本当に単純なサイトです。 もう1つは、WordPressの包括性とは、デザイナー、コンテンツマーケティング担当者、ブロガーなど、コーディングの経験がない人でも、誰でも簡単なWebサイトを構築できることを意味します。

しかし、新しいアーキテクチャの複雑さにより、多くの人が除外されます（縮小されたJavaScriptコードでサイトをデバッグすることについても考えたくありません）。 また、グーテンベルクが稼働すると、Facebookが支援するReactが世界中のすべてのWebサイトの30％に一晩で追加されます。 多くの人々は、あらゆる種類のJavaScriptライブラリに非常に多くの力を与えることに不快感を覚えていますが、他の多くの人々はFacebookに不信感を抱いています。 この懸念を軽減するために、GutenbergはReactを抽象化して、他のフレームワークやライブラリでのコーディングも可能にします。 ただし、実際には、Reactが間違いなく主要なJavaScriptライブラリになります。

それでも、新しい可能性の世界が提供されるという見通しは確かに甘いものです。 私の場合、私は興奮しています。 しかし、私の興奮は、テクノロジー（React）や実装（Gutenberg）ではなく、コンポーネントを構築単位として使用してサイトを作成するというコンセプトにあります。 将来的には、実装がVueなどの別のプラットフォームに切り替わる可能性がありますが、コンセプトは変わりません。

実装できる新機能を予測するのは必ずしも簡単ではありません。 新しいパラダイムに適応するには時間がかかり、新しい目的を達成するために新しいツールを使用する方法が明らかになるまで、古い方法で新しいツールを使用する傾向があります。 PDFファイル（Webが生まれる前の主要なテクノロジーである印刷の表現）でさえ、Webが印刷よりも優れている点を無視して、依然としてWeb上で一般的な見方をしています。

「コンピューターの画面で紙を模倣することは、747の翼をはがして、高速道路のバスとして使用するようなものです。」

—テッド・ネルソン

この記事では、コンポーネントベースのアーキテクチャ（コンセプトとして）とグーテンベルク（実装として）を介してサイトを構築することのいくつかの影響を分析します。これには、提供できる新機能、現在のWebサイト開発との統合がどれだけ優れているかなどが含まれます。トレンド、そしてそれがWordPressの将来にとって何を意味するのか。

コンテンツの拡張された汎用性と可用性

すべてのコンテンツをブロックとして扱うことの非常に重要な副作用は、HTMLのチャンクを個別にターゲットにして、それらをさまざまな出力に使用できることです。 HTML BLOBに挿入されたコンテンツは、Webページからのみアクセスできますが、チャンクとしてはAPIを介してアクセスでき、そのメタデータはすぐに利用できます。 ビデオ、オーディオ、画像などのメディア要素を取ります。 スタンドアロンブロックとして、ビデオをアプリで再生したり、オーディオをポッドキャストとして再生したり、ダイジェストを送信するときに画像をメールに添付したりできます。これらはすべて、HTMLコードを解析する必要はありません。

同様に、ブロックのコンテンツは、さまざまなメディアに適合させることができます。最小の画面から最大の画面、タッチスクリーンまたはデスクトップ、音声またはタッチによるコマンド、2D / AR / VR、または将来が何をもたらすかを知っている人などです。 たとえば、オーディオブロックを使用すると、Apple Watchでオーディオを再生したり、車載システムやAWS Echoを介して音声でコマンドを送信したり、VRヘッドセットを使用するときに仮想世界でフローティングアイテムとして再生したりできます。 ブロックを使用すると、レスポンシブWebサイト、AMP、モバイルアプリ、電子メールなど、NPRがCreate Onceを介して行ったように、コンテンツをさまざまな出力で公開するための信頼できる唯一の情報源を簡単に設定できます。 、Publish Everywhere（COPE）アプローチ。

注：これらのトピックの詳細については、ゾンビの黙示録の講演でカレン・マクグレンのコンテンツをご覧になることをお勧めします。

ブロックはユーザーエクスペリエンスも向上させることができます。 3Gを介してサイトを閲覧する場合、ブロックは低速接続モードで自己レンダリングして、低品質の画像を表示し、ビデオの読み込みをスキップできます。 または、記事に埋め込まれた場所だけでなく、Webページの任意の場所でワンクリックで画像ギャラリーを表示するように提案するなど、レイアウトを強化することもできます。

これらの体験は、コンテンツをフォームから分離することで実現できます。つまり、コンテンツのプレゼンテーションと意味が分離され、意味のみがデータベースに保存され、プレゼンテーションデータが二次的になり、別の場所に保存されます。 セマンティックHTMLは、この概念の表現です。プレゼンテーションの形式である<i> （文字をイタリック体で表示するため）の代わりに、意味を意味する<em>を常に使用する必要があります。音声などの他の媒体（アレクサはイタリック体で読むことはできませんが、文を強調することはできます）。

プレゼンテーションコードはHTMLマークアップを介してブロック内に追加されることが多いため、フォームからコンテンツを完全に分離することは非常に困難です（クラス「pull-right」の追加はすでにプレゼンテーションを意味します）。 ただし、ブロックを使用してサイトを設計することは、レイアウトレベルである程度の分離を達成するのにすでに役立ちます。 さらに、1つのことだけを実行し、それを非常にうまく実行するために作成されたブロックは、適切なセマンティックHTMLを利用でき、HTML、JS、およびCSSに関する独自のアーキテクチャの関心事を適切に分離できます（他のプラットフォームへの移植が可能になります）。最小限の労力しか必要としない場合があります）、少なくともコンポーネントレベルでアクセス可能です。

注：一般的な経験則：コンポーネントが包括的であるほど、まだ発明されていない媒体に対してより準備が整っています。

残念ながら、グーテンベルクはこの目的を念頭に置いて設計されていないため、ブロックにはプレゼンテーション用のHTMLマークアップもたくさん含まれています。 たとえば、外部画像からの画像ブロックには、その意味として、画像のURL、代替の説明、およびキャプション（および場合によっては幅と高さ）のみが含まれます。 画像ブロックを作成した後、次のコードのチャンクがDBに保存されました（クラスaligncenterはプレゼンテーション用であり、意味のみを格納する場合、マークアップ<div class="wp-block-image" />は完全に冗長になります）：

 <!-- wp:image {"align":"center"} --> <div class="wp-block-image"> <figure class="aligncenter"> <img src="https://cldup.com/cXyG__fTLN.jpg" alt="Beautiful landscape"/> <figcaption>If your theme supports it, you'll see the "wide" button on the image toolbar. Give it a try.</figcaption> </figure> </div> <!-- /wp:image -->

さらに、ブロックは、それぞれがデータベースに独自のエントリを持つのではなく、投稿のコンテンツ（大きなHTMLブロブ）内に保存されます。 ただし、再利用可能なブロック（グローバルブロックとも呼ばれます）には独自のエントリがあります。そのため、開発者がDBで直接アクセスするための簡単なハックのために、標準ブロックを再利用可能なブロックに変換する可能性があります。

同様に、適切に設計されていないと、ブロックがサイトに大混乱を引き起こす可能性さえあるのではないかと心配しています。 たとえば、知らない開発者は、機能だけでなくCSSやマークアップにもJavaScriptを使用して、最小電力のルールを無視する可能性があります。 さらに、Gutenbergのサーバー側レンダリング（SSR）機能は同形ではないため（つまり、単一のコードベースでクライアント側とサーバー側の両方のコードの出力を生成することはできません）、動的ブロックはHTMLコードを生成する関数を実装する必要がありますまた、プログレッシブエンハンスメントを提供するPHPとしても使用できます（これがないと、最初にロードされている間はサイトにアクセスできません）。

要約すると、ブロックは、WordPressコンテンツをあらゆる形式、あらゆるメディアで利用できるようにするための正しい方向への一歩ですが、決定的なソリューションではないため、まだ多くの作業を行う必要があります。

パフォーマンス

パフォーマンスが重要です。 より速いサイトはより幸せなユーザーにつながり、それはより良いコンバージョン率につながります。 たとえば、Etsyのチームは、サイトの読み込み時間が重要なしきい値を超えた場合に、新しい機能を可能な限りクールに棚上げします（Allison McKnightの長期的なパフォーマンスの構築とスライドに関する講演をご覧になることをお勧めします）。 Twitterのチームは、コンテンツをできるだけ早く表示するためにサーバー側のレンダリングをサポートするために数年前にサイトを再構築し、高速なユーザーエクスペリエンスを提供するために追加される多くの小さな変更を継続的に実装しています。

JavaScriptは開発者にとって非常に魅力的であり、使用に制約はありません。これは実際の問題です。JavaScriptはパフォーマンスに関して非常に高価であるため、慎重に使用する必要があります。

現在のところ、グーテンベルクは最適とはほど遠いです。古いエディター（クラシックエディターをインストールする必要がある）で投稿を作成するには、約1.4 MBのJavaScriptをロードする必要がありますが、グーテンベルクは、基本的なものとして、約3.5MBのJavaScriptをロードします。経験（つまり、追加のブロックをインストールせずに）：

グーテンベルクをロードするには、少なくとも3.5MBのスクリプトが必要です。
グーテンベルクのスクリプトを読み込んでいます。 （大プレビュー）

つまり、現在のところ、3.5 MBがベースラインであり、サイト管理者がより多くのブロックをインストールするにつれて、ロードサイズはそこからのみ増加します。 Smashing Magazineの最近の記事で見られたように、紹介文のブロックを作成するには、150KBの縮小されたJavaScriptが必要でした。 標準サイトにはいくつのブロックが必要ですか？ 平均的なサイトは何MBのJavaScriptをダウンロードする必要がありますか？

影響はいくつかあります。1つは、重いサイトは、主に低速接続でアクセスでき、賃金のかなりの部分を占めるデータプランを購入する次の10億人のユーザーには届きません。 彼らにとって、すべてのMBのデータが違いを生みます。Whatsappメッセージの送信は手頃な価格ですが、1つのサイトをロードするためだけに数MBのスクリプトをダウンロードするのは手頃ではありません。

確かに、ウェブサイトのユーザーはグーテンベルクと対話する必要はありません。グーテンベルクは単にサイトを構築するためのものであり、サイトを使用するためのものではないからです。グーテンベルクはバックエンドエディターであり、フロントエンドエディターではありません（ be —少なくともWordPressコアの一部として）。 ただし、コンテンツクリエーターにはペナルティが課せられ、すでにかなりのターゲットになっています。 さらに（前に説明したように）、ユーザーは動的ブロックによってもペナルティを受ける可能性があり、サーバー側のPHPではなくクライアント側のJavaScriptを使用してマークアップを作成する可能性があります。

サードパーティのプラグインによって追加された重複した機能による肥大化の問題もあります。 昔は、WordPressサイトにいくつかのバージョンのjQueryがロードされていた可能性がありますが、これは比較的簡単に修正できました。 今日では、必要な機能（ドラッグアンドドロップ、カレンダー、複数選択コンポーネント、カルーセルなど）を実装するために選択できるオープンソースライブラリが多数あり、サードパーティのブロックが数十あるサイトよりも可能性が高いです。異なるライブラリによって同じ機能が実装され、不要な肥大化が発生します。 さらに、グーテンベルク自体に少し肥大化が追加されています。ブロックはフロントエンドに登録されているため、すでに登録されているブロックの登録解除は、追加のスクリプトをロードすることによって行われます。 私の意見では、これはグーテンベルクの貢献者にとって最大の課題の1つです。合理化されたプロセスを導入して、誰でも（Webpackの経験がある開発者だけでなく）不要なライブラリを削除し、アプリケーションに必要な最小限のリソースセットのみをパッケージ化できるようにすることです。 。

最後に、グーテンベルクはサーバー側のレンダリングをサポートしていることを再度述べましたが、保守が容易ではない可能性があるため、開発者はそれに依存しないように誘惑される可能性があります。 この場合、レイアウトをレンダリングするためだけに、RESTエンドポイントからデータを取得するために必要な追加のラウンドトリップのコストが発生します。その間、ユーザーは待機します。

私の意見では、パフォーマンスはグーテンベルクにとって大きな課題の1つであり、広く採用されるという点で成功または失敗する可能性があります。また、グーテンベルクがサイトになる次の段階を主な対象として、やるべきことはまだたくさんあります。ビルダー。

Web標準

前述のように、GutenbergはReactを抽象化して、フレームワークに依存しないアプローチをビルディングブロックに提供します。これは、適切に実装された場合、WordPressがReactにロックされるのを防ぐことができます。 WordPressコミュニティは、JavaScriptフレームワークをWordPressコアにマージする際に注意を払っています。これは、WordPressコアに追加されて間もなくBackbone.jsの人気が急激に低下し、MediaManagerを強化する以外に多くの機能が実現されなかったためです。それと。 Reactが現在最も人気のあるJavaScriptライブラリであるとしても、これが常に当てはまると信じる理由はありません（jQueryの解明が証明できるように）、そしてWordPressはその日が最終的に到着するときに備えなければなりません（テクノロジーのペースは、予想よりも早く発生する可能性があります）。

ライブラリにロックされないようにする最善の方法は、Web標準を使用することです。具体的には、この場合、Webコンポーネントを介してブロックを実装します。 Webコンポーネントは、ブラウザAPIで動作する強力にカプセル化されたコンポーネントであるため、JavaScriptライブラリを使用する必要はありません。 ただし、これらはクライアント側のJavaScriptフレームワークを介して実装できます。

ReactはまだWebコンポーネントとのシームレスな統合を提供していませんが、最終的には（またはむしろうまくいけば）提供します。 Reactのドキュメントで説明されているように、WebコンポーネントとReactコンポーネントは次のものと一緒に機能します。

「ReactおよびWebコンポーネントは、さまざまな問題を解決するために構築されています。 Webコンポーネントは再利用可能なコンポーネントの強力なカプセル化を提供し、ReactはDOMをデータと同期させ続ける宣言型ライブラリを提供します。 2つの目標は補完的です。 開発者は、WebコンポーネントでReactを使用するか、ReactでWebコンポーネントを使用するか、またはその両方を自由に行うことができます。」

今日の時点で、この状況が発生する可能性はあまり期待できません。Webコンポーネントを使用したビルディングブロックのチュートリアルを見つけることができませんでした。 グーテンベルクは今、とにかく新しいテクノロジーを学ぶように強制しているので、コミュニティはこの目的に向けて努力を集中し、開発者がWebコンポーネントを使用してビルディングブロックを開始することを奨励する必要があると思います。 これは、最初からWeb標準を使用して強力な基盤を確立する機会です。

サイト間の相互運用性、サイトの均質化

ブロックはテーマやプラグインよりも小さいエンティティであるため、最終的にはブロック自体にアクセスでき、新しく作成されたブロックマーケットを通じて取得されます。 エコシステムの多くのプレーヤーがソリューションを最初に市場に投入し、最も成功したソリューションの統合に向けて中長期的にリードするため、最初はカンブリア爆発が発生する可能性があります。

ほこりが落ち着くと、いくつかのブロックが目立ち、勝者になり、特定のカテゴリで市場のほとんどを獲得します。 それが発生した場合、それが懸念と歓喜の両方の原因になります。同じコンポーネントを使用しているサイトが同じルックアンドフィールになる可能性があるため、（Bootstrapで発生したように）Webの均質化の新しい波が発生することへの懸念、同じコンポーネントと同じAPIに依存することによるサイト間の相互運用性の向上についての歓喜。これにより、新しい機会への扉が開かれる可能性があります。

特に、サイト間の相互運用性を拡大することに興奮しています。 これは、長期的にはFacebookなどの王国を元に戻すことができる領域です。情報を共有するために独占的なゲートウェイに依存する代わりに、さまざまなコミュニティのサイトがデータを直接簡単に共有できます。 これは新しい概念ではありません。IndieWebムーブメントは、Webサイトがマイクロフォーマットを介して相互に通信することにより、誰もが自分のサーバー上で自分のデータを所有できるようにすることに長い間取り組んできました。 たとえば、彼らのWebmention Web標準では、2つのサイトで会話を行うことができ、各コメントと応答は両方に保存されます。Micro.blogは、投稿が行われるオープンWebに基づいて、さまざまな種類のTwitterを提供します。ユーザーのタイムライン上のは、サブスクライブされたサイトからのRSSおよびJSONフィードから収集されます。 これらの取り組みは素晴らしいものですが、その一部であるために必要なある程度の技術的知識があるため、影響はまだ非常に小さいです。 グーテンベルクのコンポーネントベースのアーキテクチャは、はるかに幅広い影響をもたらす可能性があります。人気のあるブロックにより、多数のWordPressサイトが相互に通信できるようになり、最終的にWeb上のすべてのサイトの最大30％が分散型の疎結合ネットワークの一部になる可能性があります。 。

ただし、この領域を実行するには、多くの作業が必要になります。 デフォルトのRESTエンドポイントは、この目的のために考案されたものではないため、最良の通信インターフェイスではないと思います（micro.blogの人々は、RSS仕様に基づくJSONインターフェイスを介してより良いソリューションを提案しています）。 また、REST自体はGraphQLによって廃止されているので、長期的には期待していません。 また、現在、1つのリクエストで必要なすべてのデータを取得でき、コンポーネントベースのアーキテクチャによる拡張性をサポートする別のタイプのAPIに取り組んでいる、より良い方法を見つけることに携わっています。

また、プロバイダーは独自のブロックを解放して独自のサービスと対話できるため、クラウドサービスとの統合がより顕著になることを期待しています。 コンポーネントはスタンドアロンユニットであるため、ブロックをページにドラッグアンドドロップするだけで、ユーザーの観点からすべての作業がすでに実行され、知識がほとんどまたはまったくなくても、強力なWebサイトを非常に簡単に構築できます。 たとえば、Cloudinaryのような画像ストレージプロバイダーは、デバイスのビューポートに従って画像を自動的にトリミングするブロックをリリースしたり、サポートされている場合はWebPとして画像を要求したりすることができます。

要約すると、ブロック市場の統合は、見た目と感じ方の均質化をもたらす可能性があります。これは残念な出来事であり、避ける必要があります。また、サイト間の相互運用性とデータ共有、およびクラウドサービスとの統合に関する強力な機能もあります。

パターンライブラリとの統合

パターンライブラリは、ユーザーインターフェイスデザイン要素のコレクションであり、各要素は、多くの場合、HTML、JS、およびCSSのスニペットで構成されています。 ブロックは自律的なコンポーネントであり、多くの場合、HTML、JS、およびCSSのビットで構成されています。 したがって、ブロックは、パターンライブラリを使用して文書化/構築するのに明らかに適しています。 ブロックにパターンライブラリを出荷させることは、チームがサイトレベルでのみサイトのパターンライブラリの実装を開始するのではなく、必要なすべてのブロックからのミニパターンライブラリの集約と改良として開始できるため、非常に重要です。

この場合、先に述べた膨張のないJavaScriptパッケージを作成するための合理化プロセスに似たことが起こると思いますが、UI / UX / Documentationに関するものです。 グーテンベルクの寄稿者にとって、ブロック開発者がブロックのパターンライブラリを簡単に作成できるプロセスを導入することは、課題であると同時にチャンスでもあります。これにより、すべてをまとめると、サイトの一貫したパターンライブラリが得られます。 適切に実装されているため、このような機能は、ドキュメント/メンテナンスの観点からサイトを構築するコストを削減できます。

WordPressはどうなるのでしょうか？

グーテンベルクは確かにウェブサイトをより魅力的にしますが、必要なレベルの専門知識を犠牲にして、誰もが処理できるわけではありません。 長期的には、これはより高い品質、より少ない量につながる可能性があります。 「DemocratizingPublishing」のWordPressの格言から来て、これは問題になるかもしれません。

私はグーテンベルクに熱心ですが、Reactベースの実装というよりも、コンポーネントベースのアーキテクチャの概念としての役割を果たしています。 一般的に、私はマット・マレンウェッグがグーテンベルクを正当化するためにWordCamp Europe2018で言ったことに同意します。

「現在15年間うまく機能しているWordPressの基盤は、次の15年間は続かないでしょう。」

しかし、15年後のWordPressは、現在私たちが知っているものとは完全に異なるものになるかもしれないと私は信じています。 WordPressが主にクライアントベースのエディターになり、それ以上になるのではないかと思います。グーテンベルクをオープンWebのエディターにすることを目的として、グーテンベルクをDrupalに統合するイニシアチブにより、WordPressがヘッドレスCMS運用として公式化されます。 RESTエンドポイントを介して。 これはそれ自体で優れた開発ですが、WordPressをバックエンドで不要にします。他のバックエンドプラットフォームがより優れた機能を提供する場合、WordPressバックエンドに固執する理由はもうありません。 結局のところ、クライアント側のグーテンベルクはそれらのいずれでも作業できるようになりますが、WordPressでサイトを作成するという単純さは失われ、他のすべてのプラットフォームとの競争の場が平準化されます。

特に、動的ブロックをレンダリングするために2つのコードベース（1つはJavaScriptで、もう1つはPHPで）を維持するのは負担が大きすぎると開発者が感じ、同形のサーバー側レンダリングをサポートするプラットフォームに移行することを決定したとしても、私は驚かないでしょう。 このシナリオが実際に発生した場合、MattはWordPressバックエンドをNode.jsにシフトすることを決定しますか？

15年後のWordPressは、現在とは大きく異なる可能性があると言っても過言ではありません。 何が起こるか誰が知っていますか？

結論

コンポーネントをサイトを構築するための新しいユニットにすることで、グーテンベルクの導入はWordPressに変わります。 そして、他のパラダイムシフトと同様に、勝者と敗者が存在します。 さまざまな利害関係者は、グーテンベルクを自分の状況に応じてポジティブまたはネガティブな開発と見なします。Webサイトの品質は向上しますが、その複雑さに対処できる開発者を雇うことでそのようなサイトを構築する価格も上昇し、手頃な価格ではなくなります。あまり人気がありません。

これらはエキサイティングな時代ですが、極めて重要な時代でもあります。 今後、WordPressは私たちが慣れ親しんだものとはゆっくりと異なるエンティティになり始める可能性があり、最終的にはWordPressとは何か、そしてそれが何を表すのかをもう一度考え直す必要があるかもしれません。