2012年1月21日開催予定のWordBench福井のイベント『WordCrab Fukui 2012』。参加費の集金用に、WordBench福井名義のゆうちょ口座を開設したところ、なんだかやたらとFacebook上での反応が良かったので、その開設方法を解説したいと思います……ってどーでもいいシャレですみません

任意団体名義での口座開設というとハードルが高いようですが、ゆうちょ銀行についていうとそうでもないみたいです。WordBench福井の前に、別の団体の口座も同じような方法で開設しているので、ほぼこの手順で問題ないでしょう。

1. 団体の規約を作る
2. 代表者個人の印鑑と身分証明書を用意する
3. 代表者と会計担当者が別の場合は、会計担当者の印鑑と身分証明書を用意する
4. 1～3を持って郵便局に行く

ほぼ唯一の作業といっていいのは1.の規約作成です。といっても難しいものをつくる必要はなく、私の場合はA4判2枚の規約を作ってOKでした。参考になれば……ということで、提出した規約をもとにOpenDocument形式のテンプレートをつくりましたので、ご利用いただければと思います（一応PDF形式のファイルもダウンロードできるようにしました）。

なお、規約については一発OKが出ず何度か修正を求められるケースもあるので、口座開設手続きは最寄りの郵便局でやったほうがよいでしょうね。

規約テンプレート（OpenDocument形式）
規約テンプレート（PDF形式）

このところのVPSの低料金化で、重ったらしい共用サーバからVPSに乗り換えてWordPressを稼働させている方も多いかと思います。かくいう私もVPS（『さくらのVPS512』）に乗り換えて、当サイト含め3つのサイトを稼働させています。

PHPアクセラレータによる高速化

さて、せっかくVPSでWordPressを稼働させるのであれば、さまざまなワザを使って高速化を図りたいもの。その一つとして人気が高い（というか定番）のが、PHPアクセラレータを導入するという手法です。私が導入しているPHPアクセラレータ『APC』のサイトにはこう書かれています。

Alternative PHP Cache (APC) は、PHP の実行コードをキャッシュする仕組みで、 フリーかつオープンに使用できます。PHP の中間コードのキャッシュ・最適化を行うための、 フリーでオープンかつ堅牢なフレームワークを提供するということを目標としています。

意訳すると、PHPスクリプト（WordPressでいうとコアファイルやテーマファイル、プラグインなど *.php という名のファイル群）を、サーバがより高速に処理できる状態（バイトコードという）に変換し、メモリ上に蓄えておく仕組み。以降、同じPHPスクリプトを実行するときには変換後のバイトコードを使いまわすため、高速化が図れるというわけです。

で、何が起きた？

このメリットが実は落とし穴でした。WordPressのテーマディレクトリにある functions.php をいくらいじってもサイトに反映されないのです。

WordPressの利点として「PHPスクリプトをトライアンドエラーで修正しながらサイトを構築できる」があると思います。某CMSのように「再構築」という面倒きわまりない手順を踏まなくても、PHPスクリプトをちょっと書いて実行して、また修正して……が簡単にできる。すばらしい。

ところが、PHPアクセラレータを使っていると、PHPスクリプトの修正がすぐには反映されません。コンパイルされたバイトコードがメモリ上に残っていると、PHPスクリプトを修正しようが中身がからっぽになろうが、ゾンビのようにバイトコードが実行されてしまうのです。

例えば、当方の環境（Ubuntu 10.04 i386）におけるAPCの設定ファイル /etc/php5/apache2/conf.d/apc.ini にはこんな記述があります。

apc.gc_ttl=3600

これは、PHPスクリプトが変更されても3600秒間は変更前の古いバージョンでコンパイルしたバイトコードを使い続けるという設定です。なので functions.php をいくらいじってもサイトに反映されなかったというわけ（1時間待てば反映されるんですけどね…… ）

前振りが長くなりましたが対処法

APCを導入していて、かつ、テーマのテンプレートファイルや functions.php を変更する必要が出てきたら、一時的にAPCを停止させるのがいいでしょう。

/etc/php5/apache2/conf.d/apc.ini をエディタで開き

-apc.enabled=1
+apc.enabled=0

と変更して、ウェブサーバ（当方の環境ではApache2）を再起動。

sudo service apache2 restart

こうすることで、PHPスクリプトの変更が即座にサイトに反映されるという、WordPress本来のメリット（？）にあずかれるようになります。

