‘WordPress’ タグのついている投稿

WordPress: xreaでwp-super-cacheとktai-styleがうまくいかない

このエントリをはてなブックマークに追加このエントリをdel.icio.usに追加このエントリをLivedoor Clipに追加このエントリをYahoo!ブックマークに追加このエントリをFC2ブックマークに追加このエントリをNifty Clipに追加このエントリをPOOKMARK. Airlinesに追加このエントリをBuzzurl(バザール)に追加このエントリをChoixに追加このエントリをnewsingに追加

昨日から、WordPressの見た目やパフォーマンスとかについていじってみようかと思って色々やってみてる。今回はwp-super-cacheを入れてみた。今のサーバは十分レスポンスが速いので、別に必要ないかもしれないが。でも速くなった。

その後、ktai-style入れてみた。キャッシュがない状態だとうまく表示できた。

しかし、wp-super-cacheとktai-styleの組み合わせにすると、xreaでは文字化けした。ちなみにXAMPP環境では文字化けせず。safeモードとかが関係してるんだろうか?ktai-styleの説明ページに書かれている設定を行ってみたのだが、うまくいかず。ハーフオンだとこの設定ではダメなのかなぁ?

なんかもう3時になってるので、結局wp-super-cacheを諦めて停止させた。レスポンスは現在でも結構速いから、ケータイで閲覧できるほうを優先した。また時間があったらこの問題に取り組みたい。


PHPList:CoreServerでのWordPressとの連携設定メモ

このエントリをはてなブックマークに追加このエントリをdel.icio.usに追加このエントリをLivedoor Clipに追加このエントリをYahoo!ブックマークに追加このエントリをFC2ブックマークに追加このエントリをNifty Clipに追加このエントリをPOOKMARK. Airlinesに追加このエントリをBuzzurl(バザール)に追加このエントリをChoixに追加このエントリをnewsingに追加

WordPressのPHPList-Form-Integrationプラグインで、メールマガジン購読の際にメアド確認せずに一気に登録させるように設定していたのだが、テスト環境(社内サーバ)ではうまくいっていたのに、CoreServerではうまくいかなかった。

PHPList-Form-Integration内のpholist.phpを書き換えたり、デバッグモードでcURLの内容を出力したりしたら、セッションが引き継げてないのが原因だとわかった。そのセッションが引き継げてない理由自体は全然わかってなかったのだが、他の案件が忙しくなってこの件を一旦放置していた。CakePHPの案件にも一旦目処がついたので、この件の調査を再開しようと思った矢先、閃いた。もしかしたら、モード(版)が違うのではないか?と。

モード?それはすなわち、CoreServerだとPHPはモジュール版とCGI版がある。PHPListはセーフモードだと警告メッセージが出続けるのでCGI版で動かす必要がある。そのときに、CGI版で動かす設定を/lists/admin/以下の.htaccessとphp.iniに記述していた。ところが、/lists/以下には設定してなかったので、/lists/以下はモジュール版で動いていた。

PHPList-Form-Integrationの購読フォームの動作は、

  1. cURLで管理者としてログイン
  2. メールアドレス確認をしない場合、管理者としてメールアドレスを登録処理する

である。
管理者ログインがCGI版でログイン、メールアドレス登録がモジュール版で処理をしようとしていたため、モジュール版とCGI版ではセッション管理が異なるためメールアドレス登録が管理者扱いではなくなり、処理できてなかったわけである。ということは、/lists/以下もCGI版にしてしまえばよい。

PHPList全体をCGI版で動かすように.htaccessとphp.ini(CoreServerの場合のやつ)を修正したら、メールアドレス確認なしで動いてくれるようになった。気付けばなんともあっけないのだが、原因がわからずに深夜まで残業してしまったりしていたので何気に悔しかった。まあでも閃いてよかったわ〜。

ちなみにメールアドレス確認なしにした理由は、ケータイから登録された場合にPHPListのメアド確認用画面がケータイからは確認できないからです(テーブルレイアウトででかい!)。


WordPress:Ktai StyleとPHPList Form Integration

このエントリをはてなブックマークに追加このエントリをdel.icio.usに追加このエントリをLivedoor Clipに追加このエントリをYahoo!ブックマークに追加このエントリをFC2ブックマークに追加このエントリをNifty Clipに追加このエントリをPOOKMARK. Airlinesに追加このエントリをBuzzurl(バザール)に追加このエントリをChoixに追加このエントリをnewsingに追加

