phpを変えるということは影響範囲はキャッシュ制御以外にも及びます。心配するほどのことも起きないかもしれませんが、数千ページもあると検証しきれないのではないでしょうか。担当者さんに理由を聞いてみたほうがいいと思います。

tagbouz さんが書きました:さらにさらに、CGI版のphp4と言っていたのが、
CGI版のphp5で試してくれといってきました。

なぜわざわざCGI版のphp5なんでしょう。当てずっぽうな展開になってきてる気がします。
もともとphp4でちゃんと動いてたのだから、その状態に戻しましょう。ってことなら分かりますが。

tanaka さんが書きました:0.9系のFCKEditorでは、ハイパーリンクの追加からファイルブラウザを起動してファイルをアップロードできたので
このようなインターフェースがありがたいです。

TinyMCEでも同じように「リンクの挿入／編集」でファイルブラウザを起動してPDFファイルをアップロードできると思います。

ちなみに。試したわけじゃないけどこんなのもあるみたいです。PubKitBlog(pkBlog)

http://modxcms.com/forums/index.php/topic,38685.0.html
インテグレータじゃなくて、MODxベースで動きます。

http://www.pogwatch.com/blog.html
実際の稼働イメージ

http://modxcms.com/forums/index.php/top ... #msg236540
添付画像は管理イメージかな？

んー、、一番無難なのはEvoのcache_sync.class.processor.phpに差し替える方法のような気がしますが。 でも、もともとphp4で動いていて、その時は問題なかったのですよね？それならたぶん大丈夫だと思いますが、理屈ではphpそのものをダウングレードする方法のほうが影響範囲が広いはずです。サーバ担当者さんはMODxについてはそんなに詳しいわけじゃないと思うので「MODxってphp5とは相性悪いんじゃないですか？」みたいな感覚があるのかもですよ。 あと、xreaのphpをCGIモードで動かす方法は、MODx全体をCGIモードで動かすと負荷がものすごいことになるみたいです。 ...

タイトルに書きましたように、個人的にはプログ機能を強化してほしい。 その時はWordPress2.8をWordPress Integratorで動かしたという記事はありませんでした。 実際2.8で試してみましたが、動きませんでした。 http://forum.modx.jp/viewtopic.php?f=7&t=91 先日試してみましたが、2.8でもいちおう動くみたいです。もしよければ参考にどうぞ。 sama55さんが書いてる内容に近いかもだけど、外部API的なものが充実するとよいなと思います。classを呼び出してどうこう、ってのじゃなくて、単純にURLで呼び出せるようなもの。そ...

サーバ担当者さんがそう答えたということは、ちょうどphp4からphp5に切り換えたタイミングでそうなったということでしょうか。そうだとすれば、試してみる価値はあると思います。うまくいってから原因が分かることもありますし。

でも普通に考えると、php4しかもCGI版だともっとパフォーマンスが落ちるはずですが。fastcgiモードではないですよね？

※MODxのキャッシュプロセッサーって排他処理を行なってないみたいなので、こういうケースってこわいですね。一行追記するだけですむので、次のバージョンでは対応したいです。

http://farm4.static.flickr.com/3492/3961150225_0c1b632197_o.png 試してみたけど文字化けするみたいです。理由は簡単で、これはMODx自体を内蔵する、それ自体が独立した管理ツールなんですが、内蔵のMODxのバージョンが少し古いです。この種の文字化けは、たぶん0.9.6.2だと思いますが。たぶん差し替えるとよいのではと思いますが、完全に同じものではないと思うので少し調べる必要があります。 今回の目的に使えるかどうかはまだよく分かりませんが、サイトの管理を担当するプロ向けのツールという感じはしました。たとえばうっかり記事を削除してしまっ...

http://modxblog.com/blog/entry/19/

もしかするとこれ使えるかも。差分を復元できて、MODx本体とは独立して動く云々・・ってことなので、もしかして。
導入大変そうですが。

Dittoのエクステンダーを書くとよいのかなと思ったけど、カウント専用のスニペットを作ってテンプレート変数を利用するテが簡単でよさそう。テンプレート変数の内容を更新するメソッドはなかったと思うので(なんでだろう・・)、そこは自作する必要がありそうですが。
みたいな

折を見て、エクスポートした後、ローカル環境にでもデータをインポートして復元できるかテストを行ってみようと思います。 まずは、データのバックアップは取っておいたほうがいいですね・・・。modxの管理画面からのバックアップで問題ないですか？ それともphpmyadmin経由でエクスポートしておいたほうが無難なんでしょうか？ 念のため、最初のうちはmodxの管理画面・phpMyAdmin両方でとっておくと安心だと思います。基本的にMODx管理画面からのバックアップで問題ないはずですが。kazuikeさんのアドバイス見て思ったけど、phpMyAdmin使って圧縮状態のバックアップもとっておくといざと...

今のままのほうが安全とも言えないのでこの機会にバックアップをマメにとっておくのがよいと思います。バックアップをとる時、「レポート」のイベントログと管理操作ログをザッと見てみて、特に問題なければクリアしてからバックアップをとるといいです。このログの量がバカにならないこともありますので。イベントログのほうが肥大してたらそれはそれで何か問題ありますが・・ 数千ページレベルの運用になると、いつでもバックアップから元に戻せるようにDB操作に慣れておかないと危ない気がします。いったん別環境を作って念入りに練習してから着手してみるとよいかも。ぶっつけ本番で数千件のデータをさわるのはこわいですよね。 いちおう...

kazuike さんが書きました:

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

143行目の

コード: 全て選択

WHERE contentType != 'text/html'

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

なるほど。contentTypeがtext/htmlの場合の処理が別の場所にある可能性がありますね。
（デフォルトでtext/htmlと見なす、みたいな？）

Evoのcache_sync.class.processor.phpはパフォーマンス改善以外に２つの軽い改修が入ってますが、いずれもこのファイル内だけで完結してる処理なんですよね。連携して複数のコアファイルをアップデートしなきゃいけないってこともなく、理屈としては問題ないはずです。テストしたわけじゃないので、そういう意味では何が起きるかは分かりません。 危険性としては、もし誤った状態でキャッシュが生成されると、次回それを読み込んでセーブした瞬間にDBの内容もイレギュラーになってしまうことになります。つまりEvoにアップデートするほどの負担はないのでうまくいけばラッキーだけど、いざとなれば元に戻...

（２）はモジュールを作るアプローチが素直でよさそうな気がします。ユーザごとの「ブログ設定画面」に相当するモジュールを作って、そこでカテゴリーをいくつでも自由に作らせる。作った値をテンプレート変数のオプション値のところで@bindする。投稿画面でカテゴリーを選択できる。というイメージです。

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

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を採用するのが本当はいいですが、それが難しい場合はサーバまわりのチューニングで乗り切るアプローチに...

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

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

僕もあまり分かってなくて、かなり適当に記入してるところはあります。そのへんは逆にMEGUさんに教えてもらいたいくらいなところで。

スクリーンショットや解決案、もしくは解決コードそのものを添えるといいみたいですね。コミッターとしてもモチベーションが上がるのだと思います。

まだ試してない未確認情報ですが。

http://modxcms.com/forums/index.php/top ... #msg240006

evoでちゃんと動くものを作ったよ！って人が現れました。「assets/plugins/managermanager」までのハードコーディングが随所に埋め込まれてたのも、今回のものではちゃんと変数として扱うようにシンプルに改善されてます。CSSのパスずれの問題を認識してたかどうかは分からないけど、直ってるはずですね。