このフォームのソースはこんな感じです。

<form method="get" id="sorter" class="dark_bg center">
	<p>
		<?php if(is_search()): ?>
		<label>検索<input type="text" name="s" value="<?php the_search_query(); ?>" /></label>
		<?php endif; ?>
		<select name="order">
			<option value="ASC"<?php if(isset($_REQUEST['order']) && $_REQUEST['order'] == 'ASC') echo ' selected="selected"';?>>昇順</option>
			<option value="DESC"<?php if(!isset($_REQUEST['order']) || $_REQUEST['order'] != 'ASC') echo ' selected="selected"';?>>降順</option>
		</select>
		<select name="orderby">
			<option value="date"<?php if(!isset($_REQUEST['orderby']) || $_REQUEST['orderby'] == 'date') echo ' selected="selected"';?>>公開日</option>
			<option value="modified"<?php if(isset($_REQUEST['orderby']) && $_REQUEST['orderby'] == 'modified') echo ' selected="selected"';?>>最終更新日</option>
			<option value="title"<?php if(isset($_REQUEST['orderby']) && $_REQUEST['orderby'] == 'title') echo ' selected="selected"';?>>タイトル</option>
			<option value="comment_count"<?php if(isset($_REQUEST['orderby']) && $_REQUEST['orderby'] == 'comment_count') echo ' selected="selected"';?>>コメント数</option>
		</select>
		<input type="submit" class="submit button" value="SORT!" />
	</p>
</form>

ちょっとselected属性を出すのがめんどくさいですが、ようするにGETリクエストで色々値を渡しているだけです。

なんでこんなことが可能なのか

この他にも色々できることはあるのですが、基本的に知っておけばいいのは、以下の2点です。

1. WordPressはURLから求められるコンテンツを類推して表示している
2. URLはごにょごにょ解析され、最終的にquery_postsに渡される

とりあえずこれを理解し、以下の例を見てみましょう。

ex.1 どの一覧ページでも検索してみる

たとえば、僕のブログにおいてカテゴリーWeb制作のURLは以下になります。

http://takahashifumiki.com/topics/web/

これの尻尾に検索クエリをつけてmootollsを含むURLにしてみます。

http://takahashifumiki.com/topics/web/?s=mootools

そうすると、mootoolsを含む投稿だけが表示されます。不思議ですね！

検索結果が表示された！

ex.2 日付一覧を古い順にしてみる

僕のブログの2011年10月のエントリー一覧は以下のURLです。

http://takahashifumiki.com/date/2011/10/

これを古い順にしてみます。

http://takahashifumiki.com/date/2011/10/?order=ASC

どうでしょう、 古い順になってますよね。

順番が変わった！

このように、WordPressはURLに色んなクエリ（?key1=value1&key2=value2）を渡すことで、表示される結果がコントロールできるということです。このkeyとvalueに何を使えるかは、Codexを参考にしてください。色々あります。

絞り込み検索を実装してみる

おそらく需要が高いであろう絞り込み検索もそんなにめんどくさくありません。ためしに僕のサイトで、カテゴリーが「その他（ID:10）」または「文芸活動（ID:3）」に属していて、なおかつ「web」という単語を含むページの一覧を表示するためには以下のURLでOKです。

http://takahashifumiki.com/?s=web&cat=3,10

検索結果で特定のカテゴリーのみ出力

つまり、こういう値を渡してくれるフォームを作ればいいだけですね。ただし、カンマ区切りで値を渡してくれるインターフェースはないので、Javascriptでサポートする必要があります。

<form id="search-form" method="get" action="<?php bloginfo('url');?>">
   <label><input type="text" name="s" value="<?php the_search_query(); ?>" /></label>
   <p>
   <?php
      //登録されたカテゴリーを名前の昇順で取得
      $cats = get_categories(array('orderby' => 'name', 'order' => 'asc'));
      foreach($cats as $cat){
         //ループ処理でカテゴリーを全部出力
         printf('<label><input class="cat" type="checkbox" value="%d" />%s</label>', $cat->term_id, $cat->name);
      }
   ?>
   </p>
   <input type="hidden" name="cat" value="" />
   <input type="submit" value="検索" />
</form>

本当は現在設定されているカテゴリーを選択済みにする処理などあるのが望ましいですが、割愛。get_categoriesについてはCodexを確認してください。

上記で出力されたフォームだけだとcatが常に空っぽになってしまうので、こんなJavascriptを読み込みます。

jQuery(document).ready(function($){
      //フォーム送信直前に実行
     $('#search-form').submit(function(e){
          //チェックボックスのチェック済みをすべて取得
          var cats = [];
          $('input.cat:checked').each(function(index, elt){
               cats.push($(elt).val());
          });
          //1つ以上チェックされていたら隠しinputに格納
          //なかったら削除
          if(cats.length > 0){
               $('input[name=cat]').val(cats.join(','));
          }else{
               $('input[name=cat']).remove();
          }
     });
});

これでカテゴリーによる絞り込み検索は実装できます。他にもタグとかカスタムフィールドとかもできるので、色々試してみてください。ポイントはCodexをよく読むことです。

さらなるカスタマイズは茨の道

よくWordPressを導入した場合に言われるのが「Googleみたいに便利な検索機能をつけられないか」ということなのですが、これが難しいのは技術的な問題もさることながら、もっと高次な問題があるように思います。「ゆらぎ検索」や「低レイテンシ」などの様々な技術的難題を突破したとしても、最後に「どんな基準で表示するか」という最大の難問が発生するからです。逆に言えば、これさえわかってしまえば答えは出たも同然です。

Googleが便利なのは「どんな順番で検索結果を表示するとユーザーが便利だと思うか」ということだけを考えているからです。基準もちゃんと持ってます。

• たくさんのサイトからリンクされているWebページはいいページ
• いいサイトからリンクされているWebページはいいページ
• 東京の人は東京の店舗情報を知りたいに違いない
• 友達が進めているWebページは気に入るに違いない

最近はどんどんパーソナライズの方向へ向かっているので、Googleならびに各種検索エンジン・SNSはこうしたデータをやっきになって集めているのですね。便利さはあくまで結果でしかないわけです。

翻ってWordPressのことを考えてみると、よくも悪くもブログシステムが元になっているので、発想の根本がブログ（つまり日記）です。このエントリーで紹介しているソート機能というのは、突き詰めれば「コンテンツをどう評価するかの基準」ということになります。WordPressは日記が元なので、時系列がデフォルトのソート順になっています。

WordPressはデフォルトのままだと「いまこのサイトを誰が見ているか」も知らないし、「このページがどれだけアクセスされたか」もわかりません。評価しようにも評価するべき基準がないのです。この基準を集めるのは結構大変です。ちょっと幾つか具体例を考えてみました。

ケーススタディ１ PVでソート

PVというWordPressが持っていない外部的な指標によってコンテンツをソートする場合を考えてみます。これはMySQL知らなくてもできますね。僕もまだ実践したわけではなく、今度こういうのを作ろうと思っているだけなので、概要だけサラッと。

1. Google AnalyticsでAPIを叩いて特定のURLを取得する
2. 取得したPVをカスタムフィールドに保存する
3. 上記の処理をwp_cronなどで毎週実行する

こんな感じでPVという情報を投稿に不可することは可能です。とりあえずこれでWordPressに「どれだけの人は見たか」ということを教え込ませることはできたので、色々ソートできます。まあ、この程度のことしかやらないなら、Jetpackに入ってるstats使った方が楽ですね。

ケーススタディ2 はてなブックマーク方式

ここからMySQLの知識が必要になります。WordPressはデフォルトだと、タグと投稿は1対1の関係になります。これをテーブル構造的に見るとこうなります。

通常のタクソノミー関係構造

これだと、タグはあくまで投稿のメタデータにしかならず、あんまり有用な情報ではありません。日付とかと一緒ですね。

一方、はてなブックマークはタグとURLは紐づいていますが、さらにそのタグとURLに対する関係にユーザーが入ってきます。「誰がどのURLにどんなタグをつけたか」ということですね。これをテーブル構造的に見るとこうなります。

はてぶっぽいテーブル構造

これはWordPressのテーブル構造にないので、作らないといけなくなります。これは単にデータベースをphpMyAdminで作ればいいというだけのことではなく、CRUDというデータの保存・検索・更新・削除の機能をつけなくてはいけないですし、一覧ページをどうやって出力するかも考えなくてはなりません。ここら辺になるとフレームワークを使った方が早いんじゃないかなーと思い始める人が出てきますね。

