BuddyPressがロンチ: Web上のSNSの数が今の数千倍になる!?（きっといつかは）TechCrunch Japan (2009/5/1)

「BuddyPress」はWordPress MU用のプラグインで、簡単に言えばWordPressでSNSみたいなのが構築できます。自分もまだ使い込んでいません。実際に稼働している様子を見たい方（使いたい方）に最適なサイトがあります。WordPressのローカルコミュニティ「WordBench」です。どぞ。

さて。明日は白衣を着て「博士」になります。首にヘッドホンかけて…意味不明だっ

結論から書くと、auth_redirectを使う時は下記のように書きます。

どうやらこれはバグの様子？本家のサポートフォーラムで見つけました。コードはまだ見てませんが。

最初、単純にテンプレートにauth_redirect(); とだけ書き込んだところ、ログインしても再度ログインを促されるという状態に。
それでググって上記の方法で解決。

—

auth_redirectという関数は、WordPressで会員制サイトをつくる時に便利です。テンプレートにこの関数の記述があると、ログイン状態を見て、もしログインしていない場合は、ログイン画面に誘導され、ログイン後にリクエストページへ自動的にリダイレクトされます。この機能によって、会員制サイトの構築が容易になります。

今回、工務店のウェブサイト制作において、施主専用ページをつくるのに使いました。お施主様にID/PASSを発行して、工事の進捗状況を見てもらえるようにするためのページ。他にもアイディア次第でいろいろできると思います。

ちなみにこれはMovableType でも可能ですが、262,500円のプラグインが必要な様子。まぁ商用なら普通そうなりますよね。むしろWordPressが無償で使えるのがスゴイことで…しっかり寄付なり何なりしないとバチ当たるかも＞＜

※WordPress本体、テーマ、プラグイン全般に言えることですが、”実質的に”無料で使えてしまう代わりに誰も保証はしてくれない…トラブルが起きても自力で何とかしなければならないので、ビジネスユーザーは常に”もしもトラブルが起こった”時のことも考えていないといけないですね。WPが無料で使えるからって制作費もバカ安で提供してるとどこかで自分の首締めることになると思いますのでご注意ください。単純にMTは金が掛かる＆WPは”無料”と考えるとしたら、それは間違いです。

それでいきおい、この「WordPressカスタマイズメモ」もシックスコアへ移転させました。そしたらこちらはDNSの切り替え10分程！　ついでにオープン告知サイト【リニュース】はコアサーバーに移転させましたが、こちらは朝になってもまだ稼働しておらず…迷子状態。。まぁ大してアクセスのないサイトなのですが。

シックスコア、速いです

• PHPを高速化するeAcceleratorが標準でセットアップずみ
• 高スペックサーバ：Xeon L5410 ( 2.33GHz )、メモリ12GB
• PHP 5.1.6 /MySQL 5.0.22
• バックボーンが増えた：128G　→　166G
• まだまだ空いてる（かも）

こんなような理由からか、体感できるほど速いです。エックスサーバーのsv69よりは２倍以上は確実に速い感触。その後、WP Cache、WP Super Cacheも入れましたが、それ以上に効果がある（今はWP Cacheのみ）。

サーバ情報はこちらから↓
マルチドメイン対応、ビジネス仕様 高性能レンタルサーバー 【シックスコア】

 無料求人サイト【シゴトの森】について

２年以上前にとりあえずつくって放置していたら、ポツポツと投稿が入り始めて、今では毎日複数の投稿とそれなりのアクセスをいただいています。WordPressの2.0.xでつくられたレガシーなサイトです。まだあまりWordPressのことを熟知してない頃につくったので、コードの書き方などずいぶん遠回りなことをしています。（get_post_metaというタグすら知らなかった！）

しかし、求人専用に特化した投稿画面を用意したり、複数カテゴリでの絞り込み検索を実装したりと、つくりは雑ですがそれなりの布石を打ったサイトです。カテゴリ絞り込み検索機能は現在では「FE Advanced Search」として単体で販売しております（テンプレートへの実装も含めたカスタマイズ代行業務）。

見た目がアレなことと、ユーザービリティは良いとは言えないので（特に投稿画面）、リニューアルに取りかかったのはすでに１年以上前。しかし自社サイトということで、業務に忙殺されていまだにリニューアル完了しておりません（現状のままでもそれなりに活用されている様子なので甘えている）。

早くリニューアルを終えて、「WordPressでここまでできるのかあ！」と言われるぐらいに仕上げたい＞＜

