wordpressの更新(いわゆるバージョンアップ)をしてみたら、
ブログページも、管理ページも以下のエラーが表示されて、何もできなくなったというお話です。

現在メンテナンス中のため、しばらくの間ご利用いただけません。

結論からいうと、処理中でなく、処理完了後もこのエラーがでているようなら、
SSHやFTPや、レンタルサーバならファイルマネージャみたいので、
サーバ上のwordpressを置いてあるディレクトリ(フォルダ)直下に
「.maintenance」ファイルができてると思うので、これを削除するか、
不安だったら、「.maintenance_org」など適当な名前にリネーム(変更)したら表示されます。

具体的な内容としては、まあ、既に巷に溢れてるんだろうと思いますが、
共有のレンタルサーバとかでwordpressを利用している場合に、FTPのポートが開いているので、
wordpressのバージョンアップを自ずとFTPで行う場面が多くなりそうですが、
バージョンアップ処理を開始して、実際に新しいバージョンのファイルをコピーする前に、
「wp-admin/includes/update-core.php」ファイルの「update_core関数」によって、
以下のようにメンテナンスにロックファイルが作成されます。(関係ないけど直前に古いロックファイルは消してるみたい)

$maintenance_string = ‘‘;
$maintenance_file = $to . ‘.maintenance’;
$wp_filesystem->delete($maintenance_file);
$wp_filesystem->put_contents($maintenance_file, $maintenance_string, FS_CHMOD_FILE);

で、ブログページ側の挙動を追っていくと、　（wordpressを置いているフォルダを起点に書きます）
1. 「index.php」で「wp-blog-header.php」をrequire。

require(‘./wp-blog-header.php’);

2. 「wp-blog-header.php」で「wp-load.php」をrequire。

require_once( dirname(__FILE__) . ‘/wp-load.php’ );

3. 「wp-load.php」で、「wp-config.php」が存在すればrequire。