ただ、コンテンツを漫然と並べ立てるだけでは飽き足らなくなった場合、これは避けて通れない道だと思います。Web制作業についているだけであれば、学習コストや開発工数をトレードオフして「やらない」という結論もぜんぜんアリだとは思うのですが、コストを度外視してでも実現したいものがある人は、ぜひMySQLを勉強してみることをオススメします。そうじゃないと、新しいものを作れないような気がします。その理由は次節。

凡庸・オア・ダイ

最近破滅派をリニューアル作業をしていてとみに思うのが、データをどのように蓄積してどのように評価するかが結局キモでありコンテンツなんだなーということです。ちょっと前ですが、はてなからGREEに移籍した伊藤直也さんが古巣に提言した内容もそうなんですが、最近ちょっとエッジの効いたサービスをやろうと思ったら、ユーザー最適化などは避けて通れないですね。ロラン・バルトが言ってた作者の死ってこういうことだったんですかね。

PVや「いいね!」「はてぶ」の数などの外部的な指標を上述したような単純なやり方で自分のサイトに持ち込んでも、結局は同じ結果になると思います。伊藤直也さんは「衆愚」という言葉を使っていましたが、たしかにSFの90%はクズだが、そもそもあらゆるものの90%はクズであるとか、どこに国に行っても馬鹿の数が一番多いとか、民主主義は最悪の政治制度だ、ただしこれまで試みられたあらゆる政治制度を除けばと言い換えてもいいかもしれません。はてなブックマークのトップを見ていると、「いつまで部屋片付けてんだ？」「何年TOEIC勉強してんだ？」って思うことしきりですからね。こんなこと書くと炎上しますかね。

ともかく、集計＆ソーティングというのはすでに陳腐な技術であり、そこらへんのフリーソフトでサクッと実現できてしまいます。その結果、どんな指標を使ったにせよ、出来上がるものは大体似たようなものになってしまいまそうな予感。このままいったら僕らはみんなマトリックスにつながれて、偽物の幸福な夢を見ながらGoogleの餌になるしかないですよ。

ちょっと話が大きくなりましたが、ますます便利になりつつあるインターネッツの世界でエッジの効いたデータ提示をしたかったら、茨の道だけどMySQLいじるようにした方がいろいろ捗るぞというメッセージでした。

1. 
   関連度
   66%
   2011.06.25
   WordPressでデータベースを使ったプラグインを作成する
   

   WordPressのプラグインシステムはわりと充実しているので、テンプレートタグとフックを組み合わせれば結構簡単に作れま[...]

2. 
   関連度
   52%
   2011.04.12
   WordPressでbloginfoなくしてもDB負荷は減らないんじゃないかという話
   

   たいしたことではないのですが、WordPressのフォーラムを漁っていたら、Possible improvement o[...]

3. 
   関連度
   43%
   2011.01.28
   WordPressで会員制サイトを作るときの勘所
   

   半ば放置ぎみだったミニコme!の開発を再開したことと、４月に控えている破滅派大リニューアルに向けてWordPressの会[...]

新プラグインGianism

http://wordpress.org/extend/plugins/gianism/

プラグイン名は「ジャイアニズム」と読みます。これは簡単に言うと、WordPressにTwitterやFacebookでログインできるようにするものです。詳しくはこのサイトのログインページを見てみてください。

ログインページにボタン追加

実はSocial Connectというほぼ同じ機能を提供するプラグインがあったりしますが、おそらく100年待ったところで日本のサービスには対応しないだろうなと思ったので、作りました。ただ、作ってはみたものの、OAuthで接続する場合のライブラリがあったりなかったり（あってもPEARだったり）でめんどくさくなったので、mixiなどにはまだ対応していません。すいません。「mixiのヘビーユーザーってどうせ電子書籍買わないんじゃないの」という邪推があったのは内緒です。こちらもあわせてすいません。

Gianismの見所

というわけで、機能的に特に目新しいところはないのですが、お勉強のために車輪の再発名をしたわけではありません。このプラグインはそもそも僕のサイト用に作ったので、「Twitterやmixiのように外部サイトに対して認証機能を提供しているが、メールアドレスは渡さないサービス」向けの機能を備えています。まあ、他のプラグインをよく見ていないので、もしかしたらそういう機能があったのかもしれませんが。

で、どうなるかというと、GianismはWordPressで内部的に使われるメール送信関数wp_mailをフックし、そのメッセージを保存します。送信されるはずだったメールはユーザーのプロフィールページに一覧として表示され、ちょど簡易Webメールのような感じになります。

プロフィールページにメッセージ一覧

そしてさらに、登録した外部サービスを経由して、「高橋文樹.comだけど、あなたにメッセージがあるよ http://example.jp/wp-admin/profile.php 」という具合にメッセージがある旨を教えます。

TwitterにDM送信（日本語化は完了してます）

僕が作っている電子書籍販売用プラグインLiterally WordPressは振込にも対応しているため、メール送信が必須です。というより、振込先をメールしないとほぼ確実に振り込んでもらえません。かといってTwitterは140文字以内という制限があるためメール全文をそのままDMも無理…というわけで、こんな仕様になりました。

一応、検証してはいますが、届かない場合もあるみたいです。この機能はβ版という位置づけにしておきます。

あと、地味な機能ですが、FacebookのファンページでWordPressを使っている場合、その人がファンかどうかも判別できる関数もつけときました。僕のファンページはこちらです。

ECショップ系のプラグインを使っている方は、うまくいけば連携できると思います。

Gianismの名前の由来

「Facebookアプリ開発徹底入門」ePub買ってみた雑感でもちょろっと書きましたが、「お前のものは俺のもの」というジャイアニズムと、プログラミングの世界でよく言われる格言「巨人の肩に乗れ」の二つをかけました。その結果としてずいぶん滑った名前になりましたが、もう出しちゃったからしょうがないです。

Gianismの今後

とりあえずログインまではできたのですが、なるべくよそのメディアでバズを作るような機能を盛り込んでいきたいと思います。と同時に、国産サービスでOAuthを公開しており、なおかつ良さげなAPIを備えているところも追加していきます。こんなのがあると便利ですかね。

1. WordPress内の特定のURLをいいねしてくれたかどうかわかる
2. twitterでURLを含んだツイートが合計100RTされたかどうかわかる
3. 上記の指標を累計して、ファンの忠誠度を計る

なんか嫌らしい機能ばっかりですが、がんばって実装したいと思います。

困ったときは

使ってみて動かなかったら、この記事にコメントしてください。メールでも一応お答えするようにしますが、コメントで公開した方が同じ問題で困っている人に役立つので。

その他雑感

先述した「千人の忠実なファン」モデルですが、僕個人にはあんまり向いてないかなーという気もしています。僕と親しい人にはバレているのですが、ファンサービスに向いている人間ではないのです。

• 人からメールが来ても応えない場合が結構ある
• 誘われたら行くけど自分から誘わないし誘ってくれとも言わない
• 自分が持っている名刺全部にBCCでメール送らない

軽く列挙しただけでもこれだけの悪習を備えていますし、もう30歳も超えて矯正する気もないので、「高橋文樹のことを大好きで出すものを何でも買ってくれるファン」を増やすのは正直難しいんじゃないかと思っています。

ただそうはいってもファンを増やさないことには飢えてしまうので、「高橋文樹のことがちょっと気になっていて、何か出したら買ってみようかなと思ってくれるファン」を増やすことにしました。

ファンとのリレーションを保つために「自分のマメさ」とかは信頼できないので、なるべくプログラムなどで外部化したいと思います。乞うご期待。

1. 
   関連度
   44%
   2011.12.15
   Literally WordPress 0.8.8で定期購読とスマートフォン対応
   

   Literally WordPressを0.8.8にアップデートしました。 http://wordpress.org/e[...]

2. 
   関連度
   43%
   2010.08.20
   WordPressでrubyタグを挿入できるプラグイン作った
   

   というわけで、WordPressでrubyタグを挿入できるプラグインを作りました。 WP-Yomiganaのダウンロード[...]

3. 
   関連度
   43%
   2011.11.19
   Literally WordPressを0.8.6に更新
   

   Literally WordPressを更新しました。バージョンは0.8.6です。変更点は以下の通りです。 銀行振込に対[...]

http://wordpress.org/extend/plugins/literally-wordpress/

変更点は以下の通りです。

