以前、CakePHP1.3(ひょっとしたら1.2？)のときにもCronの使い方をメモしたのですが、あちらは通常の、ブラウザから渡されたURLに基づくアクションを疑似的に実行するという、どちらかというと裏技的なやり方であり、CakePHPの本来のShellの使い方ではなかったようです。

今回2.xを使い始めたこともあり、改めてCronの使い方について学習したのでメモします。1.3とは結構変更があったようで、ConsoleというディレクトリがApp内に追加されて自作シェルの使用がより簡単になったっぽいです。なお以下の手順のバージョンはCakePHP2.1.1です。

基本はControllerがShellに変わったような感じで、かなりスッキリ作れます。

クラスファイル作成と、Shellアクション呼び出しのポイント

1. 自作のShellクラスを記述したPHPファイル(A)、Console/cake.phpを起動させるシェルスクリプト(B)、シェルスクリプトを提示実行させるためのCronコマンド(C)、以上のA,B,C3つの設置・設定が必要。
2. 自作Shellクラス名は先頭にシェル名、続いて末尾に “Shell” をつける。
3. 自作Shellクラスは AppShell を継承する。
4. ファイル名はクラス名+”.php”
5. 無名メソッド(Controller の index のようなもの)を使いたいときは main を用いる。
6. メソッドのシグネチャはパラメータをとれない。コマンドで渡した引数は $this -> args でアクセス。
7. 自作Shell クラスファイルの保存場所は app/Console/Command/
8. シェルスクリプトから呼び出すのは app/Console/cake.php
9. シェルから cake.php に渡すアクション引数は “Shell” をつけない。
10. Shell / Web の判定は定数 ‘CAKEPHP_SHELL’ を用いる。
11. アクション共通の前処理は Shell::startup() をオーバーライド。後処理のコールバックは…無い。

と言うわけで、Webの場合の”Controller”とかなり共通点が多いと思います。
ただ、シェルスクリプトの設置やコマンドの打ち方など、直接CakePHPに関係ない部分もあるのでそちらの方で躓くことが多いかも知れない。

実際に例を挙げるとこんな具合

A:自作のShellクラス

/**
 * app/Console/Command/MyShell.php
 */
class MyShell extends AppShell {

    var $uses = array( 'MyModel' ); // モデルを使用する場合はここに記述すれば楽。

    function main() {} // メソッドを無名にする場合は "main" を用いる

    function myMethod() { // メソッド名を指定する場合。
        $arg0 = $this -> args[0]; // コマンドで渡した引数は $this -> args に配列でセットされている。
    }

    /** このようなパラメータの渡し方は出来ない
    function myInvalidMethod( $arg ) {
    }
    */

}

B:シェルスクリプト

1. php へのパス
2. cake.php へのパス
3. シェル名(=Shell クラスの名前から末尾の”Shell”を除いたもの)
4. メソッド名
5. 引数(省略/複数可能。クォータで囲むのが無難。)
6. コマンド”-app”
7. appまでのパス

のそれぞれを順番通りにスペースで区切って保存。

パラメータを指定する場合は、クォータでくくっておいた方が無難。特に先頭が”-”ハイフンから始まるものは -app 以外であっても特別な意味を持つ可能性があるので要注意。

実行権限は755以上にする。

あと、Windows環境で作成したファイルの場合は改行コードを必ずLFとすることを忘れないように。

#! /bin/sh
/usr/bin/php /*********/app/Console/cake.php My myMethod myArg0 myArg1 myArg2 -app /*********/app

C: ジョブコマンド

※ B のファイルまでの(ルートから見た)パスを記述。例えば

/home/user/private/myjob.sh

な、感じ。

以上の A、B、Cを滞りなく設定すればOKなはず。

Linuxとかで普段からスクリプト書いてる人には後半の記述は当たり前のことがばかりではないかと思うのですが、私のようにそういうのが大変な人は参考にしてください。
そういえば最初、Windows しか触ったことが無かったんで”root” とユーザーの違いが分かりにくかったですわ。