if ( file_exists( ABSPATH . ‘wp-config.php’) ) {
/** The config file resides in ABSPATH */
require_once( ABSPATH . ‘wp-config.php’ );
：

4. 「wp-config.php」で、「wp-settings.php」をrequire。

require_once(ABSPATH . ‘wp-settings.php’);

5. 「wp-settings.php」で、「wp_maintenance関数」を呼び出し。

// Check if we’re in maintenance mode.
wp_maintenance();

6. 「wp-includes/load.php」の「wp_maintenance関数」が呼び出され、
「.maintenance」ファイルがあり、かつファイル内に記載されているepoch値(エポック値)から
600秒(10分)以内の場合には、「wp-content/maintenance.php」があれば、それを表示。
それがなければ、「 _e( ‘Briefly unavailable for scheduled maintenance. Check back in a minute.’ )」が
表示される。

function wp_maintenance() {
if ( !file_exists( ABSPATH . ‘.maintenance’ ) || defined( ‘WP_INSTALLING’ ) )
return;

global $upgrading;

include( ABSPATH . ‘.maintenance’ );
// If the $upgrading timestamp is older than 10 minutes, don’t die.
if ( ( time() – $upgrading ) >= 600 )
return;

if ( file_exists( WP_CONTENT_DIR . ‘/maintenance.php’ ) ) {
require_once( WP_CONTENT_DIR . ‘/maintenance.php’ );
die();
}
:

7. 日本語設定になっている場合には、「 _e( ‘Briefly unavailable for scheduled maintenance. Check back in a minute.’ )」が
「wp-content/languages/ja.po」に基づいて「現在メンテナンス中のため、しばらくの間ご利用いただけません。」が表示される。

#: wp-includes/load.php:178
msgid “Briefly unavailable for scheduled maintenance. Check back in a minute.”
msgstr “現在メンテナンス中のため、しばらくの間ご利用いただけません。”

そして、管理者ページ側もほとんど同じですが、
「wp-admin/index.php」で

require_once(‘./admin.php’);

「wp-admin/admin.php」

require_once(dirname(dirname(__FILE__)) . ‘/wp-load.php’);

されているので、結果、ブログページの3番以降と同じフローにのります。

あとは、メンテナンスページとして自分の作成した内容を表示したい場合には、
「wp-content/maintenance.php」という名前のファイルを作って、表示させればいいです。

サンプルテキストを置くとしたら、

echo “メンテナンス中です。ご迷惑をお掛けしてすいません” > ./wp-content/maintenance.php

簡単にメンテナンスのテストするなら、コマンドラインから以下をたたいて今のepoch値でロックファイルを作ります。
（※当たり前ですが、wordpressはメンテ中になりますので、ご注意ください）

php -r “echo sprintf(‘‘, time());” > .maintenance

ということで、エラーがでたので、久しぶりにphpのコードを読んで、中身を追って、
どこにでもありそうな処理フローの解説をするという誰得っぽい記事を書いてみました。久しぶりの更新なのに。。

DB Error: mismatch

試した感じからすると、where句の内容に問題があるようだ。

【エラーが出る例】

select * from table where column != ? ;

　 ※「?」はプレースホルダしてるから。
　　　ちなみにSSH経由でmysqlコマンドで接続して実行するとエラーにならない。

【エラーが出ない例】

　select * from table where column <> ? ;

　 ※これだとエラーにならないわけです。

なんでですかね？
　phpとの相性？
　プレースホルダ絡み？
　phpの書き方に問題があった？

ちょっとわからないけど、備忘録として残しておきます。
知ってる人いたら、コメントください。

“Cannot use a scalar value as an array”

が表示されて処理ができなかったときのお話です。

グーグル先生に質問をしてみたところ、
配列を初期化している部分に問題があるのがわかりました。
たとえば、

// 初期化
$test['abc'] = ”;

// 配列に値を入れる
$test['abc']['aaa'] = aaaa;

こんなことしたときにエラーになりました。

要するに、$test['abc']はスカラー変数なのに、$test['abc']['aaa']のように
配列に値をいれようとしてるよ！
という警告のようです。

ということで、初期化している部分をコメントアウトして対処しました。

多分初歩的な内容なんだろうな。。

autoCommit(false);

としてたわけですよ。
で、id を auto_increment するようなテーブルが複数あり、
それらを、insertとかしてたわけですよ。

でも、なぜかDBが更新されないわけですよ。

mysql_insert_id();

の関数を利用して直前のSQLのauto_incrementのIDを引っ張るわけですが、
これが、ちゃんとに取得できるわけですよ。
id が 100とかなってても、100のIDのレコードがテーブルに存在しないわけです。

もう全然わからないと思っていたところ、

commit()

部分を気持ちよく、綺麗さっぱりコメントアウトしてたわけです。
そりゃー　動くわけないですがな。

中途半端にまともなIDなんて返してくれちゃうから、
余計あせっちまいましたよ。

と、いったところで、自分のinnodbの扱いの認識不足と、
注意力不足が招いた結果ですけどね。。

ということで、面倒なくインストールする方法を書いておきます。
やっぱりphpまわりは、pearでインストールできると楽ですよね。

ということで、SmartyとZend Frameworkのpearでの設置方法です。

## Smarty

pear list
pear list-channels
pear channel-discover pearified.com
pear install pearified/Smarty
pear list-channels
pear list

## Zend Framework

pear list-channels
pear channel-discover zend.googlecode.com/svn
pear install zend/zend
pear list-channels

ただ、これをやっても、pear list で一覧に出てきません。。
どうしたらいいんでしょうね。。

この辺は、また何かわかったら、追記することにします。

モジュール版の場合には、.htaccessに「php_value」を書いてみたり
phpのソース（たとえばtest.phpみたいな）ものの中で「ini_set」をして
設定を上書きすることができる(1部の設定を除く)わけですが、
CGI版ではできないようですね。

phpinfoでみても「local」の部分が書き変わってないので、
効いてないってことですね。

実際に試してみましたが、できませんでした。

これを回避する一般的な方法としては、suPHPを利用する形っぽいですね。

詳細は以下のサイトにのってるようですぜ。

FlatEight.com >> FreeBSD/suPHP

具体的には、yum版のApache2とかだと、
/etc/httpd/conf.d/php.conf とかで以下の記述がある場合、
Tracが動かなくなる。

LoadModule php5_module modules/libphp5.so

具体的には、ブラウザ上では、500エラーになり、
エラーログでは、以下のような出力がたくさんでる。

PythonHandler trac.web.modpython_frontend: DatabaseError: unsupported file format

で、上記のLoadModuleをコメントアウトすると、Phpは動かなくなるが、
Tracは動くようになる。

ということで、PhpでSqliteを使う予定がなければ、
以下のようにpdo_sqlite.iniを適当な名前にリネームしてあげればよし。

mv -i /etc/php.d/pdo_sqlite.ini /etc/php.d/pdo_sqlite.ini_org

その後、Apacheの再起動をお忘れなく。
yum版(rpm)のApacheの場合には、

/usr/sbin/apachectl restart

とかでいいですね。

で、以下のサイトを参考にさせてもらいました。

Ryuzee.com >> CentOS4でPHP4から5にするとTracが動かなくなる