CakePHPを利用している上で、一番悩むのがファイルのアップロードとその管理です。
MediaPluginという有名なファイルアップロードプラグインがありますが、高機能・多機能との引き替えに、インストール方法やその利用方法が非常にわかりづらく、さらにプラグインをバージョンアップしただけでエラーを吐いて動かなくなったりと、常時メンテナンス、するプロジェクトに導入するには少々の抵抗があります。
そこで、もっとシンプルで使いやすいファイルアップロードプラグインである、FileBinderプラグインを紹介したいと思います。
FacebookのOpen Graph Protocolの解説ページにはOGPに関する詳しい説明が記載されていますが、og:imageの仕様に関して下記のような記載があります。
og:image – An image URL which should represent your object within the graph. The image must be at least 50px by 50px and have a maximum aspect ratio of 3:1. We support PNG, JPEG and GIF formats. You may include multiple og:image tags to associate multiple images with your page.
Open Graph protocol – Facebook開発者
要はog:imageに利用する画像は、縦横のサイズが50ピクセル以上、アスペクト比は3:1までという仕様のようで、この仕様にあわない画像は取り扱ってくれません。
というような簡単な説明なのですが、あまりに簡単すぎるためか、このog:imageのアスペクト比に関しては、横長の画像なら大丈夫だけど縦長の画像はダメ！という誤解をしている方を、ちらほら見かけます。
しかしながら、このアスペクト比というのは、Wikipediaによると下記のように解説されています。
アスペクト比（アスペクトひ）またはアスペクト・レシオ（Aspect Ratio）とは2次元形状の物の長辺と短辺の比率を指し示す言葉。
アスペクト比とは長辺と短辺の比率ということになので、縦の長さが横の長さの3倍だったとしても、3:1という比率で表現できるわけですね。
ということで、Facebookのog:imageに利用できる画像の規格は、正しくは長辺の長さが短辺の3倍までの画像となります。
実際に縦長の画像をog:imageに登録してみました。
これを指定したページを、FacebookのURL Linterで読み込ませてみます。
URL Linterにも正しく認識されていますね。
WordPressでは本体機能もプラグインも、自動で最新版にアップデートができるという素晴らしい機能があります。
この機能のおかげで、追加機能やバグの修正版が出た場合でも、ボタン1つで最新のパッケージが利用出来るため、いちいちファイルをダウンロードしてサーバー上のファイルを更新するという手間がありません。
とても便利な自動更新機能なのですが、何かの都合で本体を更新出来ない場合や、更新したくないプラグインが存在する場合、サイドバー等に常に更新通知が表示されるため、逆に非常に煩わしいものに変わってしまいます。
そんな時、WordPress本体や特定のプラグインの更新通知を非表示にする方法があるので紹介します。
これは下記のサイトを参考にしました。
利用しているテーマの functions.php に下記のコードを記述するだけです。
add_filter('pre_site_transient_update_core', create_function('$a', "return null;"));
これでWordPress本体のアップデート通知は無効になります。
これは調べてもやっている方がいないようなので、WordPress本体のソースを解析してみました。
利用しているテーマの functions.php に下記のコードを記述します。
add_filter('site_option__site_transient_update_plugins', 'filter_hide_update_notice');
function filter_hide_update_notice($data) {
if (isset($data->response['プラグインのメインファイルまでのファイルパス'])) {
unset($data->response['プラグインのメインファイルまでのファイルパス']);
}
}
「プラグインのメインファイルまでのファイルパス」は、WordPressの wp-content/plugins ディレクトリの直下から、プラグインのメインファイルまでのパスを、相対パスで指定します。
例えば私の環境では、最新版に更新することで大幅に機能低下してしまうため、過去バージョンのまま利用しているYARPP（Yet another related posts plugin）というプラグインがあります。
これを例にすると、下記のように記述します。
add_filter('site_option__site_transient_update_plugins', 'filter_hide_update_notice');
function filter_hide_update_notice($data) {
if (isset($data->response['yet-another-related-posts-plugin/yarpp.php'])) {
unset($data->response['yet-another-related-posts-plugin/yarpp.php']);
}
}
これで、特定のプラグインの更新通知を無効にする事ができます。
先日、今まで利用していたWordPress3.1.4から自動アップグレードを利用してWordPress3.2にアップデートしました。
このWordPress3.2はまだ日本語版のアップデータが提供されていないようなので、英語版になってしまいましたが、過去バージョンの言語ファイルがあるためか、「投稿の一覧」や「インストール済みのプラグイン一覧」などを除いてほとんどが日本語化された状態で利用出来ます。
プラグインが多少エラーを起こしていたくらいで、機能的にもほとんど問題無く利用できる状態のようです。
ただ、英語の未翻訳がどうしても気になる！という方のために、現状でWordPress3.2を完全に翻訳する方法がありましたので、ご紹介します。
基本的にWordPressはi18nに対応しているので、翻訳用の言語ファイルさえあればすぐに多言語化対応が可能です。
そこで、WordPress日本語版のサイトから、最新の日本語ファイルをダウンロードして適用します。
2011年7月9日現在、WordPress日本語版のサイトではWordPress3.2の日本語版はダウンロードできませんが、WordPress3.2に対応した言語ファイルはすでに整っているようです。
言語ファイルのリポジトリから、SVNを利用して、言語ファイルをダウンロードします。
svn checkout http://svn.automattic.com/wordpress-i18n/ja/trunk/messages/ languages
svnって何？という方やsvnの利用出来ない環境の方は、下記のURLにブラウザでアクセスします。
言語ファイルの一覧で表示されるので、ローカルに languages/ というディレクトリを作成し、ファイルを全て保存してください。
WordPress3.2に付いてくるデフォルトのテーマである、TwentyElevenも日本語化する場合は、ローカルに twentyeleven/ というディレクトリを作成し、下記URLに存在するファイルも全てダウンロードしてください。
http://svn.automattic.com/wordpress-i18n/ja/trunk/messages/twentyeleven/
ダウンロードした language/ ディレクトリに存在する .po, .mo という拡張子の言語ファイルを、WordPressの wp-content/languages/ ディレクトリに全てコピーします。
古いファイルが存在する場合は上書きして下さい。
また、TwentyElevenテーマも日本語化される場合は、wp-content/themes/twentyeleven/languages/ に、ダウンロードした twentyeleven/ ディレクトリのファイルを全てコピーしてください。
CakePHPではデバッグレベルが2の場合、レンダリングした画面の下部に発行したSQLのログを表示してくれます。
この機能は非常に便利ですが、本番環境などでデバッグレベルを0にしていると、発行したSQLを確認する手段がありません。
本番環境で何かしらデータベースエラーが発生した場合に、発行されているSQLを確認したいと思っても、そのままでは方法が無いのが現状です。
そこで、利用しているデータベースのドライバクラスを改良して、CakePHPのデバッグレベルに関わらず、発行したSQLをログファイルに保存できるように改造してみます。
CakePHPのコアファイルに手を入れるのは避けたいので、データベースのドライバクラスを継承したログファイル保存用のドライバクラスを作成します。
ここではMySQLを利用する場合を想定します。
他のデータベースを利用している場合は、適宜利用しているデータベースのドライバクラスにを読み替えて下さい。
app/models/datasources/ に dbo_mysql_log.php を作成します。
ここではDboMysqlを継承したDboMysqlLogという名前でクラスを作成します。
そして、SQLを発行するための関数であるexecute関数と、SQLのログ表示に関する処理を行うlogQuery関数をオーバーライトして、SQLをログに保存する設定であれば、実行したSQLをログファイルに保存できるように改良します。
App::import()関数を利用してスーパークラスを読み込んでおかないとエラーが出ますので注意して下さい。
app/configs/database.php ファイルの中で、利用するデータベースのドライバ指定を、先ほど作成したドライバに切り替えます。
public $development = array( 'driver' => 'mysql_log', 'persistent' => false, 'host' => 'localhost', 'login' => '********', 'password' => '********', 'database' => 'test', 'prefix' => '', 'encoding' => 'utf8' );
driverの指定は、作成したドライバのファイル名から dbo_ と拡張子を除いたもので指定しましょう。
config/bootstrap.php に下記のようなコードを記述します。
Configure::write('Sql.log', true);
これで、デバッグレベルに関係なく、発行されたSQLが tmp/logs/sql.log に出力されます。