atl*weblog » blog

iPhoneのまとめ記事がほってんとりった

daruman — Wed, 29 Jul 2009 15:10:38 +0000

先日アップしたiPhoneを購入した際のまとめ記事、iPhoneを購入してやった事まとめ – atl*weblogがおそらく短期間ながらHatenaのホットエントリーになっていたようなので、どんな感じだったか結果報告。

異常なアクセスに気付く

iPhoneの記事をあげて約5日後、やっと記事も書き出したし久々にAnalyticsでも見てみるか…と、Google Analyticsを開いた時に気付いた。
変化率が35%もプラスだなー、ずいぶん何も書いてなかったし記事上がってみてくれる人でも少しは戻ったかね、程度に思いつつマイリポートを開いたら

なんだこの極端な推移は…？ひょっとしてwordpressのアップデートか何かの際に挿入コードとかがおかしくなってデータ取れてなかったかなぁ、と思いマウスオーバーすると

セッション625って、普段の10倍じゃねーかｗ
とりあえず参照元を見るとb.hatena.ne.jpの/hotentry/it、ITカテゴリーのホッテントリだったようだ。
ブクマ数を見るとこの時点で30、このblogにしては驚異的な数だけど、普段見てるほっとてんとりからすると微々たるもの。
ITカテゴリーだからこの数でもいけたのかなーとか考えたり。

これまでとの変化

このblogの通常時のアクセスはこんな感じだった。

セッション: 40～80程度、土日に30～40に落ち込み
ページビュー: 100前後、土日に50前後に落ち込み

これがピーク前後はこんな感じに。

ピーク前日: セッション数：214; ページビュー：269
ピーク: セッション数：625; ページビュー：756
ピーク後日: セッション数：124; ページビュー：164

このblogは土日にアクセスの落ち込む典型的な平日型アクセスだったが、その差異がグラフにおいて平坦で判別不可能になるほどピーク時が飛びぬけていた。

で、どうなった？

この記事を書いている段階までも緩やかにはてブ数は増加し、34になっている。
今後はiPhoneではてブ検索したりする人に見つけてもらって、場合によってははてブされ、そして通常通りに戻るだろう。

見てもらえるのはありがたいが、正直いってあの記事はまさに備忘録で、特にメールのくだりなんか考えながら書いてて結局まとまってない、結構ひどいものだったので、こんな事ならもうちょっと気合入れて書けばよかったと思ったりもした。
したんだけど、未だによくわからないんで書き直しようもないのが困りもの。
まぁ文章の出来はともかく、ボリュームがそれなりにあるので読むのがだるい反面ハッタリは効いてそう、有用なリンク先も掲載させてもらったんで、簡易なリンク集的な意味でまとめタグがつくのかも。

しかしiPhoneの記事であそこまでアクセスが集まるとは思わなかった…。

hetemlでwordpressのプラグイン“Shadowbox JS”を使う場合の留意点

daruman — Tue, 16 Jun 2009 19:20:42 +0000

つい最近Shadowbox JSが3.0にアップデートされて、それに伴ってphp4.xのサポートが打ち切られた。
hetemlだけじゃないかもしれないけれど、デフォルトでphp4.xを利用してるサーバーではこのpluginは使えなくなった。
幸いhetemlは一応php5.xも使えるようにする方法があるのでセフセフだったが、一応何かの役に立つかもしれないんでここに顛末を書きとめておく。

問題発覚から解決までの経緯

久々に記事を書いてupしたら、あれshadowbox動いてないじゃん。

ちょうど前後してwordpress2.8にアップデートしたので（しかもバグのある自動アップデート）、そのせいかと疑ってみる。

あれ、そもそも管理画面の設定メニューにShadowbox JSの項目すらないぞ。

pluginサイトのコメントを追っていくと、作者のこんな話が。
Shadowbox JS | Sivel.net

Matt says:
10 Jun 2009 at 12:14:43 EDT

@Jonathan: And like I told the other user, you are likely using PHP 4. PHP 4 support was dropped in this release in favor of better functionality. Please consider upgrading to PHP 5.

んだよ、readmeにもこのpluginのページのどこにも説明ねーじゃねーか！

この際だし、このドメイン内は全部php5.ｘが動くように、.htaccessを置いて切り替える方法をとろうと思いたつ。
レンタルサーバー「heteml」 – PHP5のご利用方法について

おし、管理画面にShadowbox JSの項目出たわ、どれどれ…

なんだ言語にja増えてる、ラッキー…あれ？エラーでまくってるんだけど何これ。

チェックボックスをcheckedにするかどうかの部分でエラーが出て、データタイプがちげーぞ！配列じゃねーぞ！ってエラー吐いてる

データベースに保存されてるデータ形式が変わったんだろうか、けどどうすんだこれ

Shadowbox JSpluginを一度停止し再起動

うごいたー＾＾

汎用Liblary無しで使用しても、コンフリクトしなくなった

Shadowbox JS　LightBox系のjsライブラリ・Shadowboxをwordpressに簡単実装するplugin – atl*weblog

javascriptを読み込む際にonloadの記述がチョロくて、場合によっては他のjavascriptやliblary、javascriptを利用するpluginとコンフリクトする可能性がある

と以前の記事で書いたが、今回のバージョンアップでその問題が解決している。
なのでわざわざ使ってもいない汎用Liblaryを導入してページのロードを泣く泣く遅くしている人は、もうその心配は要らない…はず。

まとめ

Shadowbox JSはphp5.x以上じゃないと動かなくなった
hetemlでは.htaccessを置けばおｋ、.htaccess自体は公式で公開してる、置いたディレクトリ以下の階層にも全部適用
wordpressとかはphp4でも5でも動くようになってるんで切り替えても問題ない
けどpluginのほうはよくわからない、とはいえphp4.xでしか動かないpluginとか恐らくない
.htaccessを置く前にShadowbox JSを一旦停止、同様のケースのために一時的にplugin全部止めてもいいかも

ニッチすぎるtips。

一ヶ月近くblogを書かないとアクセスはどうなるか

daruman — Tue, 16 Jun 2009 17:37:42 +0000

feedを合体させるのに失敗し、ガラスのハートを持つ俺は完全にモチベーションを失った。
その間レゲーに逃げるものの、それを悟らせまいとまるで実験的に更新しなかったかのように見せる試みに出るのだった…。

2009/05/22～2009/6/16のアクセス

という訳で、アクセスがどーなったかなという話。
下図は最後に更新した日からのセッション数の遷移。

定期的に二日連続で落ちこむ規則性が見えるが、これは土日viewが下がるこのblog特有の状態。みんな仕事場から見てるんだろうか、とても仕事に使えるレベルの話をして無い気もするが…。
まぁ概ね横ばい。
このblogは特に何かに特化させる気はないが、俺がその時々に手がけている内容が連続するので、その話題の切り替わりで新規アクセスが増える以外、これまで常に横ばいだった。
たまたま初期はblogを作る事自体がテーマだったため、それに付随してGoogle Analyticsの話題が多く、まずはそれに興味関心のある人がご来場、あとAmazonか。

個人サイト・個人blog立ち上げの時留意すべき事

このblogをやりはじめて約半年たったんで、上記の事も踏まえて現時点で思ってる、立ち上げ時の準備内容を書いておいてみる。

記事を何本か書き溜めておく
鉄板ネタを何本か準備しておく　オススメは利用中のfirefoxのアドオン、けど5個も使ってないよとかって場合どうなんだろ
トラックバックを使う
blogを作る時すべき○○の事柄　みたいな記事が山ほどあるんでそこにのってるSEO関連を全部やる

最初の書き溜める記事や初期の内容は、blogを作る時すべき○○の事柄みたいなのに載ってる事を実際全部やってみてそれについて記事を書けばいい。
技術的な話を書くblogじゃなくても、そういうのに詳しくない人がどこでつまづくのかは一部層に需要がある。（初心者の行動に感心のある技術者や、同じ初心者など）

そこまであざとくアクセス稼ぎたくねーよ、という話もあるんだけど、ある程度人が見てないと公開する意味もない。
かといってただ書いてるだけだと誰の目にも留まらない。

で、どうも自分でblogやってここまでのアクセスの遷移を見てると、最初にガッと増えてそれ以降落ちない。
あとは内容次第でその横ばいのラインが底上げされていく感じになるみたい。
なんで最初にガッとあげるべく、必要な手順の一つと割り切ってSEO関係を見よう見まねでやると、あとは凄いアクセスが来るわけでもないんだけど、まぁ日記レベルとしてはそこそこのアクセスがあって書いてる意味も多少あんのかな、と思える程度の水準に持っていける。

たまに更新をガッチリしろとか書いてあるアドバイスあんだけど、これは多分人気blogにするならって事なんじゃないかね。
書く内容によってはfeedリーダー使う層が少なくて、更新ないとアクセス減るってケースもありそうだけど。

てことで半年やった結果、そんなに頑張って更新しなくても有る程度のアクセスで満足いくならまったく問題ないよという事が分かった。
という事を調べるための実験のためにしばらく更新しなかったワケで、feedの合体に失敗してへこたれたとか、うっかりファイアーエムブレムに手を出してしまっただとか、そういう事では全然ない。
ましてそのせいでファイアーエムブレムの動画ばかり見てるなんて訳もない。

ファイアーエムブレム聖戦の系譜

posted with amazlet at 09.06.17

任天堂 (1996-05-14)
売り上げランキング: 3392

Amazon.co.jp で詳細を見る

wordpressで非公開コミュニティサイトを作る（7）feedのカスタマイズ2（失敗）

daruman — Thu, 21 May 2009 21:56:51 +0000

feedのカスタマイズをしてみる。

以前、をかもとさんの助言を得てfeedのテンプレートを自身のテーマ内に持つ方法を知ったので、これをwordpress自身のfeedに加え、コメントと、bbpressのfeedをあわせる方法をやってみる。

注意：今回いろいろ試した結果、挫折したのでこの記事を最後まで読んでも結局どうすればいいかは載ってないのであしからず…！！！

参考：各種フィード用テンプレートの変更 : dogmap.jp

参考：wordpressで非公開コミュニティサイトを作る（4）feedのカスタマイズ – atl*weblog

注意：をかもとさんが提示してくれたコードを、をかもとさん自身が記事にして若干変更されているので、そちらを参考にしたほうがきっと幸せ。

rss2の仕様

atomとかもあるけどまずはrss2から。
恥ずかしながらrss2の仕様についてよく知らないので、せっかくなので調べてみた。

koshigoewiki:feed:rss2.0仕様 [KoshigoeWiki]

今までなんとなく面倒そうでちゃんと理解してこなかったが、案外シンプルでわかりやすい。
詳しい仕様はリンク先を参照してもらうとして、以下個人的めも。

channel要素は仕様では複数設置できるが、フィード利用状況からひとつにおさえ、複数のコンテンツはchannel要素内のitem要素を増やす形に
必須項目・オプション項目に含まれない要素はxmlnsで指定したネームスペースを利用

rss2テンプレートの仕組み（feed-rss2.php）

wordpress2.7.1のfeed-rss2.php
※ただし元のママではなく、本文部分を出力しないよう該当部分を除外したもの、詳しくは”wordpressで非公開コミュニティサイトを作る（4）feedのカスタマイズ – atl*weblog”に。

 1:  2: /**
 3:  * RSS2 Feed Template for displaying RSS2 Posts feed.
 4:  *
 5:  * @package WordPress
 6:  */
 7: header('Content-Type: text/xml; charset=' . get_option('blog_charset'), true);
 8: $more = 1;
 9: 
10: ?>
11: '; ?>
12: 
13: 14:   xmlns:content="http://purl.org/rss/1.0/modules/content/"
15:   xmlns:wfw="http://wellformedweb.org/CommentAPI/"
16:   xmlns:dc="http://purl.org/dc/elements/1.1/"
17:   xmlns:atom="http://www.w3.org/2005/Atom"
18:   xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
19:   
20: >
21: 
22: 
23:   <?php bloginfo_rss('name'); wp_title_rss(); ?>
24:   
25:   
26:   
27:   
28:   
29:   
30:   
31:   
32:   
33:   
34:   
35:     <?php the_title_rss() ?>
36:     
37:     
38:     
39:     
40:     
41:     
42: 
43:   
44:   
45:   
46: 
47:

7行目: headerを送っている、文字コードはxml宣言時に送ってるので不要な気がしたが、両方送っても問題なさそうだしいいのかな。
8行目: 調べたんだけどよくわからないな…おそらく“続きを読む”とかその辺に関連してると思うんだけど。$moreが1だと全文って事な感じなんだけどなー。
11行目: xml宣言
13～20行目: rss要素の開始タグ。何か沢山xmlnsつけてるんだけどxmlns:contentが使われている形跡がない？？
19行目: このdo_action('rss2_ns')はどこにもadd_actionがないんだよなぁ、pluginとかで使うようにあるっぽい。
22行目: channel要素開始タグ。
23～31行目: このfeedに関する情報。タイトルとかURLとか。
32行目: do_action('rss2_ns')と同じくplugin用ぽい。
33~45行目: ここがループ部分。普通のテンプレートでのループと同じやり方。itemを一つづつ出力してる。
35~38行目: ループ中の記事のタイトルとかパーマリンクとかをrss向けに出力するテンプレートタグだったり、関数だったり。
39行目: feedのフォーマットにあわせた形で、ループ中の記事のカテゴリーを出力する。出力はカテゴリーごとにタグに入れて、カテゴリー名はCDATAとして出している。俺の環境だといまいち法則性の分からない改行とインデントも漏れなく付いてくる。
40行目: これもパーマリンクを出力してるんだけど、25行目と違うのは、こっちはwordpressで設定したパーマリンク設定ではなくデフォルトの設定でURLが出力されてるみたい。けどisPermaLink=”false”だからfeedreaderはuriとして解釈しないみたい。なんであるかは知らない。
41行目: ループ中の記事のコメントのfeedアドレス。
42行目: ループ中の記事に画像とかポッドキャストがあった場合、feed用に変換し出力するテンプレートタグ、らしい。該当するものがない場合は何も出力されない。
43行目: これもplugin用フックかな、フィードの各記事分が閉じられる直前に何かしたい場合に利用するんだろう。