1. 定期購読に対応しました。MOONGIFTさんのようなサービスが展開可能です。
2. スマートフォンの決済画面に対応しました。iPhoneやAndroidなどでPayPalにリダイレクトした場合、専用の画面が出るようにしました。
3. 決済方法を選ぶ画面を追加しました。銀行振込が追加された上に、今後もなんらかの決済方法が追加される可能性があるので。
4. ファイルをアップロード後、修正できなくなるバグを直しました。

新機能の詳しい解説

定期購読について

これまでのLiterally WordPressでは、「特定の投稿に対して支払う」という機能を持っていました。定期購読というのはこれと異なり、サイトに対する「会費」のような位置づけです。

このサイトでも試しに実装してみましたので、お金に余裕がある方はページ末尾のリンクから試してみてください。

念のため書いておきますが、このサイトにおける会費は単にプラグインの動作を確認するためのものなので、会員になったからといっていいことはありません。高橋文樹.comで売っているのは電子書籍だけです。

MOONGIFTさんがわかりやすいのですが、同サイトは月額500円の有料会員制を敷いています。ただし、単なるアクセス権のコントロールではなく、提供しているサービスは結構多いです。

• 記事の先行配信
• プレミアム会員専用記事
• 記事のePubダウンロード
• 各記事が3割増（「MOONGIFTはこうみる」などのコラム的なものが追加される）

Literally WordPressで実装している定期購読者用の機能は「コンテンツの指定した部分（moreタグ以降またはnextpageで区切った2ページ目以降）を表示／非表示にする」しかないので、もうちょっと工夫していく必要があります。一応、「現在のユーザーが購読者か否か」を判別する関数はあるので、ある程度プログラミングが得意な方なら色々提供できると思いますが。

スマートフォンの決済画面に対応

PayPalでのログイン

PayPalでのクレジットカード決済

これはプロパティーをちょろっと追加するだけで済んだのですが、PayPalのランディングページにはスマートフォン対応のものがあったので、それを表示するようにしました。

あと、以前はパラメーターを間違えていたためにランディングページで価格が表示されない状態になっていましたが、それも直しました。

支払い方法を選択できるように

支払い方法選択画面

これまでは「今すぐ購入」をクリックした場合に問答無用でPayPalへリダイレクトしていましたが、ワンステップ置くようにしました。いきなりリダイレクトされるとビックリしてキャンセルしちゃうことが多いというのがアクセス解析でわかりましたゆえ。

今後は支払い方法が増えることも考えられますし、色んなオプションも増えて行くのでワンステップあった方がいいかなーと思います。

今後の予定

ワンクリック購入の実装

今後はgihyo.jpやVoyager Storeでも採用されているPayPal Digital Goodsを採用しようと思います。PayPalアカウントをお持ちのユーザーに対して、ワンクリック購入を実現する機能です。これにより「チャリンチャリン・ビジネス」を可能にしていたガラケー公式サイトのキャリア決済と同じように、一度ユーザーの承認を得たらすぐに決済できるようになります。これは多分Adaptive Paymentという機能を使っているので、会費の自動引き落としもできるはずです。

評判を集める方法を考える

有料コンテンツの難しいところなのですが、「有料だとアクセスが増えないので評判が高まらない」という問題があり、いまこれをどうやって解決したらいいのか考えています。とりあえず思いついたのは、「コンテンツリリース直後に購入してくれたユーザーがブログなりなんなりで書いてくれて、ある程度のアクセスが集まったら返金する」というのはどうかなーと考えています。アフィリエイトタグ的なものをつけて集計する必要があるかもしれませんが、はじめは適当でもいいでしょう。有名人に献本して一本釣りみたいなやり方はあんまりWebっぽくないですし、なんかズルっこしいので、最終手段にしたいと思います。まあ、一回ぐらいTwitter砲食らってみたいですが。

というわけで、ご興味のある方は公式リポジトリからダウンロード＆インストールしてください。動かなかったらごめんなさい。

ちなみに、最近達人出版界さんから無料配布されているケヴィン・ケリー著作集１を読んで「1000人の忠実なファン」モデルについて色々と思うことがあったので、これについてまた後日エントリーを書く予定です。

関連する投稿はありませんでした。

1. nginx（特にproxy cache）による高速化
2. CDNの導入

nginxのproxy cacheはdogmap.jpかさくらたんどっとび〜ずを見れば設定できると思います。今回は2番目のCDN導入ですね。

CDNとは？

CDNとはコンテンツ・デリバリー・ネットワークの略でして、社長秘書みたいなものですね。普通WebサイトというのはHTML・JS・CSS・画像・その他（Flashとか）から構成されています。WordPressのようなPHPアプリケーションは最終的にHTMLを吐き出すので、ネットワーク的にはHTMLと同質になりますが、吐き出される内容は都度変わります。Amazonの「こんにちは、◯◯さん」の部分などがそうです。

PHPはサーバがごちゃごちゃ計算して返す必要がありますが、画像ファイルやCSSなどは単に求められているものをそのまま返せば済むので、大してリソースはいりません。

CDNの仕組みはこんな感じ

社長「大事なお客さんだったら俺に教えて、どうでもいい情報だったら適当に返事しておいて」

秘書「御意」

という状況ですね。

で、このCDNというのは高価だったのでGoogleやAdobeという膨大なアクセスを誇るサイトしか導入できなかったのですが、最近はCloudFlareという無料でもオッケーなCDNが誕生してしまったのでかなり敷居が低くなってきました。設定も簡単です。百式さんのサイトに導入方法が書いてあります。

CloudFlareはSSLありだと有料

さて、問題はこのCloudFlare無料版がSSLに対応していないということですね。SSLの場合はPro版（月額$20）利用者のみCloudFlareから証明書が代理で発行されるという仕様です。

Facebookみたいにサイト全体がSSLの場合はそれでもいいかもしれませんが、僕のサイトみたいに部分的にSSLという場合、そのためだけに年額$240払うのは嫌だなーという気分になってしまいます。まあ、ある程度収益を上げているサイトであれば、年額$240なんてタダみたいなものですが、僕のサイトはまだそうなっていないので……

対応方法

さて、ではどうやって対応するかです。基本的な理念は以下の通りです。

1. SSLの場合はCDNを経由しない
2. SSLを利用しない通常のページにおいて、画像・JS・CSSはサブドメイン（ex. s.example.jp）経由で読み込む
3. CloudFlareはs.example.jpのみキャッシュする

1. サブドメインを作成する

まず静的ファイルを読み込むサブドメインを作成します。example.jpであれば、s.example.jpとかでいいと思います。サブドメインの作成方法は環境によって異なるので、がんばってください。今回は下記のようなケースを想定します。

/var/www/example.jp #http://example.jpのドキュメントルート
/var/www/s.example.jp #http://s.example.jpのドキュメントルート

で、この静的ファイル用サブドメインからメインドメインへシンボリックリンクを張ります。「シンボリックリンクってなあに？」という方はググってください。SSH（黒い画面）が使えないサーバではこの方法は使えません。

cd /var/www/s.example.jp
#シンボリックリンク作成
ln -s /var/www/example.jp/wp-admin ./wp-admin
ln -s /var/www/example.jp/wp-includes ./wp-includes
ln -s /var/www/example.jp/wp-content ./wp-content

Apacheの場合は Options FollowSymLinks とかが必要ですが、よくわからない人はググってみてください。

さて、サーバの設定がきちんとしていれば、これでexample.jpとs.example.jpの静的ファイルは同じファイルを参照することになります。WordPressはデフォルトだと/wp-content/uploads/2011/12/photo.jpgといった具合に画像を保存しますが、下記のURLはまったく同じファイルを参照することになります。以下の2つのURLで同じ画像が表示されれば、上手く設定できているということになります。

1. http://example.jp/wp-content/uploads/2011/12/photo.jpg
2. http://s.example.jp/wp-content/uploads/2011/12/photo.jpg

これでとりあえずオーケーです。

2. URLを書き換える

さて、続いてURLの書き換えです。ここが一番めんどくさいんですが、がんばりましょう。

WordPressにおいて静的URLを読み込む方法は沢山ありますが、今回はAPIに準拠しているものみ読み込むという男前なルールで行きたいと思います。以前bloginfo削るメソッド意味ないということを書きましたが、なんかよくわからないURLの書き方をすると対応できないので、そういうのは切り捨てます。ob_startでなんとかするというのもありますが、やりたい人はやってみてください。

WordPressで静的ファイルを読み込まれるケースはだいたい以下の通りですね。

• テーマにbloginfo(‘template_directory’)とか書いてる
• 投稿内に画像等の静的ファイルが記載される（メディアップローダでimgタグが書き込まれる場合）
• プラグインなどによってJSやCSSがwp_headおよびwp_footerで出力される