解説）
Canonical URL links Yoast (2009/2/12)

ダウンロード）
Canonical URL’s for WordPress 

CMSでつくられたウェブサイトでは起こりがちなコンテンツの重複や、ページ分割されることによってブックマークされるURLがバラついたりするのをなくすことができるようになります。たぶん。301リダイレクトとして扱われるのでPageRankも引き継げる。これによって検索エンジンも効率よくインデックスできるし、サイト運営者もおそらくSEO上の恩恵を得られる。

—

参考サイト）
サイト内の重複コンテンツを防ぐ新たな手段、rel=”canonical”が登場  F.Ko-Jiの「一秒後は未来」(2009/2/13)

まずはWordPress ME 2.0.x で過去にエックスサーバー上に構築してあった、あるサイトをシックスコアに引っ越すために、現状のまま丸ごとコピーして試してみたところ、見事に文字化け。

それで、当然php.iniの mbstring.internal_encoding などの値などを見てみるとEUC-JPだったのでUTF-8に変更したが、まだ化けている。

インポートした時に文字化けしたかと思ったが、DBを眺めてみてもキレイそのもの。

今更ながら「WordPress 2.0 文字化け」みたいな検索をしたら「WordPress ME 2.0.11-2 リリースしました」のYurikoさんのコメントにヒントがあった（ヒントというかそのまま）。SET NAMES utf8 をwp-db.php に追加したら文字化けは直りました。

■対象ファイル：

wp-includes/wp-db.php

■修正内容：

57〜58行目、$this->select($dbname); の手前の行に、

を追加。以上 。

以前、エックスサーバーで文字化けした時に試したことがある方法ですね。その時は文字化けとは無関係でしたが、今になって役に立ちました。

サーバの情報はこちら↓
マルチドメイン対応、ビジネス仕様 高性能レンタルサーバー 【シックスコア】

# eAccelerator が標準でセットアップされています。「PHP高速化」の正体。

なぜ悩むかといえば、サーバによってSSLディレクトリにコンテンツを置かなくてもSSL通信ができるサーバ / できないサーバがあるからだ。

例えば、よく使う「エックスサーバー」ではSSL用のディレクトリが用意されているが、そこにコンテンツがなくても、public_htmlフォルダ内のコンテンツでSSL通信ができる。一方、最近触った「ファーストサーバー｜ウルトラビジネス２」では、SSLディレクトリにコンテンツがないとSSL通信できない。たしか、以前触った「C’S SERVER Personal」も同様。

もっと具体的に言えば、WordPressの”ページ”機能で作成した “お問い合わせフォーム” から入力された個人情報をSSLで暗号化して送信したい。その時に有効なプラグインが「Admin SSL」だが、ファーストサーバーの場合 https でアクセスするとSSLディレクトリを読みにいってしまい、そこにはWordPressのセットがないので「Not Found」になってしまうのだ。これは当然な結果に見える。

しかしエックスサーバーの場合、(共有SSLではあるが) Admin SSLがうまく働いてログイン画面などでSSL通信できる。SSLディレクトリは空であり、かわりにpublic_html内に置いたWordPressのログイン画面がロードされる。（Admin SSLの仕様で、お問い合わせフォームなどAdmin以外のページは独自SSLでないとSSL化できない）

また、静的なHTMLファイルでも(つまりAdmin SSLに頼らなくても)、エックスサーバーではpublic_htmlフォルダのコンテンツでSSL通信できている。

それで、少しGoogleで調べてみて分かったこと、思ったことは、

1. Apacheウェブサーバの設定ファイルであるhttpd.confだけでなく、ssl.confという設定ファイルもあり、そこにSSLのドキュメントルート(Document Root)が記述されている。
2. そのドキュメントルートをhttpd.confのそれと同じにすればうまくいくのではないか。
3. そのドキュメントルートの設定が、レンタルサーバによって様々なのではないか？

このことは、次に試した手順で確信に変わった。別途試用している「使えるねっと｜LinuxVPS｜シルバー」の管理パネル「Plesk」を触っていて、決定的なパラメータを見つけた！

Plesk Control Panel のSSL設定

赤枠で囲った箇所、
「SSL認証を受けないコンテンツと同じディレクトリに、SSL認証を受けるコンテンツを設置する」
このチェックをオン/オフしてみたところ、見事に想像したどおりの動作となった。

• チェックを付ける　→ public_htmlに置いたWordPressのお問い合わせフォームをSSL化できる！
• チェックを外す　→ SSLディレクトリを読みにいってしまい、 Not Found 

