Monthly Archives: February 2012

Plugin Directoryから削除されたプラグインを検知する

このサイトで使用しているプラグインは、未公開の自作品を除けば全て「WordPress.ORG」の「Plugin Directory」に登録されたものを使っている。 「Plugin Directory」に登録されたものであれば、ダッシュボードで更新通知を受信できるためアップデートが楽というメリットがあるが、実はもう1つの理由がある。 それは、「Plugin Directory」に登録されたものなら比較的安全だろうという考えに基づいている。 WordPress用のテーマやプラグインは、悪意を持って作ることも簡単である。 実際、そのようなテーマやプラグインは少なくない。 そのため、導入前のチェックが重要になる。 チェックを行うツールとして「Theme-Check」と「Plugin-Check」をインストールする手もあるが、これもメッセージの内容が理解できてこそ意味のあるツールなので、敷居は低いとは言えない。 個人的には「Plugin Directory」のプラグインが比較的安全だろうとは思っているが、登録されているプラグイン全てが安全かと言われればそうではなく、そもそも「Plugin Directory」への登録自体が簡単で、ソースコードを提出しなくとも許可される。 実際、登録申請フォーム「Add Your Plugin」を見ると、「Plugin URL」の項目が「required(必須)」になっていない。 過去に「Plugin Directory」でセキュリティ上の問題が発生したことがあり、そのタイミング登録申請したプラグインに対してソースコードの提出を求められたので、最近は面倒を避けるために、最初からソースコードも提出しているおり、現在、すべての申請に対してソースコードの提出が求められていないかは分からない。 しかし、現在もノーチェックで登録が許可されている可能性も高い。 そもそも、登録申請から許可されるまでの時間を考えると、ソースコードを提出した場合でも、殆どノーチェックではないかと思われる。 つまり、すべての登録プラグインが、ガイドライン「Detailed Plugin Guidelines」を守っているとは限らず、「Free Themes Directory」に比べると甘いと言える。 とは言え、「Plugin Directory」はユーザー自体が多いので、万が一、悪意のあるプラグインが登録された場合でも、ある程度の期間公開されれば、ユーザーによって問題が報告され「Plugin Directory」から削除される。 公開からある程度時間の経過しているプラグインは、より安全であるとは言えるだろう。 ただし、公開間もないプラグインが全て危険という意味ではないので誤解のないように。 また「Plugin Directory」から削除される理由としては、プラグインの作者の都合であるケースもあるため、削除されたからと言って危険なプラグインだったとは限らない。 私は、以前から「Plugin Directory」に一度登録された後に削除されたプラグインを簡単に調べる方法が欲しいと思っていた。 削除されたプラグインは問題があった可能性もあるので、それを知りたいと言う理由もあるが、それに加えて運用上の理由が大きい。 私の場合は、ダッシュボードでの更新通知に完全に頼っているので、更新通知によってプラグインをアップデートしている。 更新通知がない場合は、それが単にアップデートが無いだけなのか、「Plugin Directory」から削除されたためなのか知る手段がないので、単にアップデートがないと考えるしかなくなる。 その結果、作者の意思で「Plugin Directory」から登録を削除し、「Plugin Directory」以外の場所で公開されている場合でも、アップデートがないと思って、古いバージョンを使い続けることになるかもしれないからだ。 この問題に対処する1つの方法として、先日「No Longer in Directory」というプラグインを見つけた。 このプラグインは、「Plugin Directory」から削除されたプラグインのリストを保持している。 リストは、バージョン1.0でも8,000行以上もある。 ダッシュボードの「プラグイン」->「No Longer in Directory」にアクセスすると、インストールされたプラグインの中にリストにマッチするものないか調べ、マッチするものがあれば、更にそのプラグインのページが「Plugin Directory」に存在するかHTTP requestによって調べ、ページがなければ、今、現在も「Plugin Directory」から削除されたままであると判断し、警告を表示する仕様になっている。 この方法であれば、リストが間違っていたり、不幸な偶然でリスト致してしまわない限り「Plugin Directory」以外からダウンロードしたプラグインが誤検知されることはない。 大前提としてリストが正確で、今後も更新され続けることが重要であるが、この問題の解決の1つの手段にはなりそうだ。 あまりダウンロードされないと、作者も更新しなくなる可能性があるので、再度、「No Longer in Directory」を宣伝しておく。

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

POST2PDF Converter バージョン0.4 リリース

