現代のWordPress開発へのアプローチ方法（パート1）

公開: 2022-03-11

WordPressのコードベースが混乱していることは周知の事実です。 個人的には、それを経験するたびに、私が欲しいのは丸まって泣くことだけです。 一方、WordPressは競合他社よりもはるかに進んでいます。 使いやすく強力なCMSは非常に大きな仕事であり、WordPressはこれを実現するため人気があります。

では、なぜWordPressコアのコードの品質を気にするのでしょうか？ うまくいきますよね？

はい、機能します。15年前のコードベースは、ボランティアのメンテナによって完全にリファクタリングされる可能性はほとんどありません。 残念ながら、これは「WordPressの方法」をコーディングする例としても機能することを意味し、多くの開発者がベストプラクティスや最新の開発手法に従わないことを許します。 非常に多くのWordPressプラグインとテーマは悪名高いほど悪いコードを持っており、盲目的にレガシー慣行に従うことはトレンドを続けるだけです。

しかし、誰がまだその仕事をしている悪いコードを気にしますか？ ええと、無料のものは何もありません、そして誰かがひどく行われた仕事の代金を払います。 ありがたいことに、WordPressコードベース自体を使用して、そのメンテナは時間の支払いをします。 しかし、あなた自身のコードで、支払うのはあなたのクライアントです。

適度に複雑なシステムであっても、初期開発のコストはそれを維持するコストと比較してわずかであり、保守は新しい機能を追加することも意味します。 不十分に設計および実装されたソフトウェアを修正するために開発者を雇うことは、最初から適切に開発するよりも数倍の費用がかかります。

安価なソリューションは、長期的には常に最も高価なソリューションです。 または、予算がなくなった後に放棄されます。 実績のあるソフトウェア設計の原則と実践に従うと、実際にクライアントのお金を節約できます。 これらの方法は、誇大宣伝された流行ではなく、変更のために変更されるものでもありません。 ここでの知恵は、開発者の集合的な経験から生まれたものであり、それに従うことは実際に報われます。

明らかに、これは、CSSを数行追加したり、カスタム投稿や書き直しを数行追加したりするような、本当に単純なタスクには当てはまりません。 しかし、いくつかのプラグイン（またはより一般的には数十のプラグイン）を一緒に叩いたり、Visual Composerを利用したサイトを作成したりすることは、とにかくソフトウェアエンジニアリングではありません。

それ自体は悪いことではありません。一部のソリューションがこれほど単純であるという事実が、WordPressが非常に人気がある理由です。 しかし、このシリーズでは、実際のWordPress開発、つまり重要なPHP、HTML、CSS、およびJavaScriptコードの記述について説明します。 この記事では、一般的なワークフローから始めて、WordPressのフロントエンド開発に焦点を当てます。

最新のWordPress開発ワークフロー

一般的に、品質コードは次のとおりです。

  • 読み取り可能。 コードの機能とその理由は簡単に理解できます。
  • 基本単位。 明確な目的を持つ小さなコードブロックは、理解、開発、およびテストが容易です。
  • 再利用可能。 同様の問題を解決するためにすでに開発されたモジュールを再利用すると、開発が大幅にスピードアップします。
  • メンテナンス可能。 古い機能の変更や新しい機能の導入は簡単です。

主な結果、つまり開発と所有のコストの削減には、ここでは取り上げない多くのスピンオフのメリットがあります。

代わりに、どの開発手法とベストプラクティスが高品質のコードの作成に役立つかに焦点を当てます。 バージョン管理から始めましょう。

バージョン管理を使用する

これは、Gitを使用することを意味します。 悲しいことに、FTPを介した本番環境での「カウボーイコーディング」はまだほとんど問題です。 つい最近、私は英国を拠点とするエージェンシーで働いていましたが、コードベース全体に次のような名前のファイルがありました。

  • functions copy.php
  • functions copy 2.php
  • functions test.php
  • functions2.php
  • functions test2.php

WordPressサイトを利用するときに最初にすべきことは、バージョン管理下に置くことです。 タンキングサーバーは、WordPressの開発ミスを振り返る楽しいものです。 Gitを使用して、これらの問題、およびおそらくすべての人に起こった可能性のある同様の事故を修正するのは非常に簡単でした。

