1.0.14J-r2 以降の日時情報型テンプレート変数について トピックは解決済みです

プログラム(機能)関連の開発の話題
shobu
メンバー
メンバー
記事: 91
登録日時: 2011年5月26日(木) 16:54

1.0.14J-r2 以降の日時情報型テンプレート変数について  トピックは解決済みです

投稿記事by shobu » 2014年8月20日(水) 10:12

いつもお世話になっております。

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;
?>
アバター
yama
管理人
記事: 2929
登録日時: 2009年7月29日(水) 02:50

Re: 1.0.14J-r2 以降の日時情報型テンプレート変数について

投稿記事by yama » 2014年8月20日(水) 15:31

https://github.com/modxcms-jp/evolution ... e518e6fdc9
こちらの件ですね。パーサでPHxを通さず記述した場合に日付形式で出力するようにしたもので、API経由のアクセスは従来どおりです。

コード: 全て選択

if($output) return $output;

あえてUNIXTIME形式の値を表示したい場合は、上記のようなPHxモディファイアを通して出力できると思います。
shobu
メンバー
メンバー
記事: 91
登録日時: 2011年5月26日(木) 16:54

Re: 1.0.14J-r2 以降の日時情報型テンプレート変数について

投稿記事by shobu » 2014年8月20日(水) 15:47

ご回答ありがとうございます。

そういうことですね。。。
テンプレートその他にダイレクトに [*pub_date*] と書くようなケースは殆どないですし(YYYY/mm/ddになった今後は分りませんが)、
APIにも影響なしということでしたら安心しました。

引き続きよろしくお願いいたします。