WordPressの投稿や固定ページをPDF形式でダウンロード出来るようにするプラグイン「POST2PDF Converter バージョン0.4」をリリースした。 最新の「POST2PDF Converter」をダウンロード バージョン0.4では、作成されたPDFをキャッシュする機能を追加した。 過去のバージョンでは、ダウンロードリンクがクリックされる度に、PDFへの変換処理を行う仕様であったが、新しく追加されたキャッシュを有効にすることで、一度変換が行われた投稿に関しては変換を行わず、キャッシュからダウンロードされるようになり、サーバーの負荷が軽減されるようになった。 キャッシュの保持期間の設定は出来ず、無制限であるが、記事の内容が変更された場合は、更新後の最初ダウンロードのタイミングで個別にキャッシュは更新され、変更内容がPDFに反映される。 また、設定のリセットを含め、PDFの内容に影響を与える設定変更を行った場合や、キャッシュを無効にした場合には、すべてのキャッシュファイルがクリアされるようになっている。 記事とキャッシュの内容の不一致が起こらないように配慮しており、手動でキャッシュをクリアすることも出来るが、これは殆ど使う必要はないだろう。 記事とキャッシュの不一致が起こると考えられるケースは、直接、データベース上の記事データを変更した場合で、これをダッシュボード上から実行できるプラグインもあるが、通常の仕様の範囲では、まず、記事とキャッシュの不一致は発生しないと考えて良いだろう。 なお、ダッシュボードからプラグインの自動更新を行った場合も、キャッシュはクリアされてしまうため、これを避けたいならば、アップデートの際、手動で上書きインストールを行えば良い。 キャッシュは、「プラグインディレクトリ/post2pdf-converter/pdfs」に格納されている。

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

初心者による初心者のためのPHP講座 第8回 ループ処理

PHPでは、同じ処理を繰り返し実行するための「ループ処理」を記述出来る。 ループ処理は、PHPでは、出番が多い構文であり、必ずマスターしておくこと。 while構文 while構文はシンプルなループを記述するための構文で、if文と似ている。 while (式) { 処理 } if文の場合は、式が真の場合に処理を実行するが、while文の場合は、式が真である限り、同じ処理を繰り返し実行する。 下記のサンプルは、$countが6未満であれば処理を繰り返す。 $countの初期値は1であり、処理が実行される度に1加算される。 <?php $count = 1; while ($count < 6) { echo $count; $count++; } ?> 従って、上記のサンプルを実行すると「12345」と表示される。 for構文 for構文は、while構文と比較すると複雑な構文で、繰り返しの条件を定義するために3つの式を必要とする。 for (式1; 式3; 式3) { 処理 } 式1は、whileを開始した時に1度だけ実行され、式2は、処理に実行を完了する度に実行される。そして、式3が真であれば処理が繰り返される。 複雑ではあるが、以下のように読み替えると理解しやすい。 for (初期値; 条件式; 増減) { 処理 } 式1で変数の初期値を定義し、式3で変数の増減を定義しておけば、式2の条件式で変数を評価することで意図した回数ループを繰り返すことが出来る。 <?php for ($count = 1; $count < 6; $count++) { echo $count; } ?> 上記のサンプルでは、$countの初期値が1で、処理の度に1増える。 そして、$countが6未満なら処理が繰り返されるため、実行すると「12345」と表示される。 次のサンプルでは、複数の変数の初期値と増減を記述している。 <?php for ($count = 1, $value = 5; $count < 6; $count++, $value–) { echo "\$count:".$count." \$value:".$value."<br />"; } ?> 複数の変数の初期値と増減を記述する場合は、それらをカンマで区切ること。 for構文は、次のように記述しても良い。 for (式1; 式2; 式3): 処理 endfor; do~while構文 while構文やfor構文が、まず条件式を評価した上で、条件式が真であれば処理を繰り返すのに対して、do~while構文は、まず処理を実行してから、条件式の評価が行われる。 つまり、条件を満たしているか否かに関係なく、少なくとも1回の処理が実行され、2回目以降は、条件式が真である場合のみ繰り返される。 do { 処理スクリプト } while(式); 条件評価と処理の順序が逆であるが、基本的にはwhile構文と似ている。 次にサンプルは、$valの初期値が既に条件を満たしていない。 <?php $val = -1; do { echo $val; } … 続きを読む →

Posted in PHP, PHP講座, ネット・PC | Tagged | 1 Comment

PDFファイルを生成するためのPHPライブラリ「TCPDF」

