それ以外にも、WordPressが動いているサーバーのドメインを変更しなくてはならなかったり、ステージングサーバーから公開サーバーにデータコピーをしたりと、WordPressを移設して動かすタイミングって、割と多かったりします。

移設の問題点

移設を行う場合の一番の問題点は、公開URLが変更になることです。

1. テーマファイルのCSSやJavaScriptが読み込まれないためデザインが崩れる
2. 公開URLが正しくないとWordPressの管理画面にログインができない
3. 記事中に設定したリンクや、メディア（画像やファイル）が全てリンクが切れてしまう

1. 2. については公開URLの設定さえ元に変更してしまえば問題無いのですが、一番の問題は 3. で、記事中に設定した内部リンクやら、画像やら添付ファイルやらが全てリンク切れを起こしてしまうことです。

Search Regexという正規表現などで記事を検索してURLを置換できるツールなどが、まず考えつく1つの方法です。

• WordPress › Search Regex « WordPress Plugins
• 【WordPress】全記事から検索して一括置換出来るプラグイン「Search Regex」が素晴らしい | nori510.com

しかしこのSearch Regexは、通常の投稿や固定ページの内容は置換できますが、カスタム投稿は検索できません。（カスタマイズすれば可能ですが）

またなにより大きな問題として、このプラグインではカスタムフィールドに入力された内容は対象外となってしまうため、カスタムフィールドに画像のURLや記事のURLなどが入っている場合、こちらを修正することができません。

カスタムフィールドの問題

そのため、カスタムフィールドの値を一気に書き換える場合には、DBから直接UPDATEクエリなどを使って修正するしかなくなりますが、この方法にもまた問題があります。

WordPressのカスタムフィールドには、PHPのシリアライズされたデータが格納されていることがあるからです。

シリアライズされたデータというのは、下記のようなテキストデータです。
これはPHPの配列やオブジェクトなどを文字列に変換したもので、PHPのunserialie関数を通すことで元の配列などに戻すことが可能です。

a:2:{i:2;a:4:{s:5:"title";s:0:"";s:5:"count";i:0;s:12:"hierarchical";i:0;s:8:"dropdown";i:0;}s:12:"_multiwidget";i:1;}

このシリアライズされた文字列には、元の配列やオブジェクトの中のデータ形式や、格納されているテキストの長さなども保持されていて、単純に中のテキストを置換したりしてしまうと、テキストの長さが保持されているデータと合わなくなってしまい、データが復元できなくなってしまいます。

そのため、UPDATEクエリを使って一気に直すことができません。

全て解決！便利なPHPスクリプト

そこで活躍するのが下記で公開されている SEARCH REPLACE DB というスクリプト。

• WordPress Serialized PHP Search Replace Tool | Interconnect IT – WordPress Consultants, Web Development and Web Design

海外の方が開発されCODEXにも記載されている非常に有用なスクリプトで、シリアライズされたデータも含めて、DBにあるレコードから特定の文字列を一気に置換することが可能になります！

まずはダウンロード

下記のリンクをクリックしてファイルを保存してください。

解凍したファイルをWordPressと同ディレクトリにアップ

解凍して出てきた searchreplacedb2.php を、WordPressのwp-config.phpが存在するディレクトリにアップします。

ファイルにアクセス

下記のような画面が表示されればOKです。

Submitをクリックして次に進んでください。

DBへの接続情報を確認

wp-config.php と同じディレクトリにアップされていれば、自動的にwp-config.phpに存在するDB情報を読み取って表示してくれます。

Submitをクリックして次に進んでください。

書き換えたいテーブルを選択

書き換えたい文字列があるテーブルを選択します。
最低限、投稿本体が格納されている posts およびにカスタムフィールドの格納されている postmeta、設定値が格納されている options は選択しましょう。

その他のテーブルについては、必要に応じて選択してください。
ユーザーのプロフィールなどにも書き換えたい文字列が存在するようならば、usermeta なども選択する必要があるでしょう。

検索する文字列と置換する文字列を入力

検索する文字列、すなわち書き換え元となる文字列と、置換する文字列を入力します。

WordPressを移設した場合は、以前に設置してあったURLを検索する文字列に、新しく設置した先を置換する文字列に指定します。

例えば http://example.com/blog/wp に設置してあったWordPressを http://hogehoge.com/wp に移設した場合は、下記のように記述してください。

検索する文字列