これらのURLをSSLでない限りにおいてhttp://s.example.jpに書き換えてしまえばいいんですね。テーマのfunctions.phpにこんなのを書き込みます。

/**
 * 投稿内のsrc属性をCDN対応にする
 * @param string $content
 * @return string
 */
function _my_cdn_content($content){
     if(!is_ssl()){
          $upload_dir = wp_upload_dir();
          $upload_dir_url = $upload_dir['baseurl'];
          $upload_dir_cdn_url = str_replace('http://', 'http://s.', $upload_dir_url);
          $content = str_replace($upload_dir_url, $upload_dir_cdn_url, $content);
     }
     return $content;
}
add_filter('the_content', '_my_cdn_content');

/**
 * テーマディレクトリのURLをCDN対応にする
 * @param string $url
 * @return string
 */
function _my_static_url($url){
     if(!is_ssl()){
          //SSLじゃなかったらCDN用URLに変える
          $root_uri = home_url();
          $static_uri = str_replace('http://', 'http://s.', $root_uri);
          $url = str_replace($root_uri, $static_uri, $url);
     }
     return $url;
}
add_filter('template_directory_uri', '_my_static_url');

/**
 * wp_enqueue_scriptで読み込まれたJavascriptのSRC属性をCDN対応
 * @param type $src
 * @return type
 */
function _my_script_loader_src($src){
     $home_url = home_url();
     if(!is_ssl() && false !== strpos($src, $home_url)){
          $src = str_replace('http://', 'http://s.', $src);
     }
     return $src;
}
add_filter('script_loader_src', '_my_script_loader_src');

/**
 * CSSのURLを書き換える
 * @param string $tag
 * @return string
 */
function _my_style_loader_tag($tag){
     $home_url = home_url();
     if(!is_ssl() && false !== strpos('href="'.$home_url, $tag)){
          $tag = str_replace('href="http://', 'href="http://s.', $tag);
     }
     return $tag;
}
add_filter('style_loader_tag', '_my_style_loader_tag');

これでサイトを確認してみて、CSSやJSのURLがhttp://s.example.jpになっていれば問題ありません。

なお、プラグインによってはwp_enqueue_scriptなどのAPIを使っていないことがあるので、その場合はCDNの恩恵を受けられないことになります。

3. CloudFlareの設定を行う

CloudFlareのDNS設定

これで問題がなければCloudFlareの設定を行います。基本的には百式さんが紹介されている方法で問題ありませんが、DNSレコードの設定だけが異なります。

僕のサイトの場合で紹介しますが、http://takahashifumiki.comはCDNを使いません。雲マークをクリックして、曇り空にしておきます。

http://s.takahashifumiki.comだけはCDNを使いたいので、これだけ晴れにしておきます。これで設定完了です。お疲れさまでした。

CDNを導入してみて

Stocker.jpさんに「CDNお勧めですよ」と言われてはじめたのですが、当のCloudFlareに「SSL有料だよ！」と言われて一度は絶望しかけました。でも、やればなんとかなりますね。

一番いいのは「月額$20なんて無料と同じやでガハハ！」というぐらいこのサイトがアクセスを稼ぐことなんですが、ぜんぜんそうなっていないので、こういう地味な工夫をせざるを得ないという事実。貧乏暇less（古館伊知郎）とはよくいったものですよ。

他にできそうなWordPressの高速化

このサイトはnginxなんですが、ログインがあったりするので、Proxy Cacheを導入していません。ただ、クッキー見れば「ログインしているユーザーにはキャッシュを提供しない」ということも可能ですので、がんばって設定したいと思います。できたらまたブログ書きます。

そういえば、dogmap.jpのをかもとさんとこもりまさあきさんがWordPress高速化の本を近々に上梓されるそうなので、この記事読んで意味わからんという人はそれを読んでみるといいかもしれません。

1. 
   関連度
   171%
   2011.10.11
   ぼくのユーザーを守って〜Tips on WordPress + SSL〜
   

   またWordPressのTips兼メモ書きです。いま色々と制作している途中なので、あと一週間はメモ書きが続きます。Web[...]

2. 
   関連度
   80%
   2011.10.09
   WordPressのTinyMCEをチキチキにカスタマイズする
   

   最近続いているWordPressエントリーの続きです。ところでみなさん、HTMLタグは好きですか？　僕はというと、特に好[...]

3. 
   関連度
   64%
   2011.10.04
   WordPressで大規模データを扱う場合のTips
   

   ここひと月ほどお仕事が忙しくて更新できなかったのですが、やっと一段落しました。その際、WordPressでわりと大きめの[...]

クレジットカード持ってない人あつまれー！

1. 銀行振込に対応。振込で購入された場合、ユーザーのトランザクションはペンディング状態になり、入金を確認し次第管理者が手入力でステータスを変更するようになっています。
2. 返金に対応。PayPalは60日以内なら支払いをキャンセルできるので、それを利用しました。銀行振込の場合は手動＆目視で対応して下さい。
3. データベース構造の変更。上記の返金機能実装にともなってデータベース構造が変更しました。dbdeltaが上手く走るか、ドキドキしてます。
4. デフォルトのファイル保護フォルダを変更。一応、デフォルトのまま使うなとは書いてありましたが、プラグインフォルダ内にあるとアップロード時に消去されてしまうので、wp-content/uploads/lwpをデフォルトにしました。ここら辺、どのプラグインも避難用フォルダを後から指定しているので、歴史は繰り返すというやつですかね。僕も自分で作ってみてはじめて気づきました。

今回の目玉機能

今回の目玉機能はなんといっても銀行振込の対応でしょう。実は1週間ぐらい前に完成していたのですが、僕が個人口座のジャパンネット銀行のID＆パスワードを失効してしまったので、その再発行を待っていたため遅れたんですね。結局いまだ新しいIDは届かず、株式会社破滅派の口座を使うことにしました。

以前からクレジットカード以外の支払い方法を求める声は多かったので、がんばって対応しました。これで売上が全然増えなかったら、ぼくはもうテロリストになるしかないと思います。

今後の予定

今後は以下の機能に対応しようと思っています。

購入権に有効期限

現在、一度購入なりプレゼントなりをすると、ずっとファイルにアクセスできるようになっていますが、これに有効期限を儲けようかなと思ってます。買ってから一週間は好きなようにダウンロードできるけど、一週間経つとアクセスできなくなるという機能ですね。キャンペーンと組み合せるといいかなと。これは後述する機能に関係してます。

会費制

僕のブログなんかはあんまり関係ないですが、優良コンテンツを定期的に発信できて、ある程度のブランドがあり、無料と有料を出し分けできる編集能力がある方々におすすめです。「買ってから一週間はすべてのコンテンツにアクセスできる」というタイプですね。雑誌のようなものを出したい人に向いているんじゃないでしょうか。

成立型

CampFireとかGroupon系のサービスがそうなのですが、PayPalの返金機能が60日であることを利用し、「先にお金を集めておいて、必要額集まったらリリース」という機能に対応したいと思います。本来の利用法とは違いますし、PayPalには仮売上を計上する機能もあったとは思うのですが、どうやらPayPalアカウントを持っているユーザーにしか対応していないようなんです。返金機能は常に提供されているので、これを悪用してこの機能を実装してみようかと。60日以内に必要な金額が集まらなければバルク処理で返金を行うという凶悪仕様ですね。

UI改善

これまではユーザーが使っているテーマにフィットさせるためにカスタマイズ可能なフォームを出力するようにしていましたが、どうせみんなカスタマイズしないだろうということと、PayPalのWeb Payment Proがそもそもiframeであること、その２点を鑑みて、決済フローはiframeで提供した方がいいのかなと思うようになりました。僕はプラグインが勝手にモーダルボックスを読み込んだりするとうざいなーと思うタイプなのですが、ほとんどの人はそうではないと思うので、jQueryのいけてるモーダルボックス+iframeで決済フローを完結させたいと思っています。

というわけで、ご興味をお持ちの方は公式リポジトリからダウンロードしてください。なんか電子書籍とだんだん関係なくなってきましたが、がんばって開発します。

関連する投稿はありませんでした。

[hoge var=987923]

いまはショートコードを作りやすくするプラグインなどもあるので、使っている人も多いことでしょう。たとえば、このブログではtmkm-amazonというプラグインを使っていて、これはAmazonのアフィリエイトリンクを表示してくれます。こんな感じ。

これだけのショートコードはいらない！

さて、件のエントリーではだいたい以下のようなことが語られていました。

