MODXから少し離れていたので今頃気づき、今さらかもしれませんが、1.0.14J-r2 以降、
日時情報型テンプレート変数の返値の型式が変更となったとありました。
これは内部的にAPIでテンプレート変数を読み出したときも同じでしょうか?
(スミマセン、ソース確認すればいいのですが、横着しました)
今回の場合、過去のバージョンとの互換性を考えて、従来のテンプレート変数の仕様は変更なし。
別途、
[*iso-createdon*]
[*iso-editedon*]
[*iso-publishedon*]
[*iso-pub_date*]
[*iso-unpub_date*]
などと別名を指定した時に YYYY/mm/dd を返してくれるようなイメージが良かったのではないかと思いましたが、
どうでしょうか・・・。
今更感たっぷりで申し訳ないですが、もう、元には戻せないですよね…。
-----------
こういった変更は既存サイトのアップデート時、広範囲に影響を及ぼすような気がします。
unixtimeが欲しければ :unixtime と入れれば良いじゃない、、、というのはそうかもしれませんが、
前述のAPIでの読み出し時も同じ状況だとすれば、既存のプラグイン、スニペットの中にも改変が必要な
ものが出てきてしまうように思えますし、以前の経緯で、本体コード中でも気になる箇所が沢山あるような
気もしますが、どうでしょうか。
掲示板をながめた限り、今の所、この件に起因すると思われるような話題はありませんでしたが、、、
私個人が関わる狭い範囲ですが、日付を表示させたい場合、前述の :unixtime のようなイメージで
phpのdate関数のフォーマット指定で書式変換できるphxコードを作成し、場面に合わせて変換させて
いるケースが多く(他言語環境だとYYYY/mm/dd の順番や表記が良いとも限らないので、unixtime
ベースからの変換が適当だなぁ、という印象です)、こういった細かいケースはエンドユーザが少し手を
入れれば対応できると思うのですが、プラグインやスニペット中で問題が出るとこれらの調整は少し大変
ではないかと思っています。
ついでなので前述のphxでの変換コードを記載しておきます。簡単なコードですが、人によっては便利
かもしれません。入力が数値でない(UNIXTIMEでない)場合はstrtotimeでUNIXTIMEにするように
なっていますので、これに関しては新仕様の環境でも動くんではないかと思います。
コード: 全て選択
<?php if(!is_numeric($output)){ $output=strtotime($output); } $val = date($options,$output); return $val; ?>