フォーラムへの返信

15件の返信を表示中 - 1 - 15件目 (全293件中)
  • お久しぶりです。遅くなりましたが、確認してみました。

    リポートした部分は、ほぼ提案どおり直りましたが、pento の書き直しで、また enbug しました。初歩的なプログラミング・ミスです。運がよければ、以下の修正で直ります。行数は開発版のリポジトリにあるファイルをもとにしたので、ちょっと違いがあるかもしれませんが、4.2.3リリース版でも同じコードのはずです。

    wp-db.php の2731行目。

    unset( $data[ $col ]['db'] );

    これをコメントアウトしてください。次に、2750行目からの部分、

    foreach ( array_keys( $data ) as $column ) {
        $data[ $column ]['value'] = $row["x_$column"];
    }

    ここを、

    foreach ( array_keys( $data ) as $column ) {
        if ( ! empty( $data[ $column ]['db'] ) ) {
            $data[ $column ]['value'] = $row["x_$column"];
            unset( $data[ $column ]['db'] );
        }
    }

    と書きかえてください。うまくいかなかったら、またお知らせを。

    言い訳じゃありませんが、リリース間際になって、リポジトリにコミットされたので、テストができませんでした。あらためてコードを読むと、絶対の自信があるならまだしも、これをあの時期にコミットする神経がわからん、というのが正直なところです。チケットの方には、「直ってないよ」という投稿が追加されているので、私からは何も出していません。様子を見てリポートしようと思います。

    フォーラム: プラグイン
    返信が含まれるトピック: 予期しない出力が生成されました。

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

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

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

    フィルタフックやアクションフックを実行するのは、それぞれ、apply_filter()、do_action() 関数です。前者は、add_filter() された関数を、後者は add_action() された関数を優先順位の順番に実行します。どちらも、その時点で、ユーザにデータの変更や追加の処理を許可するための仕組みなので、使う必要はないように見えます。

    入力値を取得する。データベースから正解のデータを取得する。比較する。

    ですから、プラグインのユーザが何等かのデータを追加したり、変更したりする余地がないのではないでしょうか。関数を実行したい場所で実行するようにして、一連の処理全体を非同期実行するようにするのがお勧めです。

    参考: Plugin API

    フォーラム: プラグイン
    返信が含まれるトピック: 予期しない出力が生成されました。

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

    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 に任せてください。

    フォーラム: インストール
    返信が含まれるトピック: 新規投稿等すべての更新が出来ない。
    kjmtsh

    (@kjmtsh)

    ご報告、ありがとうございます。

    古い版を使うのは、セキュリティ・ホールがあるので、お勧めではありませんが、強制はできません。できれば、コメントを受け付けないようにしていた方がよろしいと思います。

    画面が白くなるのは、PHP の構文エラーなので、コードの書き間違いです。こちらからはどこを書き間違えているか知ることができません。編集をするなら、落ち着いて、慎重に作業してください。全角文字を使ったり、綴りを間違えたり、カッコや引用符の対応が間違えたりしただけでも動作しなくなります。また、Windows の場合は、メモ帳やワードプロセッサを使わないようにお願いします。

    読みにくいかもしれないので、編集後、こうなっていてほしい形を、行を折り返して再掲します。書き換える場所は、%d%f に、$value['charset']$this->charset に書き換えです。

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

    コメントアウト部分は、各行頭に二つのスラッシュをいれます。

    //if ( $charset !== $connection_charset ) {
    //	$connection_charset = $charset;
    //	$this->set_charset( $this->dbh, $charset );
    //}
    フォーラム: インストール
    返信が含まれるトピック: 新規投稿等すべての更新が出来ない。
    kjmtsh

    (@kjmtsh)

    @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 を編集したエディタなら、問題ありません。

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

    フォーラム: インストール
    返信が含まれるトピック: 新規投稿等すべての更新が出来ない。
    kjmtsh

    (@kjmtsh)

    @wakuchin さん

    現在の WordPress の状況からして、多くの現象は理解できますが、一部不可解なところがありますので、もう少し情報をいただけると助かります。

    phpMyAdimn を使う必要があるのですが、扱うことができますか? もし、できるなら、次の3つの情報がほしいです。

    1. phpMyAdmin にログインして、SQL のタブをクリックすると、エディタの画面になります。そこに次の文を入力して、「実行」をクリックしてください。

    SHOW VARIABLES LIKE 'character%';

    出力された行をコピーしてください。

    2. 同じく、今度は、下の文を入力して「実行」をクリックしてください。

    SHOW VARIABLES LIKE 'collation%';

    3. 同じく、今度は、下の文を入力して「実行」してください。「データベース名」のところは、その名前を、wp_posts のところは、wp-config.php で設定した「接頭辞」+posts となります。wp2_ のように設定してある場合は、wp2_posts となります。

    SHOW CREATE TABLE データベース名.wp_posts;

    出力が省略された形になることがありますので、全文が表示されていない場合は、印刷用画面にしてコピーしてください。必要なのは、最後の行だけですので、接頭辞など気になるようなら、最後の行だけ、お知らせいただいても結構です。

    以上、よろしくお願いします。

    kjmtsh

    (@kjmtsh)

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

    @ゆたか ちひろ さん

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

    上で述べた修正部分は削除して、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バイトになります。

    kjmtsh

    (@kjmtsh)

    おお、ゆたか ちひろさん、ありがとうございます。私も確認しました。以前の邪悪な処理はなくなったのですが、今度は問題が違うところに移っちゃいました。しかも、別の処理が追加されていて、混在した状態です。状況は厳しくて、前より修正が難しくなってます (一応、本意ではありませんが、上の1行の変更は今でも有効です)。

    もう一度コードの読み直しになってしまったので、もう少し時間をください。人柱のようにしてしまって申し訳ありません。くれぐれも、こまめなバックアップを忘れずにお願いします。データベースのコンバートも視野に入れなければならないかもしれませんので (Kuraishi さんの言うとおり、これが最善であることは確かです)。

    なんとか改善されると良いなと思っているので
    またお役に立てることがあれば、テスト等いたします。

    泣けてきます、ありがとう。ご協力に感謝します、心から。

    kjmtsh

    (@kjmtsh)

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

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

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

    kjmtsh

    (@kjmtsh)

    すいません、前の投稿は忘れてください。夢見てました。

    kjmtsh

    (@kjmtsh)

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

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

    あります。

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

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

    kjmtsh

    (@kjmtsh)

    @ゆたか ちひろ さん

    報告ありがとうございます。

    私が実験したのと同じ事態が現れているとすると、WordPress の不具合となりそうです。開発者にはまだ伝わっていません。似たような例は報告されていますが、別の問題です。このまま放置すると、ずっと直らないままになってしまうので、次回リリースで修正されるように何とかリポートを出そうと思いますが、まだコードを読み切れていないのと、他の要素がからんでいる可能性を排除できないので、少し時間がかかるかもしれません。また、上の修正が最終的な解決方法というわけではないことも、ご承知願います。どちらかというと、弥縫策に近いです。また、別の不具合が生じていないかどうか、教えていただければ、助かります。

    原因は、MySQL のサーバ文字コードと、データベース、テーブル、カラムの文字コードの違いが開発者にわかっていない、もしくは、勘違いしている、あるいは、想定から抜けている、といったところです。これらを同一視した結果、プログラムの中で混同が生じています。

    以下、不安が解消されるかどうかはわかりませんが、状況を説明しておきます。

    データベースが ujis (EUC-JP) になっているサイトがどのくらいあるかわかりませんが、WordPress の必要要件を考えると、そういうサイトでも、サーバとの通信には utf8 (UTF-8) を使っているはずです。OS の環境が UTF-8 になってしまっているということもあります。一方、古くから WordPress で運用しているサイトなら、これも高い確率で、EUC-JP のテーブルを使っているはずです。このとき、EUC-JP で表現できない文字が含まれていないなら、何もせずに UTF-8 で通信すれば、MySQL が内部で変換をしてくれます。

    これは、「文字コードの混在」ではありませんし、MySQL にとっても別に異常な事態でもありません。こういう風にして使えるデータベースなのです。wp-db.php の今回の変更は、テーブルの文字コードで許容できない文字をあらかじめチェックしようというものです。文字コードの違いを利用した SQL インジェクションを予防するという目的もあるかもしれません (コア開発者の議論が読めないので想像です)。

    EUC-JP テーブルを持った MySQL と WordPress との通信は、おおよそ下のようになっています。

    +-------+            +-----------------+            +-------------+
    | table | <- ujis -> | Database engine | <- utf8 -> | PHP library |
    +-------+            +-----------------+            +-------------+
        ^                         ^                            ^
        |                         |                            |
        +------ MySQL ------------+                        WordPress

    断言はできませんが、不具合は、テーブルの文字コードが ujis なら、WordPress と Database engine との通信も ujis のはずと決めてかかっていることからくるようです。ユーザにとっても内部の状況が掴みにくい状況であることは確かです。MySQL の文字コードを聞かれたときに、普通に外から見たら、utf8 と答えるでしょう。また、そう考えていて、問題はありません。通常ならば、と付け加えなければなりませんが。

    あらためて述べると、「データベースの文字コード」と言ったときには、phpMyAdmin が使えるなら、データベースやテーブルをクリックして、そこに表示されているものを見る必要があります。wp-config.php の DB_CHARSET は、utf8 で問題ありません。ですが、これは「データベースの文字コード」ではありません。

    さて、この状況でデータベースを utf8 に変換する必要があるかどうか、ですが、個人的な見解では、よくわからない場合には必要がない、と思っています。特に、現状の運用で問題がないなら、なおさらです。変換は、SQL 文を発行することでできますし、ujis から utf8 の変換は、その逆に比べれば容易ともいえますが、環境も調べず、バックアップも取らず、むやみに実行されても困るので、ここに書くのは控えます。ただ、変換することは、いつでもできると思ってもらってかまいません。

    EUC-JP は、文字データを1バイトと2バイトで表現しますが、UTF-8 は、規格上では1~6バイト、現実には1~4バイトで表現します。4バイト文字は、今回のアップデートで WordPress にコードが追加されましたが、MySQL 5.5.3 以降でしか扱えません。PHP の正規表現で扱えない文字を判定するというところが、ちょっと危うい感じはしますが、とにかく、そうなっています。ご存知かもしれませんが、扱える文字の範囲は、

    EUC-JP < UTF-8

    となります。EUC-JP では扱えない文字が UTF-8 には大量に存在するわけですね。上の条件で、もし、EUC-JP で扱えない文字が MySQL に渡ったら、どうなるでしょうか? MySQL は、エラーを返しません。変換できない文字を ? に変えて、テーブルに保存します。変換できない文字が飛んでくるたびにエラーになったり、止まったりしていてはサーバとしての役割が果たせませんから、当然の仕様です。

    EUC-JP で運用している WordPress サイトでこれがあまり問題にならないのは、たぶん、日本語しか入力されていないからです。通常使う現代日本語なら、EUC-JP で充分にカバーできてしまうのです。半角カタカナでさえ扱えます。広東語の「粵語」は「?語」となりますが、中文の「你好」やドイツ語の “Die fröhliche Wissenschaft” くらいなら、正しい文字が入力されます。

    これで、問題になるのは、EUC-JP で表現できない文字が、入力に含まれる場合ということになります。どうしても、UTF-8 でしか表現できない文字を使いたい、たとえば、4バイト文字の絵文字をそのまま保存したい、というような場合は、当然ですが、データベースの変換が必要になります。そうではなくて、現状で満足ならば、無理をする必要はないと思うわけです。それよりは、バックアップをこまめにとることの方が重要だと思います (ダンプデータは UTF-8 で保存されます)。

    また、データベースの変換を勧めたくない理由は、他にもあります。

    別の問題で、バグリポートを処理した pento さんが、もう utf8 だけをサポートすればいいのではないか、と言われたときに、こう述べています。

    utf8 が最良の解決策であることは認める (実際、WordPress サイトの大多数は utf8 を使っている) けれども、後方互換性を破壊して、それを使うように強いることは断じてありえない。何年も前に作られた多くのサイトがあって、それらは MySQL のユニコードサポートが不十分だったときに作られたものだ。WordPress をアップグレードするために、それら全てのサイトの文字コードを強制的に変更させることが、われわれの選択肢になることはない。

    nacin さんをはじめ、WordPress の開発者たちは、ことあるごとに、この「後方互換性 (backward compatibility)」といいます。あるいは、「現在稼働している WordPress のインストールを破壊しない変更しか許さない」とも言って、PHP 5.2.4 をサポートするために、ある意味、プログラムのスピードアップも、コードの可読性をも犠牲にして、既存のサイトを守ろうとします。反対意見もたくさんありますが、彼らは、WordPress が新たな技術を試すための場ではない、ということを肝に銘じているようです。

    私自身は、そういう開発者たちの姿勢を信頼していますし、Philosophy (心打たれる文章ですが、日本語訳がありません) に書かれた原則に則って行動しているとも思います。頑固さに辟易することもありますが、それだけに、現行のサイトが影響を受けるときには、互換性を維持しつつ、ゆるやかに時間をかけて移行するはずだと思っています。

    だから、公式に utf8 以外のテーブルをサポートしないとアナウンスがあるまでは、ユーザにデータベースの変換をするように勧めたくはありません。ただ、変換をしたいというユーザを止めるつもりもありません。

    もし、ゆたか ちひろ さんが、utf8 に変換したいということでしたら、あらためて、トピックを立て直してください。データベースの詳細がわかれば、協力できるかもしれません。あるいは、できないかもしれません。個々のケースによって、違いますから、一般的な解決策などというものはないと思ってください。

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

    状況をある程度再現することができました。古い 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

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

    フォーラム: 使い方全般
    返信が含まれるトピック: アップロードできる画像サイズが規定より小さい

    よく見たら、まだだれも PHP のバージョンを確認していませんでした。バージョンはわかりますか?

    php_valueが利用できることは、確認しました。

    とすると、mod_php5 はどのユーザ権限で動いてるんでしょうね。一応、念のため、

    <?php
    echo phpversion();
    echo exec('whoami');
    ?>

    とすると、どんな値が返るでしょうか (考えられる可能性を絞るためなので、これで解決できるわけではありません)。

    .htaccess の記述は問題なさそうです。この問題は後回しですね。

    このスレッドを最初から読んでくると、php_value を設定しない状態で、アップロードに成功しているのかどうかがわかりません。もう一度、整理してもらえますか?

    • php_value の設定なしでアップロードに成功するかどうか。ブラウザアップローダではどうか。エラーの場合、どんなエラーが出るか。
    • php_value を設定したときに、変化があるのかどうか。

    ブラウザを右クリックすると、「要素を検証」とか「要素を調査」とかいうメニューが出るので、確認するときにはそれを表示して、「コンソール」または「console」に何か出力があるかどうかを確認しながら行っていただけますか? それから、ブラウザは何をお使いなのかもわかるといいかもしれません。

    おっしゃる通り、現在のところ、エラーメッセージと、現象は整合性があります。class-wp-image-editor.php が media.php で定義されている関数を呼んでいるので、エラーは、たぶん _resize() で出ています。

    以上、まったく成算はありませんが、とりあえず。

15件の返信を表示中 - 1 - 15件目 (全293件中)