Monthly Archives: July 2011

「WP Multibyte Patch」で見るWordPressのバージョン

「WordPress 日本語版」と共にその歴史を歩んできた「WordPress 日本語版」のためのプラグインがある。 「WP Multibyte Patch」である。 「WordPress 2.5 日本語版」にパッケージされて以来、現時点の最新バージョンである「WordPress 3.2 日本語版」まで、欠かさず「WordPress 日本語版」にパッケージされ続けている。 ただし、「WordPress 3.2 日本語版」以降は、ダッシュボードからWordPress本体をアップデートしただけでは更新されず、「WP Multibyte Patch」の単独更新が必要になるので注意して欲しい。 参考記事:WordPress 3.2以降へアップデートする際の問題点 WordPressは、日本版だけでなく、中国語版をはじめとして、マルチバイト文字を使う国の言葉にも翻訳されているが、マルチバイト文字を使うが故の問題を解決するプラグインをパッケージしているものは珍しいと思われる。 これは、日本語版作成チームの1つの成果だろう。 私は、既に登録されているものと勘違いしていたが、「WP Multibyte Patch」が最近になってようやく、「wordpress.org」の「Plugin Directory」に登録された。 おそらく、バージョン3.2以降の問題への対処と思われるが、ダッシュボードで更新通知が受け取れるようになった事は有難い。 WordPress本体をバージョン3.2以降にアップデートしたなら、「WP Multibyte Patch」の更新は、「WordPress 3.2 日本語版」のアップデートに頼らず、ダッシュボードで更新通知があれば、独立してアップデートすることになる。 逆に言えば、バージョン3.2未満では、意識している、していないは別として「WordPress 3.2 日本語版」のアップデートと同時に、「WP Multibyte Patch」を更新していたユーザーが殆どではないだろうか。 つまり、過去においては、インストールされている「WP Multibyte Patch」のバージョンが分かれば、WordPress本体の大まかなバージョンも特定できる可能性が高い。 次に「WP Multibyte Patch」の各バージョンと、それがパッケージされている「WordPress 日本語版」のバージョンをまとめた。 WP Multibyte Patch 1.0・・・WordPress 2.5、2.5.1 WP Multibyte Patch 1.1・・・WordPress 2.6 – 2.6.5 WP Multibyte Patch 1.1.1・・・WordPress 2.7 WP Multibyte Patch 1.1.2・・・WordPress 2.7.1 WP Multibyte Patch 1.1.3・・・WordPress 2.8、2.8.1 WP Multibyte Patch 1.1.4・・・WordPress 2.8.2 – 2.8.4 WP Multibyte Patch 1.1.5・・・WordPress 2.8.5、2.8.6 WP Multibyte Patch 1.1.6・・・WordPress 2.9 – 2.9.2 WP Multibyte Patch 1.2・・・WordPress 3.0、3.0.1 WP Multibyte Patch 1.3・・・WordPress 3.0.2 – 3.1.4 WP Multibyte Patch 1.4.2・・・WordPress 3.2 WP Multibyte Patch 1.5・・・WordPress … 続きを読む →

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

WP SyntaxHighlighter バージョン1.4 リリース