• 最近Theme Forestとかを見ていると、どうでもいいショートコードを搭載したテーマが増えているようだ
• pタグにclass属性を付与するだけのショートコードになんの意味があるのか
• テーマに付属のショートコードを使ってしまうとそのテーマに縛られるのでよくない！

これに対し、コメントではこんな議論がありました。

• たしかにその通りだけど、ショートコード便利だよ！
• テーマに縛られるって、テーマ開発者からすればおいしいよね
• クライアントにそんなこと行っても意味ない
• TinyMCEカスタマイズしてボタンつければ全部解決
• いまなら同意できるけど、正直初心者のときはdivでくくるだけのショートコード作ってたよ！

いわゆる「べき論」なので、意見はそれぞれだと思います。個人的に「divでくくるだけならTinyMCEのボタン作れや」という意見には賛成なので、手前味噌ですが、TinyMCEをチキチキにカスタマイズするなどを読んでください。

さて、人の書いたブログを紹介するだけではしょうがないので、これから僕が考えるショートコードの「べき論」を展開してみたいと思います。

ショートコードのいいところと悪いところ

ショートコードのいいところはもちろん便利なところですが、「誰にとって便利か」というと、作る人にとって便利ということですね。使う側にとってはHTMLもショートコードもマークアップの仕方が違うだけで大して変わらないので、上のエントリーで述べられているようにボタン作ってくれるのが一番いいんでしょうが、TinyMCEのボタンを作るのはけっこうめんどくさいです。ショートコード作って「はい、終り！」ってできるとすごい楽です。その結果として、沢山のショートコードが生まれましたね。「functions.phpに貼っておいてね！」で動くんですから。

一方、悪いところは投稿内に明らかなゴミデータが混入してしまうことです。これはよくあるケースですが、そのテーマやプラグインがWordPressコアのバージョンアップに追随しなくなったとき、これが露見します。テーマに引きずられてバージョンアップできなかったり、他のテーマを使えなかったりする場合もあれば、プラグイン作者が開発を停止してしまってむき出しのショートコードが投稿内に表示されることもあります。上述したWP Tmkm Amazonの場合はけっこう長い間使っていたのに開発者さんがモチベーションを失って開発を終了してしまったので、自分で修正して使い続けています。

というわけで、「利便性」と「失ったときのリスク」をはかりにかけてショートコードを使う必要がありそうです。「とりあえず使ってみる」のは避けるべきかもしれません。

ショートコードはどんなときに使うべきか

これはテーマ・開発者側の視点です。次の2つぐらいしか思いつかないですね。

1. 動的に内容が変更されるもの（AmazonやTwitterのAPIを叩いたり、ユーザーによって表示を変えたり）
2. YoutubeやGoogleマップの埋め込みタグのように、出力されるコードの動的な変更は必要としないが、先方の都合で仕様が変わりうるもの

2に関しては、外部APIよりもプラグイン・テーマ作者が力つきる方が先のような気もします。

ショートコードを使わなくなったらどうする？

テーマを変更したり、プラグインを停止したりして使われなくなったショートコードはそのまま出力されてしまいます。これでは困るので、表示されないようにしましょう。

function _abandoned_shortcodes($atts, $content=''){
     return $content;
}
//ショートコードの数だけ登録。hogeの部分をショートコードに
add_shortcode('hoge', '_abandoned_shortcodes');
add_shortcode('fuga', '_abandoned_shortcodes');

これで囲み型も独立型もいけるんじゃないかと思います。場合によっては空行ができてしまったりするとは思いますが、しょうがないですね。もしショートコードを一括削除するプラグインとかあったら、教えてください。

WordPressのプラグインとテーマは分離できるのか

この問題の原因は、プラグインとテーマの役割がかぶっていることにつきると思います。WordPressはウィジェットやショートコード、管理画面の作成など、ほとんどのことをテーマから出来てしまいます。

テーマがいわゆるMVCモデルのビューファイルのようなものであれば、こうした問題は発生しなかったでしょう。ただ、その場合はここまで普及したか疑問ですね。PHP自体がそもそもそういう言語ですが、あまりスキルの高くない人でもそれなりのことができてしまうというのがWordPressの魅力なので。

きちんとしたガイドラインがあれば嬉しいことは嬉しいのですが、正典なきWebの世界ではガイドラインを作ることも参加者の役割なので、いろんな人の書いたいろんな記事を参考にしていくしかないですね。この記事もその一助になることを祈って、筆を置きます。

1. 
   関連度
   70%
   2011.10.29
   WP tmkm Amazonを動くように修正
   

   先日唐揚げを食べようとしていたら、親切な方から「おたくのWordPressさん、落ちてますよ」と教えてもらいました。どう[...]

2. 
   関連度
   54%
   2011.10.06
   GREEよりひどいWordPressの退会機能をなんとかするプラグイン
   

   GREEが退会できないというネタがちょっと話題になっていたので便乗しようと思ったのですが、今朝スティーブ・ジョブズが亡く[...]

3. 
   関連度
   50%
   2011.10.20
   「Facebookアプリ開発徹底入門」ePub買ってみた雑感
   

   このサイトでも電子書籍は売ってますが、よそ様の電子書籍を買わないのも変な話なので、買ってみました。技術評論社の「Face[...]

Tmkm Amazonの管理画面

先日唐揚げを食べようとしていたら、親切な方から「おたくのWordPressさん、落ちてますよ」と教えてもらいました。どうしたことかと思ってみて見ると、シングルページが中身からっぽになってしまいました。

色々調べると、Amazonの商品情報を出すwp tmkm Amazonというプラグインがエラーを起こしてコケてたんですね。このサーバはnginxというのを使っているのですが、設定ミスでログを吐かなくなっているので、特定に時間がかかっちゃいました。

で、このプラグインは作者さんがすでに更新を停止されているので、待っていても直らないので、自分で直しました。

必要な方は以下からダウンロードしてください。

WP Tmkm Amazonのダウンロード

変更点は以下になります。

• PHP4対応だったので書き直し、5.3でもエラーが出ないように
• 手元にあったファイルを直しただけなので、元が誰のかは不明。
• よくわからないJSフォルダなどを消した
• 管理画面からアソシエイトIDなどを入力できるように
• リクエストをキャッシュするように変更
• リストを出力する関数があるが、ページネーションが変なので、そこはもう知らない。１ページにずらーっと出します。

以前もフォーラムでこっそり配ったことがあるので、もし僕がつくったやつを使っている危篤かな方がいたら、以下の変更点に注意してください。

• PEAR依存をやめて、API叩く部分を自前のコードに書き換え
• XMLパーサーをSimpleXMLElementに、キャッシュシステムをWordPressのTransient APIに
• 画像は24時間ぐらいキャッシュしなきゃいけないような気がしたけど、ドキュメントあさってもわかんなかった

アップロード手順はこんな感じです。

1. 以前のプラグインを停止する
2. Amazon Web ServiceとAmazonアフィリエイトに登録して、アクセスIDなどを取得する。
3. wp-tmkm-amazonプラグインフォルダを全部削除する
4. ダウンロードしたzipを解凍してアップロード
5. プラグインを有効化する
6. 管理画面の設定 > WP Tmkm Amazonへ移動し、速攻でアクセスID、シークレットアクセスIDを入力する

手順5から手順6の間にサイトを訪問されるとエラーになりますので急いでください。

このプラグインを緊急避難的にメンテナンスしてますが、他にもやってる人がいるっぽいですね。ランダムにアソシエイトIDを僕のに書き換えるような設定にすればやるき出るかなーと思いました。動作確認のため、「アフィリエイト」で検索して出てきた書籍をぺたぺた貼っておきますね。

関連する投稿はありませんでした。

Gihyoの電子書籍サイト

このサイトでも電子書籍は売ってますが、よそ様の電子書籍を買わないのも変な話なので、買ってみました。技術評論社の「Facebookアプリ開発徹底入門」ePubです。

本来書評というモノは内容を云々するものですが、電子書籍に限ってはまだ内容以外の部分が重要かなと思いますので、そちらから雑感を書いてみます。

購入に至った動機と価格について

現在このサイトで電子書籍は売っていますが、いちいちユーザー登録してもらわないと買ってもらえない（電子書籍は大体そうだと思いますが）ので、FacebookとかTwitterでログインできるようにしたいと思っていました。

ただFacebookの場合はソーシャルグラフAPIとか、ファンゲートとか面白そうな機能が沢山あるので、もうちょっと体系的に学べる情報が欲しいなーと思っていたところでした。

