CakePHPではデバッグレベルが2の場合、レンダリングした画面の下部に発行したSQLのログを表示してくれます。

この機能は非常に便利ですが、本番環境などでデバッグレベルを0にしていると、発行したSQLを確認する手段がありません。

本番環境で何かしらデータベースエラーが発生した場合に、発行されているSQLを確認したいと思っても、そのままでは方法が無いのが現状です。

そこで、利用しているデータベースのドライバクラスを改良して、CakePHPのデバッグレベルに関わらず、発行したSQLをログファイルに保存できるように改造してみます。

ロギング用のデータベースドライバを作成

CakePHPのコアファイルに手を入れるのは避けたいので、データベースのドライバクラスを継承したログファイル保存用のドライバクラスを作成します。

ここではMySQLを利用する場合を想定します。
他のデータベースを利用している場合は、適宜利用しているデータベースのドライバクラスにを読み替えて下さい。

ファイルを作成

app/models/datasources/dbo_mysql_log.php を作成します。

dbo_mysqlを継承したコードを記述する

ここでは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 に出力されます。

Facebookのコメントプラグインは設置も簡単で、さらにフィードバックも得られやすい素晴らしいソーシャルプラグインだと思いますが、ちょっとした設定を加えるだけで「コメントの管理画面」を表示できるので、その方法を簡単にまとめてみました。

以下は何も設定していないFacebookのコメントプラグインです。

コメントができる以外に、特に機能はありません。

ここで、ちょっとした設定を加えるだけで下記のような、コメントのモデレーションやコメントプラグインの挙動を設定できる、管理画面を表示することができます。

CONTINUE READING

本日、ドメインをietomi.is-blog.netより、inspire-tech.jpに移転しました。

旧ドメインでもアクセス可能ですが、もしブックマークされている方がいらっしゃれば、URLの変更をお願いいたします。

というわけでドメイン移転をしたので、その際に行ったことをまとめてみます。

前提

自分の場合、下記のような条件でドメインの移転を行いました。

サーバー
変更無し
データベース
同一サーバー上なので変更無し
ドメインのディレクトリへのマッピング
  • ietomi.is-blog.net/www/ietomi.is-blog.net/
  • inspire-tech.jp/www/inspire-tech.jp/
行ったこと
ietomi.is-blog.netinspire-tech.jpに切り替える

新しく取得したドメインを古いドメインと同一のサーバーにマルチドメインとして割り当てて、新しいドメインでWordPressが稼働するようにしました。

ファイルを移動

まずは稼働しているWordPressの全ファイルを、古いドメインのディレクトリ/www/ietomi.is-blog.net/から新しいドメイン用のディレクトリ/www/inspire-tech.jp/に移動します。

何か不具合があったときのために、まずはコピーで対応すると良いでしょう。

データベースの書き換え

ファイルを移動しただけだと、WordPressの管理画面が404エラーになってしまい、ログインすることさえできなくなってしまっています。

これは、WordPressの環境変数に古いドメインが含まれているためです。

また、投稿記事の内容などにも古いドメインが含まれているため、データベースの内容を全て新しいドメインに書き換えてやる必要があります。

下記は最低限変更を書き換えを行ったテーブルです。
必要に応じて他のテーブルも書き換えて下さい。