rss2コメントテンプレートの仕組み（feed-rss2-comments.php）

wordpress2.7.1のfeed-rss2-comments.php

 1:  2: /**
 3:  * RSS2 Feed Template for displaying RSS2 Comments feed.
 4:  *
 5:  * @package WordPress
 6:  */
 7: 
 8: header('Content-Type: text/xml;charset=' . get_option('blog_charset'), true);
 9: 
10: echo '';
11: ?>
12: 13:   xmlns:content="http://purl.org/rss/1.0/modules/content/"
14:   xmlns:dc="http://purl.org/dc/elements/1.1/"
15:   xmlns:atom="http://www.w3.org/2005/Atom"
16:   xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
17:   >
18: 
19:   <?php
<span class="nocode">20: </span>    if ( is_singular() )
<span class="nocode">21: </span>      printf(ent2ncr(__('Comments on: %s')), get_the_title_rss());
<span class="nocode">22: </span>    elseif ( is_search() )
<span class="nocode">23: </span>      printf(ent2ncr(__('Comments for %s searching on %s')), get_bloginfo_rss( 'name' ), attribute_escape($wp_query->query_vars['s']));
<span class="nocode">24: </span>    else
<span class="nocode">25: </span>      printf(ent2ncr(__('Comments for %s')), get_bloginfo_rss( 'name' ) . get_wp_title_rss());
<span class="nocode">26: </span>  ?>
27:   
28:   
29:   
30:   
31:   
32:   
33:   
34:   
35: 36: if ( have_comments() ) : while ( have_comments() ) : the_comment();
37:   $comment_post = get_post($comment->comment_post_ID);
38:   get_post_custom($comment_post->ID);
39: ?>
40:   
41:     <?php
<span class="nocode">42: </span>      if ( !is_singular() ) {
<span class="nocode">43: </span>        $title = get_the_title($comment_post->ID);
<span class="nocode">44: </span>        $title = apply_filters('the_title_rss', $title);
<span class="nocode">45: </span>        printf(ent2ncr(__('Comment on %1$s by %2$s')), $title, get_comment_author_rss());
<span class="nocode">46: </span>      } else {
<span class="nocode">47: </span>        printf(ent2ncr(__('By: %s')), get_comment_author_rss());
<span class="nocode">48: </span>      }
<span class="nocode">49: </span>    ?>
50:     
51:     
52:     
53:     
54: 
55:     
56:     ]]>
57: 
58:     
59:     ]]>
60: 61:   do_action('commentrss2_item', $comment->comment_ID, $comment_post->ID);
62: ?>
63:   
64: 
65: 
66:

8～10行目: feed-rss2.phpと同じだが$moreはない。
12～17行目: xmlnsが少なくなっているのと、do_action('rss2_ns');がなくなっている。
19～26行目: どこのコメントかによってタイトル表記を分岐させているようだ。
20～21行目: is_singular()はコンディショナルタグで、When any of the following return true: is_single(), is_page() or is_attachment().とあるように、記事かページか画像などの添付ファイル表示ページの時のみtrueを返す。
ent2ncr()は文字実態参照を数値文字参照に変換する。
22～23行目: is_search()はまんま、検索結果表示ページなら、という意味のコンディショナルタグなんだけど、検索結果表示ページにコメントなんかつけて、しかもそれfeedで受信てどうも利用用途がわからないな。テンプレートいじればコメントつけれるようになるとは思うけど…そもそもそんなテーマも少なそう。
get_bloginfo_rss()でfeed用にフォーマットされたblog自体の名称を取得して、検索語句とあわせ出力している。
24～25行目: 上記でない場合の処理、けど上記に当てはまらないケースが思いつかない。
27～33行目: 多少差異はあるがfeed-rss2.phpと同様に表示中のfeedに関する詳細情報を出力している。
34行目: do_action('rss2_head')と同じくplugin用フックだと思われる。
36行目: ループの開始部分。
37行目: $comment->comment_post_IDでループ中のコメントのIDを取得し、そのIDをget_post()に渡す事で、そのコメントが含まれる記事やページを取得しているんだと思う。ここで取得した記事やページのオブジェクトから、記事IDや、コメントがついている元の記事タイトルなんかを引っ張り出している。
38行目: 上で取得した記事のIDを引数に渡し、なぜかカスタムフィールドを読み込んでいる。
40～63行目: item要素がこの範囲、コメントひとつ分にあたる。
41～49行目: タイトルを先ほど出てきたis_singular()で分岐させている。is_singular()がfalseの場合はタイトルとコメント投稿者名を、trueの場合はコメントの投稿者名のみを出力。
falseの場合、コメント全体を出力しているのでコメントの元となる記事やページのタイトルが必要になる。
50～53行目: 出現順やテンプレートタグは違うが、基本feed-rss2.phpと同じ。
54～60行目: コメントの元となる記事やページがパスワード保護されているかで条件分岐させている。もし保護されている場合、descriptionにパスワード入れてからコメント見てねというメッセージと入力フォームを表示する。パスワード保護がない場合、descriptionにコメント本文をfeed用に、にコメント本文をCDATAで出力。
61行目: feed-rss2.phpと同じくplugin用フック。こちらはコメントIDとコメントのついている記事のIDも引数で渡すようになっている。

通常のfeedにコメントのfeedをあわせる

さて、まずは通常feedにコメントも加えてみる。
具体的にはpostとコメント、両方を区別せず更新日時のみでfeedを生成する形を目指す。
当然そんなテンプレートタグは用意されてないので、どうするのか現時点では皆目検討がつかないが…、うまくいけばwordpressのコアの関数かなにかを使ってもにょもにょしたい。
出来ない場合は…通常のとコメントのをループまわして、それぞれ格納して、ソートしなおして、出力…？
それは避けたいなぁー！！

ループの仕組み

という事でとりあえずwordpressのループ周りの仕組みを追跡してみた。
とりあえずよくわからないけどそう書けと言うんで言われるがままに書いてきた、have_postsとかthe_postについて。

まずwordpressはループやちょっと複雑な処理を担当するWP_Queryってクラスがwp-includes/query.phpで定義されてる。
んで、つかう場合は$wp_queryオブジェクトからメソッドで操作せず、ラッパー関数から同名メソッドを呼び出す形が多い。
しかもこのオブジェクトは色々情報も持ってる、今ループ中ですとか、現ループで扱ってる記事の情報とか、そもそも現在のページはアーカイブページですよ、だとか。
…たぶん、あんま自信ないけどそういう事だと思う。

関数リファレンス/WP Query – WordPress Codex 日本語版

んで、件のhave_postsとかthe_post、あとはコメントfeedで使われてたループ制御のhave_commentsやthe_commentも、WP_Queryのメソッドだったのだ。（正確にはメソッドを呼び出すラッパー関数）
本題のhave_postsとかthe_postの機能はリンク先に既に載っているのでざっと。
have_postsが表示すべき記事がまだあるの？ってのをみてる。記事がまだ3つしかないblogのループの場合、3回ループまわして4回目は当然ないんでこのメソッドはfalseを返す。
the_postはループ中にのみ使えて、現ループ中の対象記事の情報をグローバル変数$postに突っ込んでくれる。
つまりthe_post()と書くだけで$postを参照する様々な関数だとかが、対象となる現ループ中の記事情報を参照してくれる。
コメントのほうも基本同じような事してるっぽい、なるほどなぁ～。

すんげー面倒そうでやってないけど、wp-includes/query.phpの中身をよく見ていくと、きっと何でも出来る気がしてくるんじゃないかな！
俺はまったくしないけど。

七転八倒

とりあえずwhileの条件にhave_posts()かhave_comments()がtrueでまわすようにして、中で再びそれぞれifの条件で出すような感じにしたんだけど、これじゃだめっぽい。
そもそもコメントのみ出てなかったんで、試しにコメントだけ出力するようにしてみたけど、何もでない。
あれー、と思いfeed-rss2.phpにfeed-rss2-comments.phpをまるまる上書きしてみると…うお！でねぇ！
てことは、今表示してるのが普通のfeedかコメントのfeedかをどこかで見てて、それのせいでコメントの分を混ぜれてないのか。

しょうがないのでwp_queryオブジェクトを見てみると、feed-rss2-comments.phpのほうではquery_varsにwithcommentsなんてものが存在してる。あとこれは予想通りだが、is_comment_feedが1(true)だ。
試しに無理やりこの値を設定してみたが、それでもダメくさい、
うーん、feedを読み込む際にwp_queryオブジェクトを生成してて、それがcommentsじゃないからコメントのテキストやらメタ情報が含まれて無いから、もう一回wp_queryオブジェクトを取得しなおせばいい…のか？

何かうまい方法あるんじゃねーの？と思いfeed関係のpluginのソースを眺めてみるが…ゲーッ！クエリ書いてる！
そりゃまぁ何でもできるだろうけど…スマートじゃないなぁ。

wordpressの関数を利用してやるには、今の俺にはちょっとしんどい量のソースを追跡しないといけなそう、かといってSQLクエリを書いてどうこうするのはセキュリティ的な面で非常に不安が残るし、DB構造が今後変更されたら最高に面倒なので、いったんwordpressから離れて考える事に。

別の方法を考える

さて、wordpressの機能を利用するという枷がなくなると選択肢は一気に広がる。
広がりすぎて記事数本になりかねない勢い。
ざっと思いつくのが以下。

feed-rss2.phpおよびfeed-rss2-comments.phpを、item要素を返す関数があるだけのファイルにし、それを呼び出して使う。
phpでゴリゴリ作る。
feedマージ系のwebサービスを使う。

個人的に本命は1なんだけど、今は心が折れ気味なのと、そもそも出来るのかよくわからないのと、そのうちwordpressの機能でやる方法を思いつくなり調べれるのを期待し、もっとも手軽な3で行こうかなとりあえず。
最終的にはbbpressのfeedも合成したいんで、wordpressの機能だけと言いつつどのみち1か2か、もしくは別の方法を混ぜていかないといけなくなるはずなので、そういう意味でもwebサービスは代替方法としては最適だ。
というかなんで最初から使わなかったのかってと、Yahoo! Pipesのレスポンスとかが遅いイメージがあったのと、更新頻度が低いからだったりする。

webサービスでfeedをマージする

[J] 複数のフィード (RSS) を一つにマージする方法 – Jamz

ここに非常に有益なマトメ記事があるので、すでに半分以上目的が達成している。
あとはどれを選ぶかくらいの話だ。

本来なら各サービスの速度測定とかしたり比較したりして余力がありゃ記事化したいところだが、あまりに本筋から脱線してるしそもそもwebサービスは代替方法なのでここはスルー力。とりあえずははてなRSSを非公開で試してみたが、問題なさそうではある…あれ！？bbpressのfeedが構文エラー起こしてる！

bbpressのfeedがおかしい

bbpressのfeedがwordpressと統合をしたせいでおかしな事になっていた。
簡単にまとめると以下の構造のコードが書き出されていた。




  wordpressのタイトル » ページが見つかりませんでした
  wordpressのURI
  wordpressのdescription
  日時

  http://backend.userland.com/rss092
  ja





Warning:  Cannot modify header information - headers already sent by (output started at feedのテンプレートへのパス/feed-rss.php:12) in bbpressのテーマへのパス/rss2.php on line 1




  
    bbpressの名前: トピック名
    bbpressへのパス
    bbpressのdescription
    ja
    日時

    bbpress 1.0-alpha-6
    
      <![CDATA[検索]]>
      
      q
      bbpressの検索へのURI
    

    

    
      投稿者名 :  "トピック名"
      投稿へのリンク
      日時
      投稿者名

      1@bbpressへのURI
      投稿内容

見てのとおり、最初にwordpressのfeedテンプレートを呼んじゃってて、ページは見つからない扱いになる…まではわかるのだが、なぜかその後bbpressのほうのfeedテンプレートまで呼び出すもんだから、headerがエラー出すわエラーメッセージでbrタグなんか入れるわそもそもwordpress側のrssのヴァージョンがなぜか0.92だわテンヤワンヤになっている。
しかもあれこれしてるうちに、そもそもアクセスしても何もないよとか言われる始末。
とはいえ冷静に見るとbbpressのfeedはちゃんと出てるぽいんでなんとかしてやろうかな。
（ほんと次から次へと問題でるな…）

あれ？というかbbpressのfeedってログインしないと見れないのか。
じゃだめじゃん…_no

ここで今回は力尽きた。（今回、といっても一週間以上かかっているのだが…）

wordpressで非公開コミュニティサイトを作る（6） bbpress1.0αのテーマカスタマイズ

daruman — Sat, 09 May 2009 07:36:17 +0000

無事導入できたbbpresws、次はこれを通常のwordpress同様にカスタムしていく方法を見ていく。

wordpressとbbpressの完全な統合

前回やった連携・統合というのは、ログインとユーザー情報を共有させる基本的なものだった。
けどwordpress及びbbpressを利用してあれこれ作りたい人にとって本来欲しい統合とは、テンプレートタグやAPIの統合だったんじゃないだろうか。
wordpressで作ったサイト内の1コンテンツとして、bbpressを利用したforumsがあり、それら全てのコンテンツで共通したヘッダーやフッダーが表示される、そこにはグローバルメニューがあり、メニューはwordpressのテンプレートタグからカテゴリーリストを取得している…みたいな。
俺も以前いじった時はそれがやりたくて、あれこれ調べた結果、以下の記事に載っている方法でそれを再現する事が出来た。

integratePress – Part I | Aditya Naik

