WP_Queryはどこで試す？Local・wp-env・DDEVなど検証環境を比較

本番ではなく、元に戻せる環境でWP_Queryを試す

最初に確かめたいのは、ツールの細かな違いよりも「WP_Queryをどこで試せばよいか」「失敗しても元に戻せるか」です。

本番のテーマファイルで直接試すと、PHPエラーで画面が開かなくなったり、一覧が空になったり、デバッグ情報が訪問者に見えたりする可能性があります。まず元に戻せるローカル環境かPlaygroundでコードを確認し、公開前にステージングで環境差を見ます。

WP_Query自体を初めて使う場合は、先にWP_Queryの役割を確認してください。続けて基本構文と$argsの書き方を見ると、環境の問題とコードの問題を分けやすくなります。

比較軸は、導入のしやすさ、対応OS、環境を作り直せる再現性、共同作業者との共有、本番との差です。ステージングの費用や利用条件は、契約するサーバーのプランで別に確認します。

先に用途から選ぶ

ツール名から選ぶより、「何を確認したいか」から決める方が迷いません。

GUIが必要か、Dockerを使えるか、チームで同じ環境を再現したいかで候補は変わります。ローカルはコードを安全に直す場所、ステージングは本番との差を確かめる場所です。

7つの検証環境を同じ基準で比較する

それぞれの特徴を、導入のしやすさ・共有方法・本番との差という同じ観点で比べます。

Local：初めてのローカルWordPressに向く

Localは、画面操作でローカルWordPressを作れるデスクトップアプリです。コマンド操作を最小限にして、管理画面とテーマファイルを行き来したい人に向きます。macOS、Windows、Debian系Linuxの最新要件は公式資料で確認してください。

向いている人： 初めてローカル環境を作る人、1人で制作する人。サイト作成と起動が分かりやすい一方、チームで同じ環境を再現するには別途ルールが必要です。

MAMP：従来型のローカルWeb環境を画面から扱う

MAMPはApache、PHP、データベースをまとめて動かすMac・Windows向けの環境です。WordPressの配置やデータベース接続を自分で行う分、Localより準備は増えます。

向いている人： Mac・WindowsでApacheやPHPの構成も学びたい人。GUIで基本構成を確認できますが、WordPressの設置や共同作業用の手順は自分で整えます。

XAMPP：汎用的なPHP環境からWordPressを作る

XAMPPはApache、MariaDB、PHP等をまとめて導入するパッケージで、公式サイトにはWindows、Linux、macOS向けの配布があります。WordPressの配置、データベース作成、設定を自分で行うため、WP_Queryだけをすぐ試す目的では手順が増えます。

向いている人： 既にXAMPPを使う人、PHP環境も学びたい人。OSごとに配布されているPHP等のバージョンが同じとは限らないため、導入前に公式ダウンロードページの同梱版を確認します。WordPressのバージョンやサイト設定の共有も自分で管理します。

wp-env：テーマ・プラグイン開発を再現しやすい

wp-envはWordPress公式の@wordpress/envパッケージです。標準のDocker実行方式ではDocker、Node.js、Gitを使い、.wp-env.jsonへWordPress、PHP、テーマ、プラグイン等を記録できます。リポジトリから同じ環境を起動しやすい一方、ターミナルに不慣れならLocalより準備が増えます。

向いている人： テーマ・プラグイン開発者、Gitで設定を共有したい人。本番サーバーの完全再現が目的ではありません。Dockerを使わない実験的なPlayground実行方式もありますが、データベースや利用できるコマンドが異なるため、この記事のDocker方式と分けて選びます。

DDEV：複数案件とチーム開発で条件を揃えやすい

DDEVはコンテナを使い、PHP、Webサーバー、データベース等をプロジェクトごとに管理します。macOS、Windows、Linuxで利用でき、導入前にOSに合うDocker実行環境を用意します。

向いている人： 複数案件を扱う制作者、チーム開発。環境条件をプロジェクト単位で共有しやすい一方、コンテナとCLI操作の基礎が必要です。

ステージング環境：公開前の最終確認に使う

ローカルと本番では、PHP・データベース、Webサーバー、キャッシュ、投稿件数、外部API、メールが異なります。公開前は本番に近いステージングで確認します。本番データを使うなら匿名化し、第三者と検索エンジンから保護し、メールや決済の外部動作を止めてください。

ステージングでの表示確認と、本番への同期は別の操作です。 データベースまで上書きする方式では、確認中に本番へ追加された投稿や注文を失うおそれがあります。同期対象と直前のバックアップを確認してから実行します。末尾のXServer for WordPress資料は同サービス固有の機能で、ほかのXserverサービスへそのまま適用できるとは限りません。

サーバーの申込みだけでWP_Queryの問題が直るわけではありません。先にローカルでコードと条件を切り分け、その後に本番相当の環境差を確認する順番が大切です。

