kjmtsh

わお、いつの間に写真が…

Codex は、ボランティアのユーザが書いています。英語版も日本語版も同様です。だから、WordPress の現状に合ってないものもあるし、間違いもあります。そうしたところは見つけた人が直す、というのが本来の姿なのですが、私がサボっているだけです。もちろん、ForestRiver さんも書くことができますよ。

dbDelta() は、WordPress 随一融通がきかないので有名です。スペースひとつ間違えてもまともに動いてくれません。まあ、内部のコードを見てもらえばわかりますが、正規表現でちまちまやっているので、仕方がないのです。だから、前もってのデバッグは必須です。使うときには、ドキュメントをよく読み、そこに書いてあることを全て守る必要がありますので、ご注意ください。また、第二引数に false を与えると、テーブル操作は実行せずに、何をしようとしているかを教えてくれるようになってます。

参考にしたコードが古すぎます。

if($wpdb->get_var("SHOW TABLES LIKE '$this->table_name'") != $this->table_name)

これは必要ありません。

dbDelta() 関数のすることは以下の通りです。

1. 該当のテーブル名が存在しないときは、テーブルを作成する。
2. 該当のテーブル名が存在するときは、そのスキーマをチェックする。
3. スキーマが同じなら、何もしない。
4. スキーマが異なるときには、テーブルの構造を変更する。

テーブル名だけをチェックする上のコードが存在すると、2以下の機能が果たせなくなります。ということは、本来なら、上のコードは誤りなのですが、日本語版 Codex にこのコード例があるので、広まってしまったのでしょう。プラグイン作者たちもよく間違えているので、たぶん、英語版 Codex が誤った記述をしていて、日本語版 Codex は、それを引き継いだままなのだと思います。現在の英語版 Codex では修正されています。

しかし、Warning が発生するのは、上のコードではなくて、次の2行です。

$title = $wpdb->escape("初めての投稿です");
$contents = $wpdb->escape("インストールが完了しました");

この wpdb::escape() は、deprecated なので、使ってはいけません。互換性のために残されているだけです。適切なエスケープも期待できません (攻撃を阻止できません)。wpdb::insert() 内部で wpdb::prepare() が呼ばれるので、エスケープ処理は WordPress に任せてください。

@wakuchin さん

ありがとうございます。ほぼ予想どおりの結果ですが、たいへん重要な情報を得ることができました。

利用者が多い「さくら」がこの状況だとすると、わけのわからない不具合に遭遇している方がほかにも大勢いらっしゃるかもしれません。さっさとインストールし直してしまった方は問題がなくなりますが (たぶんです、必ずそうなるとは断言できません)、データベースのエクスポート・インポートで作り直すと、同じ状況を再現するだけになってしまいます。また、不具合にあっている方は、比較的古くから WordPress を使っているはずなので、より多くの投稿を抱えているはずですから、そう簡単に現在のサイトを作り直すわけにはいかない方も多いと思います。

検索してくる人の便も考えて、現在の状況をできるだけ説明しておきます。技術的なことが知りたい場合は、ticket をご覧ください (ここでは述べません)。なお、以下は私の個人的な見解であって、WordPress.org および ja.WordPress.org の公式見解ではありません。内部コードの読解は間違っていないと思いますが、保証はありません。結果について責任を負うこともできません。ご承知おき願います。

1. WordPress の状況

4.1.2 から最新の WordPress までの全バージョンで、MySQL のテーブルで使われている文字集合が、utf8、utf8mb3、utf8mb4、ascii、latin1 でない場合、サーバとのやり取りにテーブルの文字セットを使ってしまうという致命的なバグを含んでいます。途中のバージョンからは修正が入ったのですが、前のバグが直らず、もう一つ、サーバが32ビットシステムの場合、投稿本文とコメント本文、および、postmeta、usermeta などのテーブルの meta_value カラムに入力されるデータが0バイトになるという、こちらも致命的なバグを含むようになりました。

「さくら」はたぶん、32ビット FreeBSD なので、更新の結果が反映されないのは後者のバグのためです。

最初の修正を見ると、バグリポートの「意味」が伝わらなかったのかもしれません。状況がわかって、書き込みをするたびにデータベースに保存されたデータが破壊されることがわかったので、これはマズイと思い、急いだせいもあって、うまく文章を作れませんでした。再度バグリポートを出しましたが、まだ修正はありません。また、「意味」が伝わらないかもしれません。不具合であることは理解できていると思いますので、次回のリリースで何らかの修正が入るはずですが、「意味」が伝わらない場合、またやり直しになる可能性もあります。

2. wakuchin さんの状況

MySQL のテーブルは、ujis (EUC-JP) で作られています。調べたのは、wp_posts テーブルだけですが、他のテーブルも同じでしょう。しかし、WordPress と MySQL との通信には utf8 が使われています。wakuchin さんが MySQL は utf8 だと思ったのは、たぶん、wp-config.php の DB_CHARSET の値が utf8 になっているからだと思いますが、これはテーブルの文字集合ではありません。照合順序 (collation) は、WordPress 内部では、ujis_japanese_ci として扱われているはずです。

