Monthly Archives: April 2011

ソースコードを綺麗に表示するプラグイン

ソースコードが下の例のように綺麗にハイライト表示されているサイトを見たことがあるのではないかと思う。 function add_attrib($content){//Add attribute global $id, $attribute, $attribute_value, $prefix, $suffix; $attrib = “$attribute=\”$attribute_value$gallery\”"; if ($id == null) { $gallery = “”; } else { $gallery = $prefix.$id.$suffix; } return preg_replace(“/<a(?![^>]*?rel=['\"].*)[^>]*?(href=['\"][^'\"] ?\/[^\/] ?\.(bmp|gif|jpg|jpeg|png)['\"])(?![^>]*?rel=['\"].*)[^\>]*>(<img[^>]*?title=(['\"][^'\"] ?['\"])[^>]*\/>)/i”, “<a $1 $attrib title=$4>$3″, $content); } 実は、上記のようにソースコードをハイライト表示させる事は、それ程、難しい事ではない。 ソースコードのハイライト表示を実現するライブラリがいくつか公開されているので、それらを使えば良い。 これらのライブラリの中でも「SyntaxHighlighter」、「GeSHi」の2つが有名である。 WordPressの場合は、それらのライブラリをプラグイン化したものが公開されているので、導入は非常に簡単だ。 1.主なライブラリ ・SyntaxHighlighter 「SyntaxHighlighter」は、Javaスクリプトで記述されたライブラリで、サーバーではなく、クライアント(ブラウザ)側で処理させてハイライト表示を実現している。 そのためサーバーへの余計な負荷はない。 欠点は、ハイライト表示されるまでタイムラグが生じることだ。 サーバー側の処理に割り込んでいるわけではないので、最初は、記事として記述したとおりに表示される。つまりハイライト表示ではない。 読み込みが完了し、ブラウザでの処理が完了して、初めてハイライト表示になる。 そのため、長い短いは別として、普通に表示される不恰好な時間が必ず生まれる。 「SyntaxHighlighter」は、ページが本文表示された後に読み込まれなければ、正しく本文のハイライト表示を処理できないため、これもタイムラグの一因となっている。 実際に「SyntaxHighlighter」ベースのプラグインを試したところ、このブログは、様々なJavaスクリプトを読み込んでいるため、更に遅延が生じだ。 これは極端な例だが、このブログを参照したときに実行されるスクリプトの1つが、ツイッターの情報にアクセスしているため、中国の自宅からアクセスした場合、中国からはツイッターには接続できないためタイムアウトするまで待つことになり、タイムアウト後にようやく「SyntaxHighlighter」が実行され、もはやタイムラグとは呼び難い程の酷い遅延となった。 環境によっては予想外の遅延が生じる可能性があることに注意して置かなければならない。 「SyntaxHighlighter」の実行部分は、本文の後ろかつ、他のスクリプトより上位の位置で読まれたほうが、如何なる環境でもストレスが少ないと思われる。しかし、遅延の問題は完全には避けられないだろう。 ちなみに上の例も「SyntaxHighlighter」を使用しているが、プラグインは自作した。多少タイムラグが軽減できたように思う。 2011/5/3 「WP SyntaxHighlighter」を公開。 ・GeSHi 「GeSHi」は、PHPで記述されたライブラリで、「SyntaxHighlighter」とは異なり、サーバ側で実行される。 そのため「SyntaxHighlighter」のようなタイムラグはなく、いきなりハイライトされた形で表示される。 私のサーバー環境では、サーバーへの負荷によって、ページの表示に遅延が生じるなどのストレスも感じられなかった。 ベージ上で呼び出すだけで動作し、予めハイライト表示用のCSSが用意されてる「SyntaxHighlighter」と比較すると、ややページへの実装が面倒な印象がある。 2.WordPressへの実装 「SyntaxHighlighter」や「GeSHi」をベースとしたプラグインが公開されているので、それらを使えば簡単に導入が可能である。 主なプラグインを紹介する。 ・SyntaxHighlighter Evolved 「SyntaxHighlighter Evolved 3.1.1」は、「SyntaxHighlighter」ライブラリを利用したプラグインで、バージョン3.0系と2.0系の2つのライブラリが組み込まれており、切り替えて使用出来る。 こちらは、バージョン3での表示。 行番号は非表示に出来る。(バージョン2も。) 一行が長すぎる場合は、自動的にスクロールバーが表示される。 表示部をダブルクリックすると、コピーモードのになるので、ソースをコピー出来る。 続いて、こちらがバージョン2での表示となる。バージョン2の方が、ハイライト表示までのタイムラグが少ないように思う。タイムラグについては、プラグインの実装方法によっても異なり、一概に言えなさそうである。 バージョン2では、長い行の折り返しが可能な他、Flashベースのツールバーが表示できる。 このツールバーでは、ソースのコピー機能などが提供されている。 基本的にバージョン3の方が操作性に優れていると思うが、ソースのコピー方法などは、バージョン2の方が直感的に分かり易く、ビジターに親切かと思われる。 上記の表示は、シンプルに見えるが、デフォルトのテーマでの表示例だ。 複数のテーマが用意されているので、テーマを切り替えることによってデザインを変えることが出来る。 もっとも、テーマ自体は「SyntaxHighlighter」ライブラリに含まれているので、これは「SyntaxHighlighter」ライブラリベースのプラグインに共通の機能である。 設定画面は充実しており、日本語表示にも対応している。 この設定画面で、かなり細かい設定変更が行える。 「SyntaxHighlighter」ライブラリでは、ハイライト表示の指定は、<pre>タグでマークアップして行うのが基本だが、このプラグインでは、[php]といった様な簡略化されたショートコードを採用している。 ・Syntax Highlighter for WordPress 「Syntax Highlighter for WordPress 3.0.83.2」も、「SyntaxHighlighter」ライブラリベースで、バージョン3.0系と2.0系の2つのライブラリが組み込まれている。 開発者は、日本人の方。 こちらがバージョン3での表示。 こちらがバージョン2での表示となる。 「SyntaxHighlighter」ベースなら基本的に表示は同じ。微妙な差は、初期設定値の違いによるものだ。 設定画面は非常にシンプルで、バージョンとテーマの切り替えのみ。 「SyntaxHighlighter Evolved」同様に、ソースコードのマークアップにショートコードを使う。 設定画面がシンプルな事を除けば、基本的に 「SyntaxHighlighter Evolved」と大差はない。 ・CodeColorer 「CodeColorer 0.9.9」は、「GeSHi」ライブラリをベースとしている。 そのため、ハイライト表示に切り替わるまでのタイムラグはない。 表示は下記の通り。「preg_replace」がリンクされているが、クリックすると、関数のリファレンスに飛ぶ。 複数のテーマが用意されているので、テーマの切り替えで、レイアウトを変えることが出来る。 … 続きを読む →

Posted in WordPress, ネット・PC | Tagged , , , , , | 2 Comments

WordPressのパーマリンクの設定を変更すると何が起こるか?

今更ながら、パーマリンクの設定をデフォルトから変更した。 本来は、Wordpressをインストールした直後に行う作業であろう。 以前のパーマリンクの設定は、デフォルトだったので、投稿や固定ページのURLは、 /?p=123 となっていた。 /?p=%post_id%(?p=投稿ID) の形式である。 「?」で始まる書式を嫌う人も多いが、個人的には、これでも問題はなかった。 しかし、設定の変更を試してみたいという気持ちもあり、今回、初めてトライした。 とは言え、パーマリンクの設定で、ブログのURLの形式が決まるため、パーマリンクの「書式」の決定には、一番、慎重にならざるを得ない。 多くの人が「投稿タイトル(%postname%)」または「投稿ID(%post_id%)」をURLの最後に持って来る書式を選ぶだろう。 URLは、投稿毎にユニークである必要があるという観点からも好ましい。 どちらかと言えば、「投稿ID(%post_id%)」のような意味不明の数字よりも、意味が通る「投稿タイトル(%postname%)」を最後に置くようなURLの方が、一般的には、ビジターに親切であり、好ましいと言える(らしい)。 しかし、日本語環境では「投稿タイトル(%postname%)」の利用に関して大きな問題がある。 タイトルは日本語で入力されることが通常なので、そのままでは、URLとして使えない。最も、Googleなどの検索エンジン上では、URLの一部が日本語で表示されて分かり易いというメリットもあるが・・・。 結果、「投稿タイトル(%postname%)」は意味不明の英数字に変換されてしまう。 投稿時に、半角英数字で「投稿のスラッグ」を設定するこで、この問題は解決できる。 一応、全ての投稿に「投稿のスラッグ」を設定してみたが、「投稿のスラッグ」の入力を習慣とする自信はない。 そこで、「投稿ID(%post_id%)」を最後に置く形式のURLにすることにした。 個人的な意見だが、ビジターは、管理者が懸念している程、URLがどうかなんて気にしていない。 せいぜい、気にかけるのはドメインくらいだ。面白いドメインだなぁとか。 今やツイッターの時代、見方を変えれば、わざわざ短縮しなくても良い程、十分に短いURLこそ、親切と言えるかもしれない。 基本的に、管理者本位で決めて良いように思う。 最初は、管理者本位+ビジターライクに /%category%/%post_id%.html(/カテゴリ/投稿ID.html) に変更した。 URLにカテゴリを使用することで、見かけ上のサーバーのディレクトリ構成もカテゴリ分けされているように見え悪くないが、このブログのルートは、「blog」ディレクトリ直下なので、どうもURLが長くなり過ぎる。 そこで /%post_id%.html(投稿ID.html) に変更したが、数字にhtmlが付く形式は、どうも馴染まない。 最終的には、安易に /%post_id%(投稿ID) の形式。つまり/blog/以下に単に数字が付くシンプルな形式になった。 これで、パーマリンクの設定が変わった。 パーマリンクの設定が変われば、これ以後は以前と異なるURLが付加される。 しかし、通常、ウェブサイトにおいてはURLが変わるという自体は、大変な弊害をもたらす。 ブックマークなどからアクセスしていたビジターは、アクセス出来なくなる。 当然、外部からのリンクも全て失う。 とは言え、パーマリンクの設定の場合は、ブログのトップページのアドレスは変わらないので、最悪の事態になることはないが、パーマリンクの設定するにあたって、一番懸念したのが、この点である。 幸い、変更後もデフォルトの「/?p=123」形式のURLでもアクセス出来た。 正確に言えば、デフォルトのURLへのアクセスに対しては、301リダイレクトが設定されており、新しいURLに自動転送される。 自動的にブログルートの「.htaccess」ファイルが書き換えられ、「mod_rewrite」の設定が施されていた。 301転送は、「恒久的にページが、こちらに移動しました。」という案内なので、URLの変えた場合の作法としては、非常に行儀が良い。 「カテゴリー」や「月別」、「タグ」といったアーカイブページのURL、フィードのURLまで変わるが、これらのデフォルトのURLに対しても301リダイレクトが設定されている。 アップロードした画像などが貼られる、 /?attachment_id=123 形式のページへのアクセスも、新しいURLに301リダイレクトされる。 デフォルトURLと新しいURLの間では、301リダイレクトが機能しているので、基本的にリンク切れなどの現象は起こらないので安心だ。 パーマリンクの設定をデフォルトから変えると「カテゴリー」のURLが変わることを踏まえて、予め、カテゴリーの設定では、半角英数字で「スラッグ」を入力しておいた方が良いだろう。可能ならばタグも。 タグに「スラッグ」を設定するならば、最初から習慣付けた方が良い。パーマリンクの変更後に日本語タグの「スラッグ」を変更するとスラッグベースのURLが更にもう1度変わる事になり、元のURLからの転送が効かなくなる。 パーマリンクをデフォルト以外に設定すると、固定ページのパーマリンクが個別に変更で出来るようになる。 そこで、個別ページのパーマリンクを分り易いものに変更した。 ただし、サーバー上のディレクトリ構成と一致するようなパーマリンクを設定してはいけない。 うっかり、これをやってしまった為に、そのページだけ、「アクセスする権限がない」と言う403エラーに見舞われた。 「index.html」や「index.php」などのファイルがないディレクトリにアクセスしようとしているので、このエラーは、当たり前の事なのだが、それを理解するのに時間が掛かり、一旦、パーマリンクの設定をデフォルトに戻したが、デフォルトの「/?p=123」形式のURLでも403エラーに見舞われた。 デフォルトへ戻した後のエラーは、実はブラウザの問題で、IE以外のブラウザでは問題なく、IEをリセットすることで回復したのだが、これも現象を理解するのに時間が掛かった。 こう言ったトラブルの時は、冷静さが大切だ。 無駄な努力が更に悪い結果をもたらすことも少なくない。今回は良い例だ。 403エラーに見舞われている間に、問題の固定ページを削除し、再度、投稿し直すという無駄な努力をしてしまい、その結果「投稿ID」が変わってしまた。 つまり、「投稿ID」が異なるため、内容は同じでも、別ものとして認識される。 とうとう、以前のアドレスでは転送されない状況になってしまった。 1ページだけとは言え、一番困るページである。正直、最悪だ。 それを正すために、データベースを直接操作し、投稿IDを付け替えるという技を身につけられた事は、唯一の収穫かもしれない。 さて、ブログのステータスとも言える、被リンク、ブックマークへの登録数、SNS等での言及数は、パーマリンクの設定で、どう変わるだろうか? コメント・・・URL変更とは無関係なので影響を受けない。 ピンバック・・・消えないが、URLの整合性を失う。 被リンク・・・トップページを除き、すべて失うが、転送される。検索エンジン上も問題ない。 はてなブックマークへの登録数・・・トップページを除き、すべて失う ツイッターで言及された数・・・トップページを除き、すべて失う。 Facebook「いいね!」の数・・・トップページを除き、すべて失う。 Zenback・・・URLが変われば、新規ページの扱いとなり、関連記事が再構成される。 DISQUS・・・投稿のカスタムフィールドの値で識別するため影響を受けない。ただし、リアクションのURLの整合性は失う。 当たり前だが、URLが変われば失うものも多い。 それから、設定が終わったら、検索エンジン向けのサイトマップも直ぐに更新したほうが良い。 クロールの頻度にもよるが、検索エンジン上の全ての登録ページに変更が反映されるまでは時間が掛かるものの、反映の開始は意外に早い。 実際、10時間後に確認した時には、Google上では、一部が新しいURLで表示されていた。 パーマリンクの設定を迷っている段階のURLで表示されているものもあるので困ったものだ。 迷うことは想定していなかったが、「robots.txt」を変更してから作業に入れば良かった後悔している。 ともかく、クロールから検索結果に反映が開始されるまでのタイムラグは、意外に少ないので注意が必要だ。 それから、ブログ全体のURLが変わっているので、投稿や固定ページの中の内部リンクや、画像のリンクについても注意が必要だ。 デフォルトのURLからの転送が効いているので、基本的には変更の必要はないが、「タグ」アーカイブへのリンクなどは、スラッグを変更すると転送が効かなくなるケースもあるので、可能ならば、新しいURLに変更したほうが良い。 特に変更から時間が経過すると、こう言ったことは忘れがちなので、予め「Broken Link Checker」などをインストールしてリンク切れをチェック出来る環境を整えたほうが良い。 このブログの場合は、投稿数も多くはないので、この機会にリンクを新しいURLに変更した。 そのお陰で、「リンクURL」として「投稿のURL」を指定し、貼りつけた画像も、「Add attrib for Lightbox」に依存しなくとも「Lightbox」風の表示が可能となった。 その他、気づいた弊害としては、アクセス解析に「NewStatPress」を使っているが、パーマリンクを変更した後は、解析結果に投稿のタイトルが表示されなくなり、URLに変わった。 デフォルトのURLに依存するようなタイトルの取得方法を採用しているのだろうが、URLを「投稿ID」ベースにしたこともあり、記事の判別が困難になった。 また、デフォルトのURLでアクセスした場合、2回カウントされる。 まず、古いデフォルトのURLでカウントされ、転送後に新しいURLでカウントされるのだが、道理でページビューが一気に倍増したと思ったら、ここに原因があった。 タイトルの問題は仕方ないが、2重カウントの問題は、検索エンジンなどに新しいURLが認知されるまでの辛抱。時間が解決してくれるだろう。 このようにパーマリンクの設定変更による影響は範囲は、そう甘いものではない。 出来ればパーマリンクの設定を安易に変えるのは避けたいものだ。 今回は、デフォルトから変更であったため、URL転送の問題は発生しなかったが、現在のパーマリンクから別のパーマリンクへの変更となると、古いパーマリンクから新しいパーマリンクに何らかの方法で転送しなければ、ビジターが迷うことになる。

Posted in WordPress, ネット・PC | Tagged , , | 2 Comments

アフィリエイト広告を表示するプラグイン

「アフィリエイト」もブログの醍醐味の1つである。 とは言っても容易に稼げるわけでもなく、取らぬ狸の皮算用は、禁物だが、ブログを継続する励みにはなる。 今回は、アフィリエイトの定番である「Google AdSense」と「Amazonアソシエイト」に便利なプラグインを紹介する。 ・Quick Adsense 「Quick Adsense 1.8.4」は、その名前から「Google AdSense」に特化したプラグインのような印象を受けるが、実際はそうではない。 HTMLやJavaスクリプトを好みの場所に挿入できるツールと考えた方が良いだろう。 設定画面では、投稿本文用とウィジェット用として、ぞれぞれ10種類の広告コードを設定できるようになっている。 広告コードは、「Google AdSense」の管理画面から取得したものを貼り付ける。取得を補助するような機能は備えていない。 そして、「投稿本文の先頭に広告1を表示」と言った要領で、投稿本文内での表示位置とそこに表示する広告を定義して行く。特定の広告を指定せずにランダムに表示することも可能だ。 「Quick Adsense」の優れた点は、投稿本文内での表示位置の選択が細かく出来る点であり、「本文の先頭」、「本文の後ろ」の他、「本文の中」、「段落の後」、「画像の後」といった細かな位置決めが可能となっている。 更に投稿本文内での位置だけでなく、表示するページの選択も細かく、「投稿」、「固定ページ」、「ホームページ」、「カテゴリー」、「アーカイブ」、「タグ」の中から複数選択できる。 欲を言えば、フィードにも対応して欲しいところだ。 最初に書いたが、けして「Google AdSense」に特化したプラグインではないので、挿入するのは「Google AdSense」の広告である必要は全くない。 他のアフィリエイトサービスのものでも問題はないし、ブログツールのJavaスクリプトでも構わない。 工夫次第で、色々と面白い使い方が出来そうだ。 ・WordPress-Amazon-Associate(WordPress Amazon Associate) 「Amazon」のアフィリエイト広告を掲載するためには、「AmazonアソシエイトID」が必要になる。 ところが、この「AmazonアソシエイトID」が厄介で、基本的に国ごとに異なる。 例えば「amazon.co.jp」の商品の広告を出したいなら、日本の「AmazonアソシエイトID」が必要になる。 逆に言えば、Amazon関連のプラグインは、多数、存在するものの全てが無条件に使えるわけではなく、所有している「AmazonアソシエイトID」の「国」に対応しているかが問題にある。 その点、「WordPress-Amazon-Associate 1.5.0」は、柔軟で「アメリカ」、「カナダ」、「中国」、「ドイツ」、「フランス」、「イタリア」、「日本」、「イギリス」の「AmazonアソシエイトID」をサポートしている。 ビジターの訪問元の国をIPアドレスから判断する機能が備わっているので、上記の全ての国の「AmazonアソシエイトID」を同時に使用することも出来るが、どれか1つをメインに設定する必要がある。 1つ面倒なのは、このプラグインの利用には「AmazonアソシエイトID」だけでは不十分であり、「Amazon Web Service」にユーザー登録し、「Access Key(アクセスキー ID)」と「Secret Key(シークレットアクセスキー)」を取得する必要がある事だ。 先に書いたとおり、IPアドレスから訪問元の国を判断する機能があるが、この機能のために「ip2nation」を使用しており、別途、データベースを取得する必要があるが、これは、管理画面から簡単に出来る。 単純な「プロダクトリンク」の他、「くるくるウィジェット」、「お気に入りウィジェット」、「おまかせリンク」、「プロダクトクラウド」、「サーチウィジェット」をサイドメニューなどに簡単に表示できる。 下の例は、おまかせリンク。 ご覧の通り、日本の「Amazon」に問題なく対応しているが、操作メニューや管理メニューは日本語化されていないので注意。 同様に、ビジュアルエディア上のボタンで、記事中にも簡単に広告を挿入できる様になっている。 WordPressのビジュアルエディタは、「iframe」形式のAmazonの広告コードを自動的に削除してしまうが、このボタンで、書き出されるコードは「iframe」形式ではなく、削除されない。 「Amazon」用としては、オススメのプラグインだ。

Posted in WordPress, ネット・PC | Tagged , , , , , | 1 Comment

EZ zenbackのバグと修正バージョン「Ver.1.1」

ダウンロードして頂いた方には、大変、申し訳ないが、既にアナウンスしている通り、「EZ zenback Ver.1.0」は「zenbackタグ」の挿入に関して問題を抱えていた。 「zenbackタグ」は、「zenback」に対して、どこがタイトルを表し、どこが本文なのかを教えるタグだ。 タイトルと本文の場所を「zenback」が理解することで、逆に、関係のない要素は除外され、解析の精度が上がる。 「zenbackタグ」は、「zenback」の利用に不可欠という訳ではなく、タイトルが見出しとしてマークアップされており、本文にある程度ボリュームを持つ投稿なら「zenbackタグ」が無くとも、「zenback」にきちんと認識されるだろう。 とは言え「zenbackタグ」は無いよりもあった方が良い。 「一般的なテーマでは、投稿本文の直ぐ上にタイトルが表示されているが、「EZ zenback Ver.1.0」では、これを「zenbackタグ」でマークアップしようとしていた。 技術的な話をすれば、「the_title」というフィルターフックを利用して、タイトルの前後に「zenbackタグ」を挿入していたが、「the_title()」という関数は、投稿のタイトル以外の取得にも利用されており、メニューや前後の記事へのリンクなどにも「zenbackタグ」が挿入されてしまうバグが発生していた。 これでは、どれが正しいタイトルなのか分からなくなる。 そこで、今回のリリースでは、記事の上に表示されているタイトルをマークアップするのではなく、新たに「zenbackタグ」でマークアップされたタイトルを追加する仕様に変更した。 「zenback」専用にタイトルを設けるようなイメージになる。 具体的には、以下のようなタグが挿入される。 <span style=”display: none;”><!– zenback_title_begin –>EZ zenbackのバグと修正バージョン「Ver.1.1」<!– zenback_title_end –></span> この場合、 <span style=”display: none;”> としているので、追加したタイトルは、ブラウザ上では見えない。 より正確に言えば、ブラウザ上では、見えないのではなく、「存在しない物」として扱われるので、正しい解釈するブラウザであれば、レイアウト上も問題ないはずだ。 しかし、ソース上には確かに存在するので「zenback」は、これを認識する。 上記の記述でも、「zenback」に正しく認識されることは「zenback」の開発元である「シックス・アパート」にも確認済みであるので、この点は安心して欲しい。 個人的には、問題はないと考えているが、 style=’display:none;’ としている点から、SEO上の問題を懸念する方も少なくないと思うが、その場合は、設定画面で「zenbackタグを追加」を無効にして使って欲しい。 最も、SEOを意識されている方なら「zenbackタグ」など使わなくとも、「zenback」に問題なく認識されるブログを作っておられるだろう。 以上の通り、「Ver.1.0」にはバグがあるため、大変申し訳ないが、「Ver.1.1」へのバージョンアップをお願いしたい。 今回のバージョンアップは、バグ修正が目的だが、設定画面にも若干の修正を加えた。 バージョン1.1は、商標表示の不足ため公開を中止。最新版をダウンロードのこと。 最新の「EZ zenback」をダウンロード ・アップデートの仕方 1.WordPressの管理画面の「プラグイン」の項目で「EZ zenback」を停止する。 2.ダウンロードファイルを解凍し、「ez-zenback」フォルダごと「/wp-content/plugins」にアップロード、全てのファイルを上書きする。 3.WordPressの管理画面の「プラグイン」の項目で「EZ zenback」を有効化する。 ※設定は、バージョンアップ前のものが引き継がれる。 「Disqus Comment System for EZ zenback」を併用してる場合も、同様の手順。 なお、今回は「Disqus Comment System for EZ zenback」のアップデートはない。

Posted in WordPress, ネット・PC, 自作アプリ | Tagged , , , | Leave a comment

WordPressの使い勝手が良くなる小粒なプラグイン

今回紹介するツールは、管理者の立場ではなく、ビジターの立場で、WordPressが使い易くなるツールだ。 けして、派手な機能を備えたツールではないが、ぜひ、インストールしておきたい。 ・My Category Order WordPressの欠点の1つが、カテゴリーの順序を変えられない点があげられるが、「My Category Order 3.0.1」は、これを解消してくれる。 多くカテゴリが存在するブログでは、ブログのテーマに沿ったカテゴリー、見てもらいたいカテゴリーを上位に持ってきた方が、場合によっては、ビジターに対して親切かもしれない。 カテゴリーの順序の並べ替えも、ドラッグ&ドロップで出来き、非常に簡単だ。 このブログでは、今のところカテゴリーの数は多く無いので、使ってはいないが、インストールはしている。 将来、きっと役立つだろう。 ・Super Cool QRCode 携帯電話に対応しているならQRコードを表示した方が、ビジターには親切だ。 QRコードを表示するツールは沢山あるが、私は「Super Cool QRCode 0.0.7」を使っている。 サイドバーにウィジェットとして登録するタイプで、設定もウィジェットで行う。 機能的にはQRコードを表示するだけのシンプルなものだが、きちんと、ページ毎に、それぞれのURLのQRコードを自動生成してくれる。 どのページのQRコードも、トップページのURLでは芸がない。 また、QRコードの前後にタグを挿入できるので、ちょっとしたレイアウトも可能だ。 ・WP-PageNavi ブログに限らず、ウェブサイトという物は、ナビゲーションによって使い勝手が大きく左右される。 基本的には、お目当ての記事を如何に早く探せるかと言う点が重要だろう。 しかし、こう言った事は、ブログ内部のナビゲーションよりもGoogleなどの検索エンジンの方が得意かもしれない。 また、明確な目的はなく、面白そうな記事を探してブログを徘徊することもあるが、そう言った時には、ナビゲーションは重要だ。 WordPressに限らず、ブログは、カテゴリー、月別などに分類する機能を持っており、ある程度、記事を絞り込み易くなっている。 しかし、一覧ページでのナビゲーションは様々で、WordPressのように、単に前後のページに移動するリンクを表示するタイプもあれば、各ページのページ番号をリンク表示したり、任意のページを入力して移動できるナビゲーションもある。 当然、自由にページを行き来できる方が便利であるし、「◯◯◯カテゴリの☓ページ目に面白い記事があった」など、ビジター側でも、記事の位置を把握しやすくなる。 それをWordPressで実現してくれるのが「WP-PageNavi 2.74」である。 非常に些細な事だが、随分と使い勝手が変わるはずだ。

Posted in WordPress, ネット・PC | Tagged , | Leave a comment

「zenback」をWordPressに導入するためのプラグインを作成

ブログパーツなどを追加するためにテーマのテンプレートを変更しているケースが少なくないのだが、テーマをアップデートすると加えた変更は、全て無に帰すため、テーマのアップデートのタイミングで必ず作業が発生する。 頻度は高くないが、これは結構、面倒である。 また、気軽にテーマを変更することも出来ない。 その原因の1つが「zenback」なのだが、「zenback」を導入をプラグインに任せることが出来れば、テンプレートを編集する必要がなくなる。 しかし、そのようなプラグインは、WordPressでは存在していないようなので、自作する事にし、作業を進めてきた。 根本的にPHPが分かっていない事もあるが、このプラグインの作成にはかなり苦労した。 しかも、結論から言えば、自身の要求は全て満たすことが出来なかった。 「zenback」の解析精度を高める「zenback」タグの追加は、WordPressにも比較的に簡単に実装できたが、問題は、「zenback」スクリプトコード本体の追加である。 「zenback」の表示位置としては、コメントの直ぐ上、または直ぐ下が適当だろうと考えたが、そこに追加する手段が見つからなかった。 コメントにどうにかして加えるしかないと考え、その方向で、試行錯誤していたところ「/wp-includes/comment-template.php」の中で「comment_form_after」、「comment_form_before」という、如何にも使えそうなフックを見つけ、調べたところ、ビンゴだった。 これらを使えば、コメント欄の前、または後ろに簡単に「zenback」を挿入できる。 この2つの関数のお陰で、大きく前進した。 そして誕生したWordPress用プラグインが「EZ zenback」である。 ダウンロード出来るように「EZ zenback」を公開したので、WordPressをお使いであれば、ぜひ、試して欲しい。 バージョン1.0は、商標表示の不足のため公開を中止。最新版をダウンロードのこと。 最新の「EZ zenback」をダウンロード しかし、まだ、大きな問題が残っていた。 「EZ zenback」の弱点は、標準のコメントシステムに依存している点である。 しかも、このブログでは、標準のコメントシステムではなく「DISQUS」を利用している。 従って、折角完成させた「EZ zenback」は、このブログでは使えない。 そこで「DISQUS」導入用のプラグイン「Disqus Comment System」を改造して「EZ zenback」に適合させることにした。 テーマの編集を避けるためのプラグイン化であったのに、今度は別のプラグインを弄ることになり、本末転倒である。 テーマの更新が早いか「Disqus Comment System」の更新が早いかで、今後の手間が決まる。 改造を加え「EZ zenback」に対応させた「Disqus Comment System」は、「Disqus Comment System for EZ zenback」の名称で公開した。 最新の「Disqus Comment System for EZ zenback」をダウンロード

Posted in WordPress, ネット・PC, 自作アプリ | Tagged , , , , , , | 4 Comments

WordPressにLightbox風プラグインを導入する

「Lightbox」をご存知だろうか? 画像をクリックすると「うにょーん」、「びよーん」と画像が飛び出してくるアレである。 言葉では、説明が難しいので、ともかく下の画像をクリックして欲しい。 ※焦りは禁物!ページが表示されていてもLightboxに必要なライブラリの読み込みが完了したとは限らない。画面の一番下にツールバーが表示されたタイミングならOK。 「あっ、見たことある。」と思われたのではないだろうか? 「Lightbox」は、本来、特定のツールを指す固有名詞なのだが、一般的にはこのような機能を「Lightbox」と言う。 現在は、本家の「Lightbox」の他、Lightbox風の機能を実現するライブラリが多数登場しているが、Lightbox風のクローンを含めて、単に「Lightbox」と呼ばれることが多い。 Lightbox風の機能は、JavaScriptライブラリ「JQuery」、「MooTools」、「Prototype」などのライブラリを利用して作られている。 これらのライブラリは、見た目にも、アクセサビリティ上も優れた機能をウェブページで実現する、所謂、AJAXに対応したライブラリだ。 「JQuery」、「MooTools」、「Prototype」などを利用して、Lightbox風の機能を実現するライブラリは、本家の「Lightbox」および「Lightbox2」の他、「Slimbox」、「Slimbox2」、「ThickBox」、「ColorBox」など多数存在している。 更に、WordPress用に、これらがプラグイン化して配布されているので、WordPressへの導入は難しくない。 様々な開発者がプラグイン化しているので、(相違はバージョンが違う程度で)同一のライブラリをベースにしたものが多数存在する。 私は、このブログに、Lightbox風の機能を導入したく、作業を進めていた。 有効化、無効化も簡単なプラグインとして導入するつもりだったため、導入は、直ぐに終わると思っていたが、この判断は甘く、実際は、かなり苦労した。 Lightbox風の機能を実現するプラグインの多くが、動作環境に神経質で、導入しても動かないケースが非常に多い。 特に「zenback」とは相性が良くないようだ。「zenback」を外すと、あっさり動いたものもあった。 加えて、私の画像の挿入の仕方が悪いのだが、既存の画像には、Lightbox風の機能が適応されない問題にも直面することになる。 結局、既存の画像にもLightbox風の機能を適応するためにプラグインを自作するはめになった。 以下、私が試したLightbox風の機能を実現するプラグインを紹介する。 同じような名称のものが混在しているので注意して欲しい。 ・Easy FancyBox 「Easy FancyBox 1.3.4.8」は、「jQuery」ベースの「FancyBox」をプラグイン化したもので、画像だけでなく、Flash、PDF、iFrame、YouTubeもサポートしている。 最初、設定項目がないと勘違いしたが、管理画面の「設定」 -> 「メディア」の中にあった。 流れるように飛び出してくる動きが特徴的だが、このブログでは、個別記事のページでフリーズしたようになり、閉じられない現象が発生した、詳しくは後の述べるが、「zenback」と競合しているのではないかと思われる。 ただし、「zenback」を外す気もなく、面倒なので検証はしていない。 ・WP Facebox Gallery(Facebox Gallery) 「jQuery」ベースの「WP Facebox Gallery 1.0.4」は、なかなか動作が軽快だ。 設定項目は無いが、自動的に動作に必要な属性を画像のリンクに追加してくれる。 細かい設定をしたい人には不向きだが、インストールして直ぐ使える利便性がある。 私のブログでも、特に難なく動作した。 ・FancyBox for WordPress 「FancyBox for WordPress 2.7.5」も「jQuery」ベースの「FancyBox」をプラグイン化したものなので、動作が流れるようで綺麗だ。 基本的には、「FancyBox」系のインターフェースだが、タイトルの表示方法が面白い。 設定項目が充実しており、他のプラグインとのコンフリクトを抑制する動作モードまで備えるのだが、画像リンクへの属性の自動追加が上手く機能していないように思われる。 手作業で属性を追加した場合でも、個別記事のページでは動作しなかった。 「zenback」が動いている個別記事での不具合となると、やはり、「zenback」のせいを疑ってしまう。 追記:設定画面の「Other」->「Load JavaScript in Footer」を有効にする事で、「zenback」が動作している個別記事でも、バージョン2.7.5は問題なく動作する事が分かった。 ・FancyBox Gallery 「FancyBox Gallery 0.3.2」も「jQuery」ベースの「FancyBox」が元のようなので、何か問題は出来るだろうと予想はしていたが、動作しなかった。 あるはずの設定画面が見当たらない。設定オプションには、開発上の「To Do」にも入っているので、無くて正解なのかもしれない。 属性の自動追加機能が備わっていないのか、属性も追加されない。 ・Fancyboxify 「Fancyboxify 1.1」も「FancyBox」がベースのようだ。 これまでの結果を見ても「jQuery」ベースの「FancyBox」系のプラグインは、運良く動作した場合でも、このブログとは、どうも相性が良くないようだが、やはり、個別記事のページでフリーズしたようになり、閉じられない現象が発生した。 「FancyBox」系は、「zenback」と相性が悪いのかもしれない。 これも設定画面が見当たらないが、属性の自動追加機能が備わっている。 ・Flexible Lightbox 「Flexible Lightbox 1.0.4」は、まず、属性の自動追加が上手く働いておらず、手作業で追加しても動作しなかった。 設定項目が表示されないと思ったら、画像リンクを追加する際に個別に設定する仕様になっている。 「ThickBox」ベースの「WP Thickbox Integration」も、同一の開発者によるプラグイン。 ・jQuery Colorbox 「jQuery Colorbox 3.8.3」は、「jQuery」ベースの「ColorBox」をプラグイン化したものだ。 これは、有効化しただけで、あっけなく動作した。 動作は軽快で、見た目も悪くない。 デフォルトのテーマのバックグラウンドは、単調なものではなく面白い。 多言語化されているが、日本語には未対応。 ・jQuery Lightbox 「jQuery Lightbox 0.16」は、すっきりしたデザインで表示され、バックグラウンドにもリンク表示する。開く際に、最後に、もわっとスクロールする動作が特徴的。 画像の上をオーバーマウスすると、ファイル名やボタンが表示される。 管理画面には、必要最低限の設定項目を備えるが、属性の自動追加機能を備えていない点が残念。 自作したプラグインで属性の自動追加機能を補って、暫く利用していた。 ちなみに「jQuery lightBox plugin」は、これとは別物。 ・Lightbox 2 「Lightbox 2 v.2.9.2」は、「Lightbox 2」をプラグイン化したもの。 人気のあるプラグインだが、残念ながら、このブログでは動作しなかった。 ・Lightbox Plus 「Lightbox Plus … 続きを読む →

Posted in WordPress, ネット・PC, 自作アプリ | Tagged , , , , , , , | 3 Comments

WordPressの管理者が重宝するプラグイン

今回は、「WordPress」の管理上、便利なプラグインをまとめて紹介する。 ・WordPress Database Backup(WP-DB-Backup) 「WordPress Database Backup 2.2.3」は、データベースのバックアップを可能とするプラグインで、不測の事態の際の復旧に役立つツールだ。 同様のプラグインは、多数存在するが、比較をしていないので「WordPress Database Backup」が優れているかは分からない。 ともかく、いずれかをインストールしておくと便利だ。 「WordPress Database Backup 2.2.3」の操作と設定は、管理画面の「ツール」->「バックアップ」から行う。 「WordPress」本体が利用するテーブルの他、プラグインが利用するテーブルも選択してバックアップ出来る。 スケジュール機能を利用すれば、定期的にバックアップしてファイルをメールで受け取ることも可能。 一応、インストールはしているが、正直、使っていないので、私は、不測の事態の際に泣くタイプだ。 ・Akismet 「Akismet 2.5.3」は、「WordPress」に標準でインストールされているプラグインで、コメントスパムやピンバックスパムの排除するために欠かせないプラグイン。 「Akismet API キー」が必要で、「Akismet」のサイトから取得する必要があるが、個人ブログなら無料で取得できる。 取得方法が、よく変更されること、個人ブログ用の無料「API キー」の取得方法が分かりにくいことから、ここからの「API キー」の取得はお勧めしない。 「wordpress.com」で発行される「API キー」でも代用できるので、こちらから取得すると良いだろう。 「API キー」は、「wordpress.com」でユーザー登録を行った後、送られてくるメールに記載されている。 このブログは、コメントシステムとして「DISQUS」を利用しているので、「WordPress」のプラグインとしては「Akismet」を利用していない。 「DISQUS」を利用している場合は、「DISQUS」側で「Akismet」の設定が可能となっている。 ・Revision Control 「WordPress」は作成中の記事を保存すると、記事を別のリビジョン(別の文書)として保存する。 また、自動保存の機能があるため、場合によっては、沢山のリビジョンが残ってしまう。 見かけ上は1つの記事だが、実際には10以上の記事が保存されていることも十分にあり得る。 記事の更新履歴が残り、再利用も可能なため、便利な面もあるが、データベースを圧迫する懸念がある。 また、このブログのようにパーマリンクをデフォルトに設定すると、URLは、記事のID(数字)ベースのものになるが、実は、全てのリビジョンが記事のIDを個別に持っている。 URLが連番にならないのは、リビジョンが記事のIDを消費するからだ。 そこで役立つのが、リビジョンの保存機能自体を無効にしたり、制限を加えることが出来るプラグイン「Revision Control 2.0.1」である。 また、記事の作成画面から、リビジョンを個別に削除する機能も付加される。 ・Better Delete Revision 「Better Delete Revision 1.2」は、リビジョンを一括で削除してくれる便利なプラグイン。 「Revision Control」などを導入して、リビジョンの保存機能を無効にしたものの、その時点で、既に沢山のリビジョンが保存されている場合は、これで一括削除すれば良い。 もちろん、「Better Delete Revision 1.2」だけでリビジョン管理を行って良い。 ・Broken Link Checker 「Broken Link Checker 1.2.4」は、記事内のリンク切れを調べてくれるプラグインである。 記事内で外部や内部記事へのリンクを挿入することも少なくないが、リンク切れをチェックするのは困難であるため、このプラグインは重宝する。 「WordPress」の管理画面上の「ツール」->「リンク切れをチェック」から簡単にリンク切れをチェックできる他、「設定」->「Broken Link Checker」では、定期的にリンク切れをチェックし、メールで通知させる設定ができる。 ・Redirection 「Redirection 2.2.3」は、特定のURLでのアクセスを別のURLへリダイレクトする機能を提供するプラグイン。 つまり、リンク切れの救済などに役立ちそうだが、今のところ必要性はないので利用していない。 パーマリンクの設定を変更したり、タイトルを変更してリンク切れを起こした場合は、このプラグインで、新しいURLへ転送(301リダイレクト)することができる。 リダイレクトだけでなく、「404」を返すなど、その他の処理も可能。 設定は、「WordPress」の管理画面上の「ツール」->「リディレクション」から行い、正規表現を用いることも可能。 ・Change Permalink Helper 「Change Permalink Helper 0.1」は、リクエストされたURLが見つからない場合、パーマリンクをチェックし、自動的に新しいURLに転送(301リダイレクト)してくれるらしい。 パーマリンクを変更した際は、非常に重宝しそうな気がするが、今のところ、このプラグインを使用していないので、自動処理がどこまで信頼出来るものなのかは不明。 転送先の判断には、URLの「スラッグ」を用いるらしいので、例えば、このブログのような「投稿 ID」を用いたパーマリンクから、別の形式のパーマリンクに変更する場合は、 /%year%/%monthnum%/%post_id% と言った風に「投稿 ID」を含むものにすれば、無難に処理してくれるのかもしれない。 投稿の「スラッグ」を使うという意味であれば、入力していないので絶望的だ。 ・Link to Post 「Link to Post 1.0.2」は、自ブログ内の記事、ページ、カテゴリ、タグへのリンクの挿入を手助けするプラグインだ。 記事に、自ブログ内の別の記事へのリンクを挿入することが多いなら、ぜひ、インストールしておきたい。 インストールすると、記事作成の際に使用する「ビジュアルエディタ」にリンクを作成するためのアイコンが追加される。 記事、ページ、カテゴリ、タグへのリンクが簡単に選択できる様になっている。 ・TinyMCE Advanced 「TinyMCE Advanced 3.3.9」は、記事作成の際に使用するビジュアルエディタの機能を強化するプラグインで、記事作りに拘るなら不可欠なツールだ。 「TinyMCE Advanced 3.3.9」は、バージョンアップが止まっている感があり、同様のプラグインに「CKEditor For … 続きを読む →

Posted in WordPress, ネット・PC | Tagged , , , , , , , , , | Leave a comment

WordPressを携帯電話対応サイトにする

携帯電話でウェブを参照するユーザーは、けして少なくない。 「WordPress」は、プラグインの導入によって、簡単に携帯電話向けに簡略化されたテーマでの表示が可能になるので、ぜひ、携帯電話に対応させたいところだ。 しかし、一口に携帯電話と言っても様々な種類があり、標準搭載されているブラウザの機能も様々である。 場合によっては別のブラウザを追加インストールしている可能性もある。 携帯電話の場合もPCと同様にその環境は複雑であり、一括りに考えることは出来ない。 ゲーム機などの携帯端末まで考慮すると更に複雑になる。 PCサイトの参照を目的としたフルブラウザで参照しているユーザーに対して、携帯電話向けの簡略されたテーマで表示することが、果たして親切なのか?それともパフォーマンスに優れた携帯電話向けのテーマで表示することが親切なのか? 色々と考え始めるキリがないが、幸いそこまで高度な設定が可能なプラグインを私は知らないので、もう少し、シンプルに考える。 とは言え、かなり複雑である。 基本的には、搭載されている、もしくは使用している可能性があるブラウザによって分類する必要がある。 以下、主な携帯端末のブラウザを分類した。 NTTドコモ iモード iモードブラウザ au Ezweb PCサイトビューアー ソフトバンク Yahoo!ケータイ PCサイトブラウザ ウィルコム Opera NetFront Opera(フルブラウザ) NetFront(フルブラウザ) イー・モバイル NetFornt NetFront(フルブラウザ) Apple Mobile Safari(AppleWebKit系、iPhone、iPad、iPodに搭載) Windows Mobile IE系 NetFront Android AppleWebKit系 BlackBerry ブラウザ不明 Palm OS AppleWebKit系 Symbian OS(ノキアなど) UIQ搭載ブラウザ S60搭載ブラウザ(AppleWebKit系) 任天堂 DS(Opera系?) ソニー PSP その他 Opera Mini 携帯電話への対応は、プラグインで簡単に実現出来るが、一番の問題は、実際に、どの端末で携帯電話用テーマを使って表示されるかの確認である。 ユーザーエージェントを偽装できる「FireFox」のアドオン「User Agent Switcher」や「Google Chrome」のエクステンション「User-Agent Switcher for Chrome」を用いれば、レイアウトの確認までは無理としても、携帯用テーマで表示されるか否かの確認は出来る。 使用する前に、「Options」で、ユーザーエージェントを設置する必要があるが、携帯端末のユーザーエージェントは、「ユーザーエージェント – Wikipedia」「userAgent一覧-ユーザーエージェント一覧」で確認出来る。 追記 携帯電話のブラウザをシュミレーションするFireFox用プラグイン「FireMobileSimulator」が「FireFox4」対応となった。 対応機種は限られるが、こちらの方が実際に近い画面を確認できる。端末の情報さえ得られれば、自身で機種を追加することも可能。 以下、「WordPress」を携帯電話対応にするためのプラグインを紹介する。 ・WPtouch 1.9.25 「WPtouch」は、「WordPress」に標準でインストールされているプラグインで、iPhone、iPod touch、Android、Blackberry Storm、Blackberry Torch、Palm Preやその他タッチタイプパネルの携帯端末を自動的に判別し、専用のテーマでの表示を行う。 Blackberryがリストにあるが、全てのモデルが対象ではない。 ユーザーエージェントを偽装したテストの結果では、対応リストにはないものの、iPadにも対応している様に思われる。 あくまで特定の携帯端末が対象で、日本のものを含めて、一般的な携帯電話には対応していないので、後で述べる「Ktai Style」と併用すると良い。 標準のテーマは、iPhoneアプリを意識したデザインで、見た目も悪くない。 日本語にも対応しており、「Regionalization Settings」を「Japanese」に変更すれば、日本語テーマでの表示になる。 コメントシステムの「DISQUS」にも対応している。 基本的に有効化するだけで使えるが、メールアドレスを公開したくないなら設定で「Enable Email Menu Item (Uses default WordPress admin e-mail)」のチェックを外して置くこと。 設定の「Adsense」に「Adsense ID」を設定できる。 ※「Adsense ID」は、「Adsense」の管理画面右上に表示される「pub」で始まるコード。 「Google Analytics」でアクセス解析を行う場合は、PC用のテーマとは別に、対応が必要。 「Stats & Custom Code」で、「Google Analytics」のトラッキングコードを設定出来るが、携帯電話用のトラッキングコードが設定出来る訳ではない。 ・WordPress Mobile Pack 1.2.4 「WordPress Mobile Pack」は、殆どの携帯端末での表示に対応している。 … 続きを読む →

Posted in WordPress, ネット・PC | Tagged , , , , , , , , , , , | 1 Comment

WordPressにアクセス解析を組み込む

今回は、「WordPress」にアクセス解析を組み込む方法についてまとめてみた。 「WordPress」では、外部のアクセス解析を利用することは勿論の事、様々なアクセス解析がプラグインという形で提供されているのでアクセス解析に関しては困ることはないだろう。 ここでは、「Google Analytics」、「StatPress」系、「WordPress.com Stats」について解説する。 ・Google Analytics ご存知の通り、「Google Analytics」は、Googleが提供するアクセス解析だが、WordPressにも比較的容易に組み込める。 テーマが「Weaver」なら、「外観」->「Weaver Admin」->「Advanced Options」の「<HEAD> Section」にアクセス解析用のコードを追加しても良いし、テンプレート「ヘッダー(header.php)」の「</head>」の前に直接書きこんでも良い。 テーマのバージョンアップでの上書きを避けたいなら、プラグインを利用する方法もある。 私は「Google Analytics for WordPress 4.0.11」を使っているが、真面目に比較して選んだわけではないので、正直、これが優れているかは分からない。 プラグインを利用するメリットは、単にアクセス解析用コードを挿入する以上の機能が利用出来ることにある。 「Google Analytics for WordPress 4.0.11」でも、様々な機能が提供されているようだが、全体は把握してない。 とりあえず、「Track outbound clicks & downloads」という機能を有効にして、外部リンクへのアクセスをイベントとして記録してる。 これを普通にやろうとすると、全てのリンクタグを修正する必要があるので、チェック1つで出来るのはとても便利だ。 「Google Analytics」の欠点は、「WordPress」の管理画面上で、アクセス解析データを参照できない事だが、それを解決するプラグインも沢山存在するので、必要ならばインストールするとよい。 ・StatPress系 「StatPress」と、その派生の「StatPress Reloaded」や「NewStatPress」は、リアルタイムでアクセス解析してくれる優れたプラグンである。 ただし、私は、元祖の「StatPress」は使ったことがない。 「StatPress Reloaded」は、「StatPress」の改良版としてリリースされているが、暫く更新がストップしているので、「StatPress」と比較して、実際のところ、どちらが優れているかは不明だ。 リリースが古いこともあって「StatPress Reloaded 2.7.1」は、ユーザーエージェントの解析に難があり、正しい結果を表示しない。 「NewStatPress 0.1.2」はリリース自体が新しいので、まだまだユーザー自体が少ないが、「StatPress Reloaded 2.7.1」の欠点は、大幅に改善されている。 「StatPress」系は、アクセス記録を、WordPress同様に自サーバーのデータベースに格納するため、データが肥大化した場合は、データを管理画面から削除する必要がある。 「StatPress」系の特徴は、視覚的にも優れていることだ。 ブラウザ、国、リファラなどの情報を見やすく表示してくれる。 「Details」の画面では、表だけでなく、円グラフや地図などを使った表示となるため非常に分かりやすい。 「Spy」では、訪問者毎の詳細を確認できる。 難点は、日本語の一部が化けることだが、視認性を悪くする程ではない。 ※上の画面は、すべて「NewStatPress 0.1.2」のもの。 人気ページやアクセス数を表示するためのウィジェットも備えているので、カウンターを表示したい人には便利だ。 「StatPress」系のプラグインは、共存させることが出来ない。 少なくともインストールは出来るが、有効化出来るのは、いずれか1つのみだ。 私は「StatPress Reloaded 2.7.1」から「NewStatPress 0.1.2」乗り換えたが、まず「StatPress Reloaded 2.7.1」を無効化し、「NewStatPress 0.1.2」を有効化した後に「StatPress Reloaded 2.7.1」を削除した。 アクセス記録は「StatPress Reloaded 2.7.1」から正しく引き継がれたように見える。 管理画面から「NewStatPressUpdate」を実行したが、一応、無事に終了はしたもののエラーが出た。 単純なアップデートではないので、エラーは仕方がないかもしれない。 同系統とは言え、全く別のプラグインなので、データベーステーブルにも相違があるのだろう。 とは言え、一応、正常に動作しているように見えるので、このまま使うことにした。 バグなのか、私の環境に問題があるのか分からないが、「NewStatPress 0.1.2」では、管理画面でフィードへのアクセス数が表示されない。 ただし、「NewStatPressUpdate」を実行すると、フィードへのアクセス数が反映され、そのタイミングでビジターから除外され、その分、ビジターが減る。 「StatPress Reloaded 2.7.1」、「NewStatPress 0.1.2」の解析結果は、Google Analytics」と比較して、ビジター、ページビューなどは、かなり大きな数値になり、閾値や解析方法が異なるように思われる。 とは言え、スパイダーやフィードへのアクセスは別項目で表示され、管理者(登録者)のアクセスも除外でき、ノイズは抑えられている。 ・追記 ※「NewStatPress 0.1.2」における「NewStatPressUpdate」実行時のエラーについては、後日、「MySQLAdmin」にてデータ格納するテーブルを削除した後、プラグイン自体を再インストールしたが、現象は変わらず。 過去の履歴データを失っただけの徒労だった。 フィードが反映されない点に関してだが、データベーステーブルに関して、本家の「StatPress」との互換性を重視したため、若干、設計が異なる「NewStatPress」には、即時に反映されない項目があるのだろうと思う。 フィードを反映するためには、定期的に「NewStatPressUpdate」を実行するしかないようだ。 「StatPress」系としては、「StatPress Visitors」というプラグインも登場している。 詳細表示できる項目は多いが、逆に、見難いと感じたので使っていない。 一部のデータの反映には「NewStatPress」と同様のアップデート操作が必要で、2項目あり、「NewStatPress」よりも煩雑。 ・WordPress.com Stats 「WordPress.com Stats 1.8.1」は、日本語での画面表示にも対応したアクセス解析プラグインである。 人気ページやカウンターを表示するウィジェットを追加してくれる「WordPress.com Stats Helper 0.5.5.3」も一緒にインストールしておくと便利だ。 「WordPress.com Stats 1.8.1」は、アクセス記録を、自サイトのデータベースに格納するのではなく、「wordpress.com」のデータベースに格納する。 そのため、データベースを圧迫せず、データベース絡みのパフォーマンス低下が起こらない利点がある。 ただし、このプラグインを利用するためには、API Keyが必要となるので「wordpress.com」で、ユーザー登録を行う必要がある。 API Keyは、ユーザー登録完了後に、送られてくるメールに記載されている。 また、「wordpress.com」にログインした状態で、「WordPress.com … 続きを読む →

Posted in WordPress, ネット・PC | Tagged , , , , , | 2 Comments