ルーツスタックを使用した最新のWordPress開発ワークフロー

WordPressは、少なくともインターネット標準では何年も前から存在しており、その哲学は常に下位互換性を維持することでした。 今日オンラインにあるWordPressWebサイトの数が非常に多いことを考えると、この互換性に焦点を当てることは理解できます。 ただし、これは古いPHPおよびMySQLバージョンでレガシー環境を使用しているユーザーには役立ちますが（これ自体はセキュリティリスクですが、これは今日の記事のトピックではありません）、新しいWordPressリリースでは十分に活用されていません。最新のPHP機能。

これはまた、多くのWordPress開発者がWordPressのバブルの中に住み、新しい最新のフロントエンド開発テクノロジーを学ぶように動機付けられず、時には物事の「古き良き方法」で立ち往生する原因になっています。

WordPressに最新の開発ワークフローを採​​用できますか？

あなたは間違いなくそうすることができます、そしてWordPress Rootsスタックは、3つの素晴らしいツールで2019年のように開発するのを助けるためにここにあります：

• スターターテーマとしてのセージ、
• 現代のWordPress定型文としての岩盤、
• さまざまな環境への展開とプロビジョニングを管理するTrellis 。

Rootsチームには、プラグイン構築フレームワークであるAcornとプラグインボイラープレートであるCloverの2つの追加ツールも開発中です。 どちらもアルファ版であるため、この記事には含まれていませんが、必ず注意してください。

ルーツスタックとは正確には何ですか

もともとはRootsテーマとして知られていましたが、新しいWordPressWebサイトのよりクリーンな開始点を提供することを目的とした堅実なHTML5スターターテーマでした。 時が経つにつれて、それはツールの完全なセットに進化し、すべての主要な最新のWebテクノロジーと標準（GruntからGulpとWebpack、LESSとSCSS、NPMとYarn、Bootstrap、PSR-2コーディング標準とDRY原則まで）を通過しました。したがって、それを採用したWordPress開発者は、最新のフロントエンド開発テクノロジーが提供するものを継続的に学習し、最新の状態に保つ必要があります。

今日、Rootsは継続的な拡張でツールのフルセットに成長しました。これは、開発からステージング、本番までのサイクル全体をたどることで、より優れたWordPressサイトの構築を支援し、快適さから抜け出すことでより優れた開発者になることを目的としています。いわゆるWordPressバブルによって提供されるゾーン。

しかし、それらが提供する3つの主要なツール、それらが何であるか、そしてなぜそれらの使用を検討する必要があるのか​​を見てみましょう。

ルーツセージ9

Roots Sage 9は、プロがメンテナンスしたWordPressスターターテーマの最後のイテレーションであり、元々は2011年にRootsとしてリリースされました。その存続期間中、多くの変更、改善、ベストプラクティスの再検討を経て、最終的には今日は、WordPress開発のための最新のフロントエンド開発ワークフローを紹介するための素晴らしい出発点です。

Sageがやろうとしているのは、ビューとコントローラーが完全に分離されているMVCパターン（Model-View-Controller）を採用することです。 これにより、ビューを再利用できます。ビューは、データの送信元を必ずしも「知る」必要はありませんが、コントローラーが表示するデータを提供するのを待つだけです。

Sage 9に含まれているコントローラーは、Laravelなどの他のフレームワークで既に使い慣れている実際のコントローラーではありません。主な違いは、Sage9コントローラーがURLベースのルーティングではなくテンプレートベースのルーティングを使用することです。 基本的に、WordPressにURLルーティングを処理させ、テンプレートファイルのコントローラーを作成します。

開発プロセス全体に数度の複雑さを加えることで、Sage 9は初心者にとって最良の選択ではないかもしれません。最終的にそれを習得し、本番環境で使用できるようになるためにかなりの学習が必要になるからです。依存関係と資産管理、コードのバージョン管理、新しいプロジェクト構造、Laravelから派生した新しいテンプレートエンジン、DRY（Do n't Repeat Yourself）の原則、そしてあなたは何とは少し異なる厳格なコーディング標準に固執する必要がありますWordPressが推奨します。 しかし、経験豊富な開発者であれば、それは素晴らしいスタートになる可能性があります。

Sageとオールインしたい場合は、Rootsチームの開発者の1人であるBenWordからの次のアドバイスを覚えておいてください。

セージはテーマフレームワークではなく、スターターテーマです。 更新する必要はめったになく、通常はそこから子テーマを作成しないでください。 スターターテーマであるSageは、新しいプロジェクトの開始点として使用することを目的としています。

だけでなく：

アンダースコアが1,000時間のヘッドスタートである場合、Sageは10,000時間のヘッドスタートです。

セージとファイルとフォルダの構造

