MODX JAPAN

-----
ご利用のサーバ：ロリポップレンタルサーバーロリポプラン
MODXのバージョン：1.0.6J-r5
PHPのバージョン：5.2.17
MySQLのバージョン：5.1.59-community-log
ブラウザ：どのブラウザでも状況は同じです
-----

はじめまして。
「Fatal error: Out of memory (allocated 356515840) (tried to allocate 79405 bytes) in ******/manager/processors/cache_sync.class.processor.php on line 64」
のエラーが発生して、その解決ができずにおり、相談させていただきます。

●状況

お客様の連絡・・・「リソースを移動しようとしたらエラーが出て、あれこれやっているうちに管理画面の操作ができなくなった。」　とのこと。
公開ページを確認しますと、Wayfinderで書きだしているグローバルナビ6つのうち1つしか表示されていません（以下のコピーBのみ）。その表示されているメニュー（カテゴリ）には、複数のサブリソース（サブカテゴリ）があり、その下のリソースを他のサブカテゴリに移動しようとしたとき、操作ミス（？）があったようです。
あれこれしているうちに、Bのコピーをつくってしまったよう（確かではありません）で、元々のB(3)がリソースツリーからは消えてしまっています。

---------------------------
リソースツリー
---------------------------
HOME (1)
A (2)
B (3)
C (4）
D (5)
E（6）
コピーB (499)
---------------------------

●試した対策

a）フォオーラムにあった「もしかしてこれでは？」と思ったケースの対策
「コンテナリソースをサブリソースに移動すると消える」
http://forum.modx.jp/viewtopic.php?f=7&t=1044

→バッチ適用しましたが状況は変わりません。

b）php_value memory_limit の値を.htaccessで上げる。

最初は、128MBであったのを、少し足りないというエラーが出ていましたので、248MBにしてもまた少し足りないというエラー。その後384MBに上げた際のエラーが上述のものです。

c）イベントログを消去する

消去しても、少しすると大量のエラーがたまってしまっています。頻発しているのは以下です。

Snippet - AjaxSearch
Parser - if(!$this->pluginCache) $this->s
Parser - $access .= " OR 1='{$_SESSION['m
Parser - $this->cacheRefreshTime = $cacheRe
Snippet - Ditto
Snippet - Wayfinder


他に似たような事象がないか、何か解決の糸口はないか調べておりますが、八方塞がりになっており、ご相談させていただいた次第です。
よろしくお願いいたします。

この場合のOut of memoryエラーは、メモリーリークや無限ループのために一瞬でメモリを食いつぶしてしまう現象のように思います。こういう時はメモリ割り当てをいくら増やしても効かないと思います。
古いMODXの不具合の可能性があるので、アップデートすると解決するかもしれません。たとえば、２つのリソース間で互いに相手を親リソースと見なすようなイレギュラーなリソース構造を作ってしまう問題などが実際にあって、今回エラーの発生源になっているcache_sync.class.processor.phpではその影響を受けて無限ループになったりします。
アップデートは可能でしょうか？

yamaさん、返信ありがとうございます。

アップデートしてデータ等、他の不具合が起こらないだろうかと慎重になっていましたが、それほど怖がることはないでしょうか？
サブドメインを切って、MODX最新バージョンをインストールし、サイトのデータの移行を試してみるしかないか、と考えておりました（うまくいったら公開サイトと切り替え）。そちらもやってみようと思っています。

MODX Evolution 1.0.12J へのアップデートを行ってみました。

インストール完了画面がデザインのされていない文字だけのページであれ？　と思いましたが、インストールは完了したようです。そのページで管理画面への誘導がされなかったので/manager/ にアクセスするとログイン画面はでず、データベースの内容のようなものが表示されています。ドキュメントのルートも同じ内容。その冒頭は以下のような内容です。

-------------------------------------------------
a:115:{s:13:"manager_theme";s:9:"RevoStyle";s:16:"settings_version";s:9:"1.0.6J-r5";s:18:"server_offset_time";s:1:"0";s:16:"manager_language";s:13:"japanese-utf8";s:12:"modx_charset";s:5:"UTF-8";s:9:"site_name";s:39:・・・・・・・・
-------------------------------------------------

どのような問題が考えられますでしょうか？

asssetsディレクトリの中にcacheディレクトリがあると思います。これを_cacheなどにリネームして退避させ、新たにcacheディレクトリを作成してパーミッションを書き込み可としてください。

やってみました。
今度は、「/manager/ 」「/」とも真っ白のページで、ソースコードもないようです。

了解です。以前にも同様の相談を受けて、その時は実際にサーバを見させてもらって意外と簡単に修正できたのですが・・どうやったかちょっと思い出してみますね。

問題解決しました！　yamaさん、ほんとうにありがとうございました。

PMでやりとりさせていただきましたので、（yamaさんの記述をお借りしながら）原因と解決方法についてまとめます。

---

トラブルの原因
━━━━━━━
MODX1.0.6J-r5で運用しているサイトで、下記のようなリソース構造。

ID0
├ID6（ブログ）
│├ID34（ブログカテゴリ）
││
│├ID35（ブログカテゴリ）
││└IDxxx（記事）

ID35以下の記事であるIDxxxを別カテゴリであるID34以下に移動しようとした際、誤ってID6をID34以下に移動するというご操作を行った。
その結果、D6のリソースとID34のリソースが互いに相手を親リソースと見なす設定になっており、そのため一瞬で無限ループに至っていた。


トラブル発生後の状況
━━━━━━━━━━━
・管理画面上からはID6が消失。
・表示サイト側では、Wayfinderで書き出しているグローバルナビゲーションのうち、消失したID6（ブログ）しか表示されていない。
・管理画面上で何らかの操作を行うと、「Fatal error: … cache_sync.class.processor.php on line 64」のエラーが表示されサイト更新できない状況に陥る。


試した対策と結果
━━━━━━━━
1)「コンテナリソースをサブリソースに移動すると消える」
http://forum.modx.jp/viewtopic.php?f=7&t=1044
を参考にパッチ適用
⇒状況に変化なし

2）php_value memory_limit の値を.htaccessで上げる
⇒最初は、128MBであったのを、少し足りないというエラーが出ていましたので、248MBにしてもまた少し足りないというエラー。その後384MBに上げても同様の Fatal Error。

3）MODX最新版（1.0.12J ）にアップデート
⇒管理画面、表示側サイトとも文字化けした状態で同じ文字列（上記「2013/11/26(火) 20:47」の投稿）が表示される。

4)yamaさんのアドバイスを受け、asssetsディレクトリの中にcacheディレクトリを_cacheにリネームし、新たにcacheディレクトリを作成してパーミッションを書き込み可とする。
⇒管理画面、表示側サイトとも表示が真っ白（ソースコードなし）


問題解決の方法
━━━━━━━
ID6の親リソースを0にすることで簡単に解決。

---

反省
━━
○最新版へのアップデートの必要性（yamaさんの記述です）
最新版では誤操作でこのような状態になることはないですが、自作プラグインのコーディングミスなどで同様のエラーを起こす可能性は
あると思います。そのような状態になった時でも無限ループにならずエラーログを残す仕組みを作る必要があると思います。
MODXの最新バージョンでは、そのような操作をすると「自分自身のサブリソースに移動することはできません」というアラートを表示して戻るようになっています。

○簡単に解決できたのに、なぜ時間がかかったか

1. managerが操作不能に陥ってしまっていた

2. 本人の技術力不足

3. MODXの利用者がWordPressに比すればまだ少なく、海外サイト含め参照ドキュメントが少ない。

4. 問題の確信への適切な対処をトライできなかった。
⇒プログラミング技術のないクリエイターやウェブディレクターでも、問題の根源はID6にあることは分かっていたのだから、managerが操作不能でも、phpMyAdminでリソースID6の親リーソースの不整合を正すという試みを行っていれば（ID34となっていたのを0に変更してみる）、問題解決できた。


以上。同様なトラブルニ見舞われたケースにおいて、少しでも参考にしていただければと思い。