SSL通信する際にSSLディレクトリに限定したほうがセキュリティは高いのだろうか…(感覚的にはそう思える)。しかし、少なくともWordPressで作成したお問い合わせフォームをSSLで暗号化する場合は、public_htmlディレクトリでもSSL通信できる設定でないと現実的ではない。

現実的ではない、とはつまりお問い合わせフォームをSSL化するためにいずれかの対応が別途必要になる。

• メール送信スクリプトを別途用意して、SSLディレクトリに設置する
• SSLディレクトリにpublic_htmlディレクトリに設置したWordPressと同じセットを置いてSSL接続の”受け皿”にする

こういうことが必要になり、せっかくWordPressでCMSを構築しても片手落ちである。例えば「 My Category Order 」というプラグインがあれば、クライアントの担当者自らサイドバーのカテゴリの並び順を変えられてかなり好評だが、SSLディレクトリに設置したお問い合わせフォームのサイドバーは手作業で編集しなけらばならない（デザインをWP側と統一するならば）。またWordPressのセットをSSLディレクトリに複製すれば上記の手間はなくなるが、セットを２つ管理するというのもスマートじゃないし弊害があるかもしれない。

このようなことから、WordPressでウェブサイト/企業サイト/CMSを構築する際に選ぶサーバのポイントが新たに１つ加わった。

「public_htmlでもSSL通信できるサーバ」

このようなサーバなら、お問い合わせフォームをWordPressで作成・管理しつつSSL対応できる。そしてそれを実現してくれるサーバ選択のわかりやすいポイントは「Plesk Control Panelを備えたVPSサーバ/専用サーバ」である(笑)…上でテストしたとおり。しかしVPSの安いプランは自由度が高いかわりにメモリが少なかったり、性能面では注意が必要。例えば上で紹介した「使えるねっと…シルバー」はメモリが512MBである。レスポンスも良いとは言えない。

共有レンタルサーバーの場合、SSLがpublic_htmlで使えるかどうかなんてことはWebには書いてないと思うので、個別に確認する必要があるでしょう。

もちろん自前サーバならどうにでもなる。自分でPleskをインストールしてもいいしssl.confを見つけて触ればよいでしょう…あ、ssl.confのDocument Rootかどうかは検証できていないけど。。。

—

以上、今日確認したばかりの内容で、間違い・誤解・勘違いがある可能性もありますが、もし気付かれた方はご指摘くだされば幸いです。

参考サイト）

• 使えるねっと – よくある質問「ドメインの作成（VPS・専用）」
• Parallels Plesk Panel 9.0

2200 WordPress, Joomla, Drupal, … Websites Load Time Comparisons PAGE LOAD TIME (2009/1/10)

やはり、MovableTypeは静的なページ出力ということで、一歩抜きん出ている感じでしょうか。いずれにしても数十ページやそこらでは大して差はでないですが。そして意外にもWordPressはページ数が増えても好成績…に見えますね。

サーバの性能（CPUやメモリ）や使用しているJavaScriptの数によっても全然変わってくるので、まぁ目安に過ぎないでしょうけれどね。下手なVPSや安い専用サーバなんか借りると自由度が高いかわりに低スペックだったりするので、月額1000円以下の共有サーバのほうが快適だったり。このブログが設置されているのは『エックスサーバー／X10（月額1,050円）』のサーバ番号：sv69ですが、サーバのスペックは、Core2 Duo E6600 ( 2.40GHz )、メモリ4GB。もっと新しいsv166だと、Xeon E3110 ( 3.00GHz )、メモリ8GB。

それから、今時のサーバなら大丈夫だと思いますが、WordPressの場合、PHPのmemory_limitは32MB以上は必要です（ソースの中にも書いてあったような気が…）。以前は、サーバのデフォルトが8MBというサーバもありましたが、そうするとPHPのエラーが出力されたり、画面が真っ白になったり、やたら遅く感じたり…。

php.ini の記述例

.htaccess の記述例

※たいていはトップディレクトリに置きます。
※いずれもサーバ側が設置を許可している必要あり。

WordPress 2.7がリリースされて１ヶ月近く経ちますが、過去バージョンにて実装されて知らない機能や関数がたくさんあったので、ここで今のうちに2.7の新機能を確認しておこうと思い、主にテーマ（テンプレート）に関連したものの概要を調べてみた。