Sageのファイルとフォルダーの構造は、アンダースコアなどの他のスターターテーマや、以前のメジャーバージョンのSage8で見られたものとは少し異なります。

これは、Sageをインストールした直後に表示されるものです。

 ├── app/ # it contains all the PHP code of your theme │ ├── controllers/ # your Controllers, it already contains a few │ │ # examples to use as a starting point │ ├── admin.php # setup for the WordPress theme customizer │ ├── filters.php # a good place to group all your theme │ │ # filter hooks │ ├── helpers.php # for various helper functions you want │ │ # to reuse in your theme │ └── setup.php # the main theme setup file ├── config/ # theme configuration files ├── dist/ # all built theme assets, never edit this! ├── resources/ # original theme assets, edit this instead! │ ├── assets/ # all front-end assets │ │ ├── build/ # Webpack and ESLint config │ │ ├── fonts/ # theme fonts │ │ ├── images/ # theme images │ │ ├── scripts/ # theme JS scripts │ │ ├── styles/ # theme SCSS stylesheets │ │ └── config.json # settings for compiled assets │ ├── views/ # all theme Blade templates │ │ ├── layouts/ # base Blade templates │ │ └── partials/ # partial Blade templates │ ├── functions.php # Composer autoloader and theme includes, │ │ # normally you should not edit this unless │ │ # you know what you're doing │ ├── index.php # required by WordPress but left blank │ │ # intentionally, never edit this! │ ├── screenshot.png # the screenshot used in the WordPress admin │ └── style.css # required by WordPress, it should contain │ # only the theme meta information ├── vendor/ # Composer packages, never edit this! ├── composer.json # autoloading for `app/` files ├── composer.lock # Composer lock file, never edit this └── package.json # Node.js dependencies and scripts

さらに、.editorconfig、.eslintrc.js、.stylelintrc.js、phpcs.xmlなど、コードエディターやIDEで使用されるその他のファイルもあります。

Sage9の基本的な要件の概要は次のとおりです。

• WordPress> = 4.7
• PHP> = 7.1.3（php-mbstringが有効になっている場合）
• 作曲
• Node.js> = 8.0.0
• 糸

岩盤

岩盤はステロイドのワードプレスのようなものです！

Sageがテーマ開発を改善する場合、BedrockはWordPressのインストール全体を改善します。 これは、フォルダー構造とセキュリティが改善された最新のプロジェクトボイラープレート（たとえば、Webサイトのルートに構成ファイルがないことによる）、構成ファイルとENVファイル、および適切な依存関係管理（WordPressプラグインとテーマを含む）を提供することによって実現されます。 。

一言で言えば、Bedrockはコアファイルと必要なプラグインのインストールを自動化する自己完結型のWordPressプロジェクトであると言えます。

ファイルとフォルダの構造

基本的なBedrockのインストールを見ると、最初は迷子になっていると感じるかもしれません。 Bedrockは、Web、構成、および依存関係ファイルを独自のフォルダーに分割します。 ベアボーン構造は次のようになります。

 ├── config/ # WordPress configuration files │ ├── environments/ # configuration files for other │ │ │ # environments, they will override │ │ │ # production configuration │ │ ├── development.php # overrides for WP_ENV === 'development' │ │ └── staging.php # overrides for WP_ENV === 'staging' │ └── application.php # main configuration for production │ # environment, it's the equivalent of │ # the wp-config.php file ├── vendor/ # Composer packages, never edit this! ├── web/ # the new root folder of the webserver │ ├── app/ # your new wp-content folder │ ├── wp/ # WordPress core files, never edit this! │ ├── index.php # WordPress view bootstrapper │ └── wp-config.php # required by WordPress, never edit this! ├── .env # all environment variables: db name, │ # user and password, salts, current │ # environment, site urls, and others ├── composer.json # here you can manage versions of │ # WordPress, plugins and other │ # dependencies └── composer.lock # Composer lock file, never edit this

さらに、他の重要度の低いファイルもあります。

岩盤の要件は次のとおりです。

• PHP> = 7.1
• 作曲

トレリス

Trellisは、開発、ステージング、および本番サーバーをシームレスに管理するための最新のLEMPスタックであり、それらを可能な限り相互に類似させることを目的としています（「開発と本番の同等性」）。 つまり、カスタムWordPressサイトが開発環境で機能する場合は、本番環境でも機能し、自信を持って展開できると考えて間違いありません。

ローカル開発では、TrellisはVagrantを利用vagrant upます。単純なVagrantを使用すると、仮想マシンで適切な最新環境を実行できます。

ステージング環境と本番環境へのプロビジョニングとデプロイは、Ansibleに何をすべきかを指示するYAMLファイルであるAnsibleプレイブックで管理されます。

