WordPress-Skeltonをローカルで試そうと思ったんだけど、何故かうまくいかない。そこでローカルにクリーンインストールしたWordPressに部分的に実装してみた。WordPress-Skeltonの仕組み全てを会社のWordPress環境には適用できないので、便利そうな部分のみ使ってみたテストの備忘録。
local-config.phpを活用する
wp-config.phpと同じディレクトリにlocal-config.phpを追加する。local-config.phpにはローカルで使うDB設定情報を記述する。
<?php define( 'DB_NAME', 'localdev' ); define( 'DB_USER', 'localdevuser' ); define( 'DB_PASSWORD', 'localdevpass' ); define( 'DB_HOST', 'localhost' );
次に、wp-config.phpに記述されているDB設定情報を下記のように書き換える。これで、wp-config.phpと同じディレクトリにlocal-config.phpが存在すれば、ローカルのDBに接続される。テスト及び本番環境にはlocal-config.phpをアップロードしない。
if ( file_exists( dirname( __FILE__ ) . '/local-config.php' ) ) {
// ローカル開発用
define( 'WP_LOCAL_DEV', true );
include( dirname( __FILE__ ) . '/local-config.php' );
} else {
// テスト及び本番用
define( 'WP_LOCAL_DEV', false );
/** WordPress のためのデータベース名 */
define('DB_NAME', 'database_name_here');
/** MySQL データベースのユーザー名 */
define('DB_USER', 'username_here');
/** MySQL データベースのパスワード */
define('DB_PASSWORD', 'password_here');
/** MySQL のホスト名 */
define('DB_HOST', 'localhost');
}
WordPressをルートからサブディレクトリへ移動する
CodexのWordPress を専用ディレクトリに配置するを参考に、WordPressのインストールを/wp/サブディレクトリへ移動する。手順はCodexで書かれているので基本OK。加えて:
- ステップ7で、
.htaccessとindex.phpをルートディレクトリにコピーしますが、wp-config.phpとcocal-config.phpもルートに移動する。この2つはコピーではなく移動。config-sample.phpは/wp/ディレクトリに残しておいてOK。 - 今回の僕の環境では、ステップ9の後でうまく表示されず、一度MAMPを再起動させると表示された。
これで、下図のようになる。
wp-contentを移動する
次に、テーマ、プラグイン、アップロードファイルが保存されるwp-contentディレクトリを/wp/の外に出す。Codexのwp-config.php の編集ではこう書いてある。
define( 'WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content' ); define( 'WP_CONTENT_URL', 'http://example/blog/wp-content');
が、ここではWordPress-Skeltonの通りに記述してみる。これを、ルートのwp-config.phpに書き足す。
define( 'WP_CONTENT_DIR', dirname( __FILE__ ) . '/content' ); define( 'WP_CONTENT_URL', 'http://' . $_SERVER['HTTP_HOST'] . '/content' );
管理画面をリロードすると問題無く管理画面自体は表示される。Hello Worldの投稿に画像をアップロードしてみる。
画像は新しく作ったcontentディレクトリへ、設定通りアップされている。

ただし、この段階ではwp-contentディレクトリの中身はまだ移動していないので、インストール時もしくはwp-contentを移動する前にインストールしたテーマやプラグインをWordPressが見つけられず「テーマが見つからない」「プラグインが見つかりません」などの警告がでる。言語ファイルも移動されていないので、日本語に設定してあっても英語で表示される。
なので、/wp/wp-content/の中にあるlanguages、plugins、themesを/content/へ移動する。それぞれのディレクトリにあるindex.phpも忘れずに移動。/wp/wp-content/の中身は削除してもしなくてもOKだと思う。今回は各ディレクトリとindex.phpのみ残し他ファイルは削除。
管理画面に戻り、リロードすると、全てのプラグインとテーマが認識され、言語も日本語に戻る。必要であればプラグインは再度有効化をする。
コアのテーマを活用する
さっきのところで、themesの中身を移動せずに、コアに付いてくるテーマ(/wp/wp-content/themes/の中に入ってる)と、/content/themes/に中に入れたテーマ両方を使えるようにしてみる。こうすることで、コアに付いてくるデフォルトとテーマをそのまま使ったり、それを親として、contentの中に子テーマを作ることもできる。
まず、/content/へ移動した中身を/wp/wp-content/へ戻す。
そして、WordPress-Skeltonからcontent/mu-plugins/の中身をそのまま使う。その中身はシンプルに、register_theme_directoryを使った1行が書かれているプラグインがあるだけ。
<?php register_theme_directory( ABSPATH . 'wp-content/themes/' );
試しにTwenty Elevenの子テーマ、Humをインストールして有効化してみる。
できました。ディレクトリはどうなっているかと言うと、/wp/wp-content/themes/はこんな感じでデフォルトのまま。

そして子テーマのHumは/content/themes/の中にインストールされている。(注:leafは別のテーマです)
※プラグインディレクトリの指定には、どうもここまでフレキシブルな設定方法はないよう。
なんの為にこんなことをするのか
2つある。1つにはまずローカル開発環境のDB情報をテスト及び本番環境と分離させること。ここではlocal-config.phpとして分離させ、このファイルが存在すればローカル環境、無ければテストもしくは本番環境となる。「local-config.phpはサーバーにアップしない」はサイトが丸ごとgitで管理されていることを前提として、.gitignoreに設定しておけば自動化できる。しなくても、サーバーからファイルを1つ削除するのは編集するよりも簡単。
そしてもう1つは、WordPressのコアをその他のファイルと切り離すこと。こうしておけば、コアのみgitやSVNでアップデートとかできるし、バックアップも/wp/以外でOK(なはず)。
wp-config.phpをWordPressのインストールディレクトリの1つ上に置くのはセキュリティ対策として知ってはいたが、こういう使い方をするのは関連記事を初めて読んだ時はちょっと驚いた。あと、定数の設定もこちらの記事とは少し違っていて勉強になる。
- WordPress local dev tips: DB & plugins | Mark on WordPress
- WordPress Skeleton | Mark on WordPress
- Mark Jaquith: Scaling, Servers, and Deploys — Oh My! | WordPress.tv
- Coding, Scaling, and Deploys… Oh My!
- markjaquith/WordPress-Skeleton · GitHub
実用化
まずはlocal-config.phpの仕組みはすぐに使えそう。加えて開発用に定数を設定する技を組み合わせるともうちょっとベターなローカル⇒テスト⇒本番の開発フローが作れるかも。contentsを外に出すのはシンプルなセットアップであれば大きな問題はなさそうではある。WordPress-SkeltonはWP-Stackと組み合わせることでフルパワーを発揮する、みたいな感じだけど、今回は out of scope。