この状態だと、WordPress は、DB_CHARSET の値を無視して、ujis で強引に MySQL と通信します。かろうじて、ascii、つまり、英語のアルファベットだけでできているデータは同じ1バイトなので、入力できますが、日本語を含む UTF-8 の3バイトデータは全滅です。WordPress は、ログインしたとたんに、データベースへの書き込みが発生しますが、そのほとんどが ascii でできているので、新規投稿などのページ以外は正常に見えます。新規投稿のページでは、日本語のデータが通信に入るので、ここでユーザが異常に気付きます。

現在の不具合は、すでにデータベースに入力されている日本語には及びませんので、強引なことをしなければ、これまでの投稿などは破損していないはずです。フロントエンドでの表示などに不具合がないのは、データベースからの読み出しのときは、問題のある関数をデータが通らないからです。

3. 対応方法

PHP のバージョンが 5.2.x (「さくら」のサイトでは最後の番号が確認できませんでした) とのことですから、ちょっと気になっています。本来なら、オプションで変更できる 5.3 以上にしてくださいというところなのですが、複数の変更を同時に入れると、それ以降の不具合の特定が難しくなるので、今回に限り、PHP はそのままで、お願いします。うまくいかないときに、試してもらうかもしれません。

また、データベースを utf8 に移行することも、現時点では、保留させてください。失敗すると、これまでの投稿データが破損しますので、あまりうかつなことが言えないのです。最低限、テーブルの構造や投稿データが何バイト入っているかなどの情報を調べてからでないと、アドバイスができません。しかし、将来的には、いつか移行が必要になることは確かだと思います。移行のための手引きを準備することくらいのことはできるかもしれませんが。

さて、具体的な対処方法ですが、現状では、ファイルの一部を書き換える以外に方法がありません。変更するファイルは1つです。

1. WordPress のバージョンを 4.2.2 にする。他のバージョンのファイルが混在しないように注意。
2. wp-includes/wp-db.php をローカルにダウンロードする。
3. wp-db.php をコピーして、片方をバックアップとして残し、もう片方を下のように修正する。
4. 2686行目の

   $queries[ $value['charset'] ][ $col ] = $this->prepare( "CONVERT( LEFT( CONVERT( %s USING binary ), %d ) USING {$value['charset']} )", $value['value'], $value['length']['length'] );

   を

   $queries[ $value['charset'] ][ $col ] = $this->prepare( "CONVERT( LEFT( CONVERT( %s USING binary ), %f ) USING {$this->charset} )", $value['value'], $value['length']['length'] );

   に書き換える (2か所です)。同じく、2701行目からの、

   if ( $charset !== $connection_charset ) {
   	$connection_charset = $charset;
   	$this->set_charset( $this->dbh, $charset );
   }

   の4行をコメントアウトするか、削除する。

5. 修正した wp-db.php をサーバにアップロードし、上書きする。
6. WordPress にログインして、新規投稿、更新を試す。

修正をするときには、使うエディタに注意してください。WordPress をインストールするときに、wp-config.php を編集したエディタなら、問題ありません。

実際のサーバを使っているわけではないので、他に不具合があるかもしれません。結果をお知らせいただけると助かります。要するに、人柱になってね、というお願いです。

今朝、再びバグリポートを出しました。全力は尽くしましたが、理解されるかどうか、わかりません。

@ゆたか ちひろ さん

無理はされなくてけっこうですので、もしよろしければ、下の修正をテストしていただけますか? サイトを危険に晒すような変更ではありませんが、念のため、バックアップを取ってからお試しください。

上で述べた修正部分は削除して、wp-db.php の2686行目をご覧ください。

$queries[ $value['charset'] ][ $col ] = $this->prepare( "CONVERT( LEFT( CONVERT( %s USING binary ), %d ) USING {$value['charset']} )", $value['value'], $value['length']['length'] );

ここの、%d を %f に、また、{$value['charset']} を {$this->charset} に書き換えます。

同じく、2702行目。

if ( $charset !== $connection_charset ) {
    $connection_charset = $charset;
    $this->set_charset( $this->dbh, $charset );
}

この4行をコメントアウトして、実行されないようにします。以上です。

最初の %d に対する修正は、お使いの OS が64ビットで動作している場合は必要ないと思いますが、32ビットか64ビットかを知るのは難しい場合もあると思いますので、念のためです。32ビットの場合、そのままにすると、投稿本文の入力が0バイトになります。

このパッチは、環境によって、SHOW FULL COLUMNS の結果からテーブル名がうまく取れない不具合を直すので、テーブルの character set とは関係ありません。misleading というより、misunderstanding かもしれませんね。