example.com/blog/wp/

置換する文字列

hogehoge.com/wp/

ポイントは http:// を抜くことです。

これはデータベースの中に http:// を抜いたドメインの状態で保存されているレコードがあるため、一部書き換わらないレコードが出てきてしまうためです。

入力が終わったらSubmitをクリックしましょう。

置換完了

めでたく置換が完了しました。

総計で何レコードが書き換えられたかなどがレポートされます。

最後にファイルを削除

置換が正しく完了したら、設置した searchreplacedb2.php は必ず削除してください。
放置しておくとパスワード認証も何も無くデータベースを書き換えられてしまうため、非常に危険です。

たったこれだけ

たったこれだけのステップで、面倒なURLの置換作業が全て完了します。
慣れればFTPからアップして5分もかからず作業を終えることができるでしょう。

1点注意として、データベースを書き換える作業になるため、作業前には必ずデータベースのバックアップをとった上で作業をしてください。
置換するテキストなどが間違えていた場合に、取り返しのつかないことになる場合があります。

WordPressの移設はとても手間だと悩んでいた方、是非お試しください。

しかし逆に、デフォルトの「投稿」機能から「カテゴリー」や「タグ」といった、 デフォルトで設定されている分類機能を取り外したいといった場合の情報はあまり見つかりません。

そんな時は下記のコードをfunctions.phpに記述して利用します。

function my_unregister_taxonomies()
{
	global $wp_taxonomies;

	/*
	 * 投稿機能から「カテゴリー」を削除
	 */
	if (!empty($wp_taxonomies['category']->object_type)) {
		foreach ($wp_taxonomies['category']->object_type as $i => $object_type) {
			if ($object_type == 'post') {
				unset($wp_taxonomies['category']->object_type[$i]);
			}
		}
	}

	/*
	 * 投稿機能から「タグ」を削除
	 */
	if (!empty($wp_taxonomies['post_tag']->object_type)) {
		foreach ($wp_taxonomies['post_tag']->object_type as $i => $object_type) {
			if ($object_type == 'post') {
				unset($wp_taxonomies['post_tag']->object_type[$i]);
			}
		}
	}

	return true;
}

add_action('init', 'my_unregister_taxonomies');

これだけで簡単に「カテゴリー」や「タグ」などを外すことができます。

特にメディア関してはフィルタをするような項目がなく、自分が投稿したもののみを表示するような仕組みが用意されていません。

そのため、自分が投稿した画像を他人に利用されてしまったり、逆のこともできたりと、少々お粗末な管理になってしまっています。

フィルターフックを使って表示を制限

WordPressではWP_Queryクラスを利用して、一覧や詳細画面を表示する際にデータベースから投稿を取得してきます。

そこで、WP_Queryクラスが投稿を取得する前に、今現在ログインしているユーザーの投稿やメディアのみを取得するようにクエリを書き換える事で、上記のような問題を解決することができます。

下記のコードをfunctions.php等に記述してください。

function my_pre_get_posts_filter(&$wp_query)
{
	global $pagenow;
	$user = wp_get_current_user();

	if (WP_ADMIN && ($post_type = $wp_query->get('post_type'))) {
		if (in_array($pagenow, array('media-upload.php', 'upload.php')) && $post_type == 'attachment') {
			// メディアの表示情報を制限
			$wp_query->set('author', $user->ID);
		}
	}
}

add_action('pre_get_posts', 'my_pre_get_posts_filter', 10, 1);

管理画面で表示しているかどうかの条件判断についてはもっと良い方法があるかと思うんですが、とりあえず上記コードで問題無く動作しています。

しかしながら、実際にアップロードしたファイルのURLを取得すると、
/{account_name}/files/{year}/{month}/{file_name} というURLが帰ってきます。
これは、マルチサイト用の .htaccess にURLの書き換え処理が記載されているためです。

# uploaded files
RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]

このURLに直接アクセスすればファイルは表示されますし、通常の利用上では全く問題はありません。

しかしながら、サムネイルを生成する際に非常に便利なライブラリである TimThumbなどを利用する際に、この書き換えられたURLが問題になります。

• TimThumb

TimThumbは、与えられたURLから実際のファイルパスを計算し、ファイルを読み込もうとします。

しかし、この与えられたURLは .htaccess により書き換えられたダミーのURLのため、実際にこの場所にはファイルは存在しません。

そのため、書き換えられる前のURLが必要になります。