修正が終わったら、再度 apc.ini の書き換えとウェブサーバの再起動をお忘れなく。

私がよくやる制作工程ということで、作業環境はこんな感じ。

• サーバA …… さくらのVPS 512
• サーバAのWordPressインストールディレクトリ…… /home/foo/bar
• サーバB …… さくらのレンタルサーバ スタンダード
• サーバBのアカウント …… hoge
• サーバBの初期ドメイン …… hoge.sakura.ne.jp
• WordPressを転送したいサーバBのディレクトリ …… /home/hoge/www/fuga

サーバAにログインして以下のコマンドを実行。

rsync -e "ssh -p 22" -rz /home/foo/bar/ hoge@hoge.sakura.ne.jp:/home/hoge/www/fuga/

コマンドを実行すると「DSA key fingerprint is ～」という文字列の後に

Are you sure you want to continue connecting (yes/no)?

と出てくるので yes [enter] で続行。アカウント hoge のパスワードを入力後、しばらくしてプロンプトが返ってきたら転送完了です。サーバBにSSHでログインして無事転送されたか確認しましょう。

ちなみに rsync の -a オプションを使わないのは、転送するファイルの所有者やパーミッション、タイムスタンプなどをサーバBに反映させないようにするためです。

なお、ここで紹介した作業ではデータベースの内容は移設できません。phpMyAdminを使った移設方法を別エントリーでまとめてありますので、そちらもあわせてどうぞ。

そんな『Breadcrumb NavXT』、今まで作ったいろんなサイトに組み込んでいるものの、どうもカスタム投稿タイプとの相性がよろしくない様子（プラグインのそのものはカスタム投稿タイプに対応している、ということになっているのですけれども）。

『Custom Post Type UI』プラグインを使った私の設定に原因があるのかもしれませんが、あるサイトでこんなパンくずリストが出力されました。

何が起きた？

ホーム > [カスタム投稿タイプのラベル] > [カテゴリー名] > 記事タイトル

HTMLを見てみるとこんな感じです。

<ul>
<li><a title="ホーム" href="http://www.example.com">ホーム</li><li><a title="[カスタム投稿タイプのラベル]" href="">[カスタム投稿タイプのラベル]</a></li><li><a title="[カテゴリー名]" href="http://www.example.com/path/to/category">[カテゴリー名]</a></li><li>記事タイトル</li>
</ul>

だらだらと書いてしまいましたが、結局

<li><a title="[カスタム投稿タイプのラベル]" href="">[カスタム投稿タイプのラベル]</a></li>

が余計に出力されてしまっているのです。

bcn_display() に引数を与えて解決

公式サイトにもあるようにこのプラグインは、テンプレートの任意の箇所に

<?php
if ( function_exists( 'bcn_display' ) ) {
	bcn_display();
}
?>

と記述することによりパンくずリストを表示するようになっています。ところが、このままでは上記の〈余計なリンク〉が出力されてしまいます。

実は bcn_display() という関数（WordPress的にいうとテンプレートタグ）には、

bcn_display( true );

と書くことにより、PHPで処理できる形として値を返すオプションがあります。つまり、たとえば

$str = bcn_display( true );

と書けば変数 $str にパンくずリストの文字列をいったん格納し preg_replace() などで不必要な箇所をカットして表示させることができるのです。

このオプションを活用して、上記の〈余計なリンク〉問題は

if ( function_exists( 'bcn_display' ) ) {
	$str = preg_replace( "/<li><a title=\"[カスタム投稿タイプのラベル].+?li>/", "", bcn_display( true ) );
 
	echo '<ul>';
	echo $str;
	echo '</ul>';
}

と回避。我ながら変則的なやりかたと思いながらも表示の不具合を解消できたのでした。

この画像でいうところの「活動」とか「プロフィール」といった項目ですね。

で、ソースを読んでいったところ、フィルターフックでメニュー項目の非表示ができることが分かりましたのでここに紹介する次第です。いつもどおりの「ご利用は計画的に」な技術情報ですのでご留意ください。

今回のオーダーは

• 「グループ」を非表示にしてほしい
• 「設定」→「通知」を非表示にしてほしい

というもの。ぱっと思い浮かぶのは、「テンプレートファイルいじればオッケイなんじゃない？」との発想ですが、たとえば「グループ」の非表示に絡む wp-content/plugins/buddypress/bp-themes/bp-default/members/single/home.php というテンプレートファイルを見てみますと