コードに誤りがあり、サイト全体がダウンしましたか？ git resetは、すべてを元の状態に戻します。 新しいバージョンのアップデートはすべてを壊しましたか？ git resetはタイムマシンとして機能します。 悪意のあるコードがどこからともなく現れましたか？ git statusは、新しいファイル、削除されたファイル、または追跡されたファイルへの変更を示します。 次に、 git checkoutを実行して、元のファイルを復元します。

.gitフォルダーの公開に注意してください

OK、Gitを使用することは明らかに重要です。 ただし、そうする場合は、Gitリポジトリがハッキングされるのを防ぐことも同様に重要です。 問題は、 .gitフォルダーを公開し、それらにクレデンシャルを保存している場合に発生します。

標準のWordPressインストールは完全にパブリックWebフォルダーにあり、 .gitフォルダーもそこにある可能性が非常に高くなります。 明らかに、ログインクレデンシャルはGitリポジトリに保存されるべきではありませんが、ほとんどのリポジトリには、外部に漏洩してはならない機密情報が含まれていることがあります。

したがって、 .gitフォルダーへのパブリックアクセスはブロックする必要があります。 Apacheを使用している場合は、以下のスニペットを.htaccessファイルの先頭に追加すると、 .gitフォルダーとログファイルへのアクセスもブロックされます。 ログファイルには機密情報が含まれていることが多いため、ログファイルも使用できないようにすることをお勧めします。 さまざまなWebサーバーのセットアップについては、DevOpsの専門家にサポートを依頼してください。

 RedirectMatch 404 /\.git RedirectMatch 404 ^.*\.log

別の環境を使用する

ライブサイトで開発を行わないでください。これは、ダウンタイムや不幸なクライアントのためのレシピです。 OK、でもどのように設定すればいいですか？

理想的には、コードが常に一方向に進む3つの開発環境（ローカル→ステージング→本番）が必要です。 これは、衝突を回避するための実証済みの方法です。 すべてのコア、プラグイン、およびテーマの更新は、最初にローカルで実行され、次にステージングでテストされ、最後に本番環境にデプロイされます。

たとえば、サーバー固有の構成を別のファイルに保存できます。 ローカル環境とステージング環境ごとwp-config-local.phpを作成できます。 （ .gitignoreファイルに追加することを忘れないでください！）次に、次のスニペットをwp-config.phpに追加します。

 if (file_exists(dirname(__FILE__) . '/wp-config-local.php')) : // use local settings require_once(dirname(__FILE__) . '/wp-config-local.php'); else : // production settings endif;

多くの場合、さまざまな環境を設定する最良の方法は、環境変数を使用することです。 この概念に精通していない場合は、Rootsのような完全な最新のソリューションを使用することをお勧めします。

WP-CLIを使用する

WordPressコマンドラインインターフェイス（WP-CLI）は、WordPressのインストールを管理するための非常に便利なツールです。 WP-CLIにアクセスできるということは、事実上すべてのWordPressAPI関数を実行できることを意味します。 たとえば、WP-CLIを使用して、ユーザーとそのパスワードを追加、削除、および編集できます。 サイトを継承したばかりで、所有者が自分自身をロックアウトしている場合に便利です。

もう1つの例は、最初の展開がWP-CLIを使用した簡単なことです。 これらは、いくつかのコマンドで実行できます。

  • コア、テーマ、プラグインのダウンロード
  • データベースでの検索と置換
  • 管理者ユーザーの追加

さらに、これらのアクションはスクリプト化および自動化できます。

高度な展開オプションを使用する

自動化について言えば、次のようないくつかの展開テクノロジーとプロセスを学ぶ価値があります。

  • 継続的インテグレーション/継続的展開/配信（CI / CD）
  • Docker
  • 自動テスト（フロントエンド回帰テストを含む）

確かに、バージョン管理を使用しないことからDockerを処理することへの移行は、大きな飛躍であり、典型的な1人のWordPressプロジェクトにとっては圧倒される可能性があります。 ホスティングプロバイダーによっては、一部のオプションが使用できない場合もあります。 しかし、高度な展開は、チームや大規模なプロジェクトにとって必須です。

リンティングを使用する

ただし、あらゆるサイズのプロジェクトの場合、リンティングはほとんどの開発者にとって恩恵です。 リンティングとは、コードのエラーを自動的にチェックすることを意味します。 PHPStormなどのフル機能のIDEは、箱から出してすぐにそれを実行します。 ただし、VSCodeやSublime Textなどの単純なエディターには、リンターと呼ばれる専用のプログラムが必要です。 これを設定する1つの方法は、ファイルを保存するたびにリンターを実行するようにエディターを構成することです。