おまけ。

コマンドから柔軟に引数を渡す

以上の書き方はシェルスクリプトに引数を固定した場合。これをコマンドから柔軟に指定したい場合は次のようにすればOK。ただ、なんかもっとスマートな書き方があると思います(＾＾；)

B:シェル

#! /bin/sh
/usr/bin/php /*********/app/Console/cake.php $1 $2 $3 $4 $5 -app /*********/app

C:コマンド

/home/user/private/myjob.sh My myFunction myArg0 myArg1 myArg2

呼び出しがShellであるかの是非を知る

Model などで、現在のプロセスがShellなのかそうでないのかを判別する方法として、class ShellDispatcher で定義される定数 ‘CAKEPHP_SHELL’ の使用があります。ちなみに bootstrap.php の読み込みはこの後に実行されるので、そこでもこのフラグをつかえます。

/**
 * lib/Cake/Console/ShellDispatcher.php

ShellDispatcher::run( $argv ); #Console/cake.php
    ↓
new ShellDispatcher( $argv ); #ShellDispatcher::run
    ↓
ShellDispatcher::_initConstants(); #ShellDispatcher::__construct

 */
protected function _initConstants() {
    if (function_exists('ini_set')) {
        ini_set('html_errors', false);
        ini_set('implicit_flush', true);
        ini_set('max_execution_time', 0);
    }

    if (!defined('CAKE_CORE_INCLUDE_PATH')) {
        define('DS', DIRECTORY_SEPARATOR);
        define('CAKE_CORE_INCLUDE_PATH', dirname(dirname(dirname(__FILE__))));
        define('CAKEPHP_SHELL', true);  // ←これ！
        if (!defined('CORE_PATH')) {
            define('CORE_PATH', CAKE_CORE_INCLUDE_PATH . DS);
        }
    }
}

メソッド実行後のコールバックメソッドは・・・「無い」

Controller でいうところの afterFilter のようなコールバックはありません。共通の前処理を行うには AppShell::startup() メソッドをオーバーライドすればいいのですが、後処理のそれはなく、見たところコアに触れざるを得ないようですので、実質的に共通の後処理は個別に書いていくしかない。

このあたり CakePHP はきっちり実装してる印象があるだけにちょっと残念。。。

CakePHPはよく触っていたものの、MySQLについてあまり知らなかったんですが、大規模なデータベースを扱ってみようと思い立ちいろいろ試行錯誤しています。

で、ついさっき感動したのが、40万件のレコードを扱ってるテーブルに簡単なSELECT分を投げて返ってくる時間がなんと5秒もかかっていて、なんじゃこりゃ？って首をかしげてたんですが、INDEXひとつで劇的に早くなったこと。
40万件が大規模かそうでないかはこの際おいておいて、INDEXのつけ方次第でこんなにも速度に変化があるのかと涙が出そうになった。

最初の劇遅いテーブルは簡単に書くとこんな具合。

CREATE TABLE IF NOT EXISTS `shops` (
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
    `name` varchar(255) NOT NULL,
    `status` enum('regular', 'special') NOT NULL DEFAULT 'regular',
    `created` timestamp,
    `modified` datetime,
    PRIMARY KEY (`id`),
    KEY `status` (`status`)
) ENGINE=MyISAM

発行するクエリは

SELECT * FROM `shops` WHERE `status` = 'regular' ORDER BY `id` ASC LIMIT 1

こんなごく単純にレコード一つとってくるだけなのですが、これがなんとびっくり平均5秒！
本来こんなのろまな筈がないのですが、いったい何が起こっているのかさっぱりでした。

いくらなんでもこれは遅すぎる。
何が原因かわからなかったんでクエリから条件を一つずつ削除してみようと思い、まずはとORDER BY句を削除

SELECT * FROM `shops` WHERE `status` = 'regular' LIMIT 1

