No.3498, No.3497, No.3496, No.3495, No.3494, No.3493, No.3492［7件］
開発進捗状況報告サイトで、てがろぐ Ver 3.9.2(β版)の配布を開始しました。ご自由にダウンロードしてご活用頂けます。お試し頂ければ幸いです。主に以下の点を搭載しています。
🆕 Ver 3.9.2βの更新点(概要)：
《▼新機能》
●設定に『上書きスタイルシート』項目を新設し、そこに書いたCSSソースを「スキンのhead要素末」または「スキン内の指定箇所」に挿入できる機能を追加。
●文字数を指定して本文の一部分を抽出する記法で、三点リーダではない任意の記号を指定できる新記法 [[COMMENT:TITLE:文字数:省略記号]] 等を追加。
●Powered-by表記のリンクを別タブでのリンクにできる新記法 [[VERSION:NEWTAB]] を追加。（a要素に target="_blank" rel="noreferrer noopener" の2属性を付加。）
《▼仕様改善》
●日付一覧・日付検索のリストで、2000年より古い日付もリストアップできるように改善。（ただし1970年以降のみ）
●日付境界バー内部の日付表記やリンクをCSSで装飾しやすいように、マークアップとclass名を追加。
●「補助出力」設定で、ギャラリーモード等のためのスキンディレクトリの指定でも相対パスを使用可能に。（従来は / や . 等の記号が強制削除されていました。）
●スキンのプレビュー適用時に、絶対パスや上位ディレクトリを参照する相対パスの記述での指定を許可するか禁止するかを設定可能に。
《▼不具合修正》
❎投稿日時として50年以上前の日付を指定すると、相対時間表記（＝投稿時点からの経過時間の表記）が正しくなくなる問題を修正。
詳しい使い方などは、上記の開発進捗状況報告ページの記事をご覧下さい。
🆕 Ver 3.9.2βの更新点(概要)：
《▼新機能》
●設定に『上書きスタイルシート』項目を新設し、そこに書いたCSSソースを「スキンのhead要素末」または「スキン内の指定箇所」に挿入できる機能を追加。
●文字数を指定して本文の一部分を抽出する記法で、三点リーダではない任意の記号を指定できる新記法 [[COMMENT:TITLE:文字数:省略記号]] 等を追加。
●Powered-by表記のリンクを別タブでのリンクにできる新記法 [[VERSION:NEWTAB]] を追加。（a要素に target="_blank" rel="noreferrer noopener" の2属性を付加。）
《▼仕様改善》
●日付一覧・日付検索のリストで、2000年より古い日付もリストアップできるように改善。（ただし1970年以降のみ）
●日付境界バー内部の日付表記やリンクをCSSで装飾しやすいように、マークアップとclass名を追加。
●「補助出力」設定で、ギャラリーモード等のためのスキンディレクトリの指定でも相対パスを使用可能に。（従来は / や . 等の記号が強制削除されていました。）
●スキンのプレビュー適用時に、絶対パスや上位ディレクトリを参照する相対パスの記述での指定を許可するか禁止するかを設定可能に。
《▼不具合修正》
❎投稿日時として50年以上前の日付を指定すると、相対時間表記（＝投稿時点からの経過時間の表記）が正しくなくなる問題を修正。
詳しい使い方などは、上記の開発進捗状況報告ページの記事をご覧下さい。
（ツイート埋め込み処理中...）Twitterで見る
>>3493
3489です。
助言と見解の表明に感謝します。
まずPHP化は考えた事なかったので、そちらも検討します。
3489です。
助言と見解の表明に感謝します。
まずPHP化は考えた事なかったので、そちらも検討します。
にししさんご説明ありがとうございます。
Ver3.9.1も快調に動作しております。固定記事の日時表示、設定でアクセス日時にできたんですね。
ここでそのような表示にした、というポストを見たことだけ覚えていたので配布版でも設定ができることに気が付いておりませんでした😅
GoogleSearchConsoleはたぶんリンクを貼ってるところはすべてクロールするんだと思います
どの対処法を施してもリストアップ自体はされます（404も拾うので
Ver3.9.1も快調に動作しております。固定記事の日時表示、設定でアクセス日時にできたんですね。
ここでそのような表示にした、というポストを見たことだけ覚えていたので配布版でも設定ができることに気が付いておりませんでした😅
GoogleSearchConsoleはたぶんリンクを貼ってるところはすべてクロールするんだと思います
どの対処法を施してもリストアップ自体はされます（404も拾うので
てがろぐでは、投稿内に含まれる1つ目の画像をOGPの og:image に出力する機能がありまして、デフォルトで有効になっています。
この機能では、投稿内にある1つ目の画像を問答無用で採用するので、1つ目の画像が「Twitter側がCardに求める様式」に該当していない場合は、Twitter Cardには画像が表示されないことになります。#🌱豆知識
一番よくありそうなケースは、SVGな気がします。Twitter CardはSVG形式の画像をサポートしていないので、SVG画像が1枚目にあるとTwitter Cardに画像は出ません。WebPは使えます。
あと、Twitter側が指定している条件は下記の通りです。
▼summary(小画像の場合)：Twitterのドキュメント
▼summary_large_image(大画像の場合)：Twitterのドキュメント
この機能では、投稿内にある1つ目の画像を問答無用で採用するので、1つ目の画像が「Twitter側がCardに求める様式」に該当していない場合は、Twitter Cardには画像が表示されないことになります。#🌱豆知識
一番よくありそうなケースは、SVGな気がします。Twitter CardはSVG形式の画像をサポートしていないので、SVG画像が1枚目にあるとTwitter Cardに画像は出ません。WebPは使えます。
JPG, PNG, WEBP and GIF formats are supported. Only the first frame of an animated GIF will be used. SVG is not supported.
https://developer.twitter.com/en/docs/twitter-for-webs...
あと、Twitter側が指定している条件は下記の通りです。
▼summary(小画像の場合)：Twitterのドキュメント
Images for this Card support an aspect ratio of 1:1 with minimum dimensions of 144x144 or maximum of 4096x4096 pixels. Images must be less than 5MB in size. The image will be cropped to a square on all platforms.
➡ 縦横比 1:1、最小サイズ 144x144、最大サイズ 4096x4096 ピクセル。画像サイズは 5MB まで。画像は正方形にトリミングされる。
▼summary_large_image(大画像の場合)：Twitterのドキュメント
Images for this Card support an aspect ratio of 2:1 with minimum dimensions of 300x157 or maximum of 4096x4096 pixels. Images must be less than 5MB in size.
➡ 縦横比 2:1、最小サイズ 300x157、最大サイズ 4096x4096 ピクセル。画像サイズは 5MB まで。
この動作試験場(兼サポート場)では、先頭固定投稿の投稿日時が「本来の投稿日時」ではなく「アクセスした瞬間の日時」になっています。先頭固定投稿の日時表示をどうするかは、管理画面の［設定］→［ページの表示］→【先頭に固定表示する投稿】の「先頭に固定する投稿の日付表示」欄で下図のように選択できまして、ここでは下図のように「現在日時(アクセスされた瞬間の日時)を表示」に設定してあります。
このような設定項目を設けているのは、先頭に固定された投稿の投稿日時が古い場合は、「アクセス者が最初に見る(可能性の高い)投稿日時」が古いことになるので、そこを見ただけで「なんだ、このページはさっぱり更新されていないではないか」と誤解されてしまう可能性があるかなと思いまして、それを避けるためです。
他にも、そもそも投稿日時を出力しない設定とかにもできます。デフォルト設定は「本来の投稿日時」です。#🌱豆知識
詳しくは、ヘルプドキュメントの「先頭に固定した際にだけ投稿日時の文字列を自動変更する方法」をご覧下さい。
このような設定項目を設けているのは、先頭に固定された投稿の投稿日時が古い場合は、「アクセス者が最初に見る(可能性の高い)投稿日時」が古いことになるので、そこを見ただけで「なんだ、このページはさっぱり更新されていないではないか」と誤解されてしまう可能性があるかなと思いまして、それを避けるためです。
他にも、そもそも投稿日時を出力しない設定とかにもできます。デフォルト設定は「本来の投稿日時」です。#🌱豆知識
詳しくは、ヘルプドキュメントの「先頭に固定した際にだけ投稿日時の文字列を自動変更する方法」をご覧下さい。
さくらソイラテを飲みました。🌸🌸🌸
🍓Re:3489◆Perlで書けば書くほど他の言語に移植しにくくなると思うので、PHPに置き換えるのが最終目標なら、先に現状をPHPに移植するところから始めた方が良いのではないかな……という気もします。ある機能を作るとき、Perlで書くのとPHPで書くのとではPHPの方が圧倒的に便利なので、（最終的にPHP化しようという考えがあるなら）Perlで機能追加はしない方がトータルでは楽なのではないかな……と思います。いや、もちろん開発者次第ではありますが。^^;
🍓Re:3490◆ご表明をどうもありがとうございます！ あれから全く製作は進んでいないんですが(^_^;)、製作再開しても良いかな……という気もしつつあります。
🍓Re:3491◆何か対処法があれば良いのですが、なかなかなさそうな気がしているのですよね……。対策としては rel=canonical でURLを正規化する方法があるわけですけども、だからといって、特定のハッシュタグ限定ページや日付別ページを、特定の単独ページに正規化して良いわけではないですよね……。postid=のパラメータがないURLのクロールをブロックする手はあるかも知れませんが。(^_^;) 何か良い方法はないですかね？？ ある条件での限定ページで、対象投稿が1件しかなかった場合には、その単独投稿ページのURLを rel=canonical で指定するようにする、という手はありそうな気もするのですが。
(追記)
🍓Re:3492◆おっと、回答を書いている間にレスが。rel=noindex でブロックした場合も「noindex タグによって除外されました」という理由でリストアップされるので、正攻法としては rel=canonical しかないのかな、という気もしています。というか、そういう重複ってCMSではどこでも発生しそうなので、何かそれ専用の対策をGoogleが用意してくれても良いのではないかと思うのですけどもね……。^^; rel=canonical みたいに正規化はせずに、しかし「このページには他のページと同じコンテンツが含まれていますよ」と示すだけに留めておくmeta指示みたいな……。^^;
(さらに追記)
Search Consoleをよく見たら、rel=canonical で正しく正規化できている場合でもなお、「代替ページ（適切な canonical タグあり）」という理由で『ページがインデックスに登録されなかった理由』欄にリストアップされていますので、これはもうCMS的なツールでは避けようがない、という解釈で居るのが良いのではないでしょうか。(^_^;;; >>3492,3491
「登録されたいのに登録されない」という場合は問題ですが、そうでないなら（検索上不利になるエラーとかそういうわけではないので）No.3492さんのおっしゃるように気にしないのが良いのではないかな……と思います。
🍓Re:3489◆Perlで書けば書くほど他の言語に移植しにくくなると思うので、PHPに置き換えるのが最終目標なら、先に現状をPHPに移植するところから始めた方が良いのではないかな……という気もします。ある機能を作るとき、Perlで書くのとPHPで書くのとではPHPの方が圧倒的に便利なので、（最終的にPHP化しようという考えがあるなら）Perlで機能追加はしない方がトータルでは楽なのではないかな……と思います。いや、もちろん開発者次第ではありますが。^^;
🍓Re:3490◆ご表明をどうもありがとうございます！ あれから全く製作は進んでいないんですが(^_^;)、製作再開しても良いかな……という気もしつつあります。
🍓Re:3491◆何か対処法があれば良いのですが、なかなかなさそうな気がしているのですよね……。対策としては rel=canonical でURLを正規化する方法があるわけですけども、だからといって、特定のハッシュタグ限定ページや日付別ページを、特定の単独ページに正規化して良いわけではないですよね……。postid=のパラメータがないURLのクロールをブロックする手はあるかも知れませんが。(^_^;) 何か良い方法はないですかね？？ ある条件での限定ページで、対象投稿が1件しかなかった場合には、その単独投稿ページのURLを rel=canonical で指定するようにする、という手はありそうな気もするのですが。
(追記)
🍓Re:3492◆おっと、回答を書いている間にレスが。rel=noindex でブロックした場合も「noindex タグによって除外されました」という理由でリストアップされるので、正攻法としては rel=canonical しかないのかな、という気もしています。というか、そういう重複ってCMSではどこでも発生しそうなので、何かそれ専用の対策をGoogleが用意してくれても良いのではないかと思うのですけどもね……。^^; rel=canonical みたいに正規化はせずに、しかし「このページには他のページと同じコンテンツが含まれていますよ」と示すだけに留めておくmeta指示みたいな……。^^;
(さらに追記)
Search Consoleをよく見たら、rel=canonical で正しく正規化できている場合でもなお、「代替ページ（適切な canonical タグあり）」という理由で『ページがインデックスに登録されなかった理由』欄にリストアップされていますので、これはもうCMS的なツールでは避けようがない、という解釈で居るのが良いのではないでしょうか。(^_^;;; >>3492,3491
「登録されたいのに登録されない」という場合は問題ですが、そうでないなら（検索上不利になるエラーとかそういうわけではないので）No.3492さんのおっしゃるように気にしないのが良いのではないかな……と思います。
>>3491 google seach console で未登録のページが多数存在している件について
現状できるのはrobots.txtで該当パラメータをブロックするくらいだと思いますがこれをしてもgoogle seach console「robots.txtによりブロックされました」とリストアップされてしまいます。タグや区分のリンクをインデックスに登録したい（検索結果に表示されるようにしたい）、というのでなければそんなに気にしなくてもいいのではと思います
設定でタグや区分のリンクにrel=noindex,nofollowを付加できるようになったらいいのかなぁと思いますが…
現状できるのはrobots.txtで該当パラメータをブロックするくらいだと思いますがこれをしてもgoogle seach console「robots.txtによりブロックされました」とリストアップされてしまいます。タグや区分のリンクをインデックスに登録したい（検索結果に表示されるようにしたい）、というのでなければそんなに気にしなくてもいいのではと思います
設定でタグや区分のリンクにrel=noindex,nofollowを付加できるようになったらいいのかなぁと思いますが…