「WP SyntaxHighlighter バージョン1.4」をリリースした。 最新の「WP SyntaxHighlighter」をダウンロード このブログでは、ある程度メジャーなバージョンアップのみ案内しているため、マイナーなバージョンアップで実装された機能は案内していない。 バージョン1.3のリリース以降、7回のバージョンアップを行っており、結果、バージョン1.3.x系だけでも8種類のマイナーバージョンが存在する。 その間にかなりの機能強化が行われているが、細かい説明は省く。 バージョン1.3.9では、「SyntaxHighlighter」が本来持っている機能の殆どを実装し、設定画面でカスタマイズ出来るようにしたつもりだ。 さて、バージョン1.4の新機能の説明に移ろう。 ベータテスト中と言う位置づけではあるが、バージョン1.4から、コメントに書かれたソースコードのハイライトが可能になった。 デフォルトでは、この機能はOFFになっているため、必要に応じて設定画面で有効にする必要がある。 残念ながら、「WP SyntaxHighlighter」の最大特徴である2つのボタンは、コメントにソースコードを挿入する際には利用できない。 そのため以下ように<pre>タグを使用して直接記述する必要がある。 <pre class="brush: xhtml"> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <title>Syntax Highlighting Example</title> </head> <body style="width:500px"> <h1>Syntax Highlighting Example</h1> <p><?php echo 'Hello World!' ?></p> <p>XHTML with PHP script.</p> <div class="tabs"> TAB TAB TAB TAB TAB TAB TAB TAB TAB TAB TAB TAB <p>For 'Smart tabs'.</p> </div> <p>http://wordpress.org/</p> </body> </html> </pre> 勿論、言語以外のオプションも「class属性」で指定可能だ。 ただし、コメントでのハイライト表示が可能になると言うことは、ブログの訪問者にソースコードを含むコメントの投稿を許す事になるので注意は必要である。 勿論、エスケープされていないソースコードがそのまま表示される事がないような機能は実装している。 ソースコードは、コメントが投稿され、データベースに保存される際には、エスケープされた状態になる。 しかし、一旦投稿されたコメントを、権限を持つものが、編集、保存した際には、上記のエスケープ機能は働かない。 そのため、誤ってエスケープされていないソースコードが保存された場合は、ページを表示する直前にエスケープする仕組みも実装している。 ハイライト表示のコメントへの拡張は予想外に実装に苦労した機能でもあり、それなりにテストはしたつもりだが、ソースコードのエスケープに関しては、我ながら不細工な処理を行っているため、ソースコードに含まれる文字列によっては、エスケープによって、ソースコードを壊す可能性がある。 そのため、ベータテスト中という位置づけにした。 不具合があれば、遠慮無く報告して欲しい。 もう1つの新機能は見えない部分ではあるが、Javaスクリプトの動的読み込み機能が強化されている。(言語定義ファイルの動的読み込みではない。) 以前のバージョンでも「投稿」や「固定ページ」では、この機能をサポートしていたが、バージョン1.4からは、「ホーム」、「カテゴリー」、「アーカイブ」、「検索結果」、「コメント」にハイライト表示の対象となるソースコードが含まれるかを自動的に判断し、含まれている場合にのみJavaスクリプトを読み込むようになった。 ただし、「記事」の「抜粋」のみが表示されるページでは、ハイライト表示の対象となるソースコードが含まれている記事の「抜粋」が表示されていれば、見かけ上ソースコードが無くともJavaスクリプトが読み込まれる。 ちなみに、このバージョン1.4は、全くの予定外のリリースであった。 既にバージョン1.5の構想があり、それが本来のバージョン1.4である。 実のところ、本来のバージョン1.4であるバージョン1.5は、ほぼ完成している。 バージョン1.5では、Javaスクリプトだけでなく、CSSを含めて動的な読み込みをサポートする予定である。 ただし、この機能は、ブラウザに依存する部分を増やす結果になるため、敢えてバージョン1.4には実装していない。 将来、バージョン1.5をリリースして不評ならば、先祖帰りし、このバージョン1.4系を本流とするつもりである。

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

謎の人気プラグイン「Maribol IMDB」

「wordpess.org」の「Plugin Directory」には数多くのプラグインが登録されているが、人気のプラグインの上位は、概ね固定的で、アップデートの際にダウンロード数が跳ね上がり、多少の順位変動が見られる程度である。 ところが「Maribol IMDB」と言う見慣れないプラグインが、2011/7/20の時点で2位に食い込んでいるのを発見した。 動画の情報表示するプラグインのようだ。 ちなみに、この時点での1位は、三好隆之氏の「Contact Form 7」。 常に5位以内に食い込んでいる世界的に人気が高いプラグインである。 見慣れないプラグインが、突如、上位に食い込む理由としては、「地道にユーザー数を稼いでいたプラグインが久しぶりのアップデートでダウンロード数を稼いだ。」などが考えられるかもしれないが、このプラグインは、公開から1週間で、それはない。 また、「wordpess.org」で公開される以前に、ブログなどで公開されていた形跡もなく、公開以前に、沢山のユーザーを抱えていたとも考えにくい。 とすれば、公開直後から、人気を獲得したことになる。 「Stat」を見ると更に不思議なデータに気が付いた。 7/17には、13,539回ダウンロードされたが、翌日の7/18には一気に115回に落ち込み、更に7/19には、12,077回に回復しているが、通常ならば、これ程の大幅な変動は考えにくい。 ダンロード回数が落ち込むとしても、通常は、徐々に落ち込むものである。 更に、「Last Week」が「All Time」を上回っている点も奇妙だ。 内容的にも需要がありそうなプラグインだが、どうやったら、こんな風に一気に人気が出るのか謎である。 ちなみに私が公開しているプラグインは、「Contact Form 7」や「Maribol IMDB」の遥か後方にランキングされてる。 しかも、私が作った中でも、最も一般受けしそうな「EZ zenback」は、寒い事になっている。

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