これを利用すると何が出来たか、それはbbpressのテーマファイルからwordpressのテンプレートタグを利用できるようになったのだ。
なのでbbpressのテンプレートからwp_head()を利用してheader.phpを呼び出したりとかも可能だった。
しかしこれ、既に現在のヴァージョンでは使う事が出来ない。

俺が試した時は確かwordpress2.5x、bbpressが0.9xだった頃だったが、wp2.6そして2.7にいたるまでに肝心のcookieの仕様等あれこれ変わったせいなのか、使えなくなってしまったみたい。

うーんまいったなぁと思ってたら、あれ公式のDocumentationに載ってた！

bbPress » Integration with WordPress

bbPress will not have access to WordPress’ functions unless you manually tell bbPress to load WordPress first. This integration step is also known as “deep” integration, it is a totally optional part of integration and is not required to get shared cookies and logins working. In order to do it, you need to put require_once(‘path/to/wp-blog-header.php’); in bbPress’ bb-config.php (wp-blog-header is in the same directory as WordPress’ wp-config.php file).

bb-config.phpにrequire_once('フルパス/wp-blog-header.php');を加えるだけで、wordpressのテンプレートタグが使えるように！（この際日本語化に支障が出るが、詳しくは後述）
けどDocumentationには、重くなるからplugin使ったほうがいいよとある…のだが、pluginを探してみるも一体どれがその役目を果たすものなのか見つけられなかったので、とりあえずこの方法でやる事に。
テスト環境だと特に重さは感じられないので、問題なさそうだけど。

bbpressのテーマ

テーマの位置

bbpressはwordpressと同様にbbpress独自のテーマ・テンプレートがあり、それをあれこれする事でデザインを変更する事が出来る。
bbpressのディレクトリ内のbb-templatesフォルダが、wordpressのthemesにあたる。
…と本来これで終了なのだが、bbpressではbb-templatesはコアファイル（？）に含まれるらしく、ヴァージョンアップの際上書きされる可能性が一応ある。
なのでbbpressのテーマを作る際は、bbpressのディレクトリ直下にmy-templatesという名前のフォルダを作り、ここに自分で作成するテーマを入れていく形になる。
（同様にpluginもmy-pluginsフォルダを作って管理する事が出来る）

テーマを構成するファイルの種類

日本語の革命から取ったと思われるKakumeiというデフォルトテーマを良く読めば、一応どのように作るかは把握出来る。

テーマについての情報を管理画面に表示するために最低限必要なものは以下のとおり。

style.css
300×225のscreenshot.png

wordpressと同じく、テーマの情報はstyle.cssの最初の部分にコメントとして以下の形式で記述。

/*
Theme Name:[テーマの名称]
Theme URI: [テーマのURI]
Description: [テーマの説明]
Version: [テーマのバージョン]
Author: [テーマの制作者]
Author URI: [テーマの制作者のURI]
[コメントやライセンスなど]
*/

wordpressでは上記に加えindex.phpが必要だったが、bbpressではindex.phpもそれに相当するテンプレートファイルも見当たらない。
bbpressでは必要なテンプレートファイルがない場合、デフォルトテーマであるKakumeiから該当部分のみ読み込むようになっている。

また公式サイトによると以下のテンプレートファイルが存在するとの事。

front-page.php: フロントページ、つまりbbpressのトップページにあたる。
forum.php: フォーラムの表示、ここに表示中のフォーラムに属するトピックが一覧表示される。
edit-post.php: 既に投稿したコメントを編集する画面。
edit-form.php: bbpress用関数edit_form()で呼び出される、編集フォーム。edit-post.phpから呼び出されている。
favorites.php: ユーザー情報の“お気に入り”ページのテンプレート。
header.php: その名の通り、ヘッダー。bb_get_header()で呼び出される。
footer.php: その名の通り、フッター。bb_get_footer()で呼び出される。
login.php: ログインページのテンプレート。/bb-login.phpがそれにあたる。
login-form.php: bbpress用関数login_form()で、ユーザーがログインしてない場合、呼び出される。デフォルトテーマKakumeiではヘッダー部分で呼び出している。
logged-in.php: bbpress用関数login_form()で、ユーザーがログインしている場合、呼び出される。
password-reset.php: /bb-login.phpからパスワードの回復を行った場合の結果を表示する画面。ここでユーザー名を送ると登録してあるメアドにパスワードリセット用URIが送られ、そのアドレスへ移動するとメアドに新しいパスワードを送ってくれる機能。このpassword-reset.phpはメール送りましたよ！って通知とパスワード新しく設定したよ！って通知の際に表示される。
post-form.php: フォーラムやトピックを新しく追加する際に呼び出されるフォーム。bbpress用関数post_form()で呼び出される。
post.php: bbpress用関数bb_post_template()で呼び出される。投稿を表示するためのテンプレートでループ中に呼び出される。
profile.php: ユーザーページのテンプレート。
profile-edit.php: ユーザーページの編集画面のテンプレート。
profile-base.php: プラグインでユーザーページに追加されたページがあった場合のページテンプレート。
register.php: ユーザー登録画面用テンプレート。
register-success.php: ユーザー登録に成功した旨を知らせるページ用テンプレート。
search.php: 検索結果表示用テンプレート。
search-form.php: bbpress用関数search_form()で呼び出される。検索フォームのテンプレート。デフォルトテーマKakumeiではヘッダー部分で呼び出している。
stats.php: 人気の記事や現在の登録ユーザー数等を表示するstatistics.php用テンプレート。デフォルトテーマKakumeiではどこからもリンクされていない。
topic.php: トピックを表示するテンプレート。
topic-tags.php: bbpress用関数topic_tags()で呼び出される。表示中のトピックのタグと、追加削除用フォームを呼び出す。
tag-form.php: Called by tags_form().と公式サイトにあるが、少なくとも1.0にはそんな関数もなければ、tag-form.phpもデフォルトテンプレート内に存在しない。またコアファイル内のどこにもtag-form.phpに関する関連付けがないので、作った所で何も機能しない。
これはおそらく誤表記で正確にはtag_form()だと思われるが、これはコアファイル内の関数でhtmlを出力しているので、結局テンプレートを作っても置き換えてはくれないぽい。
tags.php: タグ一覧ページ表示用テンプレート。よく使われるタグ一覧を見れる。
tag-single.php: あるタグに属するトピックの一覧・そのタグに属するトピックの作成フォーム・タグ編集フォームが表示される画面のテンプレート。アドレスはtags.phpと一緒だが、こちらは引数でタグ名を渡すと表示される。
view.php: ログインしている時のみ表示される「返信の無いトピック」や「タグの無いトピック」といった一覧を表示するためのテンプレート。ログインしている時のみ、というのは単にテンプレートでログインしてるかで分岐させているだけなので、元々そういう機能が備わっているワケではない。

bbPress » Themes and Templates

また、これ以外にもデフォルトテーマ内には以下のテンプレートが存在した。

404.php: 見てのとおり、404が帰ってきた時に表示するページ用テンプレート…のはずだがまったく機能しているように見えない。
rss2.php: RSS2用テンプレート。
style-rtl.css: サブcss。デフォルトテーマのひとつKakumei-blueでも利用されているようだ。

さらに、デフォルトテーマにはないが以下のファイルを自分で作ればテ－マファイルの一部と認識してくれるようだ。

functions.php: wordpressと同じ、テーマで使用する関数を書いておくものだろう。

見てのとおり、bbpressはwordpressよりテンプレート数が膨大なのが結構大変だったりする。
先のwordpressのテンプレートタグを使える方法をとったなら、header.php等共通化できる部分はしてしまったほうが作業量が減るケースがあるかもしれない。
ただしwordpress本体のアップグレードによるなんらかの変更でbbpressとの統合が解けてしまう可能性もある、wordpressをアップデートしていく意思があるなら極力テンプレートは別にしておき、wordpressのテンプレートタグを利用するのは最小限にしたほうが被害は少ないだろう。
また、テーマフォルダにない場合デフォルトのテーマから流用するので、流用されても問題のないものは製作必須ではない。（rss2.phpやstyle-rtl.cssは多くの場合いじる必要がないだろう）

テンプレートタグ

bbpressのテンプレートタグがまとまっているサイトを俺は知らないけれど、多くのテンプレートタグは/bb-includes/functions.bb-template.phpにまとまっているので、デフォルトテーマの中身とつき合わせていけば大体把握できる。（もちろんある程度phpはわからないとだめだけど）

注意するべきはループのまわし方やConditional Tagの違いかなぁ。

wordpressとの統合やbbpressの設定の調整

bbpressのパーマリンクの変更

bbpressの管理画面でパーマリンク設定を変更してもリンクが修正されず、wordpressの404画面に飛ばされる。
bbpressではwordpressのように自動で.htaccessを作成してくれないからのようだ。
この場合管理画面のパーマリンク設定部分の下の説明にあるprovided hereというテキストリンクから表示されるテキストを.htaccessという名前で保存し、bbpressのディレクトリにアップロードすればOK。

リダイレクト

ログインしてない場合のリダイレクト

bbpressのテーマのほうにfunctions.phpをつくり以下の内容を書く。

bbpressにはフィルターフックやアクションフックが提供されていないのでどうしたもんかなと思っていたが、functions.phpは他のテンプレートより先に読み込まれて実行されるので、関数でラップしなければ普通に実行してくれるようだ。
リダイレクト関数を利用してるんで、普通にリダイレクトする時と同じく出力が先にくるとエラーが出そうだから（試してない）functions.phpの最初に書くほうがいいかも。

日本語リソースの引用修正

既に少し触れたが、wordpressとの完全な統合のためにbb-config.phpでwp-blog-header.phpを読み込んでいると、bbpressの日本語リソースの参照先が変わってしまうので、bbpressの大部分の箇所が英語に戻ってしまっているはずだ。
一部日本語に翻訳されたままの部分もあるが、これはworpdressと共通の語句が翻訳されているだけにすぎない。
つまり、この時bbpressはwordpressの日本語リソースを読んでいる事になる。
これへの対処方法はbb-config.phpのwordpressのwp-blog-header.phpを読み込む処理の後でload_textdomain関数を実行する。

/* wordpressとの統合 */
require_once('wordpressまでのフルパス/wp-blog-header.php');

/* bbpressの日本語リソース読み込み */
load_textdomain('default', 'bbpressまでのフルパス/my-languages/ja.mo');

この二つをbb-config.phpの一番最後の部分に追加してやれば、wordpressのテンプレートタグが使えて日本語化されているbbpressが完成する。

wordpressで非公開コミュニティサイトを作る（5） bbpress1.0αのインストール

daruman — Sat, 02 May 2009 07:52:03 +0000

wordpressとの連携を考えてbbpressの導入、実際にwordpressと連携させる手順とかもろもろをやってみる。

今回はやはりフォーラム・BBSの類はどうしても欲しくなるので、折角だからbbpressを試してみる。

bbPress

wordpressの開発元が作った、wordpressに似たフォーラムの事、フォーラムってのはでっかい掲示板みたいなの。
2ちゃんで言うと、板＝フォーラム・スレッド＝トピック、みたいな。
このbbpress、数年前にいじった事があるのだが結構話題にはのぼるものの具体的な日本語での情報がろくにないのでかなり苦労した覚えがある。
そしてどうもその状況は未だ変わらず、検索しても簡単な紹介や、入れてみました、といった内容がほとんどで、しかも現在最新版である1.0-Alphaに関する言及はほぼ見かけない。
あーこれはキタな。
本来英語がろくに出来ない俺は適任ではないけど、ここはいっちょ頑張ってみるか＾＾

bbpressについて

bbpressは少しとっつきにくい。
おぼろげな記憶を手繰るに、bbpressのとっつきにくさの原因は以下にあると思う。

少し古いwordpressをベースにしている
wordpressとの連携が可能、なのだが何が連携されるのかよくわからない
wordpressとの連携が可能、なのだがそれまでに幾多の設定が必要になる
wordpressと似たような内容が違う語句で表現されている
調べようにも情報が見つかりにくい
根本的に“フォーラム”という形態にほとんどの人が不慣れ

とりあえず現時点で分かるのは、連携されるのは主にログインとユーザー情報に関する内容だと言う事だ。
wordpressでログインすると、bbpressでもログインされた事になり、bbpressでログアウトすると、wordpressでもログアウトした事になる、みたいな。
wordpressのほうはともかく、bbpressは基本的にログインして使うように作られているからだと思うが、wordpressでログインとか普段見る分には関係なくねー、っていう普通のblogの形態の場合は無理に連携しなくていいかもしれない。

日本語化は既にされていて、日本語リソースも提供されているものの、現在最新版となる1.0Alpha版はまだない。
これはAlpha版だから本格的に取り掛かっていないだけかもしれない、有志でやっていただいてるんで気長に待つ。
とはいえ0.9.0.4版の日本語リソースでもかなりの部分が日本語化されるので、とりあえずこれでまかなえる。

連携に関しては現時点での安定動作バージョンであろうversion 0.9.0.4は、最新のwordpressとcookieの形態が違うため連携がかなり難しかった覚えがある。（うろ覚えで適当な事言ってる可能性あり）
なので今wordpressとbbpressを連携して使いたい場合、日本語リソースが完全でないのを我慢してAlpha版を使うほうがいいかもしれない。（0.9.xのほうも地味にヴァージョンアップをしているので今なら0.9.xでも楽なのかな）

wordpressとbbpressは親和性が高いものの、いくつもの用語に差異があり混乱する。
keymaster等の権限周りの呼称の違いが最初理解するのに時間がかかった覚えがある。
とはいえそもそもやってる事が違うので全て同じには出来ないのだが…。