ちょっとメモ代わりに。
WordPressで、Ktai Styleプラグインを使ってPHPList Form Integrationプラグインのフォームを出そうとしたら、出なかった。理由は、PHPList Form Integrationでフォームを出すときのコードがショートコードとかじゃなくてHTMLのコメントを使っているので(<!–phplist form–>というもの)Ktai Styleのどこかで消されているようだ。

ちなみに試した各プラグインのバージョンは以下の通り。

  • Ktai Style: 1.74
  • PHPList Form Integration: 1.7

根本的な解決方法かどうかはわからないけれど、
最も簡単だと思われる解決策は、以下の通りかなと。

# /plugins/phplist-form-integration/phplist.phpの最後のほう
# phplist_callbackの呼び出し優先順位を99にしない
//add_filter('the_content', 'phplist_callback', 99);
add_filter('the_content', 'phplist_callback');

要は、Ktai Styleによって<!–phplist form–>が削除される前にphplist_callbackを実行するように修正すればいいんじゃないかということです。これで、携帯で見たときにもメルマガ購読フォームが表示されましたし、購読登録できました。


PHP:WordPressのプラグインでsession_start()

このエントリをはてなブックマークに追加このエントリをdel.icio.usに追加このエントリをLivedoor Clipに追加このエントリをYahoo!ブックマークに追加このエントリをFC2ブックマークに追加このエントリをNifty Clipに追加このエントリをPOOKMARK. Airlinesに追加このエントリをBuzzurl(バザール)に追加このエントリをChoixに追加このエントリをnewsingに追加

WordPressでsession_start()するのを、読み込みページ用関数が呼ばれた先頭でやっていたら、エラーが出ていた。あかんやん。タイミング的には確かに、もうページ表示してる途中だから、どこかでechoされてたらアウトなわけです。ということは、session_start()するタイミングは、initだ!

add_action('init', 'hoge_session_start');
function hoge_session_start(){
  session_start();
}

これでエラー出なくなった。


WordPress: cforms2 & Ktai-style

このエントリをはてなブックマークに追加このエントリをdel.icio.usに追加このエントリをLivedoor Clipに追加このエントリをYahoo!ブックマークに追加このエントリをFC2ブックマークに追加このエントリをNifty Clipに追加このエントリをPOOKMARK. Airlinesに追加このエントリをBuzzurl(バザール)に追加このエントリをChoixに追加このエントリをnewsingに追加

WordPressのプラグインのcforms2とKtai-Styleの併せ技一本を狙う。
お客さんが携帯サイトをやっていて、携帯からのお問い合わせに対応したいと。しかし、携帯からのお問い合わせで送信されてくるメールが文字化けするんで助けてください!と後輩から頼まれたというのが経緯。

WordPressのフォーラムより、
携帯からの場合は文字コード変換処理を入れるとかの対応が必要だと思います (Ktai Style の is_ktai() 関数を使えばいけそう)。
という情報を手に入れたので、cforms2のソースコードに手をいれて、携帯の場合の処理を追加することにした。
ちなみに、cformsのバージョンは11.0です。

/wp-content/plugins/cforms/lib_validate.phpの先頭に追加。

// 携帯のアクセスの場合のみ、検証の前にUTF-8にエンコードしてしまう。
if(function_exists('is_ktai')){
  if(is_ktai()){
    foreach($_REQUEST as $key => $value){
      $_REQUEST[$key] = mb_convert_encoding($value, 'utf-8', 'auto');
    }
  }
}
// 以下略

次に、/wp-content/plugins/cforms/lib_email.phpを編集。
@mailを@wp_mailに全部変更する。
ここは@mailで検索すればいいのでソース省略。

次に、/wp-content/plugins/cforms/cforms.phpの354行目あたりを修正。

### start with form tag
// $content .= $ntt . '<form enctype="multipart/form-data" action="' . $action . '" method="post" class="cform'.( $cformsSettings['form'.$no]['cforms'.$no.'_dontclear']?' cfnoreset':'' ).'" id="cforms'.$no.'form">' . $nl;
// au でメール送信できないため、enctypeを除去
$content .= $ntt . '<form action="' . $action . '" method="post" class="cform'.( $cformsSettings['form'.$no]['cforms'.$no.'_dontclear']?' cfnoreset':'' ).'" id="cforms'.$no.'form">' . $nl;

これで、開発環境のほうは、メールの文字コードがutf-8で送信できるようになり、携帯からのお問い合わせにも文字化けしなくなった。しなくなったのだが、、、。