するとなんと 0.00008秒！
次にWHERE 句だけを削除しても同様に早くなった

SELECT * FROM `shops` ORDER BY `id` ASC LIMIT 1

まぁ、これで早くなるのは当然ですが、しかしなぜ最初の文だとあれほど遅いのだろうか。
エンジンはMyISAMだし、status にインデックス振ってるし、id も当然 PRIMARY KEY にしているし。。。
で、試しに id と status を複数選択してインデックスを追加。

ALTER TABLE  `shops` ADD INDEX (  `id` ,  `status` ) ;

これが実は成功の一歩手前だったんですが、効果がほんの少しあったようで3.5秒程度にはなった。
が、それでも全然遅い。

で、たしかINDEXの順番とWHERE句の順番を同じにしないと意味がないってことだったので、WHERE句ではないと思いながらも
id, status
の順番を逆に
status, id
にして再度INDEXを設定した。

ALTER TABLE  `shops` ADD INDEX (  `status` ,  `id` ) ;

すると！なんと0.0004sec.！！！

この理由は、MySQLは(っていうからには他のは違うのかっていうとよく分かりませんが)1テーブルにつき1インデックスしか使用されないんだということ。
それからやはり順番は大事ってことですね。

ちなみにデータサイズは、インデックスを付加することで3.2MB増えた。
同じような複合インデックスを INT+INTでやると3.5MBの増加、INT単体の場合は2.8MBの増加だった。

CakePHPが2.0になって変更した仕様の一つにControllerのアクション内でComponentを呼び出す方法があるようです。

以前だと

App::import( 'Component', 'MyComponent' );
$MyComponent = new MyComponent();

で良かったはずですが、2.0だと色々と仕様が変わっているため

Argument 1 passed to MyComponent::__construct() must be an instance of ComponentCollection, none given, called in ..........

などとエラーになります。

そこで調べたらより便利な方法が提供されているではありませんか！

$component = $this -> Components -> load( 'ComponentName' );

これなら１行でOKです。

Loading Components On The Fly

You might not need all of your components available on every controller action. In situations like this you can load a component at runtime using the Component Collection. From inside a controller you can do the following:

<?php
$this->OneTimer = $this->Components->load('OneTimer');
$this->OneTimer->getTime();

BaserCMS を初めて使ってるんでメモ。

携帯の判定は /baser/bootstrap.php 内で行っていて、該当した UserAgent の場合に適宜情報を Configure::write() しています。

例：独自で作成した携帯用ヘルパー(AppMobileHelper)またはスマホ用ヘルパー(AppSmartphoneHelper)を用いる場合。
※”MobileHelper” というクラスは、BaserCMSのコアで使用されているので名前が衝突しないように注意です。

App::import('Core', 'BaserAppController', array('search' => BASER_CONTROLLERS));
/**
 * Controller 拡張クラス
 *
 * @package			baser.controllers
 */
class AppController extends BaserAppController {

	function __construct(){
		if( $prefix = Configure::read( 'AgentPrefix.currentPrefix' ) ){
			$this -> helpers = array( 'App' . ucfirst( $prefix ) );
		}
		parent::__construct();
	}
}

しかし、このCMSは簡単にそれなりのものが出来ちゃいますね♪
素晴らしいです。

ありがとう、BaserCMS !

ランサーズというサービスをご存知でしょうか。
知名度は高いらしいですが、恥ずかしながら私は先日知ったばかりです。
利用する機会がありそうなのでメモ。

このサービスは、キャッチフレーズに「仕事マーケットプレイス」とあるように、Web上で仕事を売買する市場のようなもの。
仕事を依頼するクライアントと、受注を希望する者(ランサーと呼ばれる)とのマッチングサイト。
同じマッチングサイトでありながら一般的な求人サイトと決定的に違う点は、このサービスはあくまでもプロジェクト単位でのマッチングであるという点。