また、bbpressにはwordpressと非常に似た管理画面があるのだが、このデザインがwordpress2.5.ｘより前のデザインを踏襲しているため、なんとなく不安になるｗ
個人的にこの古い管理画面 + 完全に日本語化されてなく英語が混ざる各項目 + 情報源がほぼ公式forumのみ（当然英語）、という状況が印象として導入のハードルを上げているように感じている。
あとwinXP環境だとfont指定のせいか、出来悪い明朝体による日本語表示になる部分があるのが悲しい。

ところでwordpressとの連携と聞いて一番期待するものは、実はログイン情報の共有なんかじゃなく、テンプレート等デザインやレイアウト要素の共有じゃないのだろうか。
ログインなんてのは基本blogを書いている本人のみの問題なので、自分が以前使った際も本当はテンプレート共有こそが一番期待するところだった。（今回はログインしないと見れないようなサイトをwordpressで構築するのが目的なんで別にいいんだけど）
ところがこれが案外大変だったような…今は変わったのかな。

ちなみに俺が感じてるbbpressの良い所も書いておくと、forumとしては定番のphpBBほどゴチャゴチャしてなく、けどそれなりの機能があり、テンプレートとかがwordpressの書式と似ている所だ。
つまりwordpressのテンプレートをある程度いじれる知識があれば、bbpressのデザイン変更もかなり自由に出来る。（wordpressのテーマとは別扱いだが）
forumレベルの機能のbbsをフルスクラッチするのは労力に見合わない、けれどありもののforumのデザインを変えるのは結構大変、なのでwordpressの知識を流用すればデザインが変更しやすいという一点においてのみでもbbpressは十分魅力的だったりする。

て事でだいぶ久々にインスコからやっていってみる。

bbpressのインストール

wordpressと連携させるのを前提に、bbpressをインストールしていく。
導入環境は以下。

bbpressのバージョン: 1.0-Alpha-6
wordpressのバージョン: 2.7.1
phpのバージョン: php4.4.x
MySQLのバージョン: 5.0.51a

サーバは要はheteml仕様。
さらに既にwordpressはインストールしてあるものとして、そこにbbpressをどうインストールし連携させていくかを追っていく。
今回はwordpressをインストールしたディレクトリ直下にforumsというフォルダ作る。

1.下準備

必要になデータを用意する。

bbpress本体（Alpha版は下のダウンロードから、zipでもgzでも中身は同じ）
bbPress » Download »

bbpress日本語リソース（moファイルだけでもいい気がしたけど一応両方）
Revision 397: /ja/tags/0.9.0.1

次にwordpressに秘密鍵（セキュリティ・キー）を設定しておく。
wp-config.php の編集 – WordPress Codex 日本語版

セキュリティ・キーとは、パスワードに無作為（ランダム）な要素を加えることによって、あなたのサイトへの不正アクセスや侵入・改竄を難しくする hashing salt です。

どうするかというと、WordPress.orgの秘密鍵サービスにアクセスし、自動で生成されたランダムな文字列のkeyを全てコピー。
wordpressをインストールしたディレクトリにあるwp-config.phpをダウンロードして開き、該当部分に上書きして保存、アップロードする。

WordPress.orgの秘密鍵サービス

wp-config.php

以下の部分を上書きし書き換える。

define('AUTH_KEY', 'put your unique phrase here');
define('SECURE_AUTH_KEY', 'put your unique phrase here');
define('LOGGED_IN_KEY', 'put your unique phrase here');
define('NONCE_KEY', 'put your unique phrase here');

2.インストールと日本語化

forumsフォルダを作成したらその中に解凍したbbpressのファイル一式をアップロードする。
次に日本語リソースファイルをアップロードするのだがここで注意がある。
現在多くのサイトで解説されている方法はversion 0.9.x用で、今回使う1.0Alpha版では日本語化されないということだ。

これまではforums/bb-includes/にlanguagesという名前でフォルダを作り、先ほどダウンロードした二つの日本語化リソースをアップロードすることで日本語化できた。
今回使う1.0Alphaではbbpressのrootディレクトリ、つまり今回はforumsフォルダ直下にmy-languagesというフォルダを作り、そこにリソースをアップロードする。
このmy-languagesフォルダは0.9.xと同様に、自分で作らないと存在しない上、スペルミスすると動かないので注意。

この後0.9.xだとbb-config.phpを作ってあれこれするのだが、1.0Alphaからか今では0.9.xも同様かは分からないが、手作業でbb-config.phpをいじる必要は無くなっている。（日本語化についてのみ）

この状態でアップロードしたアドレスにアクセスすると、インストールのウィザードが表示される。
日本語化に成功していれば、言語を選択するプルダウンが表示されるはずだ。
ここでjaを選択してやればOK。

ちなみに解説をしているサイトによっては日本語化のタイミングがもっと後になっているケースもあるが、今はこの段階でやっておくとインストールウィザードまで日本語化してくれるので本当にありがたい。

3.インストーラー　ステップ 1 – データベース設定

あとは基本インストーラーの指示に添って入力していけばいいだけだが、空欄でもいい箇所もあったりする、んだけどそれがどこかわかりにくかったりも。

Database name・Database user・Database password: 利用するデータベースの名前・ユーザー名・パスワードを入力する。wordpressとの統合を目指すならデータベースはwordpressと同じものがいいぽい。
使用言語: 日本語化に成功していればここには既にjaが選択されているはずなので、そのままでOK。
Show advanced settings: より細かい設定項目を表示するかどうかのチェックボックス、チェックしよう。99% of the time these settings will not have to be changed.なんて説明が書いてあるけど、ウソじゃないのこれ。（99%変更する必要はないよ、みたいな事言ってる）
Database host: これwordpressのほうでも通常変えなくていいよ、とか書いてあるんだけど本当なのかな？俺はレンタルサーバーだし当然変更しないといけないんだけど、デフォルトのlocalhostのままでいい人って自宅サーバー持ってる人とかだけじゃないのかな？？それって一般的なんだろうか…。良く分からないけどとりあえず自分が利用しているサーバーの設定にあわせて必要なら入力。
Database character set: utf8になってると思うんでそのままで
Database character collation: これは設定してもしなくてもいいと思う。文字化け対策にutf8_general_ciを入れてもいいと思うけど、データベースのテーブルが全て無い状態で設定しないといけないぽいんで、既にこの設定無しでwordpressを使っている場合、結構面倒かもしれない。（wordpressのデータを一旦エクスポートしてデータベース初期化する必要があるから）この辺自信なし、俺の環境では設定しなくても問題なかった。
bbPress “auth” cookie key・bbPress “secure auth” cookie key・bbPress “logged in” cookie key・bbPress “nonce” key: ここは後で直接config.phpをいじるのでこの時点ではスルー。
Table name prefix: データベースのテーブルの接頭語、デフォルトのままでいい。

ここまで入力し、ステップ2へ

4.インストーラー　ステップ 2 – WordPress ブログとの統合

ここでwordpressとの統合の設定をする、ここで言う統合とはログイン情報とユーザーデータの統合にあたる。
wordpressと連携する気がない場合はステップ2自体を飛ばしていい。

Add integration settings: wordpressと連携させたい場合はチェックする。チェックする事で以下に続く2つのチェックボックスが追加される。
Add cookie integration settings: wordpressとcookieの統合をする場合はチェックする。cookieを統合するとログイン情報を共有する事が出来るようになる。チェックする事で統合に関する設定項目が表示される。
Add user database integration settings: wordpressとユーザーデータを統合する場合はチェックする。チェックする事で統合に関する設定項目が表示される。

cookieの統合項目

WordPress address (URL) ・Blog address (URL): 統合予定のwordpressの一般設定と同じ内容にする。これはなんとなくではなく、ちゃんとコピペして正確に同じ文字列を入力しよう。
WordPress “auth” cookie key: wp-config.phpの上書きした部分の以下をコピペする。
define('AUTH_KEY','ここをコピペする');
WordPress “auth” cookie salt: 下の説明文中にあるthis WordPress admin pageの箇所のリンク（wordpressのwp-admin/options.php）を開き、ここに表示される幾つかの項目の中からauth_saltの文字列をコピペ。
WordPress “secure auth” cookie key: wp-config.phpの上書きした部分の以下をコピペする。
define('SECURE_AUTH_KEY','ここをコピペする');
WordPress “secure auth” cookie salt: 何も入力せず空けたままでいいようだ。
WordPress “logged in” cookie key: wp-config.phpの上書きした部分の以下をコピペする。
define('LOGGED_IN_KEY','ここをコピペする');
WordPress “logged in” cookie salt: 先ほど開いたwordpressのオプション一覧画面（wordpressのwp-admin/options.php）を開き、ここに表示される幾つかの項目の中からlogged_in_saltの文字列をコピペ。

ユーザーデータの統合項目

User database table prefix: ユーザーデータがあるデータベースのテーブルに使われている接頭語、つまりwordpress側の接頭語にあたる。何も変更していないならwp_のままでいい。
Show advanced database settings: wordpressとbbpressが別のデータベースを使う場合の設定を表示するかどうかのチェックボックス。今回は同じデータベースを使用するのでチェックは入れない。

ここまで設定したら右下にあるSave Wordpress integration settingsボタンをクリックすればOK。

5.インストーラー　ステップ 3 – サイト設定

サイト…というかこのforumの設定になる。

Site name: このbbpressの名前をつける。
Site address (URL): このbbpressのアドレス
“キーマスター” アカウント: bbpress設置初期状態のキーマスターを決める。キーマスターとはwordpressで言う所のadministrator、つまり管理者権限にあたる。
最初のフォーラム: bbpressに最初に作られるフォーラム名。

設定したら設定は完了、あとはインストール開始するだけになる。
無事インストールが終わったら、wordpressのほうを一応ログアウトしてからbbpressにアクセスしてみよう。

ここで注意してほしいのは、既に日本語化されていても最初のフォーラムを日本語で入力してはいけない。
好奇心で一度日本語でやってみたら、インストール後bbpressにアクセス出来なくなってしまった！
やめろと言われるとやりたくなる人は、こうなった場合データベースのbb_が接頭語のテーブルを全て消し、再度アクセスしてインストールの手順を踏むといい。
既にbb-config.phpは生成されているため多少早くインストールしなおせるだろう。

6.権限の設定

次にwordpressでのユーザー権限とbbpressでの権限をどう対応させるかの設定を行う。
bbpressにログインしなおしたら、bbpressの管理画面（Admin）に入り、設定＞ Wordpressとの統合を表示。

日本語化されていないが、たいしてむずかしい事をするわけじゃないので問題ない。
User Role Mapにwordpressのデフォの権限が並んでいて、それぞれにbbpressのどの権限を対応させるかをプルダウンから選択する形になる。

wordpressの日本語の権限との対応は以下の通り。（たぶん）

WordPress Administrator: 管理者
WordPress Editor: 編集者
WordPress Author: 作成者
WordPress Contributor: 投稿者
WordPress Subscriber: 購読者

例えば恐らく自分のwordpress上での権限である管理者をbbpressの管理者に相当するKey Masterに対応させるには、WordPress AdministratorのプルダウンをbbPress Key Masterにしてあげればいい。
それぞれ設定したら下にあるSave User Role Mapボタンを押せば保存される。
これでwordpressとbbpressの権限をリンクさせた事になる。

7.wordpress plugin“bbPress Integration”の導入

さて、自分のアカウントを無事Key Masterに設定し、ログインしなおしてみると…bbpressの管理画面に入れなくなっている！（wordpressの管理画面には入れる）
実はこれ、0.9.xの頃から事あるごとに起きる問題だったのだが（俺限定）、1.0Alphaにはこれを解決する専用のpluginがあるようだ。

WordPress › bbPress Integration « WordPress Plugins
ちなみにこれはwordpressのほうのplugin。

これを有効化するとwordpressの管理画面の“設定”にbbPress Integrationが追加されるので、ここで設定をしていく。
といってもむずかしくはない。

bbPress URLにbbpressのURLを入力しSave Changesボタンを押す。（“Your plugins URL”は空でいい）
Manual Cookie Settingsの下にあるテキストフォームの中身をコピー
wordpressログアウト
wordpressのwp-config.phpをダウンロード
言語設定の下辺りに先ほどコピーしたコードをペースト
wordpressのwp-config.phpをアップロード

これでbbpressの管理画面にも入れるようになるはずだ。
そもそもこんなpluginが必要なのも困り物だが、いずれ改善される…んじゃないかな。
長らく問題になってる部分だから、もうしばらくはこのpluginのお世話になる予感もするけど。

参考資料

今回の記事は以下のトピックに上がっているスクリーンキャストを元に、日本語化の工程を加えてやってみた。
数年前の初めてbbpressに触れた当時も、forumでは散々wordpressの統合の話ばかりが質問されていて、恐らくもういい加減にせいよ！という事で動画提供したんじゃないかな。（邪推）

Basic integration screencast « bbPress Support Forums

英語がわからんので何を喋っているのか把握出来てないけど、一番肝となるcookie関連について喋ってそうなので理解出来ないのが歯がゆい。
まぁこうやって工程くらいは把握できるんだけど。

余談だけど、どうせ統合できる作りにするならwordpressの管理画面でbbpressの設定とかも出来るようにしてほしいなーとやってて思った。
確かそんなpluginもあった気がするが…あの当時何もかもがバギーな印象で、そんなチャレンジブルなpluginは入れなかったと思う。

wordpressで非公開コミュニティサイトを作る（4）feedのカスタマイズ

daruman — Tue, 28 Apr 2009 06:39:44 +0000

前回保留にした、アクセス制限した状態でのfeedをどうするかという問題を考えていく。

前回、ログイン確認にfunctions.phpからアクションフックを利用してリダイレクトする方法に変更し、そのおかげでfeedも認証が必要になった。
ところがwordpressの認証にはcookieを利用している事から、cookieを判別出来ないfeed readerではアクセス出来ない問題が残ったので、これについて考えて見る。

参考：wordpressで非公開コミュニティサイトを作る（3）続・ユーザーレベルで表示内容を変更 – atl*weblog

feedはどんな風に利用されるか

