sitecache.idx.phpでのエラー  【解決済み】

質問全般・改善要望
アバター
tagbouz
メンバー
メンバー
記事: 15
登録日時: 2009年9月11日(金) 12:20

sitecache.idx.phpでのエラー

投稿記事by tagbouz » 2009年9月11日(金) 15:15

初めてご相談させていただきますtagbouzといいます。

早速ですが本題に入らせていただきます。
わかりにくいところなどあると思いますので、
そういったところについてはご指摘いただければ補足させていただきたいと思います。

まずサーバ・modx環境につきましては以下のとおりです。

[サーバ]
 ホスト&契約タイプ:(c's server,1.5GBの共有プラン,CPU XEON2.4GHz,MEMORY 1GB)
 ネットワーク:(インターネット)
 Webサーバ:(Linuxサーバ,Apache)
 PHPバージョン:(5.2.6)
 DB:(MySQL4.0.24)
[modx]
 バージョン:(0.9.6.3)
 アドオン:敢えてあげるならばsitecache.idx.php
 サイトURL: (クライアントのサイト)
[クライアント]
 ブラウザ:特定のブラウザで起こる現象ではありません


表題にありますとおり、”sitecache.idx.php”でのエラーが発生しております。
エラー文の内容は以下のとおりです。


Parse error: syntax error, unexpected T_ENCAPSED_AND_WHITESPACE, expecting T_STRING or T_VARIABLE or T_NUM_STRING in /サーバパス/assets/cache/siteCache.idx.php on line 10
(10行目の内容はこちら[ $c['site_start'] = "1"; ])




このエラーはドキュメントの編集を行った後、「保存」ボタンをクリックしたりすると出ることがあります。
(一度エラーが出ると、数秒間は他の管理画面にも公開画面にも同じエラーが表示されます。)

「出ることがある」というところがミソでして、調子がいい(?)と出ないのです。

エラーの内容から察するに”sitecache.idx.php”に問題があるかと思い、たびたびチェックしてみましたが、
構文ミスのようなものも見当たりませんでした。

サイト構造的に、ドキュメント数が3800を超えておりますので、”sitecache.idx.php”自体のファイルサイズも500kbを超えております。

サーバーのスペックの問題かとも思い、.htaccessにて、php_value memory_limit 64M(以前は8M)に変更してみましたが改善されませんでした。

”sitecache.idx.php”の上書き時にエラーが発生しているのか、サーバーのスペックの問題なのかが見当も付かず悩んでおります。
(ドキュメントによってはテンプレート変数を多数(200程度)読み込んでいるものもありますのでそれも問題の一つでしょうか?)
(また、サーバの容量自体も、以前のデータも含めると1.5GB中1.2GBほど使っておりますがサーバのレスポンスを妨げる原因になりますか?)

ドキュメント数もまだ増える予定でおりまして、最終的に「上記のエラーが出ることがない」状態にしたいと考えております。
なにかいい改善方法はありませんでしょうか?


取り留めのない文章でわかりにくい部分もあるかと思いますがなにとぞご教授お願いいたします。

尚、私自身のphpスキルは、0からプログラミングできないけど既存のものは多少改造できるレベルです。
tagbouz

http://www.400br.net/
(まだ全然やってないけど、一応modxevoのサイトです。)
http://ameblo.jp/tagbouz/
(こっちも全然更新してない・・・)
http://twitter.com/tagbouz
(これもやってないけどやろうかなって思ってる)
アバター
yama
管理人
記事: 3154
登録日時: 2009年7月29日(水) 02:50

Re: sitecache.idx.phpでのエラー

投稿記事by yama » 2009年9月11日(金) 16:14

tagbouz さんが書きました:サイト構造的に、ドキュメント数が3800を超えておりますので、”sitecache.idx.php”自体のファイルサイズも500kbを超えております。

ドキュメント数(リソース数)が多いと動作が不安定になる問題が以前から確認されていて、このへんEvoでは改良されてます。もし可能であればアップデートをお試しいただけるといいのですが、いかがでしょう?これだけのページ数をミスで失うと痛いので、事前の準備は気を抜けませんが・・
kazuike
メンバー
メンバー
記事: 491
登録日時: 2009年8月12日(水) 12:53

Re: sitecache.idx.phpでのエラー

投稿記事by kazuike » 2009年9月11日(金) 16:21

yamaさんからレスがあったようですが、参考までに以下を教えていただけますか?

エラーが出たあと、どのように復帰されていますでしょうか?
再読み込みだけで復帰するようでしたら、画面の表示タイミングだけの問題とかもあるかも?(自信はありません)

あと、”sitecache.idx.php”のチェックですが、デバッガか「php -l」のようなコマンドでチェックされてますでしょうか?
それとも、目視でしょうか?

経験上、けっこう重い更新をすると、”sitecache.idx.php”が壊れることは、たまにあります。
▼ウェブ屋のCMS→modxヒキダス流(備忘録)
http://d.hatena.ne.jp/hikidas_ikeda/
アバター
tagbouz
メンバー
メンバー
記事: 15
登録日時: 2009年9月11日(金) 12:20

Re: sitecache.idx.phpでのエラー

投稿記事by tagbouz » 2009年9月11日(金) 17:13

yama さんが書きました:ドキュメント数(リソース数)が多いと動作が不安定になる問題が以前から確認されていて、このへんEvoでは改良されてます。もし可能であればアップデートをお試しいただけるといいのですが、いかがでしょう?これだけのページ数をミスで失うと痛いので、事前の準備は気を抜けませんが・・


yama様、レスありがとうございます。
それも検討したのですが、なにせクライアントの利用レベルがやっと追いついてきたところで、アップデートするのも(いろいろ名称なども変わっているので)怖いのと、ご指摘のとおりミスが発生した場合にかなり泣けてしまいそうなので・・・。


kazuike さんが書きました:エラーが出たあと、どのように復帰されていますでしょうか?
再読み込みだけで復帰するようでしたら、画面の表示タイミングだけの問題とかもあるかも?(自信はありません)

あと、”sitecache.idx.php”のチェックですが、デバッガか「php -l」のようなコマンドでチェックされてますでしょうか?
それとも、目視でしょうか?


kazuike様、レスありがとうございます。
復帰についてですが、う~ん、表現しにくいんですが、間髪いれずに2・3回ぐらい更新すると復帰します。(とくに基幹のphpファイルを触ったりはしません。)
”sitecache.idx.php”のチェックについては、目視です。デバッガ等は使用しておりません。

画面の表示タイミングの問題というのは、”sitecache.idx.php”が生成されないうちに画面を表示しようとしているからとか、そういうところでしょうか?
もしその辺制御できるようでしたら対応したいのですが、編集を保存後、「クリーンアップ処理中」の画面が表示されずにエラーになってしまうので、どうしよう・・・みたいな感じです。

これは可能性があるかもしれないので伺っておきたいのですが、もし”sitecache.idx.php”が壊れたときは、どのように対処されておりますでしょうか?
tagbouz

http://www.400br.net/
(まだ全然やってないけど、一応modxevoのサイトです。)
http://ameblo.jp/tagbouz/
(こっちも全然更新してない・・・)
http://twitter.com/tagbouz
(これもやってないけどやろうかなって思ってる)
kazuike
メンバー
メンバー
記事: 491
登録日時: 2009年8月12日(水) 12:53

Re: sitecache.idx.phpでのエラー

投稿記事by kazuike » 2009年9月11日(金) 17:41

tagbouz さんが書きました:これは可能性があるかもしれないので伺っておきたいのですが、もし”sitecache.idx.php”が壊れたときは、どのように対処されておりますでしょうか?

「assets/cache/sitecache.idx.php」が壊れたら、管理画面も開けなくなります。(modxのアキレス腱ですね。)
FTP等を使って、「assets/cache/sitecache.idx.php」を削除します。(できれば調査用にダウンロードしてから)
これで、管理画面だけは開くようになりますので、「サイト」メニューの「キャッシュのクリア」を実行します。
これで、サイトが見える状態になり、復帰できるはずです。

ちなみに、FTPアカウントとウェブサーバ(Apache等)のアカウントが違う場合、
「assets/cache/sitecache.idx.php」
のファイル所有者が、インストール時(FTPアカウント)と変わり、ウェブサーバになります。
(実害はないとは思いますが、何かメンテナンス等することがあれば注意が必要です)

以上、modx0.9.6*を前提に書いています。
▼ウェブ屋のCMS→modxヒキダス流(備忘録)
http://d.hatena.ne.jp/hikidas_ikeda/
sama55
メンバー
メンバー
記事: 816
登録日時: 2009年8月03日(月) 08:16

Re: sitecache.idx.phpでのエラー

投稿記事by sama55 » 2009年9月11日(金) 17:48

あくまで自分の主観ですが、お伝えいただいたサーバスペックと現在のコンテンツ量が占めるディスク量などを勘案するとサーバのスペックが足りない気がします。PHPは5系で特に問題ないと思いますがMySQLが気になります。MODxのサポート対象バージョンは4.1系以上で4.0系はサポート外ですし、MySQL4のサポートは終わってます。c's serverのサイトを見てみましたが、詳細な情報が開示されておらずウェブサーバやDBサーバの細かいスペックが分かりません。MySQLは詳しくないので話半分で聞いてください。phpMyAdminなどのDBツールが使えるようでしたら、DBサーバの設定と状態をチェックすることをお勧めします。サーバのスペックや負荷状態を判断する数値は色々あるようですが、気になる項目を幾つか。

max_allowed_packet : 通信時における1パケットの最大サイズ (数字が大きいほどよい)
Qcache_lowmem_prunes : メモリ不足を解消するために、クエリキャッシュから削除されたクエリの数 (数字が小さいほどよい)
Opened_tables : これまでに開いたテーブル数 (数字が小さいほどよい) ※Opened_tables の値が多い場合、table_open_cacheの値が小さい可能性がある
Slow_launch_threads : slow_launch_time 秒よりも作成時間を要したスレッドの数 (数字が小さいほどよい)
table_cache : 開いたままにできるテーブルの数 (数字が大きいほどよい)
※数字の大小はネット上に公開されてる数値などからご判断を。

サーバによっては、ハードスペックよりも付加アプリやサービス内容が魅力的な場合もあるので一概には言えませんが、自分に当てはめて考えますと、お試し契約を利用してまずはハード的に対処すると思います(上位契約や乗り換え)。

 ・MySQLが古いこと
 ・ディスクをほぼ使い果たしてること
 ・障害の発生条件や頻度が特定できず不定期に発生すること
  (経験上このようなケースではOSに近い基盤ソフトや基盤アプリに問題の根があることが多い)

あまりお役に立てないレスで恐縮ですが、ご参考まで。
アバター
yama
管理人
記事: 3154
登録日時: 2009年7月29日(水) 02:50

Re: sitecache.idx.phpでのエラー

投稿記事by yama » 2009年9月11日(金) 18:33

http://modxcms.com/forums/index.php/topic,32299.0.html
http://modxcms.com/forums/index.php/topic,32848.0.html
http://linux.enegai.jp/modx/wp_blog.html?p=389

参考になるかどうか、cache_sync.class.processor.phpまわりの話です。このへんsama55さん・そうしさんが詳しいですね。無理なく処理できるように改善されたEvoを採用するのが本当はいいですが、それが難しい場合はサーバまわりのチューニングで乗り切るアプローチになりますね。(たぶん)
アバター
yama
管理人
記事: 3154
登録日時: 2009年7月29日(水) 02:50

Re: sitecache.idx.phpでのエラー

投稿記事by yama » 2009年9月11日(金) 18:49

もしかしたらEvo用のcache_sync.class.processor.phpを引っこ抜いてきてそのまま使えるのでは。他のコアファイルとは絡んでないはずだし。
sama55
メンバー
メンバー
記事: 816
登録日時: 2009年8月03日(月) 08:16

Re: sitecache.idx.phpでのエラー

投稿記事by sama55 » 2009年9月11日(金) 19:00

yama さんが書きました:もしかしたらEvo用のcache_sync.class.processor.phpを引っこ抜いてきてそのまま使えるのでは。他のコアファイルとは絡んでないはずだし。

うおーーyamaさん大胆な発想。 :shock:
アバター
tagbouz
メンバー
メンバー
記事: 15
登録日時: 2009年9月11日(金) 12:20

Re: sitecache.idx.phpでのエラー

投稿記事by tagbouz » 2009年9月11日(金) 19:14

sama55様、レスありがとうございます

sama55 さんが書きました:サーバのスペックが足りない気がします。

やはりそうですか・・・ :cry:
この問題は一応クライアントとも共有していて、サーバの問題という可能性も秘めている話になっています。
1.3GBの中の約450MBぐらいは運用していく上でダイエットできそうな予感はしていますが、
その他に600MBほど、デジタルパンフレットで埋められているようで・・・ :cry: :cry:


sama55 さんが書きました:max_allowed_packet : 通信時における1パケットの最大サイズ (数字が大きいほどよい)
Qcache_lowmem_prunes : メモリ不足を解消するために、クエリキャッシュから削除されたクエリの数 (数字が小さいほどよい)
Opened_tables : これまでに開いたテーブル数 (数字が小さいほどよい) ※Opened_tables の値が多い場合、table_open_cacheの値が小さい可能性がある
Slow_launch_threads : slow_launch_time 秒よりも作成時間を要したスレッドの数 (数字が小さいほどよい)
table_cache : 開いたままにできるテーブルの数 (数字が大きいほどよい)
※数字の大小はネット上に公開されてる数値などからご判断を。


これらの数値も早速確認しようと試みたのですが、当方で所有している情報ではSSH接続もできず、
phpmyadminは利用できるのですが、設定値の確認のための権限もない状態でした :cry: :cry: :cry:

でもありがとうございます。上記の情報大変参考になります!!!
tagbouz

http://www.400br.net/
(まだ全然やってないけど、一応modxevoのサイトです。)
http://ameblo.jp/tagbouz/
(こっちも全然更新してない・・・)
http://twitter.com/tagbouz
(これもやってないけどやろうかなって思ってる)
アバター
tagbouz
メンバー
メンバー
記事: 15
登録日時: 2009年9月11日(金) 12:20

Re: sitecache.idx.phpでのエラー

投稿記事by tagbouz » 2009年9月11日(金) 19:29

おお!一生懸命調べたりしてたらさらにレスが!

yama様、sama55様ありがとうございます。

yama さんが書きました:http://modxcms.com/forums/index.php/topic,32299.0.html
http://modxcms.com/forums/index.php/topic,32848.0.html
http://linux.enegai.jp/modx/wp_blog.html?p=389

参考になるかどうか、cache_sync.class.processor.phpまわりの話です。


こちら僕も事前に発見して、できることはやらせて頂きました。
質問の際に予め伝えようか迷ったんですが、説明しづらくて(汗)


yama さんが書きました:もしかしたらEvo用のcache_sync.class.processor.phpを引っこ抜いてきてそのまま使えるのでは。他のコアファイルとは絡んでないはずだし。


こちらやってみる価値ありでしょうか・・・。
自前のサイトもmodxでevo入れてますので、やろうと思えばすぐできるんですが、
今何も起きなくても土日絡むと思うと・・・。
月曜日にでもトライしてみようと思います。
tagbouz

http://www.400br.net/
(まだ全然やってないけど、一応modxevoのサイトです。)
http://ameblo.jp/tagbouz/
(こっちも全然更新してない・・・)
http://twitter.com/tagbouz
(これもやってないけどやろうかなって思ってる)
アバター
yama
管理人
記事: 3154
登録日時: 2009年7月29日(水) 02:50

Re: sitecache.idx.phpでのエラー

投稿記事by yama » 2009年9月11日(金) 19:37

Evoのcache_sync.class.processor.phpはパフォーマンス改善以外に2つの軽い改修が入ってますが、いずれもこのファイル内だけで完結してる処理なんですよね。連携して複数のコアファイルをアップデートしなきゃいけないってこともなく、理屈としては問題ないはずです。テストしたわけじゃないので、そういう意味では何が起きるかは分かりません。

危険性としては、もし誤った状態でキャッシュが生成されると、次回それを読み込んでセーブした瞬間にDBの内容もイレギュラーになってしまうことになります。つまりEvoにアップデートするほどの負担はないのでうまくいけばラッキーだけど、いざとなれば元に戻せるようにDBのバックアップを念入りにとっておく必要はあると思います。というか、今の状態も十分に危険な気はしますが・・
kazuike
メンバー
メンバー
記事: 491
登録日時: 2009年8月12日(水) 12:53

Re: sitecache.idx.phpでのエラー

投稿記事by kazuike » 2009年9月11日(金) 19:43

yama さんが書きました:もしかしたらEvo用のcache_sync.class.processor.phpを引っこ抜いてきてそのまま使えるのでは。他のコアファイルとは絡んでないはずだし。

143行目の

コード: 全て選択

WHERE contentType != 'text/html'

がちょっと気になったのですが、どうでしょう?
ここではキャッシュする情報を絞っているようですが、これを使っている側を確認しないとわからないですね。
▼ウェブ屋のCMS→modxヒキダス流(備忘録)
http://d.hatena.ne.jp/hikidas_ikeda/
sama55
メンバー
メンバー
記事: 816
登録日時: 2009年8月03日(月) 08:16

Re: sitecache.idx.phpでのエラー

投稿記事by sama55 » 2009年9月11日(金) 19:45

tagbouz さんが書きました:これらの数値も早速確認しようと試みたのですが、当方で所有している情報ではSSH接続もできず、
phpmyadminは利用できるのですが、設定値の確認のための権限もない状態でした :cry: :cry: :cry:

tagbouzさんのスキルの高さは容易に推測できたので蛇足とは思いつつ・・・調査手段がないのでは八方塞がりですよね・・・
DBのスペックをConcealmentするのってFoulですよね。見方次第ではサーバスペックにConfidenceがないEvidenceととれます。
アバター
yama
管理人
記事: 3154
登録日時: 2009年7月29日(水) 02:50

Re: sitecache.idx.phpでのエラー

投稿記事by yama » 2009年9月11日(金) 19:49

kazuike さんが書きました:
yama さんが書きました:もしかしたらEvo用のcache_sync.class.processor.phpを引っこ抜いてきてそのまま使えるのでは。他のコアファイルとは絡んでないはずだし。

143行目の

コード: 全て選択

WHERE contentType != 'text/html'

がちょっと気になったのですが、どうでしょう?
ここではキャッシュする情報を絞っているようですが、これを使っている側を確認しないとわからないですね。


なるほど。contentTypeがtext/htmlの場合の処理が別の場所にある可能性がありますね。
(デフォルトでtext/htmlと見なす、みたいな?)
アバター
tagbouz
メンバー
メンバー
記事: 15
登録日時: 2009年9月11日(金) 12:20

Re: sitecache.idx.phpでのエラー

投稿記事by tagbouz » 2009年9月11日(金) 19:51

yama さんが書きました:危険性としては、もし誤った状態でキャッシュが生成されると、次回それを読み込んでセーブした瞬間にDBの内容もイレギュラーになってしまうことになります。つまりEvoにアップデートするほどの負担はないのでうまくいけばラッキーだけど、いざとなれば元に戻せるようにDBのバックアップを念入りにとっておく必要はあると思います。というか、今の状態も十分に危険な気はしますが・・


yama様早速のレスありがとうございます!
なるほど・・・
確かにキャッシュの生成が誤っていたらアウトですよね。
今勢いに任せてやってみようと思ったのがアホでした(汗)
DBのバックアップですね。万が一3800件のデータを元に戻せる自信もないですが :cry:
ああ・・・やめておいたほうがいいですよね・・・
でも奥の手の一つとして考えておきます!
tagbouz

http://www.400br.net/
(まだ全然やってないけど、一応modxevoのサイトです。)
http://ameblo.jp/tagbouz/
(こっちも全然更新してない・・・)
http://twitter.com/tagbouz
(これもやってないけどやろうかなって思ってる)
kazuike
メンバー
メンバー
記事: 491
登録日時: 2009年8月12日(水) 12:53

Re: sitecache.idx.phpでのエラー

投稿記事by kazuike » 2009年9月11日(金) 20:02

余談ですが、
あいかわらず排他制御なしのfwrite一発ですね。
ファイルシステムのブロックサイズ以内なら、アトミックに処理されますが、
サイトの規模が大きくなって、これを超えると、壊れる可能性は色々と考えられる気がします。


ブロックサイズっていくらでしたっけ?
RedHat系は4KB?
▼ウェブ屋のCMS→modxヒキダス流(備忘録)
http://d.hatena.ne.jp/hikidas_ikeda/
sama55
メンバー
メンバー
記事: 816
登録日時: 2009年8月03日(月) 08:16

Re: sitecache.idx.phpでのエラー

投稿記事by sama55 » 2009年9月11日(金) 20:04

またまた蛇足だと思いますが、念のため。
4系のDBバックアップ(エクスポート)は、レコード(INSERT文)をばらして圧縮することをお勧めします。
過去、エクスポートしたデータを食ってくれなくて(インポートできなくて)、死ぬほど苦労した覚えがあります。
もし、マルチDBが使えるようなら、エクスポートしたデータのインポートテストを一回こなすぐらいの用心さが必要かと。

それと、DBは各種ログが圧迫してる可能性もありますので、ログを消去してみる手もあります。場合によっては、この操作がシステムの負荷を軽くし、症状が緩和される可能性がなきにしもあらず。modxはログのレコード数の上限をチェックして古いものから消していく処理が入ってないので、数十万レコード溜まってる可能性も否定できません。
でも、この操作もちょっと怖いんですよね・・・(気合かなー)
アバター
yama
管理人
記事: 3154
登録日時: 2009年7月29日(水) 02:50

Re: sitecache.idx.phpでのエラー

投稿記事by yama » 2009年9月11日(金) 20:07

今のままのほうが安全とも言えないのでこの機会にバックアップをマメにとっておくのがよいと思います。バックアップをとる時、「レポート」のイベントログと管理操作ログをザッと見てみて、特に問題なければクリアしてからバックアップをとるといいです。このログの量がバカにならないこともありますので。イベントログのほうが肥大してたらそれはそれで何か問題ありますが・・

数千ページレベルの運用になると、いつでもバックアップから元に戻せるようにDB操作に慣れておかないと危ない気がします。いったん別環境を作って念入りに練習してから着手してみるとよいかも。ぶっつけ本番で数千件のデータをさわるのはこわいですよね。

いちおうcontentTypesまわりの処理を確認してみたけど、documentparserに一ヶ所あって、ここは0963から変わってないみたいです。理屈としては問題ないはず。あとは実際試してみてどうなるかですが、うまくいくはずと思っても想定外のことが起きることって時々ありますからねー、、
アバター
tagbouz
メンバー
メンバー
記事: 15
登録日時: 2009年9月11日(金) 12:20

Re: sitecache.idx.phpでのエラー

投稿記事by tagbouz » 2009年9月11日(金) 20:20

sama55 さんが書きました:tagbouzさんのスキルの高さは容易に推測できたので蛇足とは思いつつ・・・調査手段がないのでは八方塞がりですよね・・・


スキルは高くないです :oops:
いつも試行錯誤しながらやっております・・・
あたって砕けろ的な(笑)

sama55 さんが書きました:DBのスペックをConcealmentするのってFoulですよね。見方次第ではサーバスペックにConfidenceがないEvidenceととれます。


全くそのとおりです。最近はシステム前提じゃないと新規のWEB制作も話が進めにくくなっているのに・・・


コード: 全て選択

WHERE contentType != 'text/html'

ちなみに上記の部分についてですが
該当サイトはsitemap.xmlやRSSフィードを発行しているわけではなく、
1つのドキュメントをcssとして定義しているだけで、残りのドキュメントは全てhtmlで生成されています。
なにか解決の糸口になるでしょうか・・・。

sama55 さんが書きました:4系のDBバックアップ(エクスポート)は、レコード(INSERT文)をばらして圧縮することをお勧めします。
過去、エクスポートしたデータを食ってくれなくて(インポートできなくて)、死ぬほど苦労した覚えがあります。
もし、マルチDBが使えるようなら、エクスポートしたデータのインポートテストを一回こなすぐらいの用心さが必要かと。

yama さんが書きました:数千ページレベルの運用になると、いつでもバックアップから元に戻せるようにDB操作に慣れておかないと危ない気がします。いったん別環境を作って念入りに練習してから着手してみるとよいかも。ぶっつけ本番で数千件のデータをさわるのはこわいですよね。


なるほど。
折を見て、エクスポートした後、ローカル環境にでもデータをインポートして復元できるかテストを行ってみようと思います。
まずは、データのバックアップは取っておいたほうがいいですね・・・。modxの管理画面からのバックアップで問題ないですか?
それともphpmyadmin経由でエクスポートしておいたほうが無難なんでしょうか?
いろいろと怖くなってきました(笑)


yama さんが書きました:いちおうcontentTypesまわりの処理を確認してみたけど、documentparserに一ヶ所あって、ここは0963から変わってないみたいです。理屈としては問題ないはず。あとは実際試してみてどうなるかですが、うまくいくはずと思っても想定外のことが起きることって時々ありますからねー、、


わざわざ調査していただきありがとうございます!
来週にでもsqlのバックアップからxamppに同じ環境を構築し、それができれば、ローカルで試してみて、その上で判断しようと思います。
あくまでも奥の手は奥の手ですよね・・・。
tagbouz

http://www.400br.net/
(まだ全然やってないけど、一応modxevoのサイトです。)
http://ameblo.jp/tagbouz/
(こっちも全然更新してない・・・)
http://twitter.com/tagbouz
(これもやってないけどやろうかなって思ってる)