1. wp_logout_url()
   ログアウト用のURLを表示するテンプレートタグ      
   <?php echo wp_logout_url($redirect); ?>

   従来、/wp-login.php?action=logout などとしていた部分はこのタグに置き換えることでセキュリティ的に望ましいURLが挿入されるらしい。
   引数（$redirect）には、ログアウト後に移動するページのURLを指定できる。
   ちなみに、wp_config.php内に define(‘NONCE_KEY’) という項目が加わっている。このタグにも関連していると思われる。
   これらのセキュア・キーに指定した値がパスワードに付加されることで解読されにくくするもの。

2. wp_list_comments()
   コメント＆トラックバック＆ピンバック表示のためのテンプレートタグ。
   それぞれ分けてリスト表示できるようになった。      
   <?php wp_list_comments(‘type=comment‘); ?>

   とするとコメントだけが表示される。他に trackback、pingbackを指定できる。

   <?php wp_list_comments(‘type=comment&callback=mytheme_comment‘); ?>

   上記のようにコールバック関数も使える（関数はfunctions.phpなどに記述する）。
   また、下記の５つのテンプレートタグは、コメント表示部がスレッド化、ページ分割、ネスティングができるようになった（テーマの対応が必要）ため、関連して新規追加されたテンプレートタグ。よりpostのループに近い感じになった。
    

3. previous_comments_link()
   コメントを改ページする場合に、前ページへのリンクを表示
4. next_comments_link() 
   コメントを改ページする場合に、次ページへのリンクを表示
5. comment_reply_link()
   既存コメントに返信するためのリンクを表示
6. cancel_comment_reply_link()
   既存コメントへの返信を止める（コメント投稿欄を通常に戻す）ためのリンクを表示
7. comment_form_title()
   コメント投稿欄の見出しを表示
8. post_class()
   テーマのスタイリングをシンプルに。
   記事のループを囲むdiv等の開始タグ内にこれを挿入すると、下記のCSSの一連のclassが記事に応じて挿入される。      
   1. post
   2. hentry (hAtom microformat のページ用)
   3. category-X (xは記事が属するカテゴリのスラッグ)
   4. tag-X (xは記事に付けられたのタグのスラッグ)
   5. sticky
   <?php post_class(‘special‘); ?> 

   と書くと、「special」という独自のclassを挿入できる（スペース区切りで複数指定可能）。
   ループ外で使う場合は、第２引数に記事IDを指定する。その記事に応じたclassが挿入される。

   <?php post_class(”,$post_id); ?>
9. wp_page_menu()
   
   “ページ”一覧を表示するテンプレートタグ。
   引数に     
   show_home=1

   を加えるとhome（サイトのトップ）へのリンクを含めてリスト表示。
   他はwp_list_pages()と同様。

10. query_posts()
    引数に     
    caller_get_posts=1

    を指定すると、admin＞設定＞表示設定の「フロントページの設定」にて指定した記事はループから省かれる。

11. 独自のheader、footerの読み込みを簡単に。
    get_header(‘myheader‘)

    とすると、テーマフォルダ内に用意した header-myheader.php が読み込まれる。

    get_footer(‘myfooter‘)

    とすると、テーマフォルダ内に用意した footer-myfooter.php が読み込まれる。

12. is_sticky()
    コンディショナルタグ。
    現在のページが、フロントページに指定した記事である場合、true。  
    is_sticky(‘17′)

    とした場合、記事ID=17がフロントページに指定されている場合にtrue。

参考ページ）

• WordPress 2.7 特集 WordPress Codex 日本語
• Migrating Plugins and Themes to 2.7 WordPress Codex 日本語
• Migrating Plugins and Themes to 2.7/Enhanced Comment Display  WordPress Codex 日本語
• テンプレートタグ WordPress Codex 日本語

まだあまり模索していないですが、結論から言うと、とりあえず下記のようにすれば出来ています。

1. テストサーバーを用意する（WordPressをインストールする）
   同一サーバーの別階層に別のWPをインストールすればOK。 
2. テンプレート（例：index.php）の冒頭でwp-config.phpを読み込む
   <?php include(‘../../../wp-config.php’); ?>
   <?php get_header(); ?>
   ….. 
3. プレビューの度に「ライブビュー」ボタンをOn/Offする

Adobeの新しいシリーズ「CS4」の中で、Webオーサリングソフトウェア「Dreamweaver CS4」の新機能の１つは「ライブビュー」という機能。