クローズドなサイトを作るのが今回の目的なので、通常のblogのように全文配信したりといった、feed自体の質にはそこまでこだわる必要はないかなと思っている。（特に根拠がないどころか、質がいいに決まってるんだけど）
ログインする、という手間がかかるので更新されたかどうかの通知は必須になる。
なのでfeedは必要であるものの、配信される内容はぶっちゃけタイトルだけでもいい。
コメントのやり取りも想定される事から、出きれば本文とコメント等を纏めて一つのfeedとして配信出来るといいんだけど…、これは無理にやらずに他のfeed纏めるサービス使ったほういいのかなぁ。
けどfeedの配信タイミングが遅れそうな気もするなー。

feedテンプレートってどこにあるの？

feedで吐き出すxmlをカスタムしてしまえば、本文のみ隠したりも出来るし、ひょっとしたらwordpressの関数使ってcookie見てのログイン判別も出来るかもしれない。
なんて淡い期待を込めつつやり方を探すも、どうもfeed用のテンプレートはコアファイルにしか存在しないらしい。

Customizing Feeds « WordPress Codex

ここにfeedのカスタム方法が載っているけど、ここに記載されているwp-rss2.phpだとかwp-atom.phpと同名のファイルでも作ってテーマフォルダにでも置けばテンプレートみたいになるかな、なんて淡い期待を持って無駄な時間をすごしたり。
今現在のwordpress（2.7.x）ではwp-includes内にあるfeed-atom.php、feed-atom-comments.php、feed-rdf.php、feed-rss2.php、feed-rss2-comments.phpとかがテンプレートにあたるようだ。
中身を見るとテンプレートファイルと同様に、様々なfeed用テンプレートタグを利用してfeedの雛形が作られている。

コアファイルを編集する事に抵抗が無いならこれをいじれば簡単に目的達成となるだろう、やり方もテーマの修正と同様なので特にむずかしくもない。
ただ上記の通り、ヴァージョンアップで変わってしまう可能性があるコアファイルのため、俺はこの方法はちょっと避けたい。

feedのカスタマイズの下準備

まずfeedへのアクセスに認証をしないで出来るようにする。

認証周りの処理変更

前回send_headersフックでログイン判別とリダイレクトをさせていて、これでfeed見るにも認証が必要になるぜわっしょいしてたが、ログイン判別にcookieが必要な以上通常のFeedReaderで読めなくなってしまう。
というか薄々気づいていたのだが、どうにも対処方法がわからず、それならば吐き出すfeed自体をどうにかしたほうが現実的という事でこれは一度戻す事に。
とはいえまたheader.phpに直接書くのも芸がないのでget_headerフックで以下のようにfunctions.phpにリダイレクト処理を書いた。

function op_auth() {
	if ( !is_user_logged_in() ) auth_redirect();
}
add_action('get_header', 'op_auth');

このアクションフックはheader.phpが読み込まれる際に動くらしいので、header.phpの最初に記述したのとほぼ同様の効果を得られる。
処理も別の場所に分離できていい感じ。

デフォルトのフィルターをリムーブ→再設定し、feedテンプレートを置き換える

さて、feedをあれこれするのに何かいいフックないかなーと探し幾つかそれっぽいものを見つけたものの、結局何が出来るかどうかすらわからなかった。
日本のcodexはまだ未翻訳、本家のcodexには記事がない。

Plugin API/Action Reference/atom entry « WordPress Codex

こりゃ別の方法かなー、と思って半ば諦めていたらtwitterでアドバイスを頂いた！

Twitter / wokamoto: @darumen default_filter とし …

@darumen default_filter として do_feed_rss, do_feed_rss2, … ってフィルタをフックして、ロードするテンプレートを指定しているので、これらをリムーブ後、新たにフィルタを add すれば、好きなテンプレートをロードできます。

しかもサンプルコードまで書いてもらってしまった…！
（共有メモサービスでコード提示してもらったけど、一応そっちのアドレスは伏せ）

// フィルタリムーブ
remove_filter('do_feed_rdf', 'do_feed_rdf', 10);
remove_filter('do_feed_rss', 'do_feed_rss', 10);
remove_filter('do_feed_rss2', 'do_feed_rss2', 10);
remove_filter('do_feed_atom', 'do_feed_atom', 10);

// フィルタ追加
function custom_feed_rdf() {
  load_template( get_template_directory() . '/feed-rdf.php' );
}
add_action('do_feed_rdf', 'custom_feed_rdf', 10, 1);

function custom_feed_rss() {
  load_template( get_template_directory() . '/feed-rss.php' );
}
add_action('do_feed_rss', 'custom_feed_rss', 10, 1);

function custom_feed_rss2( $for_comments ) {
  if ( $for_comments )
    load_template( get_template_directory() . '/feed-rss2-comments.php' );
  else
    load_template( get_template_directory() . '/feed-rss2.php' );
}
add_action('do_feed_rss2', 'custom_feed_rss2', 10, 1);

function custom_feed_atom( $for_comments ) {
  if ($for_comments)
    load_template( get_template_directory() . '/feed-atom-comments.php');
  else
    load_template( get_template_directory() . '/feed-atom.php' );
}
add_action('do_feed_atom', 'custom_feed_atom', 10, 1);

をかもとさんありがとうございます！（2日ほどハマってました）

コードの検証

動作確認も出来たのですぐにでも使えてしまうレベルのコードだけど、折角なのでどういう事をしているのか調べて見る。
feedが表示される際、アクセスされたfeedの種類によってdo_feed_～～というフックが動いて何かするんで、それをremove_filterで無しにした後、新たにそれぞれにadd_actionで処理を再設定している。
処理自体はテーマフォルダ内の同名テンプレートを取得する事によって、本来コアファイルに含まれるfeed用テンプレートをテーマフォルダ内にある自作テンプレートに置き換えている。
rss2とatomはコメントのfeedのケースもあるんで、引数で渡された$for_commensの真偽でどちら用のテンプレートを使うかを判別している。
…のかな、たぶん。

分からないのは、remove_filterで指定してるフックと関数名が同じだけど、どういう事だろうって点と、こういう事をする場合関数ってどうやって調べるんだろう、という二点。

まずremove_filterで指定してるフック、do_feed_～～だがこんな感じのもの。
プラグイン API/アクションフック一覧 – WordPress Codex 日本語版

do_feed_フィード名
アクション関数引数: フィードの種類（コメントフィードならtrue、投稿記事フィードならfalse）
RSS2、Atom、RDFなどのフィードが生成される直前に実行する。フィード名には rss2、atom などフィードの種類を入れる。

feedが生成される直前に実行されるってのはあってるようだ。

で関数のほうはwp-includes/functions.phpの1481行からあった！

/**
 * Load the RDF RSS 0.91 Feed template.
 *
 * @since 2.1.0
 */
function do_feed_rdf() {
  load_template( ABSPATH . WPINC . '/feed-rdf.php' );
}

/**
 * Load the RSS 1.0 Feed Template
 *
 * @since 2.1.0
 */
function do_feed_rss() {
  load_template( ABSPATH . WPINC . '/feed-rss.php' );
}

/**
 * Load either the RSS2 comment feed or the RSS2 posts feed.
 *
 * @since 2.1.0
 *
 * @param bool $for_comments True for the comment feed, false for normal feed.
 */
function do_feed_rss2( $for_comments ) {
  if ( $for_comments )
    load_template( ABSPATH . WPINC . '/feed-rss2-comments.php' );
  else
    load_template( ABSPATH . WPINC . '/feed-rss2.php' );
}

/**
 * Load either Atom comment feed or Atom posts feed.
 *
 * @since 2.1.0
 *
 * @param bool $for_comments True for the comment feed, false for normal feed.
 */
function do_feed_atom( $for_comments ) {
  if ($for_comments)
    load_template( ABSPATH . WPINC . '/feed-atom-comments.php');
  else
    load_template( ABSPATH . WPINC . '/feed-atom.php' );
}

結論：単にフックと同名の関数があるだけだった。

そしての調べ方だが、恐らくケースによるのだろうけれど、をかもとさんのアドバイスによるとdefault_filter として～～というくだりがあるので、とりあえずwp-includes/default_filters.phpを見てみたりして、目的のフックで実行されている関数があればwp-includes/functions.phpで探せばいいのかな。

ちなみにこの場合Codexは本家のほうをしっかり読み込んでれば大丈夫だと思うんだけど、俺のように怠けて辞書代わりに使ってる場合本家codexにも記述のない項目が結構あるので見つからなかったりする。

feedテンプレートのカスタマイズ

という事でアドバイスもあって見事にテーマフォルダにfeed用テンプレートファイルを持つ事が出来るようになった。
wp-includesディレクトリ下にある各種テンプレートファイルを利用中のテーマフォルダにコピーし、これを改良していく。

認証は無理だった

まず認証についてだが、案の定判別はむずかしいようだ。
利用するFeedReader次第ではあるのだが、やはり別の方法で情報隠蔽を考えたほうがいいみたい。
また、ユーザーレベルでの振り分けもどうやら無理なようだ、普通にブラウザでfeedを表示する場合には適用されるケースもあるのだが、やはりFeedReaderで見ると全てユーザーレベル0での挙動しかしないので、振り分ける意味はあまりなかった。

本文をrssに表示させない

本来概要くらいは表示させておいてもいいのだが、利用者と想定している層がすら使ってくれなそうなので、タイトルとメタ情報のみの配信にしておきたい。
なのでfeed用テンプレートの本文部分を無くしておく。
さらにデフォではコメントへのリンクもあるのでこれもはずしておく。

feed-rss2.phpのコメント部分は以下。

feed-rss2.phpの本文部分は以下。


		]]>

		]]>
	post_content ) > 0 ) : ?>
		]]>
	
		]]>

これらを削除すればいい。他のatomとか別のfeedも似たような感じなので同様に。

結局のところ…

思いもかけないアドバイスもいただき凄く勉強になったものの、今回の目的からすればfeedをテンプレートとして持つほどの修正は必要なかった感じがする。
というのも前回やったthe_contentフィルターフックによる記事本文、そしてcomment_textフィルターフックによるコメント文の差し替えはfeedにも効いているからだ。
なので、体験用メンバーの権限のユーザーレベルを0から1に引き上げてやり、feedからの閲覧は自動的にユーザーレベル0扱いにする事によって、全ての記事の本文・コメント文を非表示ないし文言置き換えをする事が可能だからだ。
ただちょっと面倒そうなのでスルーしたが、feedテンプレートを持つ事が出来たおかげで今後頑張れば本文とコメント両方の更新を一つのfeedで受信できるようにカスタムしたり、その場合はコメント用feedは一本化したほうのfeedにリダイレクトしたり、といった事が出来るかなーと思えるようになった。

しかし不安なのは、適当にfeedから本文部分を削除したけど、正しいRSS構文とかそういった観点から見るとどうなんだろう？
今まで直接xmlをいじる機会がなかったけど、そのうちこれも勉強しないと＞＜

wordpressで非公開コミュニティサイトを作る（3）続・ユーザーレベルで表示内容を変更

daruman — Sun, 26 Apr 2009 06:50:32 +0000

前回ユーザーレベルでの振り分けをpluginとphpやwordpressAPIを使い分けて行う方法を模索したが、pluginが古いせいもあり挙動が不安定なので、やはり全てを自力で行う方法を考えていく。

と言うわけでどうすればplugin無しで出来るか考えていく。
ここまでのやり方で全部代替出来るんじゃねーかなぁという感触があり、pluginが行っている閲覧制限機能を1つづつ代替出来るか試してみる。

pluginが行っているのは表面的には以下の内容。

閲覧権限がないカテゴリーの記事自体のタイトル・本文・コメント本文を非表示化、もしくはメッセージとして登録した文字列に置換
各種ループで閲覧権限がないカテゴリーの記事のタイトル・本文・コメント本文を非表示化（トップページ・カテゴリーアーカイブ・最新の記事等）
閲覧権限がないカテゴリーへのリンクを非表示化（カテゴリー一覧等）、ただしループ内に表示される記事のカテゴリー表示は非表示化されない
Feedを各記事のタイトルと記事へのリンクのみに

こんなかな。
なんかいけそ～な気がする～。
注：過程を追って書いてるんで、一度書いたコードが徐々に変わったりしてるんで注意＞＜

前提条件

ユーザーレベル0の人にも表示していいカテゴリー名は『体験用』、カテゴリーIDは『3』。
閲覧制限したいのは主に本文、タイトルは別に出てても問題なし。
あとコメント本文も閲覧制限したい。
コメント非表示の場合は入力フォームもか。

記事自体の閲覧制限

閲覧OKのカテゴリー以外の記事（post）の本文を隠す。
やり方はテーマの中のfunctions.phpに、テーマ内で利用するプログラムを含める事が出来るので、ここにその処理を作っていく。
テーマの柔軟性や保守性のため、出来る限り他のテンプレートであれこれせず、処理をfunctions.phpに集めるのがいいと思う。
wordpressは様々なフックのAPIが用意されているので、データベースからデータ取得→表示、の間に取得したデータを加工する処理をフィルターフックで割り込む形でやってみる。
pluginでもよく使われるこの方法だと、テンプレートのほうから関数呼び出しすら必要がなくなるので、綺麗に表示との分離が出来る。

詳しい記述方法はググってもらうとして、フィルターのフックを使うにはこんな感じで書く。

add_filter('the_content', 'op_hide_content');

add_filterでフィルタを設定する、1つ目の引数がフィルターフック名、2つ目がフックが起動した際に処理させる関数名。
この場合the_contentで記事本文が表示される際にフックが起動し、op_hide_content関数を実行する、となる。
で、op_hide_content関数はこんな感じで書いてみた。

function op_hide_content( $content ) {
  global $user_level;
  if ( 0 == $user_level && !in_category(3) ) {
    $content = "みせないよ";
    return $content;
  } else {
    return $content;
  }
}