色々ググった結果、The blog of H.Fujimotoというブログを発見。このブログにFacebookアプリ開発の情報は沢山書いてあったのですが、技術評論社の電子書籍販売サイトGIHYO DIGITAL PUBLISHINGから電子書籍を出しているというのでチェックしてみました。この手の専門書としては1,000円という低価格だったのでその場で購入。一応リアル書籍も調べてみましたが、大体2,000円代後半でした。この価格差は魅力的ですね。

読書体験について

複数端末での読書

設定 > iBooksでブックマークを同期

iPadおよびiPhoneのiBooksに入れて読んだのですが、これ自体はそんなに不便ではなかったです。いまではiOS5 & iCloudが出たので、ブックマークも同期できるようになりました。まだここら辺の同期にはKindleに一日の長がありますが、ないよりははるかにマシです。

iPhoneでの読書

コードはちょっと見辛い

移動中はiPhone、家ではiPadで読んだのですが、iPhoneだとこの手のコードが書いてある本はちょっと辛いですね。インデントなどで整形されたコードもiPhoneの縦画面で見ると折り返しまくりで見辛いです。iPhone4だとRetinaディスプレイなので文字サイズ最小にしても視認性は高いですが、コードは見辛いです。これはもうしょうがないですね。

検索性

検索はちょっともっさり

iBooksの検索はもっさりしてました。ちょっと残念ですね。

ただ、個人的には「書籍内全文検索」ってあんまり使わないかなーと。よっぽどの大著なら別ですけど、そういう書籍はだいたい辞書やリファレンスだと思いますので、索引や目次などがしっかりしているでしょう。それよりは本棚検索というか、「こういうことが書いてある本ってどれだっけ？」という機能が重要な気がします。

目次はしっかりリンクが貼ってあって便利でした。

その他見映え上の感想

基本的にはきちんとデザインされたものでしたが、ビューアーの制約などもあるので、幾つか。

テキスト両端揃え

iBooksは日本語の両端揃えができず、半角スペースなどでしか字間が調整されなかったのですが、この書籍ではすべての読点をカンマにし、半角英数の前後にスペースを入れることで調整しています。

ただし、iOS5のiBooksはどうやら日本語の両端揃えに対応したようですので、これも今となってはバッドノウハウですね。僕も自分のePubを直そうと思ってます。

表組

ページをまたいだ表は見辛い

表組は情報を見やすく整理するための工夫ですが、iPhoneだとあんまり見やすくないですね。項目の内容が増えてしまうと、とたんに見にくくなってしまいます。ページにまたがると項目名が見えないとか、しょっちゅう起きてました。「表組を使った方がいいケース」はかなり限られてくるのではないでしょうか。

内容についての感想

「Facebookアプリ開発徹底入門」がカバーしている範囲はその名の通り、Facebookアプリケーション開発の基本についてです。Web上の情報を検索して個別のハックを学んでいくより、ざっと概要を学んで基本は全部抑えておきたいという方にオススメです。

PC用アプリケーションが.NETなのは少し残念でしたが、それ以外は必要なポイントを抑えてあります。

個人的に役立ったのはFacebookアプリを作るにあたってのパーミッションの概念と、付録についていたFQLリファレンスでした。FQLというのはFacebook上のユーザーデータをSQLのように取得できる機能なのですが、これについての解説が助かりました。

成果物 WP Gianism

高橋文樹Facebookファンページ

僕もこれを読み終え、簡単なアプリケーションを作ることができました。まだ途中なのですが、FacebookでWordPressへのログイン・会員登録ができるプラグインです。プラグイン名WP Gianismには「おまえのものは俺のもの」ということで、よそのWebサービスのユーザー情報を自分のもののように使うという意味を込めてます。これだけ名前で滑っているプラグインを僕は見たことがありません。

なにはともあれ、このプラグインを作ったおかげで高橋文樹ファンページとWordPressを連携させることができました。WordPressに会員登録してさらに「いいね！」してくれた人を判別できます。あとはプレゼントを渡すだけなんですが、プレゼントを準備している最中なので、今はなにもありません。

プラグイン自体はまだ未完成なのですが、使いたい人はここからダウンロードしてください。Twitter連携できるようになったら公式リポジトリに上げます。

その他雑感

僕はこれまで「専門書などのニーズが小さく利益率の低いものは電子書籍に向いていて、大衆向けなどのマーケットが大きいものは利益率の高い紙の書籍で儲けるのがよい」と漠然と思っていたのですが、最近はそうでもないのかなーと考えています。

クリステンセンの「イノベーションのジレンマ」には、破壊的な新技術によって陳腐化された旧技術の成功者は高級化・ハイエンド路線をとりやすいと書いてありましたからね。入門書・新書・文庫などのローエンド市場を電子書籍が低価格で蹂躙して、高価な専門書を紙で出すように変わっていくような気が最近はしています。

「有力企業がいとも簡単にハイエンド市場へと移行できるのはなぜか。下の市場へ移動することがこれほど難しいのはなぜか」クレイトン・クリステンセン著　伊豆原弓訳『イノベーションのジレンマ』翔泳社、2001年

関連する投稿はありませんでした。

SSL、ぼくのユーザーを守って

またWordPressのTips兼メモ書きです。いま色々と制作している途中なので、あと一週間はメモ書きが続きます。Web興味ない人に呆れられてて悲しいです。

タイトルに特に意味はありませんが、特定の年齢層に響くかと思ってこれにしました。

WordPressでSSLを導入するケース

だいたい以下の2パターンあります。今回のエントリーでは僕のように少ない人的・金銭的リソースで会員制サービスを行っている人に向けた情報を記載します。

管理画面（と公開画面のごく一部）だけ保護すればよい

これはよくあるケースだと思うのですが、WordPressを企業用CMSとしてカスタマイズした場合などに当てはまります。この場合、SSLで通信を保護する対象は「ユーザーが使うお問い合わせフォーム」と「管理者が使う管理画面」ぐらいでしょう。これに関しては大して難しいことはなくて、Admin SSLなどのプラグインを使えば実現できます。

公開画面に保護すべきページが沢山ある

このケースは1番目のケースと同じくプラグインで対応できる場合もありますが、僕のように無謀にも会員制サイトを作っていて、ユーザーデータに紐づいたページ（マイページなど）が沢山ある場合はある程度WordPressの中の仕組みに詳しくなっておいた方がいいと思います。

上記の場合、すべてのページを自分で作っているとは限らなくて、なんらかのプラグインによってページやURLが生成されるケースもあると思います。そのプラグインがSSLへの対応をしていないと困ったことになってしまうので、自力で直せるようにしておきましょう。今回の記事はほとんどこっちのケースです。

管理画面・ログインのSSLを有効にする

自分でSSLを設定する場合はwp-config.phpに以下を記載してください。どちらかでもいいですし、両方書いても特に問題はありません

//管理画面はSSLじゃないと駄目という設定
define('FORCE_SSL_ADMIN', true);
//ログイン画面はSSLじゃないと駄目という設定
define('FORCE_SSL_LOGIN', true);

会員制サイトにおける共有SSLと独自SSL

これはWordPress自体の問題ではないのですが、多くのWPerは共有サーバ上で走っていることと思います。どこのレンタルサーバも「共有SSL」というものを用意しています。たとえばこのサイトは以前さくらのレンタルサーバを使っていたのですが、そのときの共有SSLのURLは http://xxx.sakura.ne.jp/main でした。要するに、ドメインが変わっちゃうんですね。

WordPressのログイン情報はクッキーを利用しており、基本的に別ドメインのクッキーを読み取ることはブラウザの仕様上できません。読み取れたら、それはブラウザとして欠陥があります。

それでもなんとかログイン情報を取得して動かすことはできるのですが、ちょっとハックっぽいことをしないと動かないので、もし会員情報必須でSSLも必要なのであれば、きちんと独自SSLをとることをお勧めします。ハックするコストを考えると、素直に独自SSLにしちゃった方が楽だったりしますからね。サーバ証明書もホスティング代金もだいぶ安くなっているので、検討してみてください。

他にもCoreServer.jpとかも独自SSLを使えるみたいですね。ちなみに僕のサイトは最近さくらVPS512に引っ越して、SSLボックスで買った2,000円の証明書を使ってます。nginxにしたら早くなったし、年額もこれまでと大して変わらなくて嬉しいですよ。

公開画面をSSLにして注意すべきこと

このサイトではお問い合わせなどがそうなのですが、注意すべきことが幾つかあります。