これは、従来ならファイルを編集後FTPでUP→ブラウザでリロード、という手順で行っていた確認作業をDreamweaver内に内蔵されたWebブラウザで行い、作業を効率化を図れる機能。注目すべきはその内蔵ブラウザの描画エンジンが、Safariなどでも採用されている「WebKit」が使われているので、かなり本番に近いプレビューができること。”使える”機能になっています。

ということで、早速WordPressのテンプレート編集につかえないかな〜と考えたわけですが、使う前から薄々懸念されることがあります。

WordPressに限りませんが、CMSのテンプレートって、それ単体では完結していなくて、header.php/index.php/sidebar.php/footer.phpなどに分かれてることが多いですね。なので、index.phpだけ「ライブビュー」でプレビューしたところで、HTMLページを構成するヘッダーもフッターも備えていないのでエラーが発生します。

ではなぜWordPressの本番サイトはエラーを起こさず、ページが生成されるかといえば、index.php内の冒頭get_header()を、ページ下部にてget_sidebar()、get_footer()というWordPress独自の関数が挿入されていて、これをきっかけに各テンプレートがいわば”合体”しているわけです。

「じゃあDreamweaverもget_header()を実行してくれればいいじゃん」

という話が出てきそうですが、そんな関数Dreamweaver自身は知る由もなし。WordPressの独自関数なので。

（この辺、DWの拡張機能として提供されたら便利ですねぇ…ちなみにget_header()をinclude(‘header.php’)に置き換えると無事実行されます、WPではなくPHPの関数なので。ただ弊害があるかどうかはわかりません）

このget_header()…関数がこのindex.phpテンプレート内に定義されていれば無事実行できますが、実際はWordPressの別ファイルに定義されています。結果として、冒頭に書いたように、WordPressの”根っこ”のファイルでもある「wp-config.php」ファイルを読み込んだところ、ページ形成に必要な情報が呼ばれてどうにかページを形成できました。

しかしこれをそのまま本番サイトにアップするとエラーが発生します。

※２のライブビューをOn/Offしないと反映されないのは使い方が間違っているのか仕様なのかバグなのかわかりません。

ということで、実用的な方法を模索したいと思いますが、すでにご存知の方は教えて下さいっ<(__)>

【追記】JavaScriptなどブラウザ側で実行されるスクリプトの編集こそ効果を発揮しそうです。PHPはサーバ側で実行するスクリプトなので、編集後は当然サーバーに何らかのかたちでアップロードしない限り実行できないですから。。。command+shift+u（アップロード）、commant+tab（アプリ切り替え）、command+r（リロード）のほうが早くて確実？

以下の関数をwp-content/themes/使用中のテーマ/funcitions.php 内に挿入。
【追記】もし下記を追加後にビジュアルエディタが使えなくなったとしたら、functions.phpを編集した時にUTF-8以外の文字コードで編集した可能性があります。その場合は、UTF-8に適用しなおして、挿入したコードの前後の改行などもいったん削除すると直ります。 

あとは、投稿orページの本文で挿入したい部分に

のように記述すればOK。 

企業サイトをWordPressで制作する場合、会社概要などにメールアドレスを記述することがあると思う。その時に、スパムボット対策でantispambot()でメールアドレスをHTMLエンティティ化するには、投稿orページ本文の中なので、上記プラグインを使用して本文内でPHPを実行すれば実現できる。が、これらのPHP実行プラグインはビジュアルエディタとバッティングするので、もしクライアントサイドでビジュアルエディタで編集するとPHPのコードが壊れて機能しなくなってしまう。

これをショートコード化すれば、（クライアントがその部分の記述を触らない限り）antispambotは使えるようになります。

メリークリスマス☆

【追記】

今更ながらにショートコードって便利＞＜っと、調子にのって、サイト内リンクを簡単にするために、get_permalink(記事ID)を使えるようにしてみました。

投稿ページでは

と書くだけで、サイト内の記事ID=1の記事へのリンクを挿入できます。
http://example.com/archives/1/

と書くと 
こちらをご覧ください
とすることもできます。  

パーマリンク構造やスラッグを変えてもリンクエラーになりません。でもビジュアルエディタ使ってる時は別ウィンドウからリンクテキストをドラッグ＆ドロップするだけでリンク貼れるので、手間を省く意味はあまりないかもですw

こんな具合で慣れてしまえば仕組みは一緒なので、投稿ページ内で使いたい関数があったらぜひ自作ショートコード作成にチャレンジしてみては？プラグインづくりのトレーニングにもなるかも。 

参考ページ）
ショートコードAPI  WordPress Codex 日本語