引数の$contentはフックにあわせた内容だったりpost_IDだったりを渡せるようだ、このケースだと記事本文を取得できる。
前回の記事のユーザーレベル取得の方法でglobalから$user_levelを持ってくる。
さらに条件にin_category()を利用し、引数で指定したカテゴリーIDに表示中の記事が含まれているかを判別。

注意点は、フックで呼び出す関数の引数は必ず1つ、ってのと必ず引数を返す、って点。
引数はオプションで数を変更できるが。

これで無事本文を隠す事が出来るようになった。
記事自体を表示した時はもちろん、トップページ等で記事の概要のみ表示している場合でも、その部分は表示されないようにする事が出来た。

コメントの閲覧制限

コメントの非表示は記事本文非表示とフックが変わるだけでやる事はほぼ同じだ。
なので同じ関数で処理できるようにフィルタだけ追加してみる。

function op_hide_content( $content ) {
  global $user_level;
  if ( 0 == $user_level && !in_category(3) ) {
    $content = "みせないよ";
    return $content;
  } else {
    return $content;
  }
}

add_filter('the_content', 'op_hide_content');
add_filter('comment_text', 'op_hide_content');

最後の行に追加されているフィルターがコメント本文のフックだ。
どのフィルターから関数が呼び出されたかを判別する方法がわからないが、もし無いなら呼び出す関数を別にしないと置き換えメッセージを本文とコメントで別々に設定できないなぁ。
add_filterを使う前にあれこれしてあげればいいけど。

とりあえずこれでコメントも隠す事ができた。
しかし記事もコメントも見れないのに、コメント入力フォームが表示されているのはスマートじゃない。
なのでコメント入力フォームも隠す方法を考える。

単一記事（post）の閲覧制限

アクションフックにcomment_formなるものも用意されてはいるものの、どうも動かない、というかこれであってるのかすらよくわからないのだが。
なんかテーマによっては動かないよって事なので、ここは仕方なくコメント部分のテンプレートをいじろうかなと思い立つ。

けどよく考えてみると、記事単体を表示する際は本文とコメントとコメント入力フォームを隠すわけだから、単一記事の投稿テンプレートをいじってまとめて隠したほうがいいな。
さっきのフィルターで本文は隠れるようになっているので機能重複するけど、あれはトップページとかでも使えたりするんでまぁいいか。
というわけで記事単体のテンプレートを修正する。

今回俺のケースだとタイトルは別に表示してもかまわないので、使用してるテーマにもよるが、本文呼び出しのテンプレートタグ（the_content()）やコメントテンプレート呼び出しタグ（comments_template()）をラップしてるblock要素を丸ごとを、分岐で変更させる。

//single.php ヘッダー部分省略
  

  
    だめー
  


  
    //本文呼び出し
     //comments.php呼び出し
  


//single.php フッター部分省略

これでおｋ。
閲覧できない場合のメッセージや表示はもっと細かく書くなり、functions.phpのほうにおいたりも可能だが、書き出された際のhtmlに矛盾が無いようにする点だけ注意。

しかしこれ、functions.phpのように関数だけ集めてあるならともかく、テンプレートを直接いじってるのでカテゴリーIDを生で入れてるのが気になる。どう考えても変更の際面倒な事になる。
なので指定カテゴリーIDをfunctions.phpに格納し利用したいなー、と思い定数にでもするかと思ったが、カテゴリーが複数ある場合困るなぁ。
定数じゃ配列入れれないし、そもそも複数ある場合はカテゴリーIDだけひっぱってきても分岐部分の書き換えが必要になってしまう。
なのでfunctions.phpのほうでその辺を判別する処理を、グローバル変数を置くのも気が引けるんでもろもろclass化したり色々書き換え。

functions.php

//非表示カテゴリーに関連するクラス
class DivergenceView {
  var $hide_cat = array(3); //表示OKなカテゴリーIDの配列
  var $hide_mess = "この内容は今の権限では見れません！"; //非表示化した際置き換える文字列
  function lv() { //ユーザーレベルの確認結果を格納する
    global $user_level;
    return ( 0 != $user_level )?true:false;
  }
  function in_cat() { //現在表示中の場所が除外カテゴリーかをチェックし、非表示にする必要がないならtrueを返す
    if ( $this->lv() ) return true; //ユーザーレベルもチェック、閲覧制限のないユーザーなら何もせずtrue返す
    foreach ( $this->hide_cat as $k => $v ) {
      if ( in_category( $v ) ) return true;
    }
    return false;
  }
}

//コンテンツの非表示化
function op_hide_content( $content ) {
  $DView = new DivergenceView();
  if ( !$DView->in_cat() ) $content = $DView->hide_mess;
  return $content;
}
add_filter('the_content', 'op_hide_content');
add_filter('comment_text', 'op_hide_content');

single.php（逆にした）

//single.php ヘッダー部分省略
  
in_cat() ) { //体験中のユーザーではない、もしくは閲覧制限のかかっていないカテゴリーの場合
  
    //本文呼び出し
     //comments.php呼び出し
  

?>


  
    hide_mess; ?> //class内にある置換メッセージ表示

本当はフィルターで呼び出す関数もメソッド化したかったが、add_filterからメソッドを呼ぶ方法が分からなかったのでそのままに。

ページ（page）の閲覧制限

テンプレート自体は記事（post）と似たようなものなため基本的なやり方は同様だが、ページの場合はカテゴリーがないので別の判別方法が必要になる。
ページにもカテゴリーをつけるpluginとか昔あった気がするが、経験上こういうトリッキーな代物は後々大変になったりするんで、今回は素直にカスタムフィールドを利用する。

カスタムフィールドに、名前を“provisional”、値にtrueを入力し追加しておく。（勿論名前は英数字なら何でもい）
ここでtrueを値にしたのは、今後カスタムフィールドの拡張pluginを利用する場合、チェックボックスのみで公開非公開を選べるといいなぁという淡い期待からである。
これをページ描画の際に取得して振り分けを行う。

ページのテンプレートpage.phpの作りは、これもテーマによるが基本的に記事用のテンプレートと大差ないはずなので、ここでは条件の部分のみ。

//page.php ヘッダー部分省略



	
		hide_mess; ?>
	



	



//page.php フッター部分省略

カスタムフィールドの情報を取得するにはthe_meta()というテンプレートタグを利用すればいい、がこれそのまま使うとそのwordpressにあるカスタムフィールドをすべて、しかもご丁寧にリストで表示してくれちゃったりする。
これじゃ分岐には使えないので引数で取得する情報を指定する、出力じゃなく値で取得するにはいくつかの方法があるのだが、今回は今見てるページのカスタムフィールドが欲しいのでpost_IDを指定しなくて済むget_post_custom_values()を使う。
ここではget_post_custom_values("provisional")の部分。
さらに返り値は配列なので、key0を代入しなおしている。

さて、このままだと分岐がちゃんと行われるものの、先ほど作ったフィルターが全てのページの本文だけブロックしてしまう。ページはカテゴリーがないからね。
なのでフィルターに少し手を加える。

function op_hide_content( $content ) {
  $DView = new DivergenceView();
  if ( !$DView->in_cat() && !is_page() ) $content = $DView->hide_mess;
  return $content;
}

if文の条件に!is_page()を加えた、これによって今の表示がページではなく、の条件が加えられる。

さらに、pageテンプレート自体の修正を減らしたいのと、このカスタムフィールドからの判別は他でも使うため（後述）、これも先ほどのclassのメソッド化しておく。

class DivergenceView {
  var $hide_cat = array(3); //表示OKなカテゴリーIDの配列
  var $hide_mess = "この内容は今の権限では見れません！"; //非表示化した際置き換える文字列
  function lv() { //ユーザーレベルの確認結果を格納する
    global $user_level;
    return ( 0 != $user_level )?true:false;
  }
  function in_cat() { //現在表示中の場所が除外カテゴリーかをチェックし、非表示にする必要がないならtrueを返す
    if ( $this->lv() ) return true; //ユーザーレベルもチェック、閲覧制限のないユーザーなら何もせずtrue返す
    foreach ( $this->hide_cat as $k => $v ) {
      if ( in_category( $v ) ) return true;
    }
    return false;
  }
  function page_cf() { //ページのカスタムフィールドをチェックし表示すべきかを返す
    if ( $this->lv() ) return true; //ユーザーレベルもチェック、閲覧制限のないユーザーなら何もせずtrue返す
    $cfv = get_post_custom_values("provisional");//カスタムフィールドの値取得
    $cfv = $cfv[0];//配列なので代入しなおし
    return ( $cfv )?true:false;
  }
}

さらに先ほどのpage.phpテンプレートもあわせて変更。
ちなみに分岐内容に重複するタグがあるのでもっとコンパクトに出来るんだけど、視認性のためにそのままにしてる。
アホなんで次の日見ただけでもう忘れてる可能性がある。俺流のリスクヘッジ2009春。

//page.php ヘッダー部分省略
	
page_cf() ) {

?>

  




  
    hide_mess; ?>
  


//page.php フッター部分省略

これで、ページを作る際はカスタムフィールドを設定してあげれば『体験中の人にも公開するページ』、を簡単に作成する事が出来るようになった。
カスタムフィールド名を選択し、値にtrueと入力するだけの簡単なお仕事だが、これは技術的な話と無縁の人にはちょっと抵抗感のある作業だ。
しかし公開する内容を書く、しかも記事でなくページ、という作業を管理者になるであろう俺以外がやるケースはあまりなさそうなので、これでいくことに。
（本来はエディタにチェックボックスでも表示させて、チェックするかどうかだけで選択出来ると初心者でも抵抗ないんで、そのうちそんな感じのpluginを探す事に。どこかで見た気がする。）

アーカイブの閲覧制限

そもそも見る事の出来ない記事をアーカイブやトップに表示する必要はあまりない、にぎやかし的に「正式加入するとこんな記事が見れるのか～」という心理効果はありそうだけど。
というわけで次はトップページからそもそも閲覧権限のない記事を書き出さない方法を。
あれ、すると本文をフィルターで隠した意味がいよいよ無くなる気がするな…まぁいいか。

if (have_posts()) :
  while (have_posts()) : the_post();

こんな感じのループの開始部分を、以下のようにしてあげる。

if (have_posts()) :
  $DView = new DivergenceView(); //オブジェクト生成
  while (have_posts()) : the_post();
    if ( !$DView->in_cat() ) continue;

ユーザーレベルとカテゴリーをチェックし、そのループ回の記事が公開してはいけないものならcontinueでループを飛ばすだけ。
これを行うのは主にcategory.php・index.php・search.php・archive.php・tag.php等になる、勿論使用しているテーマの構成によって変わる場合はある。
これによってカテゴリー、トップページ、検索結果、月ごとの投稿、同じタグの付いた投稿などの一覧表示が最適化された事になる。

サイドバーの修正

これまたテーマによるが、多くのテーマでサイドバーが1つか2つほど採用されており、そこにはページ一覧やカテゴリー・タグ一覧・最近の記事10件、といった内容があったりする。
ここまでの作業でなるべく閲覧権限の無いものは目に触れないように手を加えてきたので、当然ここもやっておく。

ページ一覧

サイドバーにページの一覧を載せる場合、wp_list_pages()っていうテンプレートタグを使う場合が多いと思うので、これの修正方法。
ちなみにwordpress2.7からwp_page_menu()というテンプレートタグも追加されたが、上記タグと比較してホームへのリンクを追加できる点とulも書き出す、くらいしか差異が見つからない、よくわからないのでこっちは今回は考えない事に。
wp_list_pages()にはオプションでincludeパラメータがあり、これに表示したいページのIDを渡すと他を除外してくれるので、閲覧してもよいページのIDを全部調べて返すメソッドを先ほど作ったclassに追加する事にする。

class DivergenceView {
  var $hide_cat = array(3); //表示OKなカテゴリーIDの配列
  var $hide_mess = "この内容は今の権限では見れません！"; //非表示化した際置き換える文字列
  function lv() { //ユーザーレベルの確認結果を格納する
    global $user_level;
    return ( 0 != $user_level )?true:false;
  }
  function in_cat() { //現在表示中の場所が除外カテゴリーかをチェックし、非表示にする必要がないならtrueを返す
    if ( $this->lv() ) return true; //ユーザーレベルもチェック、閲覧制限のないユーザーなら何もせずtrue返す
    foreach ( $this->hide_cat as $k => $v ) {
      if ( in_category( $v ) ) return true;
    }
    return false;
  }
  function page_cf() { //ページのカスタムフィールドをチェックし表示すべきかを返す
    if ( $this->lv() ) return true; //ユーザーレベルもチェック、閲覧制限のないユーザーなら何もせずtrue返す
    $cfv = get_post_custom_values("provisional");//カスタムフィールドの値取得
    $cfv = $cfv[0];//配列なので代入しなおし
    return ( $cfv )?true:false;
  }
  function hide_page_lis() { //表示可能なページのみサイドバーなどのリストに表示する
    if ( $this->lv() ) return; //ユーザーレベルもチェック、閲覧制限のないユーザーなら何もせず返す
    $r = '&include=';
    $pages = get_pages(); //全ページの情報取得
    for ( $i = 0,$c = count( $pages ); $i < $c; ++$i ) { //取得したページの数だけループ
      $cfv = get_post_meta( $pages[$i]->ID, 'provisional', true ); //ページのIDを取得し、そのIDのページのカスタムフィールドの値を取得
      if ( $cfv ) $r .= $pages[$i]->ID . ","; //カスタムフィールドの値がtrueの場合、ページIDとカンマを連結
    }
    $r = substr( $r, 0, -1); //余分に付いたカンマを除去
    return $r;
  }
}

一番下に追加したhide_page_lis()がそれにあたる。
流れとしてはまずいつもどおり準備としてユーザーレベルをチェックし、返す値を格納する変数に“&include=”を先にいれる。
全ページの情報を取得したらループでまわし、get_post_meta()を利用してページのIDを指定しカスタムフィールドの値を取得する。
あとは取得した値がtrueならカンマを付けて格納変数に継ぎ足していき、ループ後に最後の余分なカンマを除去し返す。
これを利用するSidebar.phpの該当部分はこんなかんじ。


    ページ
    
      
hide_page_lis() ); ?>