PHP_CodeSnifferは、PHPの事実上のリンターです。 構文エラーのチェックに加えて、コードがPSR-2などのスタイルガイドラインに準拠しているかどうかもチェックできます。 これにより、以下のコーディング標準が大幅に簡素化されます。

JavaScriptの場合、ESLintは人気のあるリンターです。 広範なルールセットがあり、JavaScriptのすべてのフレーバーとフレームワークのカスタム構成をサポートしています。

ここでの強力なユースケースは、リンティングをCI / CDビルドパイプラインに組み込んで、すべてのコードがデプロイされる前に自動的に検証されるようにすることです。

最新のWordPressフロントエンド開発技術

WordPressプロジェクト全体に適切なワークフローが設定されたので、フロントエンドのベストプラクティスを詳しく見ていきましょう。

最新のツールを使用する：SassとES6 +

フロントエンドの開発の世界は常に変化し、常に動いています。 SassがCSSを作成するための、そしてグーテンベルク以前のWordPress開発にとって最適なツールであると考えた後も、それは今でもそうですが、その後、誰もがCSS-in-JSとスタイル付きコンポーネントについて話し始めました。

WordPressでさえ抵抗できず、それらの新しいテクノロジーのいくつかを採用しました。 新しいブロックエディターであるGutenbergは、ReactとRESTAPIに基づいて構築されています。

これらのコアフロントエンドテクノロジーについては、必ず理解しておく必要があります。

  • ES6+。 WordPressのドキュメントでは、これをESNextと呼んでおり、使用を推奨しています。
  • サス。 WooCommerceによって使用され、CSS-in-JSにまだ興味がない場合は、CSSを作成するための最良の方法です。
  • Webpack。 現在、WordPressコアでさえWebpackとBabelを使用しています。

ES6とSassはそれぞれ現代のJavaScriptとCSSであり、Webpackは、下位互換性を気にすることなく、これらすべての最新機能を使用できるようにするツールです。 Webpackは、ブラウザーで使用するファイルを生成するフロントエンドアプリコンパイラと呼ぶことができます。

jQueryからVue.jsまたはReactへの移行

WordPressコアとほとんどすべてのWordPressプラグインはjQueryに依存しているため、使用をやめることはできません。 実際、いくつかの<div>を非表示にしたり、そのように慣れているときに1回限りのAJAXリクエストを実行したりするなど、単純なタスクでの使用をやめるのは意味がありません。 jQueryはとにかくロードされる予定であり、シンプルで使いやすいです。

複雑なアプリは、jQueryが苦労するところです。従うのが難しいロジック、コールバック地獄、グローバル変数、HTMLテンプレートなし。 これは明らかに、フロントエンドアプリを整理する別の方法を必要とします。

Reactなどの最新のフロントエンドライブラリは、オブジェクト指向プログラミング（OOP）の原則を使用し、フロントエンドアプリアーキテクチャをモジュール式の再利用可能なコンポーネントに編成します。 コンポーネントには、特定の要素のすべてのコード、マークアップ、および「コンポーネント状態」（変​​数）が含まれます。 要素はほとんど何でもかまいません：ボタン、入力フィールド、ユーザーフォーム、またはWordPressRESTAPIバックエンドからの最近の投稿を表示するウィジェット。 コンポーネントには他のコンポーネントを含めることができ、階層関係を形成します。

今日のWebページは複雑であるため、アプリをコンポーネントに編成することは、あらゆる複雑さの保守可能で高速なWebアプリを構築するための実証済みの方法です。 コンポーネントは再利用性が高く、分離されているため、簡単にテストできる「ブリック」であるため、この概念を学ぶことは非常に有益です。

現在トレンドになっているコンポーネントベースのライブラリは、Vue.jsとReactの2つです。 Reactはすでにグーテンベルクによって使用されているため、当然の選択です。 ただし、最新のJavaScriptを初めて使用する場合は、Vue.jsから始める方がよいでしょう。

Reactは、ES6の機能、クラス、独自のJSX構文、およびWebpackビルドパイプラインをすぐに使用することで、ユーザーをディープエンドに導きます。 学習曲線はかなり急です。

一方、Vue.jsは初心者にとってはるかに使いやすく、 <script>タグをドロップするだけで使用できます。 Vue.jsは、プレーンJavaScript（ES5）、HTML、およびCSSを使用します。 新しい概念の導入は、はるかに段階的です。