<div id="item-nav">
<div id="object-nav" class="item-list-tabs no-ajax">
<ul>
	<?php bp_get_displayed_user_nav(); ?>
 
	<?php do_action( 'bp_member_options_nav' ); ?>
</ul>
</div>
</div><!-- #item-nav -->

というループでメニューが生成されており、テーマファイルのカスタマイズではどうしようもない状態でした。

それじゃあ、ということで対処法を。

「グループ」を非表示に

wp-content/plugins/buddypress/bp-core/bp-core-templatetags.php で定義されている bp_get_displayed_user_nav() 関数を見てみると、ありました apply_filters() 関数が。

echo apply_filters( 'bp_get_displayed_user_nav_' . $user_nav_item['css_id'], '<li id="' . $user_nav_item['css_id'] . '-personal-li" ' . $selected . '><a id="user-' . $user_nav_item['css_id'] . '" href="' . $link . '">' . $user_nav_item['name'] . '</a></li>', &$user_nav_item );

1. メニュー項目を作るたびに apply_filters() 関数を実行
2. <li> タグに

   $user_nav_item['css_id']

   をIDとして与える

ということをやっているので、

1. 非表示にしたいメニュー項目（<li>タグ）のIDを調べる
2. 調べたIDについて以下のような関数を functions.php に書く

function remove_displayed_user_nav( $content ) {
	if ( function_exists( 'bp_get_displayed_user_nav' ) ) {
		$content = '';
	}
	return $content;
}
add_filter( 'bp_get_displayed_user_nav_groups', 'remove_displayed_user_nav' );

functions.php に書く前

functions.php に書いた後

同様にして……

「設定」→「通知」を非表示に

サブメニューの方は wp-content/plugins/buddypress/bp-core/bp-core-templatetags.php の bp_get_options_nav() 関数で実装されているようなので

function remove_bp_get_options_nav( $content ) {
	if ( function_exists( 'bp_get_options_nav' ) ) {
		$content = '';
	}
	return $content;
}
add_filter( 'bp_get_options_nav_notifications', 'remove_bp_get_options_nav' );

このような感じで。

add_fliter() 関数の引数である bp_get_displayed_user_nav_hoge や bp_get_options_nav_hoge の文字列 hoge が<li>タグのIDに相当するので、削除したいメニュー項目のIDを調べて functions.php に add_filter でどんどこ追記していけばオッケイでしょう。

ですがこのプラグイン、例えばFacebook上でシェアしたとき、デフォルトだと

こんな画像が表示されてしまいます。せっかくプラグインを組み込むのなら、オリジナルの画像を使いたいのが人情というものでしょう……ということで二つの方法を紹介。

デフォルト画像を上書き

How do I replace the default image?
Go to “wordpress directory”/wp-content/plugins/wp-ogp and replace default.jpg with another image with the same name! This only works for the default image, you need to add a featured image on the post page for it to work with articles.

……と『WP-OGP』のFAQにも載っている方法。任意の画像に default.jpg というファイル名をつけ wp-content/plugins/wp-ogp 内にアップロードするだけです。上書きするのでもともとの default.jpg が消えてしまったり、JPEG以外の画像だと使えなかったり、という欠点も。

functions.phpに追記

『WP-OGP』内の wpogp_add_head 関数をアクションフックで置き換える方法です。管理パネルの [外観] – [ヘッダー] で設定した画像だけでなく、サイト外の画像も表示可能という利点があります。例のごとく「ご利用は計画的に 」のコードですが、こんな感じで functions.php に追記します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

function my_wpogp_add_head() {
 
        if ( function_exists( 'wpogp_add_head' ) ) {
                global $post;
                $image = get_the_post_thumbnail_src( get_the_post_thumbnail( $post -> ID ) );
                $data = wpogp_set_data();
 
                if ( empty( $image ) ) {
                        $data['og:image'] = $data['image_src'] = get_header_image();
                }
                else {
                        $data['og:image'] = $data['image_src'] = $image;
                }
 
                echo get_wpogp_headers( $data );
        }
 
}
remove_action( 'wp_head', 'wpogp_add_head' );
add_action( 'wp_head', 'my_wpogp_add_head' );

上記の例では

• アイキャッチ画像がないとき……サムネイルはヘッダー画像
• アイキャッチ画像があるとき……サムネイルはアイキャッチ画像

となります。ヘッダー画像以外のものをサムネイルにしたいときは、9行目の get_header_image(); を ‘http://www.example.com/hoge.jpg’; のように書き換えればオッケイです。