お手頃価格でロゴを作ってほしい場合なんかはとても利用価値が高いのではないでしょうか。
ほかに、e-commerceシステムの作成依頼からブログの日記を書いてもらう依頼や、メルマガに登録してもらう依頼なんかもあります。
価格は自由に設定でき、例えばロゴのコンペなんかだと高額の案件ほど沢山の応募があり、質と価格のバランスが自然に取れているようにも見えました。

ランサーズ (lancers.jp)

.htaccess とは何か

• Apacheサーバ(というソフトウェア)に対してディレクトリごとにディレクティブ(=命令)を適用させるためのファイル。
• 設置したディレクトリとそのサブディレクトリにディレクティブを適用させる。
• メイン設定ファイルに記述したディレクティブや上位ディレクトリにある.htaccessのディレクティブを上書きする。
• リクエストのたびに参照される。

ディレクティブとは何か

• Apacheサーバへの命令のこと。コマンド。指示子とも呼ばれる。

メイン設定ファイルとは何か

• httpd.conf 。Apacheサーバの起動時または再起動時に反映されるディレクティブのファイル。
• .htaccess とは違い、一度起動すると再起動するまで変更を反映しない。
• .htaccess で上書き不可能なディレクティブも書かれてある。

Apacheサーバとは何か

• Webサーバソフトウェアの一種で最もシェアが高い。
• 開発はApacheソフトウェア財団が行い、オープンソースであり無料で使用できる。

Webサーバソフトウェアとは何か

• HTTP(HyperText Transfer Protocol)に則り、クライアントのWebブラウザのリクエストを解析して、Webサーバコンピュータ内に存在するデータをHTTPコネクションに送信するソフトウェア。

HTTPとは何か

• WebブラウザとWebサーバの間でHTMLなどのコンテンツの送受信に用いられる通信プロトコル(通信上の取り決め)の一種。
• リクエスト-レスポンス型のプロトコルである。

通信プロトコルとは何か

• ネットワークを仲介してコンピュータ同士が通信を行う場合の取り決めのこと。
• 国際標準化機構(ISO)により7つの階層に分けて標準化されている。
• IPは3番目、TCPは4番目、HTTPは5番目の階層でセッション層と呼ばれるものである。

get_bloginfo(), bloginfo() のパラメータとしてプリセットされている文字列を一覧にしてみました。調べたWordPressのバージョンは3.2.1 です。こうして眺めてみると、公開ページの出力に必要なデータに絞っていることがよくわかります。

bloginfo( $show ) は get_bloginfo( $show, ‘display’ ) で取得した値を echo するラッパー関数の類。

単に get_option() を呼び出しているものは意外と少なかった印象。

• (※1) bloginfo, または get_bloginfo の第2引数に 'display' を渡した場合のみ。
• (※2) 替わりに "url" を使用します。
• (※3) 内部で呼び出している関数の末尾は "I"ですが、キーワードの末尾は"L"。
• (※4) switch 構文の default でもあるため、他に該当しなかった場合もこの処理が行われる。
• (※5) いずれも末尾に'/'などのセパレータはつかない。

get_bloginfo() のフィルタ処理

get_bloginfo() の第2引数に ‘display’ を渡すことでフィルタが適用されます。( bloginfo()は常に適用されます。 )

適用されるフィルタフックは’bloginfo_url’ もしくは ‘bloginfo’ のいずれか一方で、この振り分けを $show に含まれる文字列で判定しているのがWordPressらしいところでしょうか。

具体的には、$show パラメータに ‘url’, ‘directory’, ‘home’ のいずれかが含まれている場合には ‘bloginfo_url’ フックが、それ以外の場合は ‘bloginfo’ フックが適用されます。

デフォルトでは’bloginfo’フックの場合において wptexturize(), convert_chars(), esc_html()の順にフィルタ用関数を通されます。(cf./wp-includes/default-filters.php [Format strings for display.])
‘bloginfo_url’フックの場合はデフォルトでは何も処理をしないようです。