関数作った

下記のような関数を作ってみました。

function ms_calc_media_url($blog_id, $media_url)
{
	global $wpdb;

	switch_to_blog($wpdb->siteid);
	$url = preg_replace('|^' . get_blog_option($blog_id, 'siteurl') . '/(files/[\d]{4}/[\d]{2}/.+)$|', get_bloginfo('url') . '/wp-content/blogs.dir/' . $blog_id . '/$1', $media_url);
	restore_current_blog();

	return $url;
}

$blog_id に当該のファイルをアップロードした子ブログのIDを指定して、$media_url にファイルのURLを与えれば、書き換えられる前のURLを計算して出力します。

この関数を使うことで、問題無くTimThumbなどのライブラリを活用できます。

親サイトの functions.php に下記の記述をするだけです。

function default_theme_setting()
{
	update_option('template', 'theme_name');
	update_option('stylesheet', 'theme_name');
	update_option('current_theme', 'Theme Name');
}

add_action('populate_options', 'default_theme_setting');

theme_name となっている箇所は、テーマのディレクトリ名を入れます。
Theme Name となっている箇所は、テーマの名称を入れておきます。

子テーマを指定する方法

上記の設定で、あるテーマの子テーマを設定しようとすると上手くいきません。
これは、下記の記述にすることで対応可能です。

function default_theme_setting()
{
	update_option('template', 'parent_theme_name');
	update_option('stylesheet', 'child_theme_name');
	update_option('current_theme', 'Child Theme Name');
}

add_action('populate_options', 'default_theme_setting');

parent_theme_name は親テーマのディレクトリ名を入れます。
child_theme_name は子テーマのディレクトリ名を入れます。

要は stylesheet というオプションに子テーマ名を設定し、template というオプションには親テーマを設定しておかなきゃイカンよ、ということです。

原因

これはテーマ側で wp_enquere_script() 関数を用いて、WordPress本体に附属するjQueryを利用している場合によく発生する問題です。

/* WordPress附属のjQueryを、wp_head() 内で読み込む */
wp_enqueue_script('jquery');

WordPressの wp_enqueue_script() 関数を用いてjQueryを読み込んだ場合、通常利用できるはずのjQueryのインスタンスである$変数が利用できません。

これは、WordPress附属のjQueryでは他のライブラリとの競合を防ぐために jQuery.noConflict() を自動的に実行させているため、$変数が設定されないのが原因です。

対処

テーマ側で独自にjQueryを用意して読み込んだり設置してもかまわないのですが、プラグインなどで wp_enqueue_script('jquery') でjQueryを呼び出されてしまうと、既にテーマ附属のjQueryが読み込まれているのにもかかわらず、WordPressに附属しているjQueryも読み込まれてしまいます。

そのため、scriptタグの記述される順番によっては、WordPress附属のjQueryが優先され、jQuery.noConflict() 関数が実行されてしまうために$変数が使えなくなる事もあります。

そのため、いかなる場合にも正常に動作させられるようにするには、jQueryを利用するコードを工夫する必要があります。

問題の起きないコード

下記のように、jQueryのインスタンスを$変数として利用できるスコープを作り、その内部にjQueryを利用したコードを書きましょう。

(function($) {
    /* いつも通りのjQueryを利用したコードを書く */
    $(function() {
        /* 初期化コードなど */
    });
})(jQuery);

こうすることで、WordPressに附属するjQueryが利用された場合でも問題無く$変数を使ったコードを実行することができますし、他のフレームワークとのバッティングも起きません。

• WP Google Maps

WP-GoogleMapsプラグインの概要

WP-GoogleMapsは1ブログ1マップという感じで実装するプラグインで、1つのマップの中にいくつでもマーカーを落とし込むことができます。

今のところ1つしかマップが登録できないのですが、ショートコードにidという記載があるため、もしかしたら今後複数のマップの管理などもできるようになるかもしれません。

有償のアドオンが存在する

有償のアドオンが存在し、アドオンを導入することで、

・デフォルトのマーカーアイコンの変更
・マーカー毎のアイコンの変更
・フキダシのテキストの変更
・フキダシへの画像挿入
・フキダシへのリンクの挿入
・マーカー情報のインポート、エクスポート（CSVファイル形式）

といったことが可能になります。

• WP Google Maps – WordPress Google Maps Plugin

問題点

