EUC+PHP4で動いているd3diaryをUTF+PHP5のサーバに移転する際の不具合

素晴らしいモジュールをありがとうございます。
現在、サイトの引越しというか、UTF化およびPHP４から５への移行を進めています。minidiaryを使わせていただいていましたので、d3diaryはまさに福音でした。本当にありがとうございます。全くの無知ですが、積年の課題として、ここ２年くらい検索し続け、断片的な文章を読み続けて、やっと何とか取り掛かろうというところです。

その際、d3diaryの移転にあたってつまずいており、いろいろ素人なりに工夫してみたのですが、どうしてもうまくいきませんので、何かヒントをいただけれればと思い、投稿させてもらいました。具体的にはEUC+PHP4で動いているd3diaryを、UTF+PHP5のサーバに移転するにはどうしたらよいかということです。

余談ですが、XoopsのUTF化については、素人でもわかるような文章がほぼ皆無だったり、ほとんど参考にならないものが多く、具体的にどうすればよいのかが、いくら検索しても未だにわかりません。PHPやデータベースについて一から勉強した人でないと使えないソフトなんて！と、正直精神的に追い詰められた気持ちです。７年にわたって蓄積してきたものを捨てたくない一心だけでXoopsにしがみついていますが、こういう普通のユーザーには手の届かないレベルのマニュアルについては、公式サイトなどでフォローしてくれないかなあと思う今日このごろです。

私が移転にあたり、自分なりに検索してやったことは、
１.まず旧サーバ（さくら・PHP４）にd3diary0．18をインストールし、minidiaryのデータをインポート（成功）
2.実験環境の新サーバ（さくら・PHP５）にも、VerをそろえるためにSQLを書き直して無理に0．18を新規インストール（成功？）
3.旧サーバのデータベースにPHPMyadminでアクセスしてデータをエクスポート
4.EUCからUTFにコード変換し、PHP５用に直して新サーバにインポート
という流れでした。

まず最初の不具合は、d3diary_photoのテーブルがインポートできなかったこと。

MySQLのメッセージ: ドキュメント 

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '(14) NOT NULL,

 PRIMARY KEY  (`bid`,`pid`)

) ENGINE=MyISAM' at line 6

xoops側の表示をみますと、「全30件のうち1 - 10件目を表示しています」などと表示されますが、実際には何も表示されておらず、記事を閲覧することができません。カテゴリーやカレンダーなどにも記事があることを示す表示がありましたが、クリックしても記事を閲覧することはできません。ただしデータベースのテーブルには記事はちゃんと存在しているようでした。
その時のPHPデバグですが、
Notice [PHP]: Undefined index: mailpost in file /home/×××/xoops_trust_path/modules/d3diary/class/diaryconfig.class.php line 44（同じく45～48も）
Notice [PHP]: Undefined index: subcat in file /home/×××/xoops_trust_path/modules/d3diary/class/func.class.php line 285
というものでした。

やはり0．18ではダメかと思い、今度は新サーバのほうに0．24をインストールして同じことをしてみましたが、症状は改善されず、移転することができません。ただし、d3diary_photoのテーブルはインポートできたようです。

それと不思議なことですが、旧サーバの管理画面ではd3diary（移転後もURLをそろえるためにディレクトリ名はminidiary）のバージョンが0．05と表示されています。別ディレクトリ名でインストールしても変わりません。なのに新サーバに同じものをインストールすると、ちゃんと0．18と正しく表示されます。そして新旧のサーバで同じものをインストールしたはずなのに、管理画面の一般設定で違うものが出ます。具体的には旧サーバでの一般設定のメニューには、「更新Pinの送信」設定が出てきません。

以上、何が何やら、いったいどうすればいいのやら、専門の勉強をされた方ならわかるのでしょうが、私ごときでは狐につままれたような気持ちです。どういう方向で何を調べればいいのかすらわかりません。
藁にもすがる気持ちといったら失礼ですが、どうかヒントだけでもいただけませんでしょうか。

新サーバ　　　　　　　　　　　　旧サーバ
MySQL 5.5　　　　　　　　　　　MySQL 4.0
PHP 5.2.17 (CGI版)　　　　　　 PHP 4.4.9 (CGI版)
Apache 2.2.22　　　　　　　　　Apache 2.2.22
XCL 2.2.1 Beta1　　　　　　　　XCL 2.1.7