本番環境(xreaのcoreserver)で文字化けが続いた。
件名が文字化けするのだ。件名に『=?utf-8?B?44C(略)』と表示された。

調査すること3時間。遂に解決!!原因はWP Multibyte Patchの設定だった。
utf-8でエンコーディングされている件名をiso-2022-jpで解釈してるために化けているみたいだった。

/wp-content/plugins/wp-multibyte-patch/wpmp-config.phpを修正。
ない場合は、wpmp-config-sample.phpをコピーしてwpmp-config.phpを作成して修正。

// wp_mailに対してのパッチを外す
$wpmp_conf['patch_wp_mail'] = false;

ちなみに、上記の設定をtrueにしたままパッチプラグインの/ext/ja/config.phpでUTF-8を使うように指定したら、何故かさらに文字化けた。本文までiso-2022-jpで解釈されてしまった。UTF-8って指定したのに!!このあたりはまだよくわかっていない箇所なので、もっといい設定があるのかもしれない。

最後に、cformsのmy-functions.phpを修正する。
携帯でのアクセスの場合のみ、検証処理後に出力に用いられるデータをutf-8にエンコードしておく。

// 値の検証後、出力前にコールされる関数
function my_cforms_filter($POSTdata){
	if(function_exists('is_ktai')){
		if(is_ktai()){
			foreach($POSTdata as $key => $value){
				$POSTdata[$key] = mb_convert_encoding($value, 'utf-8', 'auto');
			}
		}
	}
	return $POSTdata;
}

これで、パソコンと携帯からお問い合わせフォームを利用してみたが、どちらも文字化けせずにメールが届いた!後輩も喜んで一件落着!!


WordPress: 自作プラグインでAjaxする正しい方法

このエントリをはてなブックマークに追加このエントリをdel.icio.usに追加このエントリをLivedoor Clipに追加このエントリをYahoo!ブックマークに追加このエントリをFC2ブックマークに追加このエントリをNifty Clipに追加このエントリをPOOKMARK. Airlinesに追加このエントリをBuzzurl(バザール)に追加このエントリをChoixに追加このエントリをnewsingに追加

WordPressの自作プラグインでAjaxする方法で、正しく行う方法がないか探していた。Googleで検索しても、Ajaxを使ってるプラグインの情報がたくさん出てくるばっかりで、作り手に有益な情報を調べるにまでいけなかった。だから、必要なファイルのみを無理矢理require_onceで読み込んでインスタンスを生成してから、やりたい処理を行うという強引な方法を取っていた。しかし、Ajaxしたいところで毎回require_onceをやるのは面倒だし、正しくやる方法があるに違いないと思っていたら、あったよ!やっぱり!

http://wpdocs.sourceforge.jp/AJAX_in_Plugins

上のサイトの例では、javascriptライブラリとしてSACKを使っているが、俺はprototype.js&scriptaculousファンなので、prototype.jsを使ったAjaxで勝負!

まず、プラグイン側でjavascriptファイルを読み込む設定を行う。
プラグインの名前は、hogeとします。

/**
 * /wp-content/plugins/hoge/hoge.php
 *
 * 管理画面でjavascriptを読み込む
 */
add_action('admin_enqueue_scripts', 'hoge_script_admin');
function hoge_script_admin($hook_suffix){
  // 指定したページのみでjsを読み込むために、条件を設定
  // ここではhogeプラグインのカテゴリー管理ページに焦点と絞ったとする
  if (preg_match('/page_hoge_category_list$/', $hook_suffix)) {
    // hoge_category.jsと、prototype.jsを読み込む
    wp_enqueue_script('hoge_category', plugins_url('hoge/js/hoge_category.js'), array('prototype'), '1.0', false);
  }
}

次に、hoge_category.js側に処理を記述する。
関数 update_category_list が呼ばれると、Ajaxでカテゴリーリストを更新する想定です。

function update_category_list(){
  // ajaxurlはWordPressが定義してくれてる
  var params =[];
  // Ajaxアクションを指定
  params.push('action=hoge_get_category');
  // あとは必要なパラメータを設定
  params.push('abc=xyz');
  new Ajax.Updater(
    'category_list', // 更新される領域のID
    ajaxurl,
    {
      method: 'post',
      parameters: params.join('&')
    }
  });
}

最後に、hoge_category.jsから呼ばれるサーバ側の処理を記述する。

// ajaxで呼ばれるアクションを追加する
add_action('wp_ajax_hoge_get_category', 'hoge_get_category');
// 実際に呼ばれるアクションを定義する
function hoge_get_category(){
  $output = '<ul>' . "\n";
  for($i = 1; $i < 10; $i++){
    $output .= '<li>カテゴリーその'. $i .'</li>' . "\n"
  }
  $output .= '</ul>' . "\n";
  echo $output;
}

