【解決済み】phpを変えるということは影響範囲はキャッシュ制御以外にも及びます。心配するほどのことも起きないかもしれませんが、数千ページもあると検証しきれないのではないでしょうか。担当者さんに理由を聞いてみたほうがいいと思います。CGI版のphp4と言っていたのが、CGI版のphp5で試してくれといってきました。CGI版のphp5なんでしょう。当てずっぽうな展開になってきてる気がします。php4でちゃんと動いてたのだから、その状態に戻しましょう。ことなら分かりますが。0.9系のFCKEditorでは、ハイパーリンクの追加からファイルブラウザを起動してファイルをアップロードできたのでこのようなインターフェースがありがたいです。TinyMCEでも同じように「リンクの挿入/編集」でファイルブラウザを起動してPDFファイルをアップロードできると思います。個人的にはプログ機能を強化してほしいちなみに。試したわけじゃないけどこんなのもあるみたいです。PubKitBlog(pkBlog)http://modxcms.com/forums/index.php/topic,38685.0.htmlインテグレータじゃなくて、MODxベースで動きます。【解決済み】んー、、一番無難なのはEvoのcache_sync.class.processor.phpに差し替える方法のような気がしますが。php4で動いていて、その時は問題なかったのですよね?それならたぶん大丈夫だと思いますが、理屈ではphpそのものをダウングレードする方法のほうが影響範囲が広いはずです。サーバ担当者さんはMODxについてはそんなに詳しいわけじゃないと思うので「MODxってphp5とは相性悪いんじゃないですか?」みたいな感覚があるのかもですよ。あと、xreaのphpをCGIモードで動かす方法は、MODx全体をCGIモードで動かすと負荷がものすごいことになるみたいです。個人的にはプログ機能を強化してほしいタイトルに書きましたように、個人的にはプログ機能を強化してほしい。Integratorで動かしたという記事はありませんでした。実際2.8で試してみましたが、動きませんでした。先日試してみましたが、2.8でもいちおう動くみたいです。よければ参考にどうぞ。sama55さんが書いてる内容に近いかもだけど、外部API的なものが充実するとよいなと思います。classを呼び出してどうこう、ってのじゃなくて、単純にURLで呼び出せるようなもの。【解決済み】サーバ担当者さんがそう答えたということは、ちょうどphp4からphp5に切り換えたタイミングでそうなったということでしょうか。すれば、試してみる価値はあると思います。うまくいってから原因が分かることもありますし。普通に考えると、php4しかもCGI版だともっとパフォーマンスが落ちるはずですが。fastcgiモードではないですよね?※MODxのキャッシュプロセッサーって排他処理を行なってないみたいなので、こういうケースってこわいですね。一行追記するだけですむので、次のバージョンでは対応したいです。試してみたけど文字化けするみたいです。理由は簡単で、これはMODx自体を内蔵する、それ自体が独立した管理ツールなんですが、内蔵のMODxのバージョンが少し古いです。この種の文字化けは、たぶん0.9.6.2だと思いますが。差し替えるとよいのではと思いますが、完全に同じものではないと思うので少し調べる必要があります。今回の目的に使えるかどうかはまだよく分かりませんが、サイトの管理を担当するプロ向けのツールという感じはしました。サブサイトについて教えていただきたいのですが・・http://modxblog.com/blog/entry/19/もしかするとこれ使えるかも。差分を復元できて、MODx本体とは独立して動く云々・・ってことなので、もしかして。【解決済み】Dittoのエクステンダーを書くとよいのかなと思ったけど、カウント専用のスニペットを作ってテンプレート変数を利用するテが簡単でよさそう。テンプレート変数の内容を更新するメソッドはなかったと思うので(なんでだろう・・)、そこは自作する必要がありそうですが。折を見て、エクスポートした後、ローカル環境にでもデータをインポートして復元できるかテストを行ってみようと思います。データのバックアップは取っておいたほうがいいですね・・・。念のため、最初のうちはmodxの管理画面・phpMyAdmin両方でとっておくと安心だと思います。基本的にMODx管理画面からのバックアップで問題ないはずですが。今のままのほうが安全とも言えないのでこの機会にバックアップをマメにとっておくのがよいと思います。バックアップをとる時、「レポート」のイベントログと管理操作ログをザッと見てみて、特に問題なければクリアしてからバックアップをとるといいです。このログの量がバカにならないこともありますので。数千ページレベルの運用になると、いつでもバックアップから元に戻せるようにDB操作に慣れておかないと危ない気がします。別環境を作って念入りに練習してから着手してみるとよいかも。ぶっつけ本番で数千件のデータをさわるのはこわいですよね。したらEvo用のcache_sync.class.processor.phpを引っこ抜いてきてそのまま使えるのでは。他のコアファイルとは絡んでないはずだし。'text/html'がちょっと気になったのですが、どうでしょう?ここではキャッシュする情報を絞っているようですが、これを使っている側を確認しないとわからないですね。contentTypeがtext/htmlの場合の処理が別の場所にある可能性がありますね。【解決済み】Evoのcache_sync.class.processor.phpはパフォーマンス改善以外に2つの軽い改修が入ってますが、いずれもこのファイル内だけで完結してる処理なんですよね。連携して複数のコアファイルをアップデートしなきゃいけないってこともなく、理屈としては問題ないはずです。テストしたわけじゃないので、そういう意味では何が起きるかは分かりません。危険性としては、もし誤った状態でキャッシュが生成されると、次回それを読み込んでセーブした瞬間にDBの内容もイレギュラーになってしまうことになります。MODxをマルチユーザー、カテゴリ自由定義(ブログライク)に運用することは可能か?(2)はモジュールを作るアプローチが素直でよさそうな気がします。ユーザごとの「ブログ設定画面」に相当するモジュールを作って、そこでカテゴリーをいくつでも自由に作らせる。作った値をテンプレート変数のオプション値のところで@bindする。投稿画面でカテゴリーを選択できる。【解決済み】もしかしたらEvo用のcache_sync.class.processor.phpを引っこ抜いてきてそのまま使えるのでは。他のコアファイルとは絡んでないはずだし。参考になるかどうか、cache_sync.class.processor.phpまわりの話です。このへんsama55さん・そうしさんが詳しいですね。サイト構造的に、ドキュメント数が3800を超えておりますので、”sitecache.idx.php”自体のファイルサイズも500kbを超えております。ドキュメント数(リソース数)が多いと動作が不安定になる問題が以前から確認されていて、このへんEvoでは改良されてます。トピックは解決済みです僕もあまり分かってなくて、かなり適当に記入してるところはあります。そのへんは逆にMEGUさんに教えてもらいたいくらいなところで。スクリーンショットや解決案、もしくは解決コードそのものを添えるといいみたいですね。コミッターとしてもモチベーションが上がるのだと思います。【解決済み】まだ試してない未確認情報ですが。#msg240006evoでちゃんと動くものを作ったよ!って人が現れました。「assets/plugins/managermanager」までのハードコーディングが随所に埋め込まれてたのも、今回のものではちゃんと変数として扱うようにシンプルに改善されてます。CSSのパスずれの問題を認識してたかどうかは分からないけど、直ってるはずですね。