Trellisが提案するフォルダ構造

Trellisには、2つのサブフォルダーのみで構成される推奨フォルダー構造があります。

 ├── trellis/ # the clone of the Trellis repository └── site/ # the Bedrock-based WordPress website

そのままにしておくことをお勧めしますが、好みやニーズに応じてカスタマイズできます。

トレリスの要件

• 作曲
• Virtualbox> = 4.3.10
• 放浪者>=2.1.0

なぜそれを使うべきなのか

WordPressがすでにそのまま機能している場合、なぜより複雑なスタックに切り替えて、それを習得するためにかなりの時間を費やす必要があるのでしょうか。 明らかな、そしていくつかのそれほど明白ではない利点があるからです。 それらが何であるかを見てみましょう。

フレームワークにとらわれないスターターテーマ

WordPressのスターターテーマが多すぎると、特定のCSSフレームワークを使用する必要があります。これは、好きかどうか、または知らないかもしれませんが、Sageは完全にフレームワークに依存しません。 インストール中に、Bootstrap 4、Bulma、Foundation、Tachyons、Tailwind CSSを自動的に含めるか、最初から始めたり他のものを使用したりする場合はフレームワークをまったく含めないオプションがあります（ヒント：最近、Tailwindが好きになり始めていますCSSがたくさんあります）。

プロのヒント： Windowsマシンでは、インストール中に「TTYモードはWindowsプラットフォームでサポートされていません」というメッセージが表示される場合があり、フレームワークを選択したり、Sageを構成したりすることはできません。 自動構成を利用する場合は、テーマフォルダー内から次の3つのコマンドを手動で実行する必要があります。

 $ vendor\bin\sage meta # to specify the metadata for your # theme (the name, etc., that goes # in style.css). $ vendor\bin\sage config # to specify your theme's dev URL and # theme directory. $ vendor\bin\sage preset # to set up the theme with one of the # supported frameworks or no # framework at all.

最新のビルドプロセス

Sageに含まれているWebpackを使用すると、アセットのコンパイル、JavaScriptとCSSコードの連結と縮小、画像の最適化、JavaScriptとスタイルのエラーのチェック、外部ライブラリの管理について考える必要がなくなります。 ビルドプロセスは、単純なyarn build （またはアセットを本番用に最適化する場合はyarn build:production ）ですべてを処理し、テーマ/dist/フォルダーにすべての静的ファイルを生成します。

最新のPHPと要件

WordPressを実行できる最小のPHPバージョンはPHP5.2.4です。これにより、レガシー環境でWebサイトを実行しているすべてのユーザーとの下位互換性が確保されますが、古いバージョンのPHP（<= 7.0）は正式にEndOfに到達しています。ライフなので、サポートされなくなり、サイトがセキュリティの脆弱性やパフォーマンスの問題にさらされる可能性があります。

SageとBedrockの両方にPHP7.1の正常なバージョンが必要です（ただし、7.3を選択するオプションがある場合は、そうしてください）。

Sage 9は、PSR-2コーディング標準（最も広く使用され、受け入れられているコーディング）も完全に採用しています。

PHPコミュニティで使用されている標準）。WordPressのコーディング標準とは少し異なりますが、特にチームで作業している場合や他の人とコードを共有する必要がある場合は、よりクリーンで保守性の高いコードを使用できます。

より良い依存関係とパッケージ管理

Rootsスタックは、Composerを大いに活用して、WordPressコア、プラグイン、テーマを含むすべての依存関係とパッケージを管理します。 これは、サードパーティのツールを使用してWordPressの更新（ManageWP、MainWP、InfiniteWPなど）を管理する場合に問題になる可能性がありますが、すべてをバージョン管理下に置くと、より詳細に制御でき、以前の作業に簡単にロールバックできると主張する人がいるかもしれません。何かがうまくいかない場合のバージョン。

さらに、SageはYarnをアプリケーションコードのパッケージおよび依存関係マネージャーとして使用し、ビルドプロセスを起動します。

より良いテンプレートファイル

WordPressには実際のテンプレートエンジンがないため、それを補うためにSageはLaravel's Bladeを採用し、DRYの原則に従っています。

これは、デフォルトのsingle.blade.phpテンプレートファイルの外観であり、わずか6行のコードです。

 @extend('layouts.app') @section('content') @while(have_posts()) @php the_post() @endphp @include('partials.content-single-'.get_post_type()) @endwhile @endsection

ブレードテンプレートエンジンは、ビューとコントローラーを完全に分離し、その構文は、PHPタグよりもエレガントで、簡潔で、読みやすく、記述が簡単です。 ここでの経験則は、すべてのPHPコードをテンプレートファイルから除外することです（または少なくともそうしようとします）。