SSLで保護されたページの中にSSLで保護されていない画像やCSSなどを読み込むと警告が出ます。SafariとかFirefoxだとあまり気づかないですが、IEだとアラートが出てしまうので、詳しくないユーザーがビビって逃げちゃうんですね。

SSLページで読み込むべきでない外部サービスは表示しない

SSLで保護されたページにおいて画像等を読み込む場合は同様にSSLで保護されている必要があります。WordPressにはこの機能がきちんと備わっていて、たとえばスタイルシートなどは自動でURLが書き変わります。

bloginfo('stylesheet_url');
//通常
//→ http://takahashifumiki.com/wp-content/themes/takahashifumiki/style.css
//ページがSSLのとき
//→ https://takahashifumiki.com/wp-content/themes/takahashifumiki/style.css

外部サービスのJS・CSS・画像に注意

WordPress内部のコンテンツはこれで大丈夫なのですが、駄目なのが外部APIを使っている場合です。たとえば、このサイトだとTwitterウィジェットやInstagramなどがそれにあたります。これは相手が対応してくれないことにはどうしようもないので、対応するまでは表示しないようにしましょう。ログイン画面にTwitterウィジェットなくても困らないですからね。

WordPressは現在のページがSSLかどうかを判定する関数を持ってますので、それを使えばいいでしょう。

//SSLじゃないときだけサイドバーを読み込む
if(!is_ssl()){
     get_sidebar();
}

このサイトでは二段あるフッターの一段目を外部サービスでまとめ、SSL時に非表示にするようにしました。

ちなみに、Google系のサービス（Analyticsとか、Google+とか）はわりかしSSLに対応しています。お金持ちだからでしょう。GravatarとかWordPress.comのサービスもちゃんとSSL対応してますね。Automaticもお金がたまってきたんでしょうか。

投稿内のURLは自動で書き変わらないので書き換える

たとえばこのサイトのように「お問い合わせ」をSSLにして、その投稿内に画像を挿入したとしましょう。そうすると、こういうソースが投稿に入ると思います。

<img src="http://s.takahashifumiki.com/wp-content/uploads/2011/10/hoge.jpg" />

このSRC属性がSSLのとき不味いので、こんなフックをfunctions.phpに書きます。

/**
 * SSLのコンテンツが表示されているときにsrcなどを修正する
 * @param string $content
 * @return string
 */
function _replace_ssl_content($content){
     if(is_ssl()){
          $upload_dir = wp_upload_dir();
          $upload_dir_url = $upload_dir['baseurl'];
          $upload_dir_ssl_url = str_replace('http:', 'https:', $upload_dir_url);
          $content = str_replace($upload_dir_url, $upload_dir_ssl_url, $content);
     }
     return $content;
}
add_filter('the_content', '_replace_ssl_content');

WordPressのアップロード機能を使って保存されたファイルのURLはhttpsに上書きするというものですね。

リンクがすべてhttpsになるのを書き換える

タグクラウドまでhttpsに…

一度SSLを有効にするとわかるのですが、公開ページでSSLを有効にすると、WordPressの出力するリンクがすべてhttpsになってしまいます。

このサイトでいえば、タグクラウドとか、カテゴリーメニューとか、ページメニューとかが全部httpsになってしまうんですね。基本的にSSL通信は負荷が高いので、必要のないところでは無効にしておきたいところです。

この原因はなにかというと、WordPressのルートURLを返す関数home_urlがSSL通信のときにhttpsでURLを返すことです。リンク出力系の関数はほとんどこの関数を使っているので、全部httpsになってしまうという寸法ですね。

スタイルシートやJavaScript、画像等はSSLのままでもいいのですが、トップページへのリンクまでhttpsに変わるのは困るという問題を解決するためには、こんなものをfunctions.phpに書いておきます。

/**
 * SSLページですべてのリンクがHTTPSになってしまうのを修正する
 * @param string $url
 * @param string $path
 * @param string $orig_scheme
 * @return string
 */
function _ssl_home_url($url, $path = '', $orig_scheme = 'http'){
     if(is_ssl() && strpos($path, 'wp-content') === false){
          $url = str_replace('https:', 'http:', $url);
     }
     return $url;
}
add_filter('home_url', '_ssl_home_url');

アップロードディレクトリを変更している場合とかは駄目かもしれませんが、僕のサイトはこれで直りました。

SSLに対応していないプラグインの挙動を修正する

これはどんなプラグインを使っているかによるため、漠然としたことしか言えないのですが、プラグインによってはすべてのページで外部のJavascriptを書き込んだり、リンクのURLを書き換えるものがあります。こうした「お行儀の悪いプラグイン」の後始末をすることが必要になるケースがあります。幾つか具体例を上げます。

Theme My Loginの場合

このサイトではTheme My Loginというプラグインを使っています。このプラグインは公開側でオリジナルのログイン画面を作れる機能を持っており、wp_login_url（ログイン画面へのリンクを出力するテンプレートタグ）を書き換える機能を持っているのですが、SSLには対応していません。ソース上は「ここでFORCE_SSL_LOGINをチェック」と書いてあるのですが、実際はチェックしていないんですね。なので、こんな風に修正する必要がありました。

/**
 * SSLが有効な場合はURLをhttpsにして返す
 * @param string $url
 * @return string
 */
function _my_login_ssl($url){
     if(FORCE_SSL_LOGIN || FORCE_SSL_ADMIN){
          $url = str_replace('http:', 'https:', $url);
     }
     return $url;
}
add_filter('login_url', '_my_login_ssl');
add_filter('register', '_my_login_ssl');
add_filter('logout_url', '_my_login_ssl');

/**
 * Theme My Loginが出力する管理画面へのURLをSSLにする
 * @param string $url
 * @param string $action
 * @param int|string $instance
 * @return string
 */
function _my_admin_ssl($url, $action = 'login', $instance = ''){
     switch($action){
          case 'login':
          case 'register':
          case 'lostpassword':
          case 'retrievepassword':
          case 'resetpass':
          case 'rp':
               if(FORCE_SSL_LOGIN || FORCE_SSL_ADMIN){
                    $url = str_replace('http:', 'https:', $url);
               }
               break;
          default:
               if(FORCE_SSL_ADMIN){
                    $url = str_replace('http:', 'https:', $url);
               }
               break;
     }
     return $url;
}
add_filter('tml_action_url', '_my_admin_ssl');

Disqusの場合

コメントフォームをソーシャル化してくれるDisqusですが、これもSSLに対応していないJSをすべてのページで読み込んでしまうため、Javascriptの書き込みを削除しなくてはなりません。「どこでJavascriptを書き込んでいるか」を見つけるには、プラグインが出力したであろうソースをコピペしてフォルダ内検索するのがお手軽です。

/**
 * DisqusのスクリプトがSSLでも読み込まれるのを防止
 * @return void
 */
function _my_remove_disqus(){
     if(is_ssl()){
          remove_action('wp_footer', 'dsq_output_footer_comment_js');
     }
}
add_action('wp_footer', '_my_remove_disqus', 1);

というわけで、利用しているプラグインによっては作業が増えたりするので、SSLを導入する場合は注意してください。

次回予告

というわけでSSLの設定についてあれこれ書いてきましたが、これでようやくFacebookページとWordPressの連携に着手できそうです。FacebookページもSSL必須となるようですし、しっかり設定しておきましょう。「いいねしてくれたら電子書籍あげるよ！」とか、「Facebookアカウントで会員登録orログインできるよ！」という機能を作る予定なので、お楽しみに。僕のFacebookページはこちらです。

1. 
   関連度
   207%
   2011.12.09
   SSLありのWordPressだけど高速化したいからCloudFlareのCDNを無料で使う
   

   最近WordPress界隈では高速化の話題が多いですが、僕もちょくちょく試しています。静的キャッシュのプラグインとかYa[...]

2. 
   関連度
   98%
   2011.10.09
   WordPressのTinyMCEをチキチキにカスタマイズする
   

   最近続いているWordPressエントリーの続きです。ところでみなさん、HTMLタグは好きですか？　僕はというと、特に好[...]

3. 
   関連度
   76%
   2011.12.15
   Literally WordPress 0.8.8で定期購読とスマートフォン対応
   

   Literally WordPressを0.8.8にアップデートしました。 http://wordpress.org/e[...]

さて、WordPressにはTinyMCEというWYSIWYGエディタがついています。これはWordPressの中の人ではなくMoxiecodeというスウェーデンの人が作ったオープンソースのソフトですね。

今回はいかにタグ打ちをせずに済ませるかという点にしぼってご説明します。たぶんリンク集みたいになると思いますが、カスタマイズの方法は大体下記の通りです。

