開発中の1.0について

1.0J-b1へのアップグレードをやってみました。
今回は、スニペットやプラグインは触ってなかったので以下の手順でお手軽更新しました。

　（１）　1.0J-b1のファイルを0963j-Beta1に上書き
　（２）　installフォルダにアクセス
　（３）　インストールモードで”更新”を選択し、インストーラの指示に従って最後まで実行
　（４）　管理画面にログイン
　（５）　グローバル設定を一通りチェックして保存

更新の過程で幾つか分かった（注意すべき）ことがあったのでご報告します。

（１）　1.0J-b1のインストールセットには、比較的古い日付のファイルが存在するので、
　　　　ファイルの日付に関係なく、すべてのファイルを強制的に上書きすること。
　　　　（ＦＦＦＴＰでのミラーアップロードでは古いファイルがアップされないのでご注意を）

（３）　注意点
　　　インストーラによる更新操作を２回以上繰り返すと、インストール対象プラグインの
　　　システムイベントの設定が外れてプラグインが動かなくなります（例：tinyMCEによる編集が不可に）。
　　　この状態になった場合は、一世代前のバックアップされてるプラグインのシステム
　　　イベントを見て、同じ設定を施すことで復旧します。但し、tinyMCEは、グローバル設定の
　　　RTEによる編集がOFFになってしまうので、そちらもtinyMCEを使うよう再設定します。

　　　※本件は、本家版も同様で日本版に限った現象ではありません。

（３）　参考情報
　　　インストールモードにある”カスタムアップグレード”は今まで使ったことがなかったのですが、
　　　これは、サーバのMySQLのバージョンを4.0系から上げた場合に使うようです。（皆さんはご存知ですよね　＾＾；）
　　　契約するさくらインターネットが先日、MySQL5系も選択できるようになったので、ＤＢを4.0系
　　　から5系に入れ替えたのですが、それによって、バージョン0.9.6.2のサイトの管理画面で
　　　テンプレート変数まわりで文字化けが起こりました。問題のあるサイトを0.9.6.3系に
　　　”カスタムアップグレード”したところ、この文字化けは解消されました。

　　　※さくらインターネットをお使いで、ＤＢをＶ５に上げようとお考えの方はご注意を。


（４）（５）　1.0版では、ログイン画面のデザインが固定になりました（？）。
　　　以前のバージョンではグローバル設定でマネージャテーマを変えるとログイン画面も変わりましたが、
　　1.0では変化しません。これは、意識的な仕様変更のようです。
　　　また、更新操作を行うと、Carbonテーマが強制的に適用されたような覚えが・・・
　　　（記憶がはっきりしません。どなたかフォローを・・・）

以上、更新のお役に立てば幸いです。

ログイン画面まわりは以前までは該当のテーマディレクトリ内に収録されてましたが、今回から assets\templates\manager ディレクトリに移されました。Carbon決め打ちのファイル構成なのでちょっと違和感ありますが、リソース領域なのでコア領域よりは用途に応じて自由にさわっていい感じですね。その程度の目的ではない気はしますが・・
管理画面トップのダッシュボード領域のwelcome.htmlも同じようにテーマディレクトリ管轄外とされました。

プラグインのインストールについては、MODxはもともとプラグインを手軽にインストールするフレームワークを実装してなくて、インストーラ頼りなところがちょっとまずい気がします。インストーラがなければ手作業でイベント登録しないといけないし。他のCMSだったらもっと簡単に拡張機能をインストールできるわけだし、MODxでも今後の課題として提案してみたいです・・

ファイルのタイムスタンプに関しては、実際には改修を加えていないのにタイムスタンプのみ更新されているファイルが0963日本語版ベータ１にいくつかあって、そっちのほうの問題のような気がします。今回のevo日本語版ベータに関しては、本家版と比べる限りにおいてはタイムスタンプを巻き戻したりなどはないですし。マージツールが高機能なおかげで、タイムスタンプではなく実際に中身を見て更新を判別しています。

整理したつもりでもまだファイル数がそこそこあって大変ですけど、やっぱり全部上書きが無難ぽいですね。

見様見真似でやってるところがかなりありますので、「こんなことになった人がいるんだ」的に
読んでいただければ・・・　＾＾；

さて、昨日本家ＪＩＲＡ（バグトラッカー）に、ある障害レポートを提出しました。
1.0では改修されてるだろうと期待を込めて試したのですが、残念ながらまだのようです。
この障害は、通常の使用では殆ど目に付かないものですが、modxをフレームワークとして
使う場合の大きな制約になるため、何とか早めに修正して頂きたいと思ってます。

［概要］
　テンプレート変数の規定値にバインド（@EVAL）を設定しても処理されない

［参考サイト］
　http://modxcms.com/forums/index.php/topic,24564.msg193606.html#msg193606　　　　　　　　　