プラグインを普通に導入すると、マーカー設置の際に日本語を入れると、文字化けして住所検索もできず、全く使い物になりません。

原因はプラグインのソースコードに有り、管理用のデータベーステーブルを生成する際、文字コードをlatin1として指定しているためです。

wpGoogleMaps.php 1064行目付近

    $sql = "
        CREATE TABLE `".$table_name."` (
          `id` int(11) NOT NULL AUTO_INCREMENT,
          `map_id` int(11) NOT NULL,
          `address` varchar(700) NOT NULL,
          `desc` varchar(700) NOT NULL,
          `pic` varchar(700) NOT NULL,
          `link` varchar(700) NOT NULL,
          `icon` varchar(700) NOT NULL,
          `lat` varchar(100) NOT NULL,
          `lng` varchar(100) NOT NULL,
          `anim` varchar(3) NOT NULL,
          PRIMARY KEY (`id`)
        ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ; // この CHARSET=latin1 が問題
    ";

改善する方法

プラグインインストール前

WordPressの自動インストール機能を利用せず、アーカイブとしてまずはファイルをダウンロード・解答し、ソースコードを修正します。

--- wpGoogleMaps.php    2012-02-17 18:24:32.000000000 +0900
+++ wpGoogleMaps2.php   2012-02-21 23:50:50.002343200 +0900
@@ -1074,7 +1074,7 @@
           `lng` varchar(100) NOT NULL,
           `anim` varchar(3) NOT NULL,
           PRIMARY KEY (`id`)
-        ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
+        )
     ";
 
    require_once(ABSPATH . 'wp-admin/includes/upgrade.php');

具体的には、ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 の指定はいらないので削ってしまいます。

プラグインインストール後

コンソールまたは管理ツール（PhpMyAdminなど）でテーブルの文字コードをutf8に変更します。

ただ、このカスタムメニュー、cssのクラス名などを指定する事は可能ですが、リンクボタンに画像を直接利用しようとなると、いろいろな工夫が必要になります。

単純に画像のURLを、メニューのに登録したエントリのタイトルに指定することもできますが、WordPressに多少詳しくないと、アップロードした画像のURLなどを指定するのは敷居が高いですし、メニューの管理上も画像のURLがエントリ名となってしまうため、管理がし辛くなってしまいます。

もっと簡単に画像を使う

そこで、「メニュー名＋メニューに登録したエントリー名」と同一の画像がライブラリに登録されていた場合、自動的にその画像を利用するコードを書いてみました。

利用条件

• PHP 5.2
• WordPress 3.1

functions.php

上記のコードをfunctions.phpとして利用するか、既存のファイルに追記して使って下さい。

使い方

カスタムメニューを下記のような状態で登録したとします。

• メニュー名：　テスト
• エントリー名：　テストの記事

この場合、ライブラリに「テスト/テストの記事」というタイトルの画像があった場合、自動的にその画像をメニューの画像として利用します。

カスタマイズ性の高いフォーム作成画面

通常のテキスト入力やテキストエリアなどの他に、チェックボックスやセレクトボックスなどの多彩な入力フォームを設けることができ、さらにその組み合わせを、フォーム単位で保存する事が可能です。

選択できる入力フォーム

入力フォームは下記の11種類から選択し、各フォームをいくつでも配置する事が可能です。

• テキスト項目
• メールアドレス項目
• テキストエリア
• ドロップダウン・メニュー
• チェックボックス
• 承諾の確認
• クイズ
• CAPTCHA（画像認証）
• ファイルのアップロード
• 送信ボタン

右ペインのドロップダウンメニューから入力フォームのタイプを選択すると、入力フォームのカスタマイズを行う画面が表示されます。

必須入力かどうかや、IDやclass名などを指定する事が可能です。

また、入力された内容に従って、入力フォームや入力フォームの内容をを表示するためのテンプレートタグが表示されています。

このテンプレートタグを使って、お問い合わせフォームのHTMLテンプレートを作成します。

テンプレートタグは表示される際に適宜指定した入力フォームのHTMLに差し替えられ、お問い合わせフォームが表示されます。

通知メールのカスタマイズ

問い合わせがあった場合に、その問い合わせの内容がメールで管理者に送られてくる、通知メールの内容もカスタマイズすることが可能です。

入力フォームを作成した時に表示されたテンプレートタグを利用することで、送信されるメールのテンプレートを作成します。

