てがろぐ - Fumy Otegaru Memo Logger -

昼食はそうめん。🧊🧊🧊

🧊Re:5181◆なるほど、新たな視点をどうもありがとうございます！ 投稿からの経過時間に応じて表示を変えるという発想はありませんでした。今のところ経過時間に応じて表示/非表示が切り替わるような機能はないのですが、[[DATE:～]]記法に『投稿からの経過秒数』を得られるようなオプションを加えてみましょうかね？ そうすると、JavaScriptを使って簡単に経過時間が判別できるので、JavaScriptで表示/非表示を切り替えられるでしょうし。

《補足》現状でもJavaScriptで実現できなくはない話

なお、現状でも、JavaScriptで const $pastTimeStr = "[[DATE:A]]"; のように書くと、変数 $pastTimeStr には「5秒前」や「10分前」や「3時間前」や「2日前」のような文字列が入ります。

事前に、てがろぐ管理画面の[設定]→[ページの表示]→【経過時間(相対時間)の表記】で、『1時間以上 24 時間未満なら「時間」で表示』のように、24時間を超えると「日」単位で表示されるように設定を変更しておけば、24時間が経過した時点で「2日前」という表示になります。
とすると、この変数$pastTimeStrの中に「秒」か「分」か「時間」という漢字が含まれていなければ、投稿から24時間以上が経過していると判断できます。

これを使って、（例えば相対時間表記の部分に <span id="pastTime[[POSTID]]">[[DATE:（A）]]</span> のような感じで、その要素を特定できる何らかのid名を割り振っておけば）JavaScriptで表示/非表示を切り替えることはできそうに思います。

(追記) ➡もっと良い方法を No.5185 さんが提示して下さいましたので、それを実現するソースを No.5186 に書きましたからそちらをご覧下さい。

🧊Re:5182◆そうですね。Skebサイトに久しぶりにアクセスしたとき、ほんの数秒間くらいだけ『繰り返し表示される場合はCookieを有効にしてください』のような表示が出ますよね。なので、Skebのページをまともに閲覧するには、Cookieを使ったセッション確認的なものが必須なんだと思います。（つまり、Cookieを受け入れる仕組みを持ったユーザエージェント以外でアクセスすると中身が見えない。）
Skebは、利用規約でプログラムによる自動アクセスを禁止していますが、単に禁止と言うだけではなくて、技術的にもアクセスを拒否する仕組みを用意しているということでしょうね。

そもそも、人間がブラウザでアクセスしても、Skebのページって「JavaScript前提」になっているんですよね。HTMLソースを表示させても、Skebページ内に見えている日本語文字が出てきません。^^;
なので、Skebは「Cookieを受け入れた上で、JavaScriptが実行できる環境」（要するに一般的なブラウザ）からのアクセスしか受け付けない実装になっているのではないかと思います。

……とはいえ、Twitter Cardっぽい情報の欠片みたいなのはHTMLソースに含まれていますから、Skeb側が認めたSNS等からOGPを参照された場合には正しく情報を返すような仕組みが（Skeb側に）用意されているのかもしれません。

任意のWebサイトからSkebのOGPを読んでリンクカードを作るのは、たぶん諦めるほかないのではないかな……と思います。（もしかしたらSkeb側が何かAPIを用意しているかもしれないのですが、軽く探してみた限りでは見つけられませんでした。もし何か公式情報があるようでしたら教えて下さい。）

あいうえお

tesuto
(Loading...)...

SkebへのカードリンクがダメなのってSkeb側の仕様なんですかね……

検索して探したのですがなかなか見つからなかったので、こちらにて失礼します。経過時間(相対時間)表記機能について質問です。[[DATE:《A》]] を使ってn秒前やm分前という表示を24時間以内の時だけ表示させ、24時間を過ぎたら非表示にしたいのですが、この場合はどこを設定すればできますか？
経過時間の表記変更は設定の項目でできる事は分かったのですが、一定時間後に非表示にするなどの方法が探してもなかなか見つからなくこちらで質問させて頂きました。
お忙しいところ恐れ入りますが何卒よろしくお願い致します。

5174/5176です。要望、ご検討いただきありがとうございます。

また、余談とのことでしたが、具体的な対応策を詳細にご教示いただき、ありがとうございました。何度も読み返させていただきました。

少し前に、同じく手作業で1000件ほど、SNSの投稿データをてがろぐに移動させたことがあったものですから、300件くらいなら…と、感覚が麻痺してしまっていたような状態でした。
でも、やはり何かしら効率化は【できる】し、恐らく自分の勉強のために、【やるべき】でもあるのだなと猛省いたしました。ご想像のとおり、プログラミング言語やAIとは縁遠い人生でしたので、これを機にもう少し、勉強してみようと思います。

この度は色々とお時間を割いていただき、誠にありがとうございました。

朝食はサンドイッチ。🥪🥪🥪

🥪Re:5178◆おっしゃるとおり、30MBというのは「サーバへのアップロード時の連続通信を切る閾値」でしかなく「扱えるサイズの上限」というわけではありません。なので、FTP等の別手段でUPした場合は、30MBを超えていても（てがろぐ側が扱う上では）問題はありません。その画像を [PICT:～]で表示させても問題ありませんし、画像管理画面に出しても問題はありません。

仕様上の上限があるのは、●CGI側の処理がサーバに負荷を掛けすぎていると解釈されないようにするため、●誤って巨大なファイルをUPしてしまわないため、●未知の不具合で莫大なファイルがUPされてしまうようなケースがあった場合の被害を軽減するため、などが理由ですが、その閾値を30MBに設定しているのは「まあ、それくらいを超えるファイルをUPする需要はないだろう」という予想からでしかありません。(^_^;) よほどそれでは不足するようなら見直しも考えます。（プログラムの起動時点で上限を固定しておく必要があるので、設定画面等でユーザが自由に変更できるようには作れないので。）

平素より大変お世話になっております。
素敵なツールの開発に継続的な改良、本当にありがとうございます。
自分好みにカスタマイズ可能でマイペースにつぶやき・メモを残せる理想のミニブログとして愛用させていただいています。

当方、てがろぐにてイラストを投稿することがありますが、投稿に失敗することが度々ありました。
そこでユーザー側で設定可能な画像の容量上限とは別にCGI側にて設定されている「強制的にHTTP接続を切る仕様上のデータサイズの上限」は30MBとの記載を見つけ、投稿に失敗したすべての画像がこのサイズを超過していたためおそらくこの仕様に引っかかったものと思います。
質問ですが、例えばFTPでサイズ上限を超過するメディアファイルをアップロードの上でてがろぐの投稿から [PICT:メディアファイルのパス]とした場合てがろぐの動作に支障はありませんでしょうか？
記載を読む限り30MBはサーバーとの通信を切る上限サイズでてがろぐで扱えるデータサイズの上限ではないと読み取れますが、CGIの仕様には疎いため念の為質問をさせて頂きました。(それ以前に上限に収まるように事前に調整すべきとは思います…)

#質問