これで閲覧制限のかかった記事は、サイドバーのページ一覧に顔を出さなくなる。
ところでメソッドのほうで全ページの情報取得、なんかしてるけどこれを格納した変数って開放しなくていいのかな…よくわからないんでやってないけど。

カテゴリー一覧

これを表示させるかが非常に迷う…。
たった一つのカテゴリーのみ閲覧可能なら、そもそも見れないカテゴリーばかり並ぶ一覧を表示する必要はない、と前提に立てれるなら単純にユーザーレベルでカテゴリー一覧の表示非表示を切り替えればいい。
ただ1つの投稿記事に複数のカテゴリーを付けれるので、決して閲覧可不可を決定するカテゴリー以外役に立たない訳でもない。
逆に体験者にとって体験者カテゴリー内の記事しか見れないのなら、体験者カテゴリーというもの自体が見えている必要がない。なにせ目に付く記事全部がそのカテゴリー内なわけだし、そもそもこのカテゴリーの役目が本来のものではなくむしろ管理制御用なのだから。
というわけで、体験者権限のみカテゴリーリストから体験者カテゴリーを取り除く形にする。
（カテゴリーが複雑にネストしだすと結構面倒な事になりそうだが、今回はそれは考慮外とした。）

カテゴリーの表示にはwp_list_categories()テンプレートタグが利用される。（たまにドロップダウンを使う所もあるが基本は同じ）
このテンプレートタグには指定・除外が出来るオプションがあるので、ページ一覧と同様に引数を作って渡してあげればいい。

functions.php

class DivergenceView {
  var $hide_cat = array(3); //表示OKなカテゴリーIDの配列
  var $hide_mess = "この内容は今の権限では見れません！"; //非表示化した際置き換える文字列
  function lv() { //ユーザーレベルの確認結果を格納する
    global $user_level;
    return ( 0 != $user_level )?true:false;
  }
  function in_cat() { //現在表示中の場所が除外カテゴリーかをチェックし、非表示にする必要がないならtrueを返す
    if ( $this->lv() ) return true; //ユーザーレベルもチェック、閲覧制限のないユーザーなら何もせずtrue返す
    foreach ( $this->hide_cat as $k => $v ) {
      if ( in_category( $v ) ) return true;
    }
    return false;
  }
  function page_cf() { //ページのカスタムフィールドをチェックし表示すべきかを返す
    if ( $this->lv() ) return true; //ユーザーレベルもチェック、閲覧制限のないユーザーなら何もせずtrue返す
    $cfv = get_post_custom_values("provisional");//カスタムフィールドの値取得
    $cfv = $cfv[0];//配列なので代入しなおし
    return ( $cfv )?true:false;
  }
  function hide_page_lis() { //表示可能なページのみサイドバーなどのリストに表示する
    if ( $this->lv() ) return; //ユーザーレベルもチェック、閲覧制限のないユーザーなら何もせず返す
    $r = '&include=';
    $pages = get_pages(); //全ページの情報取得
    for ( $i = 0,$c = count( $pages ); $i < $c; ++$i ) { //取得したページの数だけループ
      $cfv = get_post_meta( $pages[$i]->ID, 'provisional', true ); //ページのIDを取得し、そのIDのページのカスタムフィールドの値を取得
      if ( $cfv ) $r .= $pages[$i]->ID . ","; //カスタムフィールドの値がtrueの場合、ページIDとカンマを連結
    }
    $r = substr( $r, 0, -1); //余分に付いたカンマを除去
    return $r;
  }
  function hide_cats_lis() {
    if ( $this->lv() ) return; //ユーザーレベルもチェック、閲覧制限のないユーザーなら何もせず返す
    $r = '&exclude=';
    foreach ( $this->hide_cat as $k => $v ) $r .= $v . ',';
    $r = substr( $r, 0, -1); //余分に付いたカンマを除去
    return $r
  }
}

sidebar.php

Categories

  
hide_cats_lis() ); ?>

やってる事はページ一覧と大差ない。
classが長大になってきたな…大差ない事やってるならもう少しメソッドを抽象化できりゃいいんだけどうーん。

feedの閲覧制限

feedへのリンクやheadタグ内のメタタグは分岐してやりゃいいだけなのですぐ終わる。
分岐させて非表示にした所でfeedは存在するという点で、画像への直アクセスに似ているが、これは対処可能だった。

参考：wordpressで非公開コミュニティサイトを作る（1）認証機能をつける – atl*weblog

上記記事内ではheader.phpに直接処理を書いていたが、その後偶然send_headersというアクションフックがある事を知った。
このフックを利用する事で、header.phpに直接かかなくて済む上に、feedへのアクセスにもログインが必要になる。

function op_auth() {
  if ( !is_user_logged_in() ) auth_redirect();
}
add_action('send_headers', 'op_auth');

これをfunction.phpにでも書いておけばOK。
ちなみにこの方法でも画像への直アクセスは防げないので注意。

とりあえずここまでやったが、大事な問題がある。
このfeed、権限があるとして、どうやって見るのって話なのだｗ
…wordpressのログイン管理は当然cookieを利用してるんで、普通に考えたらcookieを利用出来ないfeedreaderじゃ見れないよなぁ。
今後解決策を考えていくけど、場合によってはタイトルと概要のみのfeedを認証が必要ない状態で吐き出すとか、妥協案も考える必要がありそうな雰囲気。
BASIC認証みたくhttp://username:password@example.com/feed/とか、こんな感じの方法ないかなぁ、なんか難しそうで解決しなそうな雰囲気を感じるな…；；

記事単位での所属カテゴリー表示の加工

もーないよな！と思いつつ色々見てたら、記事ごとにその記事がどのカテゴリーに属するかを表示するカテゴリー一覧があったんだった。
別に記事がどのカテゴリーのものかを表示する事自体はいいのだが、さっきサイドバーのカテゴリー一覧で体験用カテゴリー表示のみ消したのと同様に、こちらも消しておかないといけないだろう。
しょうがない、やるか！

記事ごとの所属カテゴリー表示はテンプレートタグthe_category()を利用する、引数にはセパレートを指定できる。
この所属カテゴリー表示は記事単体表示のみならず、トップページやらアーカイブ系やら、ループでいくつも記事を表示する際にも必ず出てくる。
なのでテンプレートを直接いじるのではなく、functions.phpに処理を書いてフィルターする事に。

the_categoryというフィルターフックを使う事で、テンプレートタグthe_category()が吐き出すhtmlを表示する前に受け取って加工できる。
これを利用してこんな感じで書いてみた。

function cat_fill( $htm ){
  $DView = new DivergenceView();
  if ( $DView->lv() ) return $htm; //ユーザーレベルもチェック、閲覧制限のないユーザーなら何もせず返す

  $r = "";
  $sp = "\|"; //セパレート
  $lis = split( $sp, $htm ); //セパレートで分割し配列に格納
  for ( $i = 0,$l = count($lis); $i < $l; ++$i ) {
    $FLG = true;
    //urlのパラメータの位置を探し、文字分を足した位置から後を切り出す
    $p = substr( $lis[$i], strpos( $lis[$i], "?cat=") + 5);

    //切り出した文字列の頭からurl終りの位置までを格納（カテゴリーID）
    $p = substr( $p, 0, strpos( $p, "\"") );

    foreach ( $DView->hide_cat as $k => $v ) { //取り出したカテゴリーIDが閲覧禁止かチェック
      if ( $p == $v ) $FLG = false;
    }

    $r .= $FLG?$lis[$i].$sp:"";

  }
  if ( strpos( $r, $sp ) ) $r = substr( $r, 0, -4); //カテゴリーが1つしかない場合、セパレート除去

  $htm = $r;
  return $htm;
}
add_filter('the_category', 'cat_fill');

フィルターから呼び出す関数の処理の流れは以下。

関数スタート、引数$htmはテンプレートタグthe_category()が書き出すはずだったhtml
オブジェクトを生成しユーザーレベルチェック、制限かからない権限だった場合そのまま返して終了
各変数初期化、$rは一時格納、$spはセパレート、$lisには引数で渡されたhtmlをセパレートで分割し配列を格納
$lisの配列をループ回し、始めにフラグ
html内のurlのパラメータから後ろを切り出す（urlのカテゴリーIDの前部分を切捨て）
切り出した文字列頭からurlの最後までを切り出す（カテゴリーIDから後ろ部分を切捨て）
こうやって取り出したカテゴリーIDが閲覧制限のあるものかをチェック
問題なければ格納変数$rに文字列連結
ループ終了、複数項目があった場合、ケツに余計なセパレートが付いてるはずなんで切り捨て
いじくりまわしたhtmlを返す（引数と同じ名前じゃないとダメだった気がして入れなおしてる、記憶おぼろげ）

絶対もっとうまい方法があった気がする…カテゴリーIDは正規表現で取り出せるだろ、とかｗ
文字列いじりをするって個人的に最終手段というか、大概の場合悪手で他にいい手があったりするイメージなので気が引けるが、functions.phpのほうだけで済んだからまぁいいか。
（アクセス数が多い場合はちゃんと効率のいい方法でやらないときっとサーバに負担かかるんだと推測）

wordpressで非公開コミュニティサイトを作る（2）ユーザーレベルで表示内容を変更+plugin“Category Access”

daruman — Sun, 19 Apr 2009 22:30:38 +0000

認証は出来たので、今度はログインしたユーザーの権限をあらわすユーザーレベルで表示を変えたり、見る権限がない記事を表示しようとした場合は別のページへ飛ばす方法を探っていく。

wordpress界（？）ではWordBenchという立派なソーシャルコミュニティが出来たらしく話題になっているが、残念ながらあそこまで立派なものはちょっと難しそうだし、そもそもwordpressではなくwordpressMUを使っていたり、一人一人のblogまで必要じゃないんでとりあえずこのままwordpressをベースとして考えていく。

WordBench

通常ユーザーによって見せる見せないをwordpressで選択する場合、記事投稿時にパスをつけたり非公開設定をつけたりという事はデフォルトの機能として備わっている。
今回もそれを使えばこんな面倒な事をする必要はないのだが、下記理由によりその手が使いにくい。

wordpressになれて無い（かつ面倒事が嫌いな）ユーザーも記事投稿を行うため、記事書くたびに非公開やパス設定させるのに無理がある
体験中の人でも見れる記事・ページのほうが更新頻度が少なく、公開範囲の狭いほうをデフォルトとしたい

といった諸般の事情から、基本的な流れとしては全部の記事を見る権限の無いユーザーがログインしたら、そのユーザーレベル専用のフロントページへ飛ばす、見る権限の無い記事へ飛んだらフロントページへ戻す、サイドバーなり検索結果等で見る権限のない記事は非表示もしくは本文が見れないような感じでいこうかなと画策。

二つの対処法

上記の条件を満たすために、pluginによる制限とphpであれこれやるという二つの方法で対応していこうと考える。
最初は全てphpをいじってやろうと思っていたし、後々の事を考えるとそのほうが安全なのだが、これが俺程度のスキルではちょっと難しく、数日ハマった後pluginで出来る事はやってもらおうという方針に変更。
偶然ちょうど目的に合ったpluginを見つけたというのも大きいが。

カテゴリー単位で閲覧制限をかけれるplugin “Category Access”

で、そのpluginがCategory Access。

試したwordpressのヴァージョン: 2.7.1
試したヴァージョン: 0.8.2
対応するwordpressの最新バージョン表記: 2.3.X, and not prior versions
auther page: David Coppit’s Code Page

wordpressといえば、という事でこちらから情報ゲット。
Category Access – わーどぷれすっ！

分かりにくいのだが、Code Pageってところにこの開発者の作ったpluginとかがあれこれ置いてあるんで、下のほうにあるCategory Access 0.8.2ってリンクからDLする。
後はwordpressのpluginのインストール項目からDLしたzipを選択すればOK。

このpluginは公式Plugin Directoryにも登録されてないし、まして最終更新日が2007年と、まず動かねーだろうなぁと思っていたが、多少怪しい部分はあれどすんなり動いた。
今後wordpressの大幅なアップデートに際しても動き続けれるかは不安だが、2.3時代から2.5、2.7と乗り気って動いている事になるので、案外いけるんじゃないかなと思っている。（ソースを見ろと言う話）
最悪動かなくなってもこのpluginのソースを参考に自力で作り直すという荒業も残っている、実力不足で不安だが今の時点で動くお手本があるのは心強い。

なんていう話はともかくpluginについて。
このpluginはアクティブにするとwordpressの管理画面の設定に専用のオプションページ、さらに各ユーザーページの下部に幾つかの項目を追加する。

管理画面

Category Access for:: New UsersとAnonymous Usersの二種から選択。
Anonymous Usersはログインしていないユーザーを意味する、これの用法はシンプル。
今回俺が使うのはログインしたユーザーの権限で見れる範囲を指定なので、今回はNew Usersを選択。
実はNew Usersが何を表すかよくわからないのだが、恐らくはユーザーを新規登録した際、デフォルトで割り振られる権限の事なんだと思う。（詳細後述）
その下に幾つか出ているだろうチェックボックスは現在存在するカテゴリーにあたり、チェックを入れたカテゴリーは公開してもOK、という感じ。
Check all categoriesボタン・Uncheck all categoriesボタン: 上に表示されるカテゴリーを全てチェックする・全てのチェックを外すボタン。カテゴリー数がやたら多い場合に使えるかもしれない。

Protected Posts in the Blog

blogの閲覧制限の設定