テンプレートタグはお問い合わせフォームのHTMLテンプレートと違い、各フォームに入力された内容に差し替えられます。

確認メールも、もちろん送ることができる

問い合わせを行ってくださった方に、入力内容の確認として送信する「確認メール」も、簡単に対応することが可能です。

先ほどのメールの設定エリアの下にメール2という項目があり、「利用する」のチェックを入れると、こちらのメールテンプレートの内容も、同時にメールとして送信されるようになります。

このメールの「宛先」欄をメールアドレスのテンプレートタグを入力することで、確認メールとしての機能を実現する事ができます。

メールアドレスの入力フォームを設置していない場合、当たり前ですが確認メールは利用できません。

保存

メールフォームに適当な名前を付けて保存してください。
この時、画面下にフォームを埋め込むためのテンプレートタグが表示されます。

フォームの設置

フォームは、カスタムポストを含むあらゆるページに埋め込むことができます。
本文に、先ほど作成したメールフォームのテンプレートタグを埋め込むだけです。

動作確認

実際にフォームを設置したページを開いて、送信テストを行ってみましょう。

Ajaxを使ったリッチな送信画面なので、確認画面を作成する手間や、煩わしい画面スクロールがありません。

メールが正しく届いていれば大丈夫です。

文字コードによる注意

私の環境では発生していませんが、サーバーのPHPの文字エンコードの設定によってはメールの内容が文字化けするようです。

下記フォーラムの投稿をリンクしておきますので、文字化けが発生してしまった方は参考にしてください。

• WordPress › フォーラム » Contact Form 7のコンタクトメールで文字化けしてしまう

総括

MovableTypeでAFormというプラグインを利用したことがあるのですが、そちらに近いインターフェースで、簡単にお問い合わせフォームを作成する事が可能になっています。

AFormと比べると、コンバージョン率の測定やお問い合わせ内容の一括エクスポートなどの機能は無く、使い勝手も多少劣りますが、無償で利用出来る点を考えると、非常に利用価値の高いプラグインだと感じました。

WordPress版AFormと言っても過言ではないように思います。

高機能なメールフォームが欲しい方、WordPress版のAFormを探していた方など、WordPressを利用している方であれば是非導入を考えてみて下さい。

この機能のおかげで、追加機能やバグの修正版が出た場合でも、ボタン1つで最新のパッケージが利用出来るため、いちいちファイルをダウンロードしてサーバー上のファイルを更新するという手間がありません。

とても便利な自動更新機能なのですが、何かの都合で本体を更新出来ない場合や、更新したくないプラグインが存在する場合、サイドバー等に常に更新通知が表示されるため、逆に非常に煩わしいものに変わってしまいます。

そんな時、WordPress本体や特定のプラグインの更新通知を非表示にする方法があるので紹介します。

WordPress本体のアップデート通知を非表示にする

これは下記のサイトを参考にしました。

• WordPressの自動アップグレードを表示させない方法 | WordPress（ワードプレス）コミュニティ

利用しているテーマの functions.php に下記のコードを記述するだけです。

add_filter('pre_site_transient_update_core', create_function('$a', "return null;"));

これでWordPress本体のアップデート通知は無効になります。

特定のプラグインのアップデート通知を非表示にする

これは調べてもやっている方がいないようなので、WordPress本体のソースを解析してみました。

利用しているテーマの functions.php に下記のコードを記述します。

add_filter('site_option__site_transient_update_plugins', 'filter_hide_update_notice');
function filter_hide_update_notice($data) {
	if (isset($data->response['プラグインのメインファイルまでのファイルパス'])) {
		unset($data->response['プラグインのメインファイルまでのファイルパス']);
	}
}

「プラグインのメインファイルまでのファイルパス」は、WordPressの wp-content/plugins ディレクトリの直下から、プラグインのメインファイルまでのパスを、相対パスで指定します。

例えば私の環境では、最新版に更新することで大幅に機能低下してしまうため、過去バージョンのまま利用しているYARPP（Yet another related posts plugin）というプラグインがあります。

これを例にすると、下記のように記述します。

add_filter('site_option__site_transient_update_plugins', 'filter_hide_update_notice');
function filter_hide_update_notice($data) {
	if (isset($data->response['yet-another-related-posts-plugin/yarpp.php'])) {
		unset($data->response['yet-another-related-posts-plugin/yarpp.php']);
	}
}

これで、特定のプラグインの更新通知を無効にする事ができます。