souka431さん、こんにちは。

ごぶさたしています。

新サーバーは、MySQl5.5ですね。　となると、TYPE=MyISAMは受け付けられず、ENGINE=MyISAM　にする必要があり、　d3diary-0.18ではそのままではだめですね。

手順からいえば、

1. 0.18のSQlを変更してインストールして、そこにインポート
2. その後、0.24にアップデート
   が良さそうです。

具体的には、ver0.18の、xoops_trust_path/modules/d3diary/sql/mysql.sql の中にある全ての「TYPE=MyISAM」を「ENGINE=MyISAM」に編集してアップロードしてからインストールし直してみてください。

(追記)　うまくいかない場合は、原因を追及する必要がありますが、　旧サーバーで0.18をもうひとつインストールして、0.18同士でインポートできるかどうか試してみてください。

早速のお返事ありがとうございますm(__)m

やっぱりそうですよねえ。
おっしゃる通りにSQLフォルダの中のmysqlファイルにある
TYPE=MyISAMをすべてENGINE=MyISAMに変更して
インストールしてあります。だからインストール自体は成功していると思います。

ただ、その後のインポートができない、PHPMyadminがエラーを返すということなのです。

やはりxoopsのバージョンもそろえないとダメということなのかなあ。
他の理由で違うバージョンになってしまっているのですが、
だとすれば、あちら立てればこちら立たず。
ほんとパズルみたい(^O^；

これから仕事なので、帰宅しましたら、アドバイスに従い、
旧サーバの0．18同士でインポートしてみます。

そうですが。では原因は別のところですね。

うまくいかない場合は、原因を追及する必要がありますが、　旧サーバーで0.18をもうひとつインストールして、0.18同士でインポートできるかどうか試してみてください。　もしかすると、インポート機能自体に不具合があるのかも？

あと、新サーバーでMySQLのテーブルを当初はEUCのままでインストールして、（XOOPSもEUC-JP）　うまく行ったら後でUTFにするというのも一つの手順ですね。　XCL2.2がEUCで動かないと思っている人が多いようですが、ちゃんと動きますし。

souka431 さん

どうやら原因がわかりました。
（きっと旧サーバー上で0.18同士のデータ移行も失敗するだろうと思って先回りしてみました）

おそらく、minidiaryからd3diary-0.18にインポートした時点で、configテーブルとcategoryテーブルがきちんとインポートできていないためと思われます。　（インポートスクリプトの不具合）

ちょっと今、出張先なので、ちゃんとした対応ができないのですが、取り急ぎ以下を試してみていただけますか？　最初にminidiaryをインポートする旧サーバー上のd3diary-0.18の

xoops_trust_path/modules/d3diary/include/import_functions.php を、以下のものに差し替えてから、minidiaryからのインポートからやり直してみてください。

import_functions.php

もし、d3diaryへのインポート後にデータ追加されているということでしたら、minidiaryからの再インポートはできないでしょうから、　その場合は動作中のd3diaryのconfigテーブルとcategoryテーブルの全てのデータを、再度保存し直すことで正規化する必要があるかもしれません。　データ数が半端無く多くてそれも大変、ということでしたら、一括変更のSQLを作って実行するか、ダンプしたSQLを編集する形が良いかもですので、その場合はまたお知らせください。

お手数をおかけしますが、よろしくお願いします。

（追記）念のためですが、UTF8環境の新サーバーへ旧データを移行する場合は、旧データのダンプファイルの中身はUTF8に文字コード変換していると思いますが、　上記変更後のダンプデータでも失敗する場合は、変換データに問題があるケースもあるかもしれませんので、失敗するテーブルはデータを分割して少しずつインポートしてみるとか、そんなこともやってみる必要があるかもしれません。

（更に追記）ver0.18以降は、最新のver0.24でもDB構造に変更ない気がするので、もしかすると上記変更後の0.18からのダンプデータを、0.24にインポートできるかもしれません。

真摯に対応してくださり、ありがとうございます。
本当になんとお礼を申し上げてよいやら。
直接なーおさんにお返しする方法がありませんが、私も自分のサイトのユーザー様から何らかの反応を受けた際には、なーおさんを見習って、真摯に（紳士に）対応することで返していきたいと思います。

さて、実は以前のURLディレクトリが「minidiary」という名前だったので、リンクが切れることを嫌って、現在のd3diaryも「minidiary」というディレクトリで運用しています。そのために以前のminidiaryは綺麗に削除してしまい、データは残っていません。

なお、その際に旧サーバーで
１.d3diary0.18を普通にインストール
２.minidiaryのデータを0.18にインポート
３.成功を確認してminidiaryを削除
４.もう一つの0.18を「minidiary」の名前でインストール
５.d3diary→「minidiary」へ0.18同士でインポート
という手順をとっています。なのでこの時は0.18同士のデータ移行は成功していることになりますねえ(？_？)

で、今回は新たにインストールした別の0.18モジュールを、管理画面で開こうとすると、ALTSYSのCSSが読み込めなくなったのか、画面の表示がガタガタになってしまい、恐ろしくなってそこから先はまだ試していません。まあ、これは私の環境が原因かと思いますが。

今日はMyX_BackUpモジュールを試してみましたが、やはり結果は同じでした。

TABLE CREATED : `×××_minidiary_photo`
エラーが発生しました。（このファイルの処理は中断されます）
0 DATA INSERTED : `×××_minidiary_photo`

のメッセージが出て止まってしまいます。
（d3diaryを「minidiary」ディレクトリで運用しています）

次は添付していただいたimport_functions.phpを上書きして、旧サーバーで0.18同士のインポートを試してみます。

souka431 さん、こんばんは。

昨日添付したは、import_functions.php　からのインポートを修正しただけですので、　d3diary同士のインポート部分は何も変わっていません。

で、新たに問題に気付いたのですが、d3diaryの0.18では、photoテーブルのtstampフィールドの形式を、timestampからdatetimeに変更しています。　しかしminidiaryからのインポートの際にはそのまま格納しているので、何らかの問題が出ている可能性がありますが、インポートした後の画像一覧などの表示は問題ないですか？

DBでインポートエラーが起きるファイルを見たいのですが、PMなどで連絡いただき、何らかの形で送っていただくことは可能ですか？

souka431さん

どうも以下の部分が気になります。

旧サーバーのd3diaryをminidiaryとして名前変更でインストールするとき、元のminidiaryと混色していませんか？　あるいは、minidiaryを削除する前にちゃんとminidiaryのアンインストールはされていますか？

まあそうでないとしても、どうも元々のこの部分がおかしい気がします。
だからもうひとつ0.18をインストールしようとした時に管理画面が崩れたりしているのかも。

souka431さん

php4.4+MySQL4.0の環境を作って、ホダ塾ディストリ（XCL2.1.6）をインストールし、minidiaryをインストールして記事を作成、d3diary-0.18へのインポートを試してみました。

結果、minidiaryからのインポートはやはり異常終了してしまいました。このスレッドで貼った修正済みのimport_functions.phpに差し替えると正常に終了します。　そしてこの時、d3diaryのバージョンは管理画面上で0.18と示されています。

たぶん、minidiaryからd3diaryへのインポートができたのは、おそらくd3diaryが0.05だったのではないかと思われます。　実際に、d3diaryの0.05をインストールしてインポートしてみたら正常に完了しました。

さて、上記のような状況が想定されるので、まずは以下を確認してください。

1. 現状、d3diaryのページを表示したとき、私のこのサイトのブログのようなCSSベースの表示（BOX日付）になっていますか？
2. インポートは成功した、とのことですが、管理画面でver0.05を表示したそのd3diaryの表示上の問題は何かありますか？
3. 念のため確認ですが、d3diaryのソースをサーバーにアップロードする時、xoops_trust_path/modules/d3diary のディレクトリ名まで変更してませんよね？　変更が必要なのはhtml側だけなので。。
   （以下、この投稿は随時追記するかもしれません）

もし上記想定どおりとなれば、今後の方策としては、以下のように考えられます。

1. ソース、DBとも、バックアップをしっかり取って
2. 現状のver0.05に、ver0.18を上書きして、モジュールのアップデートを行う。
3. 無事にアップデートできたのであれば、その後のDBデータをダンプして、然るべき変換などを行って、新サイトの0.24のDBにインポートする。