月: 2012年2月

MODX Evolution 1.0.5J-r8以降で有効な方法です。

manager/media/style/MODxCarbon/manager/login.html

上記のファイルをテキストエディタで開き、その内容をチャンクの作成画面に貼り付けます。チャンク名は「ログイン画面」など適当につけてください。続いて、チャンク内のHTMLコードを好きなように編集します。スニペットなども使えます。

global $tpl;
$tpl = $modx->getChunk(‘ログイン画面’);

上記のような内容のプラグインを作って、OnManagerLoginFormPrerenderイベントにフックします。

できあがりです。

ログインできなくなった時は

記述ミスなどのためログインできない場合は、以下のように対応します

assets/cache/siteCache.idx.phpをテキストエディタで開きます。

プラグイン名を探します。今回はチャンク名と同じで「ログイン画面」としています。

適当にリネームします。またはこの行ごと削除またはコメントアウトしてもよいです。

デフォルトのログイン画面が表示されるので、ここからログインして修正作業を行なうことができます。

1.0.5J-r7以前のバージョンの場合

assets/templates/manager/

1.0.5J-r7以前のバージョンの場合は、上記ディレクトリ内のファイルを編集してカスタマイズできます。1.0.5J-r8以降でもファイルでカスタマイズを行ないたい場合は、login.htmlというファイル名で作ると同じようにできます。

MODX Evolution 1.0.5J-r11で、処理の流れがほぼ確定しました。r10以前と比べて、違うのはindex.phpの処理。パスの取得やconfig.inc.php読み込みのタイミングなどに問題があり、汎用的な使い方をする上で問題があったため整理されています。

index.phpの中では、以下の処理が行なわれます。

1. ベンチマークに必要な初期情報をセットします。
2. 設置ディレクトリにautoload.phpというファイルがあればインクルード。MS-DOSのautoexec.batのようなイメージで、管理者が必要に応じて自由に使います。
3. protect.inc.phpを読み込んで、PHPコードを安全に扱うための基礎的な無害化処理を行ないます。危険なデータが入ってこないように、ここでガードします。
4. initialize.inc.phpを読み込んで、MODXのコントロールに必要なパス情報を生成します。
5. config.inc.phpを読み込んで、データベースアクセスとセッション生成に必要な情報を取得します。この時点ではまだデータベースに接続しません。
6. set_parser_mode()関数を実行し、パース展開のモード設定を行ないます。ページ表示を行なうのか管理画面アクセスを行なうのかをここで決定します。
7. startCMSSession()関数を実行し、セッションを開始します。ここから、CMSとしてのシステム制御が始まります。
8. DocumentParserオブジェクト($modx)を生成します。この時点で、MODXが備えるAPIを全て利用できるようになります。
9. $modx->executeParser()が実行され、ページ出力の処理が始まります。ただし、MODX_API_MODEがセットされている場合は、executeParser()を実行せず、DocumentParserオブジェクトにアクセスできるようになった時点で処理が終了します。

executeParser()の処理を説明する前に、DocumentParserオブジェクトを生成する際の初期化処理について説明します。

1. $_REQUEST[‘q’]の値をFIX。フレンドリーURLの処理に必要となります。この処理は1.0.5J-r11で加わったもので、mod_rewriteを使わずここで処理することで、URLで用いると特殊な扱いを受ける「 + 」などの文字や、日本語エイリアスを正確に扱うことができます。
2. DBAPIオブジェクトを生成。この時点ではまだデータベースに接続しません。
3. SystemEventオブジェクトを生成。プラグインのコントロールに必要です。
4. $modx->dumpSQL・$modx->dumpSnippets・$modx->stopOnNotice をセット。デバッグ作業に関係しますが、このタイミングでは無効にします。必要に応じて、後のタイミングで有効にして使用します。
5. ini_set(‘track_errors’, ‘1’)を実行し、PHPが出力するワーニングやエラーをCMS側で巻き取り、イベントログとして蓄積します。
6. 管理画面にログインしていない場合は ini_set(‘display_errors’,’0′)を実行し、PHPのエラー表示を抑制します。本家版ではこの処理に関係なく、詳細なエラー情報を一般ユーザに対して出力するため注意が必要です。

$modx->executeParser()以降の処理は、下記のとおりです。大きな流れとしては、executeParser()・prepareResponse()・outputContent()・postProcess()の順に処理が実行され、スクリプトが終了します。

1. executeParser() – ここで初めてデータベース接続が行なわれ、configの取得を行ないます。サイトステータスの判定によりエラーページの出し分けを行なった後、通常のページ出力であればdocumentMethodのFIXが行なわれ、フレンドリーURLモードが確定します。リソースIDを取得した直後に、最初のシステムイベントOnWebPageInitが実行され、さらに、config[track_visitors]が有効な場合はOnLogPageHitイベント(※非推奨)が実行されます。
2. prepareResponse() – ページ出力に必要な情報の取得が行なわれます。まず、ページキャッシュがあればそれを取得しOnLoadWebPageCacheイベントを実行、そのままprepareResponse()の処理を終えます。OnLoadWebPageCacheイベントを実行する時点でdocumentObject(リソース変数・テンプレート変数)は取得されており、ここで自由に扱うことができます。
   ページキャッシュがない場合はデータベースにアクセスし、documentObjectを取得します。そのページの公開状態・削除状態・権限状態に応じたページ遷移判定を行ない、通常のページ出力として判定されれば、ウェブリンク判定を経てからテンプレートコードとdocumentObject[content](本文です)の取得を行ないます。その直後でOnLoadWebDocumentイベントが実行されます。OnLoadWebDocumentイベントが実行されるタイミングで、パース処理前の documentObject[content] の内容が $modx->documentContent にセットされます。直後にパース処理が実行されます。
3. outputContent() – 最終的なページ出力処理が行なわれます。この時点では、キャッシュの有無に関係ない処理の流れに戻っています。まず、非キャッシュ書式のスニペットコールが残っていれば、これを展開します。続いて、APIを通じて登録されたCSSやJavaScriptがある場合は、これをページ内に挿入します。次に、documentObject[content_dispo]がセットされているリソースであれば、これをダウンロードダイアログに引き渡して関数を終了します。通常のページ出力である場合は、ベンチマークタグの処理を行ない、その値をセットします。最後にシステムイベントOnWebPagePrerenderを実行し、その直後にページの内容を全て出力します。
4. postProcess() – ページ出力後の処理を行ないます。まずOnBeforeSaveWebPageCacheイベントを実行し、ブラウザに出力されたdocumentContentデータとシリアライズされたdocumentObjectを結合し、これをページキャッシュとしてファイルに書き込みます。最後にOnWebPageCompleteイベントを実行し、ここで全ての処理が終了します。