これで、カテゴリーリストがAjaxで更新されます。


WordPress:検索条件にプラグインのデータも含ませる

このエントリをはてなブックマークに追加このエントリをdel.icio.usに追加このエントリをLivedoor Clipに追加このエントリをYahoo!ブックマークに追加このエントリをFC2ブックマークに追加このエントリをNifty Clipに追加このエントリをPOOKMARK. Airlinesに追加このエントリをBuzzurl(バザール)に追加このエントリをChoixに追加このエントリをnewsingに追加

WordPressでプラグインにて作成したテーブルも検索条件に含めたいと思っていたのだが、方法がわかったので記載する。最初は、検索したというフックがあるのかな〜と思っていろいろ探していたのだが、そんなものは見当たらず。

そしたらありましたよ!本家に書いてありました。

キーワード検索プラグインテーブル

// 仮想プラグインhogeです
array_filter('posts_join', 'hoge_search_join');
array_filter('posts_where', 'hoge_search_where');
function hoge_search_join($join){
  global $wpdb, $hoge_db; // $hoge_dbはプラグイン用dbクラス
  if(is_search()){ // 検索のときのみテーブルを連結する
    $join .= " LEFT JOIN {$hoge_db->table} ON " . $wpdb->posts . ".ID = " . $hoge_db->table . ".post_id ";
  }
  return $join;
}

function hoge_search_where($where){
  global $wpdb, $hoge_db;
  if(is_search()){ // 検索のときのみ検索条件を追加する
    $where = preg_replace(
      "/\(\s*{$wpdb->posts}.post_title\s+LIKE\s*(\'[^\']+\')\s*\)/",
      "({$wpdb->posts}.post_title LIKE \\1) OR "
      ."({$hoge_db->table}.title LIKE \\1) OR "
      ."({$hoge_db->table}.description LIKE \\1) OR "
      ."({$hoge_db->table}.summary LIKE \\1) OR "
      ."({$hoge_db->table}.note LIKE \\1)",
      $where );
  }
  return $where;
}

検索フックではなく(というかそんなの存在しない!)、is_search()メソッドで、検索かどうかをチェックするんか〜。
勉強になった!!


WordPress:管理画面で自作プラグインのjavascript読み込み

このエントリをはてなブックマークに追加このエントリをdel.icio.usに追加このエントリをLivedoor Clipに追加このエントリをYahoo!ブックマークに追加このエントリをFC2ブックマークに追加このエントリをNifty Clipに追加このエントリをPOOKMARK. Airlinesに追加このエントリをBuzzurl(バザール)に追加このエントリをChoixに追加このエントリをnewsingに追加

いやー、知らなかったー。こんなフックがあったんだな〜。
自作プラグインが管理画面用の場合、フック名admin_enqueue_scriptsというのがあった。
使い方わからんかったんだけど、以下のサイトを参考にしたらできた。
http://lesterchan.net/wordpress/2009/01/26/loading-javascript-in-footer-in-wordpress-28/

// 架空のhogeプラグイン内のphpファイル

// 管理画面なら関数hoge_script_adminを呼び出す
add_action('admin_enqueue_scripts', 'hoge_script_admin');

function hoge_script_admin($hook_suffix){
  // CSS,JSを読み込みたいページを配列に持たせる。ここでは新規投稿、編集画面
  $post_pages = array('post.php', 'post-new.php');
  if(in_array($hook_suffix, $post_pages)){
    /**
     * @param string ユニークなハンドル名
     * @param string 読み込みたいCSSファイルのパス
     * @param mixed? 依存するCSSライブラリ?
     * @param string バージョン
     * @param string メディアタイプ
     */
    wp_enqueue_style('hoge', plugins_url('hoge/css/hoge.css'), false, '1.0', 'all');
    /**
     * @param string ユニークなハンドル名
     * @param string 読み込みたいJSファイルのパス
     * @param array 依存するJSライブラリのハンドル
     * @param string バージョン
     * @param boolean falseならヘッダーで読み込み trueならフッターで読み込み
     */
    wp_enqueue_script('hoge', plugins_url('hoge/js/hoge_admin.js'), array('prototype'), '1.0', false);
  }
}