WordPress 3.2以降へアップデートする際の問題点

先日「WordPress 3.2 日本語版」にアップデートした事を書いたが、どうも「WordPress3.2」から、ダッシュボードで本体パッケージを自動更新した際の挙動が変わったようだ。 差分のみ取得し、効率化する機能があるそうだが、単にそれだけなら機能強化であり、特に注意する必要もないのだが、どうも仕様自体が大きく変わったようだ。 結論から言えば、本体パッケージをダッシュボードで自動更新した場合、本体パッケージに含まれるテーマやプラグインは、更新されないようである。 勿論、新規インストールや、FTPでファイルを入れ替える場合は関係ない話だが・・・。 気づいていなかったが、実際、この仕様に起因する問題が「WordPress 3.2 日本語版」へのアップデート時にも発生していた。 ダッシュボードから「WordPress 3.2」にアップデートした数日後に「WP Multibyte Patch」の更新通知があったので、「WP Multibyte Patch 1.4.2」のアップデートした。 「WP Multibyte Patch」は、「WordPress 日本語版」パッケージにバンドルされているプラグインで、通常は「WordPress 日本語版」の更新と共に、最新版が配布され、単独の更新通知自体珍しい事だが、「WordPress 3.2」リリース直後という事もあり、緊急の修正が必要になったのだと思っていた。 ところが後日調べてみると「WordPress 3.2 日本語版」に「WP Multibyte Patch 1.4.2」は含まれており、つまり本体パッケージを更新した際に、なぜか「WP Multibyte Patch」は最新版に置き換わらなかった事になる。 更に調べてみると、「[wp-ja-pkg:1655] Re: 3.2.1」という記事を見つけた。 「WordPress 3.2.1 日本語版」のリリースが遅れている原因もこのあたりにありそうだ。 いずれにせよ、「WordPress 3.2.1 日本語版」のリリース時には、更新時の作業について何かアナウンスがあると思われるので注意が必要だ。 自動更新については、WordPress 本体のアップデートだけでなく、テーマやプラグインの単独自動更新ついても変更があったか否かも気になるが、プラグインの作成者は注意した方が良いかもしれない。 実際、私も、自動更新時の動きはよく分かっておらず、これは事前にテスト出来ないため、実際にリリースするまで結果は分からない。 例えば、プラグインの自動更新の際には、 プラグインを停止。 既存のプラグインのファイルを削除。 新しいプラグインのファイルを取得。 プラグインを再び有効化。 が行われると思っていたが、「WordPress-Amazon-Associate 1.7.0」への自動更新時にトラブルに巻き込まれた事から、どうもこれは間違いであることが分かった。 単に私が知らないだけかもしれないが、自動更新の際の動きについても公式なドキュメントが欲しいところだ。 ソースを見て、動きを確認しろでは、あまりにも不親切である。

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

WordPress 3.2へアップデート