昨年末にWordPressの投稿や固定ページをPDF形式でダウンロード出来るようにするプラグイン、「POST2PDF Converter」をリリースしたところ、予想外に反響があった。 そもそも、同様の機能を持つプラグインは既に複数存在しており、「POST2PDF Converter」は、特に目新しいプラグインではないのであるが・・・。 投稿や固定ページをPDFへ変換するプラグインのうち、人気のものは外部のオンラインサービスを利用してPDFファイルの変換している。 例えば、「Print Friendly and PDF Button」は、「printfriendly」と言うサービスを利用してPDFに変換している。 また、「PDF24 Article To PDF」は、「PDF24」というサービスを利用しており、「PDF & Print Button Joliprint」は、「joliprint」を利用している。 これらのサービスは、PDF変換以外の機能も提供しているケースが多く、概ね高機能である。 対して「POST2PDF Converter」は、「TCPDF」というオープンソースのPHPライブラリを利用しており、外部サービスに依存せず、サーバー上で変換を行う。 もっとも、「TCPDF」を利用したプラグインは、以前から他にも存在しており、この点でも「POST2PDF Converter」が特に目新しいものでは無いのであるが・・・。 どちらかと言えば、「TCPDF」を利用したプラグインは、WordPressのプラグインの中ではマイナーな部類になるが、それは「TCPDF」が機能的に劣ると言うことではなく、UTF-8のWordPressコンテンツとも基本的に相性が良い。 「TCPDF」は、イタリア人のNicola Asuni氏(Tecnick.com S.r.l)によって開発されたPHPライブラリであり、「FPDF」の派生である。 このライブラリを使用するには、PHP 5が必要であるが、PHP 4用のパッケージも用意されている。 PHPのライブラリであるが故に、WordPressとの相性も良く、簡単な記述でDBからHTML形式のコンテンツ取得し、それを「TCPDF」に渡してPDF形式に変換することが出来る。 また、グラフやQRコードなどのバーコードの描画も可能であり、工夫次第で、かなり凝ったPDFを生成できるようになっている。 APIは単純とは言えないが、僅かなコードの追加でHTMLをPDFに変換するための処理を記述できる。 WordPressのようにコンテンツをHTML形式で取得し易いシステムであれば、導入に苦はないはずである。 PDFへの変換処理に関しては「TCPDF Examples」でサンプルが用意されているので、これを真似て書くと手っ取り早いだろう。 少し版は古いが「MONZEN.ORG」で日本語ドキュメントが用意されているので、これも参考になる。 TCPDFについて TCPDF マニュアル 日本語版 ディレクトリパス、フォント、フォントサイズと言った設定パラメーターは「/config/tcpdf_config.php」で定数として設定する形になっており、必要に応じてこれを編集する。 「/config/lang」ディレクトリには、各言語用の設定ファイルが格納されている。 バージョン5.9.145からは日本語用の設定ファイル「jpn.php」が同行されているので、これを使えば良いが、設定ファイルの記述自体は単純であり、足りない言語の設定ファイルも簡単に自作することが出来る。 $l['a_meta_charset'] で文字コード、$l['a_meta_dir']で記述方向(左から右ならltr、右から左ならrtl)、$l['a_meta_language']で言語コード定義する。 そして、$l['w_page']では、「page」の訳を定義する。 下記は、UTF-8、日本語の場合の記述例である。 // Japanese global $l; $l = Array(); // PAGE META DESCRIPTORS ————————————– $l['a_meta_charset'] = 'UTF-8'; $l['a_meta_dir'] = 'ltr'; $l['a_meta_language'] = 'ja'; // TRANSLATIONS ————————————– $l['w_page'] = 'ページ'; //============================================================+ // END OF FILE //============================================================+ この設定ファイルは、最初にrequire_once()で読みこめば良い。 更にもう1つ、言語によって変更すべき要素があり、それがフォントである。 フォントは、setHeaderFont、setFooterFont、SetFont、SetDefaultMonospacedFontメソッドで指定する。 なお、SetDefaultMonospacedFontでは、プロポーショナルフォントを指定することは出来ず、等幅フォントを指定する必要がある。 標準の日本語フォントは、 cid0jp(ArialUnicodeMS) kozgopromedium(Kozuka Gothic Pro) kozminproregular(Kozuka Mincho Pro) の3つであるが、残念ながら文字化け等が発生するケースがある。 場合によっては、オープンソースのTrueType日本語フォントなどをTCPDF用に変換して、それを使った方が良いかもしれない。 バージョン5.9.123からは、TrueTypeフォントをTCPDF用に変換するためのメソッド、addTTFfont()が追加されたので、フォントの変換の際にはこれを利用する。 また、5.9.122以前に同梱されていたツールを使っても良い。 なお、このサイトでもオープンソースのIPAフォントと梅フォントをTCPDF用に変換したものを公開している。 TCPDFは、HTMLタグを解釈し、タグに従ってレイアウトを行った上でPDFに変換するが、全てのタグや属性を正しく解釈できる訳ではない。 また、通常ウェブサイトは、別途CSSを読み込んでレイアウトを行なっているが、このCSSがPDFに反映される訳でもない。(あくまでHTMLのみ解釈する。) そのため、生成したPDFは、実際のウェブサイトとレイアウトが異なってしまう場合が多い。 必要であれば、HTMLにstyle属性を付加するなどして、微調整する必要がある。 PDFに変換される事を意識してHTMLを書くのも良いし、HTMLをそのままTCPDFに渡すのではなく、その前の段階で、HTMLをTCPDFに最適化させる処理を入れても良い。 拘れば、ここが最も面倒な作業になるだろう。

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