［2011.5.1追記］
初出時のコードにて『WP-OGP』プラグインOFF時の挙動に不具合がありました。コードを修正しましたので、初出時のものをお使いになった方がいらっしゃいましたら、再設定をおねがいいたします。

子テーマを作るディレクトリは『子テーマ – WordPress Codex 日本語版』にあるとおり wp-content/themes 内でOK。でも、Codexどおりの書式ではBuddyPressのデフォルトテーマ（BuddyPress Default）を継承してくれないので、以下のように style.css を定義します（必須の項目だけ記しました）。

1
2
3
4
5
6
7
8

@charset "utf-8";
/*
Theme Name: hoge
Template: bp-default
*/
 
@import url( ../../plugins/buddypress/bp-themes/bp-default/_inc/css/default.css );
@import url( ../../plugins/buddypress/bp-themes/bp-default/_inc/css/adminbar.css );

BuddyPressデフォルトのテーマファイルは wp-content/themes 内ではなく wp-content/plugins/buddypress/bp-themes/bp-default 内にあるので @import のパス（7～8行目）が通常の子テーマとは異なっている、というわけです。

テンプレートをオーバーライド（上書き）したいときは、子テーマディレクトリ内に wp-content/plugins/buddypress/bp-themes/bp-default と同じ構造でテンプレートファイル（*.php）を配置していきます。

たとえばフォーラムのテンプレートをカスタマイズするなら wp-content/themes/hoge/forums というディレクトリを作り、その中に index.php や forums-loop.php を作ればいいということになります。

ではではハッピーなBuddyPressライフを！　BuddyPressの日本語ドキュメントはまだまだ発展途上だと思うので、BuddyPressと格闘するみなさんといろいろ情報共有したいですね。

ということで、備忘録を兼ねて図版入りでテスト環境→本番環境への移設手順をまとめてみました。いつものとおり「ご利用は計画的に 」な技術情報ですのでご容赦のほど。

以下、テスト環境（localhost）のファイル・ディレクトリ等を青文字で、本番環境（www.example.com）のファイル・ディレクトリ等を緑文字で示します。

1. wp-config.php の DB_NAME，DB_USER，DB_PASSWORD，DB_HOST の行を本番環境に合わせて書き換えます。
2. インストールディレクトリ以下の全ファイル・ディレクトリを本番環境にアップロード。
3. phpMyAdminにアクセスし、テスト環境のデータベース内容を表示させます。
   
4. 「エクスポート」タブをクリックし
   すべてのテーブルが選択されていることを確認したら……
   
   「ファイルに保存する」にチェックを入れてエクスポート。
5. phpMyAdminにアクセスし、本番環境のデータベースを表示させます。
   
   テスト環境の全ファイル・ディレクトリをアップロードしたものの、WordPressのインストールスクリプトを実行させていないのでデータベースの中身はからっぽです。
6. 「インポート」タブをクリックし、4.でエクスポートしたファイルを読み込みます。
   
7. 読み込まれるとこんな感じになります。この例ではプラグインが使うテーブルも読み込まれてるので、デフォルトよりもテーブルの数が増えています。
   
8. テスト環境のURLを本番環境のものに置換するため、「SQL」タブをクリックします。
   
9. 以下のSQL文を実行します。

   UPDATE `wp_options` SET option_value=REPLACE( option_value, "localhost", "www.example.com" );
   UPDATE `wp_posts` SET post_content=REPLACE( post_content, "localhost", "www.example.com" ), guid=REPLACE( guid, "localhost", "www.example.com" );

10. では、本番環境のURLにアクセスしてみましょう。いかがでしたか？

ちなみに今回の例では、テスト環境でインストールしていたプラグイン『Contact Form 7』が使うテーブルもSQL文で置換する必要がありました。

UPDATE `wp_contact_form_7` SET mail=REPLACE( mail, "localhost", "www.example.com" ), mail_2=REPLACE( mail_2, "localhost", "www.example.com" );

ちなみにphpMyAdminを使わずとも、4.でエクスポートしたファイルをテキストエディタで開き localhost を www.example.com に一括置換→本番環境にインポート でうまくいく場合もあります。私の場合は、何度かこの方法を試してみてまったくダメだったんですが……

なお、以上の手順ではWordPressのコアファイルやテーマ、プラグイン、アップロードした画像などは本番環境に移設できません。別エントリーで手順をまとめましたのでそちらもあわせてどうぞ。