いくつかのVue.jsプロジェクトを実行した後は、Reactを深く掘り下げる準備が整います。 常に必要なわけではありませんが、たとえばグーテンベルクの開発では必要です。

WordPressRESTAPIを使用する

WordPressのRESTAPIは、WordPressからのデータをリモートでリクエストおよび変更するための標準化されたインターフェースです。 これは、まったく異なるコーディング方法というよりも、ソフトウェアアーキテクチャの問題です。 同じ古いjQueryAJAXスニペットをわずかに異なるパラメーターで使用できます。

最も重要なメリットは？ WordPress REST APIはバックエンドとフロントエンド間の通信を標準化するため、コードのモジュール性、再利用性、および可読性に向けた主要なステップです。 HTMLとPHPが混在し、いくつかのSQLが混在しているこれらのひどいテンプレートは、実行する必要があります。 テンプレートがパラメータとして渡されるデータのプレースホルダーを持つ単なるHTMLになると、PHPでデータを渡すか、RESTAPIを介してフロントエンドアプリにデータを渡すかに大きな違いはありません。

WPGraphQLを調べることもできます。 最終的にはWordPressRESTAPIに取って代わる場合もあれば、そうでない場合もありますが、急速に勢いを増しています。

グーテンベルクを学ぶ（クライアントはすぐにそれを必要とします）

グーテンベルクの究極の目標は、他の計画の中でもとりわけ、完全なサイトのカスタマイズです。

これは、プラットフォームのパブリッシングエクスペリエンス全体に最終的に影響を与えるWordPressCoreの新しいモデルの基礎を築きます。

GitHubのWordPressGutenbergプロジェクトページ

グーテンベルクは、WordPress開発者から大きな反発を受けました。 それをWordPressコアにマージすることに反対する議論のいくつかは次のとおりです。

  • エンドユーザーの大部分はそれを必要としないので、それはオプションのプラグインであり、コアの一部ではないはずです
  • それはいくつかのサイトを壊しました
  • それは単に準備ができておらず、より多くの研磨とより少ないバグを使用することができました

ただし、ブログプラットフォームとしてWordPressを使用するコンテンツ作成者にとって、Gutenbergは明らかに古いエディターよりも優れたエクスペリエンスを提供します。

グーテンベルクの無効化は、必要な限りサポートされます。 しかし、今それを緩和することは賢明な考えです。クライアントがあなたに近づき、グーテンベルクの開発を依頼すると、準備が整います。

スピードを上げる時間：「WordPressWay」でさえ進化しています

WordPress開発で上記のすべてのツールとテクニックを使用することに反対する最も一般的な議論はこれです：物事を行う「WordPressの方法」はまだ機能し、その方法はこれらすべての新しい光沢のあるものよりも優れていると思われます。

しかし、WordPressのコア開発者はすべての最新の開発をよく知っていることがわかりました。 それだけでなく、明らかな利点があるため、コアの新しい部分で可能な限りそれらを使用します。 私たちを阻んでいるのは、誰もリファクタリングしないレガシーコードだけです。

しばらくの間、WordPressとWooCommerceは、新しいテクノロジーを実装して使用する「機能プラグイン」を開発する慣行に従ってきました。 時が来れば、グーテンベルクが行ったように、これらのプラグインはコアにマージされます。 WooCommerceには独自のReactプロジェクトもあります。 WordPress REST APIも別のプラグインとして開始され、現在はWordPressコアの一部となっています。

問題は、新しいことを学び、それを日常業務で使用する必要があるかどうかではなく、どのように行うかです。 答えは、一度に1ステップずつ「段階的に」です。 新しいことを学ぶか、よく知っていることを新しい別の方法で行います。

たとえば、すべての古いスクリプトでWebpackを使用する方法を学びます。 Webpackは、新しいES6 +コードを、古いブラウザーと互換性のある「プレーンな」JavaScriptにトランスパイルできます。 また、スクリプトを縮小してバンドルすることもできます。 それは1つの新しいことです。 終わり？ 次に、ES6機能を利用してJavaScriptを書き直します。 それはあなたがよく知っていることをするための新しい方法です。

結果：WebpackとES6を学びます。 専門家として、私たちは一歩下がるべきではなく、一歩下がるべきです。 常に学び続けます。 そして、共有するときに共有します。Toptalは、WordPress開発のベストプラクティスのリストを維持し、コミュニティからの貢献を歓迎します。

シリーズのパート2では、最新のWordPressバックエンド開発のPHPパートについて詳しく説明します。