WordPress 3.2 日本語版がリリースされたので、早速、アップデートした。 管理パネルから自動更新したが、特に問題なくアップデートを完了し、今のところ不具合も出ていない。 バージョン3.2のシステム要件は PHP:バージョン5.2.4 以上 MySQL:バージョン5.0 以上 なっており、以前のバージョンと異なり、PHP4はサポートしていないのでアップデートする際は注意が必要だ。 レンタルサーバーによっては、この要件を満たしていないケースもあるかもしれない。 PHPとMySQLのバージョンが分からない場合は、「Health Check」プラグインなどで調べることも出来る。 また、フォーラムでは、不具合と思われる報告も見受けられるので、こちらも注意が必要だ。 バージョンアップ後に正常に動作しないプラグイン、テーマが出る可能性もあるので、不具合が出るようなら「WP Multibyte Patch」以外のプラグインを停止し、標準のテーマに切り替えてみると良いだろう。 バージョン3.2では、パフォーマンスの向上が謳われていたたが、実際、パフォーマンスは向上している様に感じられた。 地味な部分ではあるが、パフォーマンスは、重要な要素である。 管理パネルのデザインも若干変わっているが、基本的にバージョン3.1.Xの大差はなく、さほど目新しさはないかもしれない。 OFFにしている人が多いかもしれないが、管理バーの機能は更に拡張されている。 画面上のブログタイトルの表示が小さくなっているが、私は、ここをクリックしてブログを表示させていたので、少し違和感がある。 バージョン3.2で追加された機能のうち、個人的に最も気になったのがエディターの変化である。 過去のバージョンでも、ビジュアルエディターに「フルスクリーンモード」が搭載されていたが、この「フルスクリーンモード」がHTMLエディターにも拡張され、加えて「集中執筆モード」を搭載した。 ビジュアルエディターやHTMLエディターをフルスクリーンモードに切り替えると、下の画像のようになる。 これだけでも、上部にメニューを配しただけのシンプルな画面構成であるが、暫く時間が経つつ、「集中執筆モード」に移行し、メニューが消え、白紙に投稿だけが表示されような画面になる。 メニューは、マウスオーバーで復元するので、必要な時にだけ表示させる事が出来る。 集中して執筆出来るようにと言う配慮だろうが、どうせなら、使用中のテーマを使って、実際の記事のように表示してくれるモードもあっても良いように思った。 プレビューしながら書けるイメージだ。 「フルスクリーンモード」の仕様変更は、私が公開しているプラグイン、「WP SyntaxHighligher」と「SyntaxHighlighter TinyMCE Button」にも、少なからず影響を与えている。 「フルスクリーンモード」でTinyMCE用のボタンが表示されなくなってしまった。 ビジュアルエディターの「フルスクリーンモード」では、表示されるボタンが激減することからも分かるように、処理が少し特殊になったようで、普通にTinyMCEのプラグインとして追加しただけでは「フルスクリーンモード」では表示されない。 /wp-admin/includes/post.php には、 $buttons = array( // format: title, onclick, show in both editors ‘bold’ => array( ‘title’ => __(‘Bold (Ctrl + B)’), ‘onclick’ => ‘fullscreen.b();’, ‘both’ => false ), ‘italic’ => array( ‘title’ => __(‘Italic (Ctrl + I)’), ‘onclick’ => ‘fullscreen.i();’, ‘both’ => false ), ’0′ => ‘separator’, ‘bullist’ => array( ‘title’ => __(‘Unordered list (Alt + Shift + U)’), ‘onclick’ => ‘fullscreen.ul();’, ‘both’ => false ), ‘numlist’ => array( ‘title’ => __(‘Ordered list (Alt … 続きを読む →

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

SyntaxHighlighter TinyMCE Button バージョン0.7 リリース

「SyntaxHighlighter TinyMCE Button バージョン0.7」を公開した。 最新の「SyntaxHighlighter TinyMCE Button」をダウンロードする バージョン0.7では、ボタンをクリックした時に表示されるポップアップウィンドウの入力オプションのデフォルト値を設定できるようになった。 これは、あるユーザーさんからのリクエストに応えて実装した機能である。 例えば、言語を選択するドロップダウンリストから使わない言語を除外して、リストを自分好みにカスタマイズ出来る。 デフォルトのドロップダウンリストには、かなり沢山の言語が登録されているが、実際に必要な言語は限られるているはずなので、必要ないものを無効にすることでリストをスッキリと整理できる。 また、行番号が必要ないなら、予め行番号を表示しない設定にしておくことで、ボタンでの余計な操作を省くことが出来る。 なお、「使用中のプラグイン」で、特定のプラグインを選択している場合は、そのプラグインの設定に従いデフォルト値を決定しているため、この機能をフルに生かすためには「その他」を選択すると良い。 バージョン0.7では、設定項目が一気に増えたため、設定をリセットするボタンも追加した。 巷では「WordPress 3.2」がリリースされ、既にバージョンアップを済まされている方も少なくないと思うが、「WordPress 3.2」では、ビジュアルエディターのフルスクリーンモードが変更され、フルスクリーンモードでは「SyntaxHighlighter TinyMCE Button」のボタンが表示されなくなってしまった。 フルスクリーンモードへのボタンの追加方法が分かり次第、この点は改善したいと考えているが、まだ情報収集の段階である。 /wp-admin/includes/post.php を見たところ、 「wp_fullscreen_buttons」フックを使えば、何とかなりそうな気がするが・・・。

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

WordPressのプラグインの後始末

プラグインをアンインストールした後、データベースの「options」テーブルの掃除することが習慣になって来ている。 掃除と言っても、プラグインによってデータベースに書き込まれたデータを削除しているだけだが。 最近、偶然に、 http://WordPressのURL/wp-admin/options.php にアクセスすると、「すべての設定」というページが表示され、「options」テーブルに格納されたデータの一覧を見ることが出来る事を知った。 シリアル化されていないものについては、データの更新も出来るようだが、残念ながら削除は出来ない。 WordPress上から「options」テーブルの掃除が出来れば掃除も楽になるが、phpMyAdminを使うしかなさそうだ。 そこで、WordPressの管理画面からMySQLを管理できるプラグインは無いかと探してみたところ、「Adminer」と言うプラグインが見つかった。 「Adminer」は、phpMyAdminのようなMySQLの管理ツールで、それをプラグイン化したものらしい。 高機能なツールなのだが、「options」テーブルを掃除したいだけなので、もっとシンプルな機能のもので十分なのだが・・・。 さて、今回の話題は、以前からプラグインの利用者としても開発者としても気になっていたが、最近、Twitterでも話題になったようだ。 私の作成したプラグインもそうであるが、WordPress用のプラグインの多くが、データベース上に設定値などを格納している。 例えば、アクセス解析プラグインのログなど、頻繁に書き込みや更新が発生するようなデータは、データベース上に独自のテーブルを作成し、そこにデータを格納しているのが通例だが、対して、設定値など頻繁に書き込みや更新が行われないデータであれば「add_option()」を使って、データベース上の「options」テーブルに保存している事が多い。 プラグインを使っている間は、これらデータベースに格納された値は、なんら問題にならない。むしろ、動作に必要である。 ところが、プラグインが不用になり、一旦アンインストールしてしまうと、データベース上のゴミと化す場合も少なくない。 アンインストール時にデータベースの「options」デーブルに追加した値を削除してくれれば良いのだが、そうではない行儀の悪いプラグインも多い。 開発者なら知っていることだが、add_option()で追加されたデータは、delete_option()で簡単に削除できる。 要はタイミングの問題で、プラグインのアンインストール時にdelete_option()を実行出来れば、ゴミを残すこともなくなる。 勿論、その方法は用意されており、プラグインのアンインストール時にdelete_option()を実行したいのなら、下記の様に記述した「uninstall.php」ファイルを作成し、プラグインファイルに含めるだけで良い。 <?php if (!defined(‘ABSPATH’) && !defined(‘WP_UNINSTALL_PLUGIN’)) {exit();} delete_option(‘my_plugin_option1′); delete_option(‘my_plugin_option2′); delete_option(‘my_plugin_option3′); . . . ?> 「uninstall.php」が実行される前に「WP_UNINSTALL_PLUGIN」が定義されているかは、確認したほうが良いようなので上記のような記述になっている。 また、現在は使われていなが、過去のバージョンで使用して値がある場合は、それも記述した方が良い。 同様の処理を「register_uninstall_hook()」を使って実行させる方法もあるが、私のプラグインの場合は、「uninstall.php」を使っている。 アンインストール時の処理とは関係ないが、プラグインが有効化された時、無効化された時の処理を記述する場合は、「register_activation_hook()」、「register_deactivation_hook()」が利用出来るので覚えてくと役立つかもしれない。 しかし、「uninstall.php」や「register_uninstall_hook()」は、WordPress 2.7からの新機能のようなので、もっと古いバージョンでも動作するプラグインの場合は、別の方法をとる必要があるかもしれない。 と言え、開発者にアンインストール時の処理が浸透するまでは、データベースの「options」テーブルの掃除から解放されそうにはない。 様々なプラグインのデータを格納している「options」テーブル自体、雑居ビルのような状態であるため、不要なものを探すだけでも一苦労である。

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