※ちなみに、get_bloginfo() の第2引数は今のところ ‘display’のみが有効。なお、Codex には大文字イニシャルで ‘Display’ とありますが実際は case-sensitive で小文字が正しいです。

[参考ページ]

• Function Reference/get bloginfo « WordPress Codex

管理画面のエラーの内容からスクリプトをgrepなどで辿って調べたいと思っても日本語化されてるので手間がかかって仕方ない。というわけで、いったん英語モードにしようと思ったものの、確か見た記憶のある言語を変更できる管理画面上のインターフェイスがどこにもない。確かに見たはずなんだけど…

調べたところ、マルチサイト化している場合のみ、ブログ単位で管理画面から言語を変更できるようだ。私がうろ覚えしていたのは、たまたまそれがマルチサイト内だったからというわけでした。

// /wp-admin/options-general.php
$languages = get_available_languages();
if ( is_multisite() && !empty( $languages ) ):
// 以下、言語設定用の表示が続く

ここで設定された言語設定はマルチサイトでのみ作成される wp_blogs テーブルの lang_id に格納されるため、単独ブログでは反映するすべがない。

単独のサイトの場合は wp-config.php を編集する必要あり。

define('WPLANG', 'ja');

これをコメントアウトすればデフォルトの英語表記になります。

複数言語のユーザーで同一ブログを編集するためには何らかのプラグインが必要になるのでしょうね、今のところは。

参考サイト：

• Kinopyo Blog: WordPress言語の変更
• hyokoya: 言語設定の変更　英語→日本語　日本語→英語 wordpress

あえて定石から外れたやり方でポストを表示するためのメモ。

// 通常のWordPressループとは別に投稿オブジェクトを取得
$another_post = get_post( $args );

// パーマリンクの取得
$permalink = apply_filters( 'the_permalink', get_permalink( $another_post -> ID ) );

// コンテンツの取得（ だいぶ端折った簡易版 ）
$content = apply_filters( 'the_content', str_replace( ']]>', ']]>', $another_post -> ID ) );

コンテンツの取得は自信ないけどこんなものでしょうか。
ほかに、抜粋（excerpt）や $more の取得などもありますがまたの機会に。
WordPress の定石だとクエリを発行して投稿オブジェクトを取得してそれをループさせてってなるんですけど、どうも扱いが苦手。それにしてもグローバル変数をこれほど多用しながら、よくもここまでの規模のシステムを維持できるものですね。すごい。個人的にはありえないですわ。

WordPress の thickbox のグループ利用でハマったこと。バグなのか私の使い方に問題があるのか不明。
きっと皆さん問題になってるのだろうと検索したのですが見当たらないってことは、私の環境または使い方に問題があるのかもしれませんが、一応解決したので同じ問題に当たった方はご参考にしてください。ちなみに、有名な(?)「thickbox.js から ＠マークを取り除く」ってのではないです。これはもちろん対処済みでした。

(なお余談ですが、WordPress は管理画面で jQuery を多用していて、そのライブラリの thickbox も一般の表示でしっかりと利用できるようにサポートされています。スクリプトとスタイルのハンドルを用意するのみならず、それを一度で呼び出してなおかつマルチサイトでも利用できるような関数として add_thickbox という関数まであります。これをヘッダでコールすれば、wp_head, wp_footer の呼び出し時に必要なスタイルシートとスクリプトが呼び出されます。)

単体表示では”ほぼ”問題なく表示されたのですが、グループ化を行った場合に正常に動作しませんでした。
WordPressのバージョンは 3.1.4 ja
この問題を確認できたブラウザは Firefox 5.0、Chrome 12.0.742.112 m
一方でなんと、 IE9 では動作しました。
ブラウザによって異なるってことは結構微妙な問題なのでしょうか。

まず、あまり重要でない箇所の修正を一点

