0.9.6.3→1.0.2ｊアップデート テンプレート変数Dateのあつかい

[min-o]

お世話になっております。
modx0.9.6.3から1.0.2ｊへアップデートしました。
evoはこれまでとページ設定での、公開日時など日付部分の書き方が変更になっていますね。

modx0.9.6.3の場合
04-03-2010 10:00:00

1.0.2ｊの場合
2010/03/03 10:00:00

アップデートの際、公開日時、取り消し日時は自動でデータベースも書き換えてくれたのですが
入力タイプでDateを使っているテンプレート変数の値は
04-03-2010 10:00:00
のまま書き換えられませんでした。

プレビューの日付は合っているのですが、これは値をすべて2010/03/03 10:00:00のように変更しておいた方がいいのでしょうか？

ちょっと気になるのが、アップデート終了画面に以下のような警告が出ていたのです。
これが原因で日付が書き換えられなかったのかもしれないです。
とりあえずサイト自体は問題なく表示できているのですが…

必要なテーブルの作成: データベースの警告

MODx setup couldn't install/alter some tables inside the selected database.

インストール中に以下のエラーが発生しました

Column 'description' cannot be part of FULLTEXT index during the execution of SQL statement ALTER TABLE `modx_site_content` MODIFY COLUMN `pagetitle` varchar(255) NOT NULL default '', MODIFY COLUMN `alias` varchar(255) default '', MODIFY COLUMN `menutitle` varchar(255) NOT NULL DEFAULT '' COMMENT 'Menu title'.

いくつかのテーブルはアップデートされませんでした。修正などに起因しているようです。

インストール終了

よろしくお願いします。

-----サーバー環境---------
さくらインターネット　共用サーバ　ビジネスプロ
ネットワーク：インターネット
Apache/1.3.42 (Unix) mod_ssl/2.8.31 OpenSSL/0.9.8e
PHP 5.2.12
MySQL 5.1.42

modx1.0.2J

[yama]

dateタイプのテンプレート変数は現時点では日付対応の対象になってないので、報告されたとおりの状態で合ってます。すっきりしないですが、このへん簡単そうで意外と難しいところで。これはそのまま運用しちゃってください。

アップデート直後にエラーが出力された件は別の話しのようですが、少し気になります。MODxのインストーラは少しおバカなところがあって、実はインストールに失敗しても最後まで「完了」してしまいます。

http://modxcms.com/forums/index.php/topic,18933.0.html
上記に参考情報があります。ただし、このとおりにすればよいということではなくて・・たぶんさくらインターネットのサーバ側に問題があると思うので、念のためにさくらさんに問い合わせてみるとよいかも。

たしかさくらのSQLサーバって、デフォルトの文字セットの照合順序がutf8_unicode_ciのように見えるけどujis(euc)になってるケースがほとんどのはず。config.inc.phpの「$database_connection_charset」の値はutf8になってますでしょうか？たぶんujisになってる気がします。僕はさくらのサーバを利用する案件にあたるたびに、phpMyAdminでutf8に設定し直してます。（対象データベースの操作タブで確認できます）

[min-o]

yamaさん　返信ありがとうございます。
テンプレート変数　Dateの件は了解です。表示には問題ないのでこのまま運用します。

エラーの件、
さくらのSQLサーバ、わたしも最近気が付きまして、新規インストのときは参照順序をutf8_general_ciに直すようにしました。
しかし今回アップデートしたサイトは、
1.以前別のレンサバで新規インストールで運用
　　（初めてだったので参照順序未確認のまま）
2.サクラに引越し
　　しばらくして気が付いて参照順序をutf8_general_ciに変更
3.サクラでアップデート

