WordPressのマルチサイトを利用して子ブログを作った場合、
子ブログでアップロードしたメディアファイルは、
全て /wp-content/blogs.dir/{blog_id}/{year}/{month}/{file_name} に保存されるようになっています。

しかしながら、実際にアップロードしたファイルのURLを取得すると、
/{account_name}/files/{year}/{month}/{file_name} というURLが帰ってきます。
これは、マルチサイト用の .htaccess にURLの書き換え処理が記載されているためです。

# uploaded files
RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]

このURLに直接アクセスすればファイルは表示されますし、通常の利用上では全く問題はありません。

しかしながら、サムネイルを生成する際に非常に便利なライブラリである TimThumbなどを利用する際に、この書き換えられたURLが問題になります。

TimThumbは、与えられたURLから実際のファイルパスを計算し、ファイルを読み込もうとします。

しかし、この与えられたURLは .htaccess により書き換えられたダミーのURLのため、実際にこの場所にはファイルは存在しません。

そのため、書き換えられる前のURLが必要になります。

関数作った

下記のような関数を作ってみました。

function ms_calc_media_url($blog_id, $media_url)
{
	global $wpdb;

	switch_to_blog($wpdb->siteid);
	$url = preg_replace('|^' . get_blog_option($blog_id, 'siteurl') . '/(files/[\d]{4}/[\d]{2}/.+)$|', get_bloginfo('url') . '/wp-content/blogs.dir/' . $blog_id . '/$1', $media_url);
	restore_current_blog();

	return $url;
}

$blog_id に当該のファイルをアップロードした子ブログのIDを指定して、$media_url にファイルのURLを与えれば、書き換えられる前のURLを計算して出力します。

この関数を使うことで、問題無くTimThumbなどのライブラリを活用できます。

WordPressをマルチブログで利用する場合に、子サイトのテーマをあらかじめ設定しておく方法を紹介します。

親サイトの functions.php に下記の記述をするだけです。

function default_theme_setting()
{
	update_option('template', 'theme_name');
	update_option('stylesheet', 'theme_name');
	update_option('current_theme', 'Theme Name');
}

add_action('populate_options', 'default_theme_setting');

theme_name となっている箇所は、テーマのディレクトリ名を入れます。
Theme Name となっている箇所は、テーマの名称を入れておきます。

子テーマを指定する方法

上記の設定で、あるテーマの子テーマを設定しようとすると上手くいきません。
これは、下記の記述にすることで対応可能です。

function default_theme_setting()
{
	update_option('template', 'parent_theme_name');
	update_option('stylesheet', 'child_theme_name');
	update_option('current_theme', 'Child Theme Name');
}

add_action('populate_options', 'default_theme_setting');

parent_theme_name は親テーマのディレクトリ名を入れます。
child_theme_name は子テーマのディレクトリ名を入れます。

要は stylesheet というオプションに子テーマ名を設定し、template というオプションには親テーマを設定しておかなきゃイカンよ、ということです。

WordPressのテーマで、jQueryを利用したプラグインを組み込んでいるのにもかかわらず、エラーが発生して利用出来ないことがあります。

原因

これはテーマ側で wp_enquere_script() 関数を用いて、WordPress本体に附属するjQueryを利用している場合によく発生する問題です。

/* WordPress附属のjQueryを、wp_head() 内で読み込む */
wp_enqueue_script('jquery');

WordPressの wp_enqueue_script() 関数を用いてjQueryを読み込んだ場合、通常利用できるはずのjQueryのインスタンスである$変数が利用できません。

これは、WordPress附属のjQueryでは他のライブラリとの競合を防ぐために jQuery.noConflict() を自動的に実行させているため、$変数が設定されないのが原因です。

対処

テーマ側で独自にjQueryを用意して読み込んだり設置してもかまわないのですが、プラグインなどで wp_enqueue_script('jquery') でjQueryを呼び出されてしまうと、既にテーマ附属のjQueryが読み込まれているのにもかかわらず、WordPressに附属しているjQueryも読み込まれてしまいます。

そのため、scriptタグの記述される順番によっては、WordPress附属のjQueryが優先され、jQuery.noConflict() 関数が実行されてしまうために$変数が使えなくなる事もあります

そのため、いかなる場合にも正常に動作させられるようにするには、jQueryを利用するコードを工夫する必要があります。

問題の起きないコード

下記のように、jQueryのインスタンスを$変数として利用できるスコープを作り、その内部にjQueryを利用したコードを書きましょう。

(function($) {
    /* いつも通りのjQueryを利用したコードを書く */
    $(function() {
        /* 初期化コードなど */
    });
})(jQuery);

こうすることで、WordPressに附属するjQueryが利用された場合でも問題無く$変数を使ったコードを実行することができますし、他のフレームワークとのバッティングも起きません。

WordPress上にてGoogleMapsAPIを利用する必要があったので、比較的使いやすそうなWP-GoogleMapsというプラグインを利用してみたところ、日本語が文字化けしてしまって使い物にならないというバグに遭遇して解決したので、プラグインの紹介とその解決方法を掲載します。

CONTINUE READING

CakePHPではデバッグレベルを0としている場合、あらゆるエラーが非表示になり、CakePHPのエラーをはじめPHPのWarningやFatalエラーも記録されなくなります。

例えば、その状態で致命的なエラーが発生しても、画面が真っ白になったり、ErrorHandler::error404メソッドが実行されるだけで、どこかで能動的に$this->logなどで記録していない限り、解決につながる情報が記録されません。

そんな時、下記ブログを参考にカスタムエラーハンドラや、PHPエラーを記録する条件を定義しておくだけで、手軽にログを取ることができるようになります。

この中の内容で、自分も利用させて頂いている2つめの方法が手軽でよいので、紹介させて頂きます。

/app/config/bootstrap.phpの中にphpエラーログを常に/app/tmp/log/php_error.logに出力するとか
例えば:
if ( Configure::read(‘debug’) == 0 ) {
error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED);
ini_set(‘display_errors’, 0); ini_set(‘log_errors’, 1);
ini_set(‘error_log’, LOGS . DS . ‘php_error.log’);
}

CakePHPでdebug=0の際にset_error_handler – benny毎日ラボ

下記のコードをAPP/config/bootstrap.phpに書いておくだけです。

if (Configure::read('debug') == 0) {
    error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED);
    ini_set('display_errors', 0);
    ini_set('log_errors', 1);
    ini_set('error_log', LOGS . DS . 'php_error.log');
}

これだけで、デバッグレベルが0の場合でも、APP/tmp/logs/php_error.logにエラー情報が記録されるようになります。