Hide entire post.: 閲覧限定されたユーザーから、記事のタイトル・本文・コメント本文を隠す。ただし公開用カテゴリーアーカイブページでの“最新の投稿”等では非公開カテゴリー記事のタイトルが表示されてしまう。テーマの作り方次第でどうにかなるとは思う。
Show title, but a private message for the body text.: 閲覧限定されたユーザーから、記事のタイトルのみを表示し、本文・コメント本文を隠す。本文の代わりに指定したメッセージ（private post message）を表示することも出来る。
Show a private message for the title and nothing for the body text.: 閲覧限定されたユーザーから、記事のタイトル・本文・コメント本文を隠し、タイトルの代わりに指定したメッセージ（private post message）を表示する。表示出来ない記事を開くとタイトルの他に同じく指定メッセージが妙な位置に配置される。
The private post message:: 上記選択肢で三項目目を選んだ際、タイトルの代わりに表示させるメッセージを入力する
Show a padlock icon on the private post message.: private post messageを表示する際、南京錠のアイコンを表示する
Consider a message to be visible if the user can view any of its categories (rather than all of its categories).: このチェックボックスをONにすると、1つの記事が複数のカテゴリーに属する場合、そのうち1つでも公開OKなカテゴリーが含まれていれば公開する。

Protected Posts in Feeds

フィードの閲覧制限の設定

Show the title and links (but not the summary or content) instead of hiding posts.: 非公開の投稿を隠す代わりに、タイトルとリンクのみ表示させる。
これはcookieによるログイン判別をしているので、cookieを読み取らないfeed reader等を制限する事が難しいため、ならfeedのタイトルとリンクは隠さずに吐き出して、アクセスしてきたら閲覧制限がかかるよ、的な手なんだと思う。なので基本はチェックを入れておく。

The Category List

閲覧許可をしていないカテゴリーを表示するかとか、表示出来ないカテゴリーに南京錠のアイコンを表示するか、といった選択肢なのだが、これは働いてなく、チェックを入れてアクセスするとエラーか何かが出て表示されなくなってしまう。
ちなみに表示されるメッセージは以下の通り。

Unknown column 'wp_term_relationships.term_taxonomy_id.term_taxonomy_id' in 'where clause'

内容からいって、このpluginが作られた当時とDBの構成が変わっているため、わからんカラムが存在するよとか、そういう事なのかな。

下の2つのボタン

特筆する必要もない、設定更新とリセットボタン。
なんだけど、似たような位置に配置されているんで、クセで設定変更したあと一番したのボタン…を押すと見事にリセットがかかったりする。

ユーザーページ

Category Accessという項目が各ユーザーページの項目に表示される。ちなみに管理者のユーザーページには表示されない。

ここには現存するカテゴリーとcheck all、uncheck allのボタンがある。ここで個別ユーザーごとに公開範囲を指定する事が出来る。

実際の動作

New Usersでユーザーを新規登録すると、設定をいじってなければ通常権限は購読者になる。
この状態だと当然デフォの設定のまま、指定したカテゴリーの記事しか閲覧する事が出来ない。
当初New Usersとはこのデフォルトで割り振られる権限の事だと思っていた。
ところがこの新規登録したユーザーの権限を購読者の上の投稿者にしても、さらにその上の作成者にしても閲覧制限がかかったままなのだ。
その上の編集者にしてやっとAs a category manager, this user can view all categories.というメッセージがユーザーページのカテゴリー選択部分に表示され、全カテゴリーを閲覧できる状態になった。（勿論管理者権限になれば当然全部観れる）
そして編集者権限から下に再度変更すると、カテゴリーのチェックボックスが復活するのだが、このチェックが全て外れているのだ！
つまり常にではないものの、このpluginを使用した状態で権限をいじる場合には個別の手直しを前提で使う必要がある事になる。
権限を上下に頻繁に変更する事は俺の今回の想定利用環境ではありえないが、ちょっとこれは面倒な気がしてしまう。
カテゴリーが大量にあって、細かく分類している場合なんかは結構しんどそう。

なので、このpluginは複雑大量のカテゴリーをユーザーごとに細かく閲覧設定したい、みたいなヘビーなユーザー管理には向かない。
今回の俺の用途のように、低い権限だとこのカテゴリーしか見れないよ、程度なら耐えれる程度のものだろう。（古いしね）

自力で権限・ユーザーレベルで振り分け

さて上記pluginを利用すれば記事（post）の保護は出来る、けどページにはカテゴリーが無いためpluginではどうこう出来ない。
さらにトップページなりサイドバーなりで閲覧出来ないんだから本来見える必要もない項目も出てくる。（カテゴリー1つ分しか閲覧許可出さない場合、カテゴリーリストを表示する部分は不要、だとか）
アクセス時に最初に飛ばしたい、体験者用ページなんかも作るかもしれないし、既に説明したとおり、ちょっとpluginが不安定なんで今後の事も考えると、やっぱり自力で振り分けする方法も把握して、部分的にでも使っていく必要がありそう。

ユーザーレベルを取得する

これをするには当然、今ログインして見てる人の権限を取得しないといけない。

権限っていうとwordpressの管理画面で言う管理者とか編集者とかの事なんだけど、実は内部処理的には0～10の11段階のユーザーレベルってのが設定されていて、こっちを使って判別する。
ちなみに管理者はユーザーレベル10、閲覧者はユーザーレベル0、と内部で振られていて、数字が上がるほど権限が増える感じぽい。（ここで言う権限は使う事が出来るwordpressの機能、設定の数や種類の事）

で、見てる人のユーザー情報を取得するにはglobal $user_levelとするだけで取得できる。

実際に振り分けてみる

仮に管理者をユーザーレベル10、一般メンバーを編集者とするとユーザーレベル7、で体験中のメンバーを閲覧者でユーザーレベル0と設定する。（デフォなんで設定する必要ないんだけど）
このケースで閲覧者とその他、で処理を分けたい場合こんな風にすればいいっぽい。

 0 ) {

//正式メンバーの人用の処理

} else {

//体験中のメンバーの人用の処理

}
?>

あら簡単。
これで例えば体験中の人にはサイドバーのこの項目は表示させなくていいな、とかそういう事がテーマ内で出来るようになるね！

トップページを変えたい場合のやり方

トップページを体験用と一般用に分けたい場合のやり方もついでにメモっておく。
と言っても既にユーザーレベルで分岐できているんで終わったようなものなのだが。

header.phpの一番上に以下のコードを挿入すればいい。

global $user_level;
if ( is_home() && $user_level == 0 ) {
        wp_redirect( get_option('siteurl') . '飛ばし先のパス' );
}

頑張ってheader送信しようとあれこれやってたんだけど、んもう全然出来なくて半泣きであれこれ調べてたらwp_redirect()なんていう関数を発見したのだったりする。

Function Reference/wp redirect « WordPress Codex

Redirects the user to a specified absolute URI.とあるように、絶対URIで書く必要があるようだ。

という事で、前回のアクセス制限のコードとあわせてheaderの頭に以下のコードを突っ込む事になる。

';
?>

関数化されているとはいえリダイレクトには変わらないようなので、echoより先に。

後は飛び先となるページを作り、それ用のテンプレートを用意すればいい。

wordpressで非公開コミュニティサイトを作る（1）認証機能をつける

daruman — Wed, 15 Apr 2009 19:13:18 +0000

wordpressを使い会員のみのコミュニティサイトを作るべく、それに必要そうな部分をメモがてら。
まずは一番肝要な、認証制度から。

まえおき

長い事やっているMMORPGの仲間内用のサイトをリニュするタイミングがあったので、wordpressで構築してみようかなと。
一度チャレンジしてほぼ完成まで持っていったものの、wordpress自体のバージョンがすでに0.2ほどアップしてしまい、汎用性のあるように作れてなかったために半お蔵入りになった過去を踏まえ、もう一度チャレンジする事に。
今回は以前の反省を踏まえ、基本機能のみ完成した時点で速攻公開し使ってもらう（とはいえここで公開はしないが）、後でwordpressアップデートや機能拡張に対応できるようなつくりを意識する、この二点を意識しておく。（手馴れた人なら当たり前なんだろうけど、前回始めてwordpress使ったので何も考えてなかった）

んでまずは基本であるユーザー認証をつける事になる。
認証周りに関する条件はユーザー管理関係も含めて以下。

ユーザー登録は全部俺がやる
大まかに管理者、一般、体験中、の三段階の権限構成
管理者は俺なので全権限onで特に何も無し
一般は記事作成とかは出来るけどwordpress自体の設定は出来ない
体験中は体験中の人専用のコンテンツしか見れない
注意すべきは体験中専用とは、記事は書けるけど編集出来ない、ではなく、それ用のページしか見れない、つまり権限判別で振り分けする

こんな感じかな。
ポイントは体験中の扱いで、書いたとおり権限、無いしユーザーレベル（後述）による振り分けを行うのが少し面倒。
けどこうしないとwordpressでユーザーアカウントの一元管理が出来ないので面倒ってのと、wordpress側で記事やページ作成して体験中の人に公開すべきかどうかを判別するだけで記事内容のコピペとか無駄手間を減らしたい、という理由から。

余談だがなんだよ“体験中”って、と感じる人が大半だと思うが、なにぶん使用想定環境がMMORPGの仲間内用なので、いわゆるギルドとかゲームによってはクラン？、この手の集団に一時的に加入して正式加入するかを判断する時期の事だったりする。
ゲームごときに認証ｗｗｗｗｗというのはもっともな話だけど、ゲームだけに妬み嫉み荒らし秘密情報だとかあれこれあったりするのだ。

.htaccessでBASIC認証も作れないのださ～ぃ！

ユーザー管理に関してwordpressを知らないけど俺よりプログラムとか詳しい人に言うと、.htaccessつくりゃすぐじゃん的回答があるのだが、wordpressでの.htaccessによるBASICとかの認証は、不可能ではないにせよちょっとむずかしいようだ。

未定… – WordPress の .htaccess 書き換えを止めたい (前置き) , WordPress の .htaccess 書き換えを止めたい (改変内容) , 最近

つまるところ、wordpressが.htaccessを自動生成・書き換えをしているという話だ。
この方法だとwordpress本体のプログラムの書き換えが発生する、つまりwordpress自体のアップデートのたびに書き直すハメになる可能性が出る。
これは面倒なので別の方法でいく。

pluginで何かねーの？

検索すると結構hitするように、以前はこれを使っていた。

Angsuman’s Authenticated WordPress Plugin – Password Protection for Your WordPress Blog

んだけどすでに更新されておらず（有料版にサポートが移行したのか、標準で関数実装したからなのかわからないが）、以前使っていたwp2.5時代ですら結構な書き換えが必要だった事から、今回はさすがに無しで。

他にも認証周りのpluginは結構ありそうなのだが、特定権限のユーザーのみあれこれ変えるという特殊な目的があるので、今回はpluginの利用は見送る事に。
普通に認証だけできりゃいいよって人はPlugin DirectoryでAuthenticationとかで検索すれば色々出ると思う、ちなみにplugin検索精度がこないだやっとマトモになったので助かる。

WordPress › WordPress Plugins

ログインしてないと閲覧出来ないようにするには

じゃ本題へ。

wordpressでのログインというと普通にblogを使用している人にとっては、記事を書いたりする管理画面に行くためにはパスが必要でそれがログイン、だと思う。
間違ってないんだけど、wordpress的には上記のログイン動作をしないでblogを見ている状態と、ログインしてから管理画面からblogに戻って見ている状態では、見た目には同じでもちゃんと区別をつけている。
この感覚が最初wordpressをいじりだした時は分かりにくかったが（主にloginを意識させないテーマが多いせいで）、ログインした状態じゃないと見れない記事を書いたり（非公開記事）、以前書いたログインした状態ではGoogle Analyticsにトラッキングさせないpluginだとか、あれこれあるんで、こーゆーの使い出すとつかめてくる。

参考：Google Analyticsの勉強メモ(9) Wordpress pluginの検討 – atl*weblog

で、今回やる認証ってのはこのログインをしてないとblogが見れないようにする。
具体的な遷移は、blog自体のトップページだろうが記事単体だろうがどこのアドレスに移動しようとしても、まずログイン画面に飛ばされて、ログインしたら見れるようになる、というよくある流れ。
そのやり方はめちゃ簡単でauth_redirect()って専用の関数があった。

Function Reference/auth redirect « WordPress Codex

こんなの昔からあったっけかなぁ、なんだよ簡単すぎんじゃん。

実際の使い方はis_user_logged_in()っていう、ログインしてるかどうか確認する関数と一緒に利用して

こんな感じで書くと、ログインしてない場合はログイン画面に飛ばされるようになる、これをテンプレートのheader.phpの最初のほうにでも書いてあげるといいと思う。
なんか調べてるとwp-blog-header.phpっていうファイルに書いている人もいるようなんだけど、これだと確かに楽なんだけどwordpress本体のプログラム部分だから、やっぱwordpressのアップロードとかあった時消えちゃう可能性あると思うんだけどどーなんだろ。

テンプレート構成で、header.phpを読み込まない部分があるなら別だけど、普通記事だろうがページだろうがheader.phpは読み込むと思うんで、header.phpでいいんじゃないかなぁ、自信ないけど。

と思ったら、画像直リンとかってケースもあるんだった。
うーんどうしたもんかな。

とりあえずwp-blog-header.phpに記述する方法を試してみたら…あれ？画像そのまま出んじゃん。
てことは画像直リンは別の方法で対策する必要がある、そしてwp-blog-header.phpに書こうがheader.phpに書こうがかわらなそうだなぁ。
画像以外でheader.phpに書かれてるんじゃ防げないアクセスってなんだろうなぁ、思いつかないしそこまで完全にアクセス禁止する事もないんでいいか。
どうしてもマズいなら.htaccess書けばなんとかなりそうだし。