Playground：インストールせず短時間で試す

WordPress Playgroundは、ブラウザーからWordPressを起動できる環境です。テーマやプラグインの動作を短時間で試したい場合に向きます。作業を残す場合は保存先を選ぶか、エクスポートしてから終了します。

向いている人： まずWordPressの画面や小さなコード例に触れたい人。通常のMySQLではなくSQLiteを使うため、SQLの挙動や本番の速度まで同じとは判断できません。 WP_Queryの基本表示から始め、公開前の確認は本番に近い環境で行います。

OSと経験から候補を絞る

使っているOSとコマンド操作の経験を手掛かりにすると、最初に試す環境を絞りやすくなります。

対応OS、Docker、Node.js、必要容量は更新されるため、導入前に公式要件を確認してください。

ローカルから本番までを4段階に分ける

検証環境を選んだら、次の順に確認します。

検証用データは結果の違いが分かるように作る

投稿が1件では件数や並びを確認できません。次の違いが見えるテストデータを用意します。

最初は3件取得する最小コードだけを試す

環境を起動できたら、複雑な条件から始めません。現在のWP Query Builderで、投稿タイプ「post」、公開状態「publish」、件数「3」、並び順「DESC」、並び替え「date」を選んだコードを使います。自動高速化はオンのままで、画面にメタ情報やターム情報を出さず、総ページ数も使わない一覧に合う補助設定まで含めて生成しています。

次の例を、ローカルで有効なクラシック子テーマのtemplate-parts/wpq-test.phpへ保存します。固定ページ用テンプレートのメインループ内でthe_post()を呼んだ後に、get_template_part( ‘template-parts/wpq-test’ );を追加して、その固定ページを開いてください。

投稿本文やfunctions.phpの直下へ貼るコードではありません。ブロックテーマのHTMLテンプレートへそのまま貼ってもPHPは実行されません。確認が終わったら、呼び出しと確認用ファイルを取り除きます。

<?php$args = array(    'post_type' => 'post',    'post_status' => 'publish',    'posts_per_page' => 3,    'order' => 'DESC',    'orderby' => 'date',    'no_found_rows' => true,    'ignore_sticky_posts' => true,    'update_post_meta_cache' => false,    'update_post_term_cache' => false,    'lazy_load_term_meta' => false); $query = new WP_Query( $args ); if ( $query->have_posts() ) {   echo '<ul>';    while ( $query->have_posts() ) {      $query->the_post();      printf(         '<li><a href="%s">%s</a>（ID: %d）</li>',         esc_url( get_permalink() ),         esc_html( get_the_title() ),         get_the_ID()      );   }    echo '</ul>';} else {   echo '<p>投稿が見つかりませんでした。</p>';} wp_reset_postdata();

Builderが生成したのは$argsまでです。new WP_Query()、表示ループ、0件時の文言、投稿IDの表示、wp_reset_postdata()は、同じ条件を各環境で確かめるために手動で追加しています。

まず確認するのは、公開済みの通常投稿が最大3件、投稿日時の新しい順に表示されることです。同じ投稿日時どうしの順番まではこの生成コードで固定しません。ignore_sticky_postsは先頭固定による特別扱いを外す指定で、固定投稿そのものの除外ではありません。最後のwp_reset_postdata()で固定ページの投稿データへ戻します。

表示された投稿IDと管理画面を見比べる

次の表示例は、DDEV上のローカルWordPressに公開済みの通常投稿が23件ある場合です。上のPHPから新しい3件のID82・81・80が表示されます。IDはそのサイト固有の値なので、自分の管理画面の公開日と投稿IDに置き換えて見比べてください。

公開投稿が2件しかなければ、3件指定でも2件です。動いた後にpost_typeや絞り込み条件を一つずつ変えると、どの指定が結果へ影響したか追いやすくなります。この画像はDDEVでの取得結果であり、各ツールの導入成功や処理速度を比べた結果ではありません。

動いた最小条件から次の$argsを作る

あわせて読みたいWP Query Builderの使い方。条件設定からコード生成まで記事を読む

最小コードが動いたら、WP Query Builderで投稿タイプ・件数・並び順を整理できます。生成した$argsを同じ表示ループへ渡し、条件を1つ変えるごとに投稿IDを比べます。

環境が決まったら導入手順へ進む

検証環境を選んだ後は、基本構文、コードを置く場所、各環境の作り方を次の記事から確認できます。

あわせて読みたいWP_Queryの基本構文と$argsの書き方記事を読む

あわせて読みたいWP_Queryのコードをどこに書くか記事を読む

検証環境でも公開情報と個人情報を守る

ローカルやステージングという名前だけでは安全になりません。本番データを使う場合は、公開範囲と外部送信を先に確認します。

導入前に公式資料で現在の要件を確認する

各環境の導入条件は、次の公式資料で確認してください。