TORIYAMAHONPOS WordPressのまめ知識
の記事
2013年12月2日(月) KDDIウェブコミュニケーションズセミナールームにて開催されたWordBench 東京に参加した。初のこころみとして平日の夜となったなか、東京近辺のWordPress好きが集まった。会場に着くと季節がらサンタ帽がちらほら、私もさっそくかぶせてもらった。
まずはWordBench 東京モデレーター直子さんより今後の抱負をいただいた。
規模が大きくなりすぎてあまり開催できていないWordBench 東京について、これからは月1回の定期開催を目標とし、毎回異なるテーマを設定していきたいとのこと。たくさんの人が WordPress というオープンソースコミュニティを知り、 深く関わっていけるきっかけにしたいと語ってくれた。
TORIYAMA Yuko
とあるサイトをレスポンシブ対応したら、Google Mapで地図拡大などのコントロール表示が崩れてしまった。気をきかせて 画像の最大表示幅を100%としていることが原因らしい。
地図を表示する枠内では、画像の最大表示幅を無効にする必要がある。
#gmap img {
max-width: none;
}
テーマをTwenty Elevenに戻しても治らないし、どうして急に表示がおかしくなったのかと困った。Twenty Elevenもレスポンシブということだからか。
Twitter Bootstrap を使っている場合も同様の現象となる。
(さらに…)
TORIYAMA Yuko
コメント関連で使ったことがあるプラグインをメモ
Quick Comments
画面遷移せずにコメント投稿できる、というのはユーザからけっこう要望をいただくインタフェースだ。なぜならWordPressでコメントした際のエラー表示があまりにしょぼくて見たくないからである。このプラグインを使うと、コメントの入力チェック、エラー表示、表示までの一連の作業がAjaxで行われる。ただ最近のコメント階層や、コメントの並び順に対応していないため、使う機会が減った。とても残念、国産だから対応してくれないかしら？
Ajax Comment Posting
やはりコメント投稿をAjax処理してくれるプラグインだ。エラー表示がLightBox風に表示されるのが好みでない。(画面の真ん中にマウスを持って行ってOKボタンを押すのがめんどい) あとログインしているのに名前の入力が必須となっているのは設計ミスだろう。名前欄がないのでコメント投稿できなくなり、すぐに捨て去った。こんなのも公式プラグイン？
Comment Validation
JavaScriptでチェックできる範囲のエラーが、送信ボタンの下に表示される。コメントが早過ぎたり、重複などのコアなエラーは素画面が表示されるのが不満だ。これも名前とメールアドレスの入力を必須にしていないにもかかわらず、名前欄が必須のエラーとなる。そこさえ直せばこの中では無難といえる。
Comment Image
写真関連の掲示板を頼まれたので、これを使って画像も投稿できる掲示板を実現しようとしている。ファイル参照欄は自動で挿入する形式と、特定の箇所に自力で設置する方式が選べる。掲示板のみで使いたいので後者でやってみた。アップロードされた画像はプラグインのフォルダに保存される模様だ。そのためマルチサイトに未対応となっている。コメント欄のCSSを工夫すれば楽しくなりそう！
WP Ajax Edit Comments
投稿してしまったコメントを、一定の期間内であれば修正できるプラグインだ。コメント欄で使える10のWordPressプラグイン | Webクリエイターボックスで知った。おもしろい！こんなことができるなんて思いつきもしないから、探しもしなかった。
このなかですぐに使ってみたいと思ったのは、Comment ImageとWP Ajax Edit Commentsだ。どちらもWordPressにはないけど、あったら良いなという機能を実現している。冒頭に挙げたAjaxを使ったコメント投稿はぜひ欲しい機能だけど、コメントが複雑化してきたため対応が難しいのだろうか。なかなか思ったとおりのが見つからない。
TORIYAMA Yuko
プラグインより新規投稿画面にだけJavsScriptを追加したい場合には、admin_print_scripts-post-new.php というアクションフックがあると分かった。たとえば、新規投稿画面であらかじめ特定のカテゴリーを選択状態にしておくということができる。こんなことをしなくてもデフォルトのカテゴリーは設定できるが、投稿元によってカテゴリーを変更したかったのだ。
[PHP]
function my_scripts_new(){
$file = WP_PLUGIN_URL . ‘/’ .dirname(plugin_basename( __FILE__ )) .’/example.js’;
wp_enqueue_script(‘wp-multilingual_new.js’, $file);
}
add_action(‘admin_print_scripts-post-new.php’, ‘my_scripts_new’);
[/PHP]
似た処理で、新規投稿画面のフッタにだけ処理を加えるということもできる。その場合は、admin_footer-post-new.php というアクションフックが利用できる。
[PHP]
function my_footer_new(){
// 処理
}
add_action(‘admin_footer-post-new.php’, ‘my_footer_new’);
[/PHP]
WPtouchの無料版では、機能制限としてテーマディレクトリを設定することができない。テーマディレクトリは/plugins/wotouch/themes/default/に固定されているので、スマホ用テーマを自作した際には、このディレクトリ下のファイルを差し替えるのが無難としてきた。
このほど複数あったブログをひとつのWordPressにまとめ、マルチサイトとして管理するようにしたところ、ここでつまずいた。ブログは複数あるのに、WPTouchのテーマディレクトリが固定(ひとつしかない)ではブログによってスマホ用テーマを分けることはできないではないか。
おとなしく有料版にグレードアップするしかないのか？
そもそも有料版ではマルチサイトに対応しているのか？
と諦めモードになりつつ、ダメモトでWPtouchのコアコードを修正する手段にでた。wptouch.phpの中にreturn ‘default’としている箇所が2つある。まさにテーマディレクトリを固定で返しているところだ。ここでディレクトリ名を操作できそうだ。get_blog_ID()によりマルチサイトのブログIDが分かるので、この値によってテーマ名を分ければよさそうだ。たとえばブログIDが2であればexample-2、3であればexample-3というように分岐してそれぞれのディレクトリにテーマファイルを置けばよい。結果、いまのところうまく動いている！
TORIYAMA Yuko
ログイン画面に表示される「WORDPRESS」というロゴを変更することができる。
[PHP]
function my_login_logo() {
$url = “画像のフルパス”;
echo ‘
‘;
}
add_action(‘login_head’, ‘my_login_logo’);
[/PHP]
さらに、ダッシュボードの左上の「W」というアイコンを変更することもできる。
[PHP]
function my_admin_logo() {
$url = “画像のフルパス”;
echo ‘
‘;
}
add_action(‘admin_head’, ‘my_admin_logo’);
[/PHP]
どちらもフックを利用してCSSを上書きしている。属性が強いのか、!importantが必要だった。
これだけでも、けっこうカスタマイス感が上がる！
TORIYAMA Yuko
WordPressを使ってAndroid向けコンテンツを作成した。
スマートフォンでの表示はWPTouchに頼ればよいと気軽に取り組んだものの、テーマのカスタマイズに思った以上に手間取った。WPTouchはダッシュボードからロゴ画像やリンク色はじめ様々なオプションを選択できて、かっこよくモバイル表示ができるようになっている。ここに自社のデザインをあてはめようした場合にはそれらのオプションはあまり意味をなさず、WPTouch独自の関数を理解せねばならないところから始まる。
それでもなんとかデザインチームから出てきたHTMLを反映することができた。リリース後しばらくして、PC閲覧時にたまにモバイル表示になってしまうことが発覚した。フォーラムなどを調べていて逆の例(モバイルなのにPC表示)は対応策が述べられているなか、PCなのにモバイル表示という例は見つからず、1週間ほどが過ぎた。
WPTouchの動作を見ていたところ、UserAgentは正しく取得できているもののテーマの振り分けがうまく行かない場合がごくまれにあるようだった。テーマの構成としては、
PC用 /themes/mytheme
モバイル用 /plugins/wptouch/themes/mytheme
のようにしていた。
そしてWPTouchが無料版であるため、モバイルテーマのディレクトリを”default”ではなく”mytheme”を参照するように、wptouch.phpを修正してもいた。結論としてはそれがダメだった。
wptouch.phpをもとに戻した。つまりモバイル用テーマのディレクトリを
/plugins/wptouch/themes/default
に戻して、中身には自作のmythemeをコピーした。再現しなくなったようだ。とすると、PC用とモバイル用でテーマ名が同じだったのが原因か。かならず発生するわけではないのでなんともいえない。ともかく無料版ではモバイルテーマのディレクトリはdefaultのままにしておくのが無難としておく。
TORIYAMA Yuko
WordPress 3.0にしてから WP-Cron が9時間遅れていることに気が付いた。1日1回の処理をwp_schedule_event()で午前2時に設定してあり、毎日実行されているようなのであまり気にしていなかったのだ。ある朝処理されていないことに気がつき、それが昼の11時ぐらいなると動くことが分かった。
ちょうど9時間だからタイムゾーンの設定かサーバの設定がおかしいに違いない。まずWordPressでのタイムゾーンの設定は「UTC +9」で、投稿時間が正常であることを確認した。WP-Cron Dashboard というプラグインで予定を確認したところ、午前2時に設定されている。同じサーバに稼働している他のサイトで、似た処理があるものの正常だ。どうもWordPress 3.0のサイトだけが遅れると分かった。
WordPressフォーラムで質問したところ、
date_default_timezone_set('Asia/Tokyo');
を設定するとよいとの回答を得たので、仕込んでみた。
今後、時間を扱うテーマやプラグインでは この設定が必要になるのだろうか。
バージョンアップ時の対応しわすれでは？という気がするものの、解決したのでよいか。
TORIYAMA Yuko
テーマやプラグインでJavaScriptを追加したい場合は、アクションフックのwp_print_scriptsを利用する。管理画面の場合は admin_print_scripts になる。ただしここでやると、管理画面のすべてのページで読み込まれてしまう。これを、たとえば新規投稿画面のみで宣言したい場合には、以下のようなフックを利用するとよい。
[PHP]
add_action(‘admin_head-post-new.php’, ‘my_admin_script’);
[/PHP]
admin_head- に その画面のphpファイル名をつなげたフックが発生するのだ。似たようなことで、自作したプラグインの設定画面では、以下のようなフックが発生する。設定画面がmypluginというプラグインのmy_main.phpというファイルの例だ。
プラグインの設定画面だけで使いたいCSSやJavaScriptがある場合は、ここで追加するとよい。
[PHP]
add_action(‘admin_head-toplevel_myplugin/my_main’, ‘my_admin_script’);
[/PHP]
