EUC+PHP4で動いているd3diaryをUTF+PHP5のサーバに移転する際の不具合
- このフォーラムに新規トピックを投稿できます
- このフォーラムではゲスト投稿が許可されています
投稿ツリー
- EUC+PHP4で動いているd3diaryをUTF+PHP5のサーバに移転する際の不具合 (souka431, 2012/9/9 23:38)
- Re: EUC+PHP4で動いているd3diaryをUTF+PHP5のサーバに移転する際の不具合 (なーお, 2012/9/10 0:32)
- Re: EUC+PHP4で動いているd3diaryをUTF+PHP5のサーバに移転する際の不具合 (souka431, 2012/9/10 8:05)
- Re: EUC+PHP4で動いているd3diaryをUTF+PHP5のサーバに移転する際の不具合 (なーお, 2012/9/10 8:07)
- Re: EUC+PHP4で動いているd3diaryをUTF+PHP5のサーバに移転する際の不具合 (なーお, 2012/9/11 1:15)
- Re: EUC+PHP4で動いているd3diaryをUTF+PHP5のサーバに移転する際の不具合 (souka431, 2012/9/11 21:43)
- Re: EUC+PHP4で動いているd3diaryをUTF+PHP5のサーバに移転する際の不具合 (なーお, 2012/9/11 23:12)
- Re: EUC+PHP4で動いているd3diaryをUTF+PHP5のサーバに移転する際の不具合 (なーお, 2012/9/12 1:19)
- Re: EUC+PHP4で動いているd3diaryをUTF+PHP5のサーバに移転する際の不具合 (なーお, 2012/9/12 17:50)
素晴らしいモジュールをありがとうございます。
現在、サイトの引越しというか、UTF化およびPHP4から5への移行を進めています。minidiaryを使わせていただいていましたので、d3diaryはまさに福音でした。本当にありがとうございます。全くの無知ですが、積年の課題として、ここ2年くらい検索し続け、断片的な文章を読み続けて、やっと何とか取り掛かろうというところです。
その際、d3diaryの移転にあたってつまずいており、いろいろ素人なりに工夫してみたのですが、どうしてもうまくいきませんので、何かヒントをいただけれればと思い、投稿させてもらいました。具体的にはEUC+PHP4で動いているd3diaryを、UTF+PHP5のサーバに移転するにはどうしたらよいかということです。
余談ですが、XoopsのUTF化については、素人でもわかるような文章がほぼ皆無だったり、ほとんど参考にならないものが多く、具体的にどうすればよいのかが、いくら検索しても未だにわかりません。PHPやデータベースについて一から勉強した人でないと使えないソフトなんて!と、正直精神的に追い詰められた気持ちです。7年にわたって蓄積してきたものを捨てたくない一心だけでXoopsにしがみついていますが、こういう普通のユーザーには手の届かないレベルのマニュアルについては、公式サイトなどでフォローしてくれないかなあと思う今日このごろです。
私が移転にあたり、自分なりに検索してやったことは、
1.まず旧サーバ(さくら・PHP4)にd3diary0.18をインストールし、minidiaryのデータをインポート(成功)
2.実験環境の新サーバ(さくら・PHP5)にも、VerをそろえるためにSQLを書き直して無理に0.18を新規インストール(成功?)
3.旧サーバのデータベースにPHPMyadminでアクセスしてデータをエクスポート
4.EUCからUTFにコード変換し、PHP5用に直して新サーバにインポート
という流れでした。
まず最初の不具合は、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ではそのままではだめですね。
手順からいえば、
- 0.18のSQlを変更してインストールして、そこにインポート
- その後、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からのインポートからやり直してみてください。
もし、d3diaryへのインポート後にデータ追加されているということでしたら、minidiaryからの再インポートはできないでしょうから、 その場合は動作中のd3diaryのconfigテーブルとcategoryテーブルの全てのデータを、再度保存し直すことで正規化する必要があるかもしれません。 データ数が半端無く多くてそれも大変、ということでしたら、一括変更のSQLを作って実行するか、ダンプしたSQLを編集する形が良いかもですので、その場合はまたお知らせください。
お手数をおかけしますが、よろしくお願いします。
(追記)念のためですが、UTF8環境の新サーバーへ旧データを移行する場合は、旧データのダンプファイルの中身はUTF8に文字コード変換していると思いますが、 上記変更後のダンプデータでも失敗する場合は、変換データに問題があるケースもあるかもしれませんので、失敗するテーブルはデータを分割して少しずつインポートしてみるとか、そんなこともやってみる必要があるかもしれません。
(更に追記)ver0.18以降は、最新のver0.24でもDB構造に変更ない気がするので、もしかすると上記変更後の0.18からのダンプデータを、0.24にインポートできるかもしれません。
真摯に対応してくださり、ありがとうございます。
本当になんとお礼を申し上げてよいやら。
直接なーおさんにお返しする方法がありませんが、私も自分のサイトのユーザー様から何らかの反応を受けた際には、なーおさんを見習って、真摯に(紳士に)対応することで返していきたいと思います。
さて、実は以前のURLディレクトリが「minidiary」という名前だったので、リンクが切れることを嫌って、現在のd3diaryも「minidiary」というディレクトリで運用しています。そのために以前のminidiaryは綺麗に削除してしまい、データは残っていません。
なお、その際に旧サーバーで
1.d3diary0.18を普通にインストール
2.minidiaryのデータを0.18にインポート
3.成功を確認してminidiaryを削除
4.もう一つの0.18を「minidiary」の名前でインストール
5.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(移転後もURLをそろえるためにディレクトリ名はminidiary)のバージョンが0.05と表示されています。別ディレクトリ名でインストールしても変わりません。なのに新サーバに同じものをインストールすると、ちゃんと0.18と正しく表示されます。そして新旧のサーバで同じものをインストールしたはずなのに、管理画面の一般設定で違うものが出ます。具体的には旧サーバでの一般設定のメニューには、「更新Pinの送信」設定が出てきません。
旧サーバーの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をインストールしてインポートしてみたら正常に完了しました。
さて、上記のような状況が想定されるので、まずは以下を確認してください。
- 現状、d3diaryのページを表示したとき、私のこのサイトのブログのようなCSSベースの表示(BOX日付)になっていますか?
- インポートは成功した、とのことですが、管理画面でver0.05を表示したそのd3diaryの表示上の問題は何かありますか?
- 念のため確認ですが、d3diaryのソースをサーバーにアップロードする時、xoops_trust_path/modules/d3diary のディレクトリ名まで変更してませんよね? 変更が必要なのはhtml側だけなので。。
(以下、この投稿は随時追記するかもしれません)
もし上記想定どおりとなれば、今後の方策としては、以下のように考えられます。
- ソース、DBとも、バックアップをしっかり取って
- 現状のver0.05に、ver0.18を上書きして、モジュールのアップデートを行う。
- 無事にアップデートできたのであれば、その後のDBデータをダンプして、然るべき変換などを行って、新サイトの0.24のDBにインポートする。