wp_options
UPDATE wp_options SET option_value=REPLACE(option_value, 'ietomi.is-blog.net, 'inspire-tech.jp')
wp_posts
UPDATE wp_posts SET post_content=REPLACE(post_content, 'ietomi.is-blog.net', 'inspire-tech.jp'), guid=REPLACE(guid, 'ietomi.is-blog.net', 'inspire-tech.jp')

.htaccessのでリダイレクト設定

古いURLを参照した場合に404になってしまうのは問題なので、ModRewireを使ってリダイレクトを設定します。

.htaccess/ietomi.is-blog.net/に設置することにします。

RewriteEngine on
RewriteBase /ietomi.is-blog.net/
RewriteRule ^$ http://inspire-tech.jp/ [R=301,L]
RewriteRule ^(.+)$ http://inspire-tech.jp/$1 [R=301,L]

ステータスコード301を返すことで、検索エンジン等に恒久的なURL移動があったことを伝えます。

移行完了

以上でドメインの切り替えは完了です。

切り替えは非常にあっけなく終わりましたが、ソーシャルプラグインのカウントが0になってしまったのはちょっと寂しいですね。

OGP属性であるfb:adminsに自分のFacebook IDを指定したWebページに、Facebookでログインした状態でアクセスすると、そのWebページに設置したいいね!ボタンの横に「管理用ページ」というリンクが表示されるのにお気付きでしょうか?

このリンクから管理用ページにアクセスすると、Facebookページ(旧ファンページ)のような画面になります。

実は管理用ページというのは、外部のWebページ用のFacebookページのようなもので、管理者であるユーザー以外は見られないということ以外、ほぼFacebookページと同一の機能を持っています。

そのため、いいね!ボタンを押してファンになってくれた方などに、後から一斉にお知らせを配信することが可能であり、使い方によっては非常に便利なページです。

詳細が下記のサイトに載っていますので、是非一度ご覧下さい。

しかし、この管理用ページへのリンクですが、いいね!ボタンの対象であるWebページのog:type属性がarticleの場合には、表示されず、アクセスすることができません。

よって、上述のような使い方ができないのです。

Facebook側の仕様

これはFacebook側のポリシーがあるようで、

あと、ひとつだけ注意すべきなのは og:type が article なものはこのお知らせの機能は使えません。 これは、 article は一時的なものでリアルなモノを指さない(ブログの記事など、それ自体がファンの対象ではない)からだそうです。

フェイスブック、ミクシィ、グリーで使われている OGP (Open Graph Protocol) とは何か – IT戦記

ということで、バグなどでは無く明確な仕様のようです。

表示されない場合はog:typeをチェックしてみる

最初に、

意外と気付いていない方が多いのがこの3つ目です。 冒頭で「外部ページをFacebookページに見せかけれる」と書いたかと思います。 実は、OGPを設定すれば、普通のFacebookページとは違う、「外部ページ用のFacebookページ」が生成されています。 2 この「外部ページ用のFacebookページ」のウォールにコメント・URL等を投稿する事で、そのページに「いいね!」を押した人のニュースフィードに、アップデート通知を送れるのです。

<遂に公開>SEOの2倍のアクセスを稼ぐFacebook活用術。皆が知らない「いいね!」ボタンと「OGP」の設定方法、超解説:ガイアックスソーシャルメディア ラボ/Facebook・twitterの企業利用法についての研究機関

という記述を見て管理用ページの存在を知ったのですが、このサイトではog:type属性がarticleの場合に管理用ページが生成されない点については触れていないため、気づかない方もいらっしゃると思います。

Facebookのいいね!ボタンを設置してfb:adminsを指定してみたけど、管理用ページへのリンクが出ない!とお嘆きの方、当該Webページのog:type属性が、articleになっていないかを確認してみてください。

管理用ページを削除した場合

管理用ページは、一度アクセスするとFacebookページと同様に、Facebookのサイドバーに表示されます。

現在は表示されないようです。アクセスするためには、いいね!ボタンの横にある「管理用ページ」のリンクから行くしか無いようです。(2011.07.09)

そこからFacebookページと同様に管理できるのですが、ここで管理用ページを「削除」をしてしまった場合、次から管理用ページにアクセスできなくなる場合があるようです。

管理用のFacebookページは、いいね!ボタン横のリンクからアクセスするか、URL Linterで当該のページを解析した際に自動生成されるようなのですが、自分の環境だと再生成されなくなってしまいました。

バグなのか仕様なのかわかりませんが、念のため管理用ページの削除をする場合は気をつけて下さい。

どうやらこのエラーはバグのようです。Facebookのバグトラッカーで議論されているようなので、続報があり次第また追記します。 (2011.07.08)

バグの解決がなされたようです。バグトラッカー上でも解決の報告が見られます。自分のWebサイトもURL Linterでのエラーは表示されなくなり、いいね!ボタンにも、正しく「管理用ページ」と「インサイト」のリンクが表示されるようになりました。(2011.07.09)

WebサイトにOGPタグを設定したとき、果たして正しく設定できているのか?と疑問になったり、Webサイトを編集してOGPタグを書き換えたのに、Facebookのウォールやニュースフィードに投稿されたWebサイトの情報が更新されなかったことはありませんか?

そんな時便利なのが、FacebookのURL Linterです。
下記のURLからアクセスできます。

このツールがいったい何かというと、入力されたURLのWebページに正しくOGPタグが設定されているかをチェックして、正しくなければエラーを、正しければどういった内容で設定されているかをレビューしてくれます。

いわば、OGPのチェックツールですね。

Facebookのキャッシュも削除してくれる

またこのツールは、入力されたURLに関するFacebook上の古いキャッシュデータを削除してくれる役割も持っています。

基本的にFacebookもWebサイトクローラーのような物を持っていて、Webサイトに設定されたOGP情報などをキャッシュとして蓄えています。

いいね!ボタンやシェアボタンなどでWebサイトがFacebookのウォールなどに流れる際は、キャッシュがあればキャッシュからデータを読み込むため、一度Facebookに掲載されたWebサイトのOGPなどを変更しても、再度FacebookのクローラーがWebサイトのデータをキャッシュしてくれないと、データが更新されません。

URL Linterは、入力されたURLの古いキャッシュを削除して、新しいデータで上書きしてくれます。

そのため、OGPを設定したり、設定し直した場合に利用する事で、新しい情報を即Facebookに反映させることができます。

WordPress用のプラグインも

WordPressを利用していて、一度公開した記事がFacebookにキャッシュされてしまっている場合、タイトルや内容を変更したとしても、やはりFacebookのキャッシュが優先されてしまうために変更が反映されません。

そんな時、下記の記事で紹介されているプラグインを利用すると、URL Linterをフックして即Facebook上のキャッシュを書き換えてくれます。