これはグループ化に関わらない問題で、ブラウザ間の解釈の相違もない単純なものです。
thickboxのラッパー部分で使用する画像(「ロード中」のloadingAnimation.gifと、「閉じるボタン」のtb-close.png)のパスが、相対パス指定になってしまってるので、ページによっては正しくロードされません。(サブディレクトリの下にあるページのみ問題が生じます。)

if ( typeof tb_pathToImage != 'string' ) {
    var tb_pathToImage = "../wp-includes/js/thickbox/loadingAnimation.gif";
}
if ( typeof tb_closeImage != 'string' ) {
    var tb_closeImage = "../wp-includes/js/thickbox/tb-close.png";
}

これはWordPressをデフォルトで使用する場合には問題ないですがパーマリンクをカスタマイズしてURLの階層をひとつでも増やすとNGです。なのでこれは絶対パスに変更せざるを得ないのですが、ここで javascript を用いてURLを決定するコードをあえて書かずに、テンプレートのヘッダに

<script type='text/javascript'>
var siteRootUrl = '<?php echo site_url(); ?>';
</script>

このように記述して、

先ほどの箇所を

if ( typeof tb_pathToImage != 'string' ) {
    var tb_pathToImage = siteRootUrl + "/wp-includes/js/thickbox/loadingAnimation.gif";
}
if ( typeof tb_closeImage != 'string' ) {
    var tb_closeImage = siteRootUrl + "/wp-includes/js/thickbox/tb-close.png";
}

このように修正。このほうが楽だと思います。siteRootUrl という値をほかのスクリプトでも使えますし。というよりも、たぶんWPのバージョンを変更するたびに修正しなくてはならない部類なので、なるべく変更の量を減らしたほうが良いという考えです。

本題

さて話がそれました。肝心の問題はこれではなく、thickbox を rel 属性でグループ化した場合に正しく表示されないということ。
これは修正箇所は3箇所ありまして、この何が不具合を引き起こしているのかは不勉強なため不明です。また、ブラウザによって挙動が異なるようなので、ブラウザの実装に問題があるのかもしれません。どなたか理由がお分かりの方はお教えくださればありがたいです。
いずれにしても上記の環境では画像は一枚も表示されませんでした。スクリプトをalertなどを使って調べた結果、3点に問題が見つかったという次第です。

まず、1箇所目と2箇所目は同じような修正。
93行目と97行目にある   を全て削除。これはデザイン的な空白なのでスタイルシートで余白を取る方向で。なぜこれが不具合を引き起こすのか不明ですが、とにかくこれを削る。(たぶん、’&’が問題。)
つぎに、97行目の <a href=’#'>”+thickboxL10n.prev+”</a> を <a href=’#'>&lg;前へ</a> に変更。
つまり 97行目は最終的に
TB_PrevHTML = “<span id=’TB_prev’><a href=’#'>&lt;前へ</a></span>”;
になります。
これで動くはずですが、気になるので同じように thickboxL10n.next の箇所も変更しておきます。

まとめると次のようになります。

変更前

TB_NextHTML = "<span id='TB_next'>&nbsp;&nbsp;<a href='#'>"+thickboxL10n.next+"</a></span>";
(…略…)
TB_PrevHTML = "<span id='TB_prev'>&nbsp;&nbsp;<a href='#'>"+thickboxL10n.prev+"</a></span>";

変更後

TB_NextHTML = '<span id="TB_next"><a href="#">次へ&gt;</span>';
(…略…)
TB_PrevHTML = '<span id="TB_prev"><a href="#">&lt;前へ</a></span>';

[tsuiki]このあと、インライン表示のコードも大幅に書き換えてカスタマイズした結果、半分近くがリライトされたことになってしまい、何がなにやら。。。jQuery の trim 関数が IE8では非サポートだったってことも知ったり。[/tsuiki]

余談ですが、管理画面で呼び出している thickbox はこれとは別です。上記の操作は管理画面には影響しませんので念のため。