このファイルタイプはセキュリティの観点から許可されていません。

という警告が出てきてたいそう困りました。配布については、ダウンロード数をカウントできるプラグイン『WordPress Download Monitor』を使うことを決めてたのですが、それ以前にアップロードできないのでは話になりません。

で、探したところ『PJW Mime Config』というプラグインを発見したので紹介します。

公式プラグインディレクトリではこのような説明が書かれてます。

This plugin allows you to configure extra mime-types for support by the inline-uploader.

A new options page is added as Options … Mime-types which allows you to add/delete the extra mime-types.

By default the following extra mime-types are registered: audio/ac3, audio/MPA and video/x-flv.

（拙訳）
インラインアップローダ（WordPress標準のアップローダ）にて、アップロード可能なファイルのMIME Typeを拡張するプラグインです。

プラグインをインストールすると、設定メニューに「MIME Types」という項目が追加され、MIME Typeの追加と削除ができるようになります。

デフォルトとして audio/ac3，audio/MPA，video/x-flv のMIME Typeが設定されています。

ということで、上記「MIME Types」メニューよりAndroidアプリ（*.apk）のMIME Typeを追記します。

[Add mime-type]をクリックして完了です。

WordPress › PJW Mime Config « WordPress Plugins

http://wordpress.org/extend/plugins/pjw-mime-config/

結論からいうと、私の場合「このページにアクセスするための十分なアクセス権がありません。」のエラーメッセージが出てアップグレード後の管理パネルに入れなかったのはインポート時の「MySQLの接続照合順序」の設定が原因でした。

移行元と移行先の環境、および作業の手順は以下のとおりです。

移行元

• サーバ……さくらのレンタルサーバ　スタンダード
• MySQLのバージョン……4.0.27
• データベースの文字コード……EUC-JP（ujis）
• WordPress設定ファイル（wp-config.php）のテーブル接頭辞……hoge_
• 稼働中のURL……http://www.example.com/fuga

移行先

• サーバ……ローカルのテスト環境（Ubuntu 8.04 Server Edition）
• MySQLのバージョン……5.0.67（XAMPP for Linux内で稼働）
• データベースの文字コード……UTF-8 Unicode（utf8）
• WordPress設定ファイル（wp-config.php）のテーブル接頭辞……wp_hoge_
• 稼働させようとするURL……http://192.168.x.x/fuga

作業の手順

1. 移行元のphpMyAdminにて hoge_ で始まるテーブル一式をSQL形式でエクスポート
2. 1.で書き出したファイルをテキストエディタで開き（このとき文字コードはUTF-8と自動認識された）「hoge_」を「wp_hoge_」に一括置換し保存
3. 移行先のphpMyAdminにて新規データベースを作成。MySQLの接続照合順序はデフォルトの utf8_general_ci にて
4. 移行先にWordPressの最新版（本記事執筆時は3.1）全ファイルをアップロード。インストールスクリプト（http://192.168.x.x/fuga）は起動させない
5. 移行先のphpMyAdminにて2.で作ったテキストファイルをインポート
6. インポートした wp_hoge_options を開き siteurl と home を http://192.168.x.x/fuga に修正
7. インポートしたテーブルはWordPress MEの構造のままなので、http://192.168.x.x/fuga/wp-admin にアクセスしてデータベースをアップグレード
8. 移行元で使っていたユーザー名・パスワードで管理パネルにログインすればオッケイ……のはずが「このページにアクセスするための十分なアクセス権がありません。」のエラーメッセージ発生！

このメッセージが現われる原因として

[wordpress error] アクセスする権限がないと表示されて管理画面にログインできない場合の対処法 | Odysseygate.com

にて示されているような「wp_options の wp_user_roles 問題」がググるとよく出てくるのですが、ウチの場合は微妙に違っていました。上記サイトの「エラーの原因」「解決方法」にある対処法ではNGで、上で示した「作業の手順」の3.で

接続照合順序を utf8_unicode_ci にしてデータベースを作成

したことで問題を解決できたのでした。エクスポートされたファイルがUTF-8と判定されたのでデフォルトの接続照合順序で作成したのですが……原因がナゾです 　移行元のMySQLがEUC-JP（ujis）の文字コードで稼働してるのに wp-config.php で

define( 'DB_CHARSET', 'utf8' );

と書いてたのがまずかったですかね。