1. TinyMCEでの見映え自分のブログと統一する（初級）
2. TinyMCEに元からあるボタンを追加する（中級）
3. TinyMCEに消されるタグを救う（特にiframe）（中級）
4. TinyMCEにオリジナルのボタンを追加する（上級）

TinyMCEでの見映え自分のブログと統一する（初級）

このブログのTinyMCEはこんなです

世の中には全部タグ打ちで書いているWPerもいるかと思いますが、見映えが一致しているとビジュアルエディタで書くのも楽しくなってきますし、なによりクライアントワークのときは一々説明するのがめんどくさくないので楽です。

このやり方は簡単で、テーマ内のfunctions.phpに以下のコードを書いてください。

add_editor_style("editor-style.css");

これでテーマフォルダのトップにあるeditor-style.cssが適用されるようになります。

もし投稿タイプごとに異なるデザインにしてたりする場合は、こんな感じで書いておくと別々のを読み込んでくれます。Killer hacks to enhance WordPress editorに書いてありました。

/**
 * 別々のeditor-style.cssを追加
 * @return void
 */
function _my_editor_style(){
     global $current_screen;
     switch ($current_screen->post_type){
          case 'post':
               add_editor_style('css/editor-style-post');
               break;
          case 'ebook':
               add_editor_style('css/editor-style-ebook');
               break;
     }
}
add_action('admin_head', '_my_editor_style');

TinyMCEに元からあるボタンを追加する（中級）

WordPressのTinyMCEは色々と設定が施されたものなのですが、実は後から変更できます。こんなことを書くのはなんですが、まずはTinyMCE Advancedというプラグインを使ってください。便利です。

ここではこのプラグインでたぶん実現できないものを紹介します。

ブロックレベル要素のボタンをカスタマイズ

選べるタグを変更

僕のブログではタイトルにh1を使っており、「一文書にはh1ひとつ」という原則に従って本文中にh1を使うことはありません。小見出しもレベル5までと決めています。その一方、定義リスト（dlタグ）が大好きなので、これを追加したいです。やり方はこちらをfunctions.phpに書いておいてください。

/**
 * TinyMCEの初期化配列を作成する
 * @param array $initArray
 * @return array
 */
function _my_tinymce($initArray) {
     //選択できるブロック要素を変更
     $initArray['theme_advanced_blockformats'] = 'p,h2,h3,h4,h5,dt,dd,div,pre';
     return $initArray;
}
//TMAより後に実行されるように、10000番ぐらいにフック登録
add_filter('tiny_mce_before_init', '_my_tinymce', 10000);

これで選択できるものが変わりました。なぜかdlはないのでタグ打ちしないと行けないのですが、やり方わかったら追記します。

ちなみに、選択できる要素はtinyMCEのドキュメント（見辛い！）によると、そんなに多くないですね。これ以外も書けるのかもしれませんが、よくわかりません。基本はブロック要素だけですね。sampタグなんて使うの？

スタイルボタンの要素を追加

これはeditor-style.cssをきちんと設定したときに威力を発揮します。ある程度WordPressのデザインを作り込むと、デフォルトのタグだけでは扱いきれない要素が出てきて、span.cautionとか、p.errorとかも使いたくなってきます。たとえば、このブログではp.successとp.warningという要素があります。

これはp.successです。

色んなスタイルを設定した場合、そのスタイルを適用するボタンを作りたくなりますね。スクリーンキャスト撮ったので、参考にしてください。

やり方はこんな感じです。先ほど上で定義した_my_tinymceの中に書いて下さい。

//スタイリング用クラス
$style_formats = array(
      array(
           'title' => 'サクセス',
           'block' => 'p',
           'classes' => 'message success'
      ),
      array(
           'title' => '注意',
           'block' => 'p',
           'classes' => 'message warning'
      ),
      array(
           'title' => '注意書き',
           'inline' => 'span',
           'classes' => 'alert'
      )
);
$initArray['style_formats'] = json_encode($style_formats);
return $initArray;

クラスは複数指定可能なので、clearfixとかも使えます。フロート解除等にも便利ですね。

TinyMCEに消されるタグを救う（特にiframe）（中級）

これはGoogleマップが消される問題を解決するために使っています。他にもrubyタグとか、mapタグとか、マイナーなタグを使うときはこの方法で。HTML5もいけるんじゃないでしょうか。上と同様、_my_tinymceの中に記述してください。

$initArray[ 'extended_valid_elements' ] .= "iframe[id|class|title|style|align|frameborder|height|longdesc|marginheight|marginwidth|name|scrolling|src|width]";
//タグ名[属性|属性],タグ名[属性|属性],タグ名[属性|属性]...

TinyMCEにオリジナルのボタンを追加する（上級）

オリジナルのボタンを追加するとなるとかなり使いこなしてる感が出て嬉しいですね。たとえば、僕が個人的に好きなのにあんまり使われてないタグに引用文であることを示すqタグというのがあります。blockquoteのインライン版ですね。これにcite属性を組み合せれば、かなり論文っぽいブログを作ることができます。qタグのcite属性を引っこ抜いて文末脚注を作るようなjQueryを書いたりするとアカデミックでかっこいいですよね。ibid. citéとか書きたいです。

オリジナルのボタンを追加するには、プラグイン（WordPressのプラグインではなく、TinyMCEのプラグイン）として作成する必要があります。一応、このためのインターフェースは用意されています。

/**
 * オリジナルのボタンを登録する
 * @param array $buttons
 * @return array
 */
function _my_register_button($buttons)
{
	array_unshift($buttons, "mybutton", "separator");
	return $buttons;
}
//mce_button_の数字は1〜3で好きな値に
add_filter('mce_buttons_3', '_my_register_button');

/**
 * TinyMCE用のプラグインを登録する
 * @param array $plugin_array
 * @return array
 */
function _my_mce_plugin($plugin_array)
{
	$plugin_array['mybutton'] = '/url/to/plugin/directory/editor_plugin.js';
	return $plugin_array;
}
add_filter("mce_external_plugins", "_my_mce_plugin", 100);

これでeditor_plugin.jsにTinyMCEのプラグインとしてのコードを書いていかなくては行くことになるのですが、けっこうやることは多いです。

1. 翻訳用ファイルを登録する（これはなくてもいいけど、WordPressのgettextを使った翻訳と統一するためにはちょっと工夫が必要）
2. ポップアップダイアログ（qタグの場合、cite属性を入力するためのプロンプトが必要になる）を作る場合は、そのためのファイルを用意する必要があり、ダイアログウインドウの入力を受け取るためのJSを記載する必要がある
3. 選択文字列のタグを脱がせたり着せたりするのはTinyMCEのAPIを使うとできるので、ドキュメントを漁ってください。基本的にはtinymce.Editorクラスをなんとかすればいけるはずです。

もっと細かく説明しようと思ったのですが、もう出かけなくてはいけないのと、めんどくさいという感情が高まってきたので、以前作ったrubyタグ挿入プラグインのGithubリンクを貼って終わりにします。他にWebTechNoteというブログにTinyMCEのビジュアルリッチエディタにカスタムボタンを追加するや自作したショートコードをビジュアルエディタ内で置換するなどの記事があるので、参考にしてみてください。上級者ならできる！

終わりに

TinyMCEは改行連続がついこのあいだまでできなかったことやタグの自動消去機能などからマークアップ大好きな人に嫌われていたのですが、世の中の大半の人はマークアップを知らないので、WordPressを納品したり、WordPressでサービスを提供している人はがんばってカスタマイズするのが吉だと思います。

でも管理画面使いやすくしてもあんまりお金貰えないんだよなーと愚痴りつつ、尻すぼみでエントリーを終えます。WordPressのビジュアルエディタをカスタマイズするというエントリーなども参考になります。

1. 
   関連度
   90%
   2011.10.11
   ぼくのユーザーを守って〜Tips on WordPress + SSL〜
   

   またWordPressのTips兼メモ書きです。いま色々と制作している途中なので、あと一週間はメモ書きが続きます。Web[...]

2. 
   関連度
   89%
   2011.12.09
   SSLありのWordPressだけど高速化したいからCloudFlareのCDNを無料で使う
   

   最近WordPress界隈では高速化の話題が多いですが、僕もちょくちょく試しています。静的キャッシュのプラグインとかYa[...]

3. 
   関連度
   74%
   2011.01.28
   WordPressで会員制サイトを作るときの勘所
   

   半ば放置ぎみだったミニコme!の開発を再開したことと、４月に控えている破滅派大リニューアルに向けてWordPressの会[...]