なので、むかしの設定を引きずっているのかもしれません。
今回のアップデート前と直後、modxのシステム情報で確認したら
-------
データベース文字コード ujis
文字セット照合順序 ujis_japanase_ci
------
このときphpMyAdminを開いて中を見てもutf8_general_ciでしたので、？？だったのですが
数時間後にシステム情報確認したら
--------
データベース文字コード utf8
文字セット照合順序 utf8_general_ci
-------
に直ってました。なにやらナゾですがutf8になってるならいいか、とスルーしてしまいました--;
phpMyAdminでも、各テーブルの参照順序もutf8_general_ciになっていますが、まだどこかにujisが残っているのでしょうか？

[sama55]

こんにちは

phpMyAdminでも、各テーブルの参照順序もutf8_general_ciになっていますが、まだどこかにujisが残っているのでしょうか？

確証は得てないのですが、どうもそんな匂いがしますね。

---

－－お試し案１（一括補正）－－
MySQLのエラーメッセージを基に下の順序でページを巡ってみました。

MySQLが出力してるエラーメッセージの定義）
http://dev.mysql.com/doc/refman/5.1/en/error-messages-server.html#error_er_bad_ft_column　　※ER_BAD_FT_COLUMNが肝っぽい
　↓
ER_BAD_FT_COLUMNについての議論）
http://bogdan.org.ua/2008/02/08/convert-mysql-database-from-one-encodingcollation-into-another.html
※ページを表示してから”ER_BAD_FT_COLUMN”でページ内検索すると３件該当
※DB全体の照合順序ではなく個別フィールドの照合順序に問題がありそう
※偉い人がＤＢの各テーブル、各フィールドの照合順序を"utf8_general_ci"に変更するプログラムを公開してる模様
　↓
change-collation-on-all-tables-and-columns-in-mysql　というツールのありか）
http://www.phoca.cz/documents/38-tools/ ... n-database
※日本語環境では問題があるようです（スミマセン）。下のmin-oさんの記事も必ず読んでください。
viewtopic.php?p=1654#p1654

このプログラムはＤＢ内のすべてのテーブルのすべてのフィールドの照合順序を"utf8_general_ci"に書き換えるので、DB内に"utf8_general_ci"にしてはまずいテーブルが混在してる場合は使えません。
（さくらはＤＢが原則一つなので要注意）
上記のスクリプトは自分もダウンロードしてみて、試験的にローカルサーバで実行してみましたが、しっかり処理してるようです。
適用方法は簡単。
　・ファイルをダウンロード
　・解凍
　・フォルダをサーバにアップ
　・index.phpにアクセス
　・表示画面でＤＢの情報を入れて実行
　・発行されたSQLと実行結果が表示されます
　・フォルダ削除　（忘れずに！）

---

－－お試し案２（マニュアル補正）－－

エラーメッセージからエラーになるテーブル名とフィールド名を一つづつ特定し、phpMyadminから個々に照合順序を確認後マニュアルで補正

---

以上、どちらかを行った後に、再度アップグレードしてみる。

[min-o]

こんにちは。
sama55さん、返信ありがとうございます。
サブドメインでテスト用とmodxとデータベースを用意して、お試し案1の方法をやってみました。
tool_phoca_changing_collationはすべてOKがで無事終了したのですが、
再アップデートしても、まったく同じエラーがでました。
やっぱり手動でvarchar(255)を修正するしかないかも＾＾；

tool_phoca_changing_collation
凄く便利なツールですが、日本語環境ではちょっと注意です。
というのも、modxのエレメントで、カテゴリー名に2バイト文字を使っていたものあったのですが、カテゴリーがなくなって、カテゴリー外（？）になってしまいました。
これによってチャンクの位置がわからなくなったらしく、表示がうまく行かなくなってしまいました。
またエレメントの説明につけていた日本語も消えました。
他にはテンプレートで名前にIndex_xxxとかつけていたものも、名前が消えて空白になっていました。
使う方はご注意ください。

[sama55]

やっぱり手動でvarchar(255)を修正するしかないかも＾＾；

残念。話の流れと調査結果から自分も照合順序を変えるだけでＯＫと思ったのですが、甘かったです。
対処フィールドが少ないことを祈ります。