こうすることで、既にWordPress側で準備しているJSライブラリを使うことができる。プラグイン側で独自にライブラリを準備すると同じライブラリを読み込んだりすることがある。その影響で誤動作や、処理が重たくなったりする。しかしこれを使えば多重読み込みによる誤動作も発生しなくなるだろうし、なにより軽いはず。

いや〜、知らんかったっす…。WordPress 2.8からかな?


WordPress:admin_head-ページフック名って?

このエントリをはてなブックマークに追加このエントリをdel.icio.usに追加このエントリをLivedoor Clipに追加このエントリをYahoo!ブックマークに追加このエントリをFC2ブックマークに追加このエントリをNifty Clipに追加このエントリをPOOKMARK. Airlinesに追加このエントリをBuzzurl(バザール)に追加このエントリをChoixに追加このエントリをnewsingに追加

admin_headフックを使って、cssやjavascriptを読み込ませていたんだけど、プラグインによって重複したり、全ての管理ページでcssとjavascriptを読みにいってるみたいだったので、なんか回避方法はないものかとWordPressのドキュメントを読んでいたら、こんなフックがあった。

  • admin_head-ページフック名
  • admin_head-プラグイン管理ページ名

どういう意味なのか、さっぱりわかんない。
wordpress ページフック名 でググってみたが、よさげな情報が出てこない。うーむ。
先人の知恵を拝借するために、Eclipse内で、正規表現を使って
admin_head-[\w]+?
で検索したら、admin_head-プラグイン管理ページ名を使ってるプラグインがあったー!

add_action('admin_head-wp-postratings/postratings-manager.php', 'ratings_header_admin');

なるほど。プラグインディレクトリからのパスを書くのか。
じゃあ、admin_head-ページフック名ってどうするの?

答えは、

// 新規投稿画面でのみ、hoge_header_include関数を呼び出す
add_action('admin_head-post-new.php', 'hoge_header_include');
// 投稿編集画面でのみ、hoge_header_include関数を呼び出す
add_action('admin_head-post.php', 'hoge_header_include');

おそらく、/wp-admin/****.phpの****.phpをadmin_head-****.phpで指定すればよさそう。
はぁ〜、めっちゃはまったので、とりあえず備忘録として残します。


WordPress: プラグイン開発でログを出す方法

このエントリをはてなブックマークに追加このエントリをdel.icio.usに追加このエントリをLivedoor Clipに追加このエントリをYahoo!ブックマークに追加このエントリをFC2ブックマークに追加このエントリをNifty Clipに追加このエントリをPOOKMARK. Airlinesに追加このエントリをBuzzurl(バザール)に追加このエントリをChoixに追加このエントリをnewsingに追加

まあプラグイン開発じゃなくてもいいんだけど。
プラグインを開発していると、テーブルを新たに作成して、投稿したタイミングでそのテーブルにデータを保存ということもあるかと思うんですが、フックであるsave_postのタイミングのデータをvar_dumpとかで出力できないんじゃないかと思って(そういえば試してないな…)、ログファイルに出力する方法を探していた。

functions.phpに、

  • debug_fopen($log_file, $mode);
  • debug_fwrite($fp, $message);
  • debug_fclose($fp);

という関数があったので、これを使うこととした。

ただし、これらの関数はWordPressのデバッグモードでしか動かないらしい。デバッグモードにするには、$GLOBALS['debug']を1に設定しなければならないらしいのだが、どこで設定すればいいのか見つけられなかったので、wp-config.phpの最後に以下を追加した。

// wp-config.phpに追加
$GLOBALS['debug'] = 1;

その後、プラグインのクラスにデバッグログを保存するためのメソッドを追加。各プラグインディレクトリ内のlogディレクトリ内にdebug.logというファイルを作成して追記していく仕様にした。

// プラグインファイルで処理担当のクラスを実装
class hoge{
	/**
	 * プラグインのログディレクトリにデバッグログを保存する
	 * @param $message ログファイルに出力するメッセージ
	 * @return void
	 **/
	function debug_log($message){
		$message = date('Y-m-d H:i:s') . ' ' . $message . "\n";
		$log_file = dirname(__FILE__) . DIRECTORY_SEPARATOR . 'log' . DIRECTORY_SEPARATOR . 'debug.log';
		$fp = debug_fopen($log_file, 'a+');
		debug_fwrite($fp, $message);
		debug_fclose($fp);
	}
}

ひょっとしたらもっとスマートな方法があるのかもしれないけど、ログを残す方法としては、いいのではないかと。プラグイン用の基底クラスが欲しくなるな〜、とかいって。


Get Adobe Flash playerPlugin by wpburn.com wordpress themes