原因と修正方法をご存知の方がおられましたら、ご指導のほど宜しくお願いします。

このスレッドに書いていいものかどうか...?

Quote from: sama55 at May 19, 2009, 09:32 AM

［概要］
　テンプレート変数の規定値にバインド（@EVAL）を設定しても処理されない

やったことが無かったんで、自分でも試してみました。
普通にテキスト型のTV(ウィジェット無し)を作って、規定値に「@EVAL return time();」と書いて、
コンテンツとして [*TV_Name*]と書いてみたんですが、
それっぽくUNIX時刻らしき桁数の整数値が表示されました。

...ということができないという問題ではないんですよね?

tkfmさんありがとうございます。

Quote from: tkfm at May 19, 2009, 10:31 AM

このスレッドに書いていいものかどうか...?

確かに仰るとおりで・・・すんませんです。＾＾；
Quote from: tkfm at May 19, 2009, 10:31 AM

普通にテキスト型のTV(ウィジェット無し)を作って、規定値に「@EVAL return time();」と書いて、
コンテンツとして [*TV_Name*]と書いてみたんですが、
それっぽくUNIX時刻らしき桁数の整数値が表示されました。

...ということができないという問題ではないんですよね?

tkfmさんの説明で気がついたのですが、この件私の思い込み（というか、願望）だったようで、
障害としたのは間違いでした。申し訳ないです！

私の期待結果は、ドキュメント編集時にも@EVAL処理した結果を表示して欲しい、でした。

実例を挙げてご説明しますと、例えば、pagetitleのクローンとなるpagetile2というテンプレート変数を
Text属性で作り、規定値を、@EVAL return $modx->runSnippet(’GetField’, array(’field’=>’pagetitle’));
とした場合、このテンプレート変数が有効なドキュメントを開くか、ドキュメントの編集中にこのテンプレート
変数が有効なテンプレートに切り替えた場合に、編集画面内のテンプレート変数の入力フィールドに、
開くか、切り替えた時点のpagetitleを初期表示して欲しい、という”願望”でした。

このような願望を抱くのは、ドキュメントの編集者が技術者であれば、@EVAL・・・と表示されても別段
問題ありませんが、テンプレート変数は入力データ拡張ですから、当然、技術的なことが分からない
エンドユーザにも@EVAL・・・を見せることになり、何かの手違いでコードを触ってしまうと、その項目が
まったく出力されないということが簡単に起こってしまいます。
こんな思考が働いたため、お門違いな願望を障害と考えてしまったのかもしれません。

ある意味MODxらしい実装であるようにも思えます。これだと困るというニーズも理解できるし、選択できるといいですが。
実際のところ、たとえばeval文が実行されるタイミングのグローバル変数の値などに依存するような内容だったりするケースが
あるでしょうし、厳密に対応しようと考えると難しいと思います。たぶんこういうところは厳密に考えたいところでは。

代替案として、ドキュメント編集画面ではリードオンリーまたはhiddenにしてしまえる選択をつけるとかはアリかも？

Quote from: sama55 at May 19, 2009, 12:30 PM

私の期待結果は、ドキュメント編集時にも@EVAL処理した結果を表示して欲しい、でした。

あ～それはmodxの構造上難しいんじゃないですかね～

管理者の事故的な誤編集を防止するとなると、
触られたくないフィールドはManagerManagerプラグインとかで隠しちゃうとか、
入力オプションとしてテキスト型の入力は極力使わないようにするとかしか思いつきません...

Quote from: tkfm at May 19, 2009, 01:45 PM

Quote from: sama55 at May 19, 2009, 12:30 PM

私の期待結果は、ドキュメント編集時にも@EVAL処理した結果を表示して欲しい、でした。

あ～それはmodxの構造上難しいんじゃないですかね～

そうですね～。考えれば考えるほどそう思えてきます。
フレームワークとしては、あってしかるべき実装とも思えるのですが、高望みなんでしょうか。。。 :’(
eZやTYPOあたりは軽くこなしてくれたりして・・・

Quote from: tkfm at May 19, 2009, 01:45 PM

管理者の事故的な誤編集を防止するとなると、
触られたくないフィールドはManagerManagerプラグインとかで隠しちゃうとか、
入力オプションとしてテキスト型の入力は極力使わないようにするとかしか思いつきません...

ManagerManagerにmm_defaultというメソッドがあるのを思い出して、検証してみたのですが、
真偽値や日付の設定しかサポートしてなくてこちらもアウトでした。コードの改造はなるべく
やりたくないし。。。Revoに期待ですかね。

mutate_content.dynamic.phpにほんの数行ほどの改造を加えたら、簡単なphp出力ならあっさりと実現できそうな気はします。
（興味があれば調べてみますが）
MODxの構造と紐付くようなeval文を書くのはちょっと無理があるかもしれませんね。

追記
処理をしてるのはmanager/includes/tmplvars.inc.phpのようです