Bladeを使用するもう1つの利点は、テンプレートの継承です。基本レイアウトテンプレート（デフォルトは/resources/views/layouts/app.blade.php ）は、共通のWebサイト要素を含むブロックを定義し、子テンプレートによって継承されます。 テンプレートの継承は、個々のテンプレートから繰り返されるマークアップを削除し、物事をドライに保つのに最適です。

Browsersync

yarn startを実行すると、Browsersyncセッションが起動します。 Browsersyncは、開発中の同期ブラウザテスト用のモジュールです。 フロントエンドアセットに加えられた変更を監視し、Webpackと連携して、変更をブラウザセッションに自動的に挿入します。

迅速、簡単、安全なWordPressの導入

Trellisは、ダウンタイムゼロのWordPressデプロイメントを提供します。 デプロイを起動すると、Trellisはリポジトリのgit cloneを実行し、composer installを実行してから、シンボリックリンクを現在のリリースに更新します。これにより、現在本番環境で提供されているファイルが直接編集されることはありません。

Bedrockを使用する場合、Trellisもほとんど構成する必要がありません。

欠点

完全なRootsスタックを使用することの唯一の欠点は（新しいことを学ぶことは別として、まったく問題とは見なされないはずです）、Kinsta、DigitalOceanドロップレット、またはその他のホストなどのTrellis対応のホスティングプロバイダーを使用する必要があることです。 Webルートパスを更新するオプションとともに、少なくともSSH、Composer、およびWP-CLIをサポートします。

これにより、安価な（っぽい）共有ホスティングのほとんどがゲームから除外され、新しいプロジェクトを開始する前に、あなたやあなたのクライアントが考慮しなければならないことがあります。

どうやって始めるのか

これは、有名な「WordPress 5分インストール」の新しい見方と見なすことができますが、現代のフロントエンド開発者にとってはそうです。 それは後の開発のために数度の複雑さを追加しますが、結局、あなたが得ることができる利益は間違いなくそれだけの価値があります。

フルスタック（Sage、Bedrock、およびTrellis）の採用に焦点を当てますが、これらの1つまたは任意の組み合わせを使用できます。 Sageは、WordPressのインストールでスタンドアロンテーマの開始点として使用できます。 Bedrockは、任意のWordPressテーマで使用できます。 Trellisのデプロイは、Bedrockベースのサイト用に構成されており、必要なすべてを処理しますが、少し手を加えるだけで、ほとんどすべてのニーズに合わせてカスタマイズできます。

新しいプロジェクトを作成する方法

Trellis、Bedrock、Sageを使用して新しいWordPressプロジェクトを設定するのは非常に簡単で、コマンドラインを数行使用するだけです。

目的のフォルダ（ example.comなど）にTrellisをインストールします。

 $ mkdir example.com && cd example.com $ git clone --depth=1 [email protected]:roots/trellis.git $ rm -rf trellis/.git

/site/サブフォルダーにBedrockをインストールします。

 $ composer create-project roots/bedrock site $ cd site/web/app/themes/

Sageをインストールしてビルドします。

 $ composer create-project roots/sage your-theme-name $ cd your-theme-name/ $ yarn && yarn build

展開

公式ドキュメントに従ってすべてを適切に構成していれば、ステージングまたは本番環境への展開はさらに簡単になります。 コマンドラインからわずか1行です（ example.com/trellis/フォルダーから実行）。

 $ ansible-playbook deploy.yml -e "site=<domain> env=<environment>"

次のコマンドを実行するだけで、デプロイを簡単にロールバックすることもできます。

 $ ansible-playbook rollback.yml -e "site=<domain> env=<environment>

Windowsでの開発環境のセットアップに関するヒント

Rootsスタック、特にTrellisをインストールして使用する方法についてグーグルで検索すると、LinuxまたはMacOSに焦点を当てたチュートリアルがたくさん見つかりますが、Windowsで利用できる情報はほとんどなく、2つの主要な問題があります。Ansibleが利用できないWindowsの場合、Vagrantは通常Windowsマシンでは非常に低速です。

私が最初にこの記事について考えたとき、Windowsの公式Trellisドキュメントは、Vagrant仮想マシン内でAnsibleを実行することを提案していましたが、これは一種のハッキーな方法であり、信頼性はあまり高くありませんでした。

それ以来、WSL（Windows Subsystem for Linux）を使用してすべてをセットアップするための適切な手順でドキュメントを更新しているため、車輪の再発明やチュートリアルを作成する必要はありません。 Trellisをインストールする前に従うことができる3ページ分の詳細なステップバイステップの説明があることを知っておくとよいでしょう：Windowsセットアップ、Windowsセットアップ：SageおよびWindowsセットアップ：Trellis。

ハッピーコーディング！