別のところで出した報告に対して、数時間前に pento の変更が入ってますが、trunk または、4.2 branch でテストしてくれと言ってます。ゆたかちひろ さん、もしできるようしたら (読んでいてくれることを願いますが)、テストしていただけませんか? 今のところ、間違いなく、テーブルの character set が原因だとわかっているのは、ゆたかちひろさんだけなので (無理強いはしません)。

私もやってみますか、無理やり作った環境なので、ちゃんとした不具合の環境での(?)テスト結果がほしいです。

とりあえず、時間がないので、1点だけ。

今回行われたデータベース周りの改変でバグや実装として望ましくない部分はないか？

あります。

何行ものコードを通って、結局、どんな入力があっても、それと同じデータしか出力しない部分を見つけました。不正な入力を削除するという目的なのに、肝心のものが素通しです (\xC080 とか通っちゃいます)。どこかで見覚えがあると思ったら、RFC3629 のほぼコピペで…

MySQL が非常にエライので、後始末をしてくれています。まあ、何もしないのと同じコードなので、無駄なことをしているというだけなんですけど、修正案を出すために本気で実装となると、関数をそっくり書き換えになってしまうし、MySQL ができることを PHP でやることに意味があるのかどうか…思案中です。予想では、たくさんのプログラマが気づいていると思います。どうすればいいんでしょうねぇ?

どこに投稿すればいいのかわからないので、とりあえず、ここに投げます。

状況をある程度再現することができました。古い MySQL は用意できなかったので、試したバージョンは 5.6.21 です。

1. WordPress 4.1.1 の場合

文字コードを ujis、collation は ujis_japanese_ci でデータベースを作り、wp-config.php の DB_CHARSET は、

define('DB_CHARSET', 'ujis');

としてインストールします (ここで、utf8 にすると、WordPress が CHARSET を変えてしまうので、再現できません)。これで全てのテーブルが、文字コードは ujis、collation は ujis_japanese_ci として作成されます。インストール自体は完全ではなくて、入力データの日本語文字列が全て削除された状態で保存されていますが、動作はします。

この状態では、クライアントからサーバに ujis を使ってアクセスしようとするので、WordPress から日本語をデータベースに送れません。そこで、あらためて、

define('DB_CHARSET', 'utf8');

としてログインしなおすと、日本語を保存することができるようになります。4.1.1 で正常に見えたサイトは、この状態になっている可能性が高いです。問題なく運用ができます。

ここから、4.1.2 または、4.2 へアップグレードすると、下の状態になります。

2. WordPress 4.1.1 から 4.1.2 または 4.2 へのアップグレードした場合

すでに保存されているデータは正常に表示できますが、新規作成の画面は「エディタが表示されない」やボタンが「レビュー待ちとして送信」などの状態になります。実質、新規投稿ができません。

また、既存の投稿を更新すると、日本語文字列はすべて ???? となり、そのままの状態でデータベースに保存されます。これは不可逆な変更なので、破壊されたデータを復旧する手段がなくなります。

ユーザのデータが破壊されるという、ちょっとまずい不具合なので、データベースの文字コードが ujis の場合 (つまり EUC-JP です)、あるいは、ujis のテーブルを含む場合で、4.2 にアップグレードした場合は、下の変更が有効かどうか試してもらえますか?

なお、この CHARSET というのは、wp-config.php の DB_CHARSET で指定しているものではありません。データベース、テーブル、カラムの CHARSET を確認してください。

CHARSET=ujis, COLLATE=ujis_japanese_ci

のようなものが見える場合は、該当します。条件を整理すると、

1. MySQL サーバ (データベースではありません) のサーバ側文字セットが utf8 である。
2. データベースが ujis である。あるいは、ujis のテーブル、カラムを含む。
3. wp-config.php で、DB_CHARSET に utf8 を指定している。

今時の MySQL なら、サーバ側文字セットが ujis ということはほとんどないと思いますが、一応確認してください。万が一、ujis なら、wp-config.php の DB_CHARSET は、ujis に設定されているはずです。その場合は、また別のことを考える必要があります。

wp-db.php の変更点。2479行目を下のように変更します。一応前後の行をつけておきます。

foreach ( $data as &$value ) {
   $charset = $this->charset; // ここを書き換える

   // Column isn't a string, or is latin1, which will will happily store anythin

運がよければ、これで日本語が通るようになるかもしれません。

また、4.2 で、wp-db.php を 4.1.1 のものと差し替えると直ったという報告もありますが、4.2 では、wp-db.php で新設された関数を、別のファイルが使っているので、別のエラーを誘発します。関連のあるファイルは以下の通りです (GNU GLOBAL を使って調べましたが、漏れがあるかもしれません)。

strip_invalid_text_for_column() 関数を使っているファイル
 -> wp-admin/includes/post.php
 -> wp-includes/comment.php
 -> wp-includes/formatting.php

get_col_charset() 関数を使っているファイル
 -> wp-includes/post.php

これらを同時に入れ替えれば動作するかもしれませんが、未検証です。不具合の特定が難しくなるので、一部を入れ替えるのはあまりお勧めではありません。