カテゴリ「情報」・「アップデート✨」・「雑記」・「つぶやき」・「つぼやき」・「質問/要望」・「回答/返信」・「テスト」のどれかに属する投稿[1205件](3ページ目)
🍨Re:5118-5119◆ご確認ありがとうございます。問題が解消していて良かったです~。(╹◡╹)ノ これで次は正式版(4.6.0)リリースで問題なさそうな感じですね。^^
by nishishi. ⌚2025年4月20日(日) 20:19:23〔111日前〕 回答/返信 <194文字> 編集
🧀Re:5114◆まさに必要な情報をありがとうございます。
ログイン限定モードで使用しているためこれが原因です。ログイン者限定モードでは、ログインしている人しか中身を閲覧できません。「OGPを読みに来るクローラー」は当然『ログインしていないユーザ』なので中身は読めず、「非ログイン状態の画面」しか読み込めないのです。したがって、OGPの記述も読めないわけです。これは、Basic認証で保護されたページのOGPが読めないのと同じことです。
🧀Re:5115◆ご確認ありがとうございます~。(╹◡╹)ノ
by nishishi. ⌚2025年4月18日(金) 21:58:09〔113日前〕 回答/返信 <280文字> 編集
by nishishi. ⌚2025年4月18日(金) 21:07:03〔113日前〕 回答/返信 <256文字> 編集
🆕 Ver 4.5.7βの更新点(概要):
《▼新機能》
●投稿欄下部のボタンでカード型リンクを挿入できるようにする「OGPカード」ボタンの表示機能を追加。
《▼不具合修正》
❎カード型リンクが文字化けするケースがある問題を(さらに)修正。
詳しい使い方などは、上記の開発進捗状況報告ページの記事をご覧下さい。
🍘SNSでのアナウンス:
Mastodon(Pawoo)
Bluesky
Twitter:
(ツイート埋め込み処理中...)Twitterで見る
by nishishi. ⌚2025年4月18日(金) 19:46:52〔113日前〕 アップデート✨ <300文字> 編集
>>効かなくなっているのはDirectoryIndexだけでしょうか? 他のiniファイルやxmlファイルへのアクセスを拒否する設定は、ちゃんと403エラーを返すでしょうか?(500エラーではなく)
今まで使用していた.htaccessのままtegalog.ini、tegalog.xmlにアクセスしたところ、共に403エラーを吐きました。
>>どのような操作をしたときに(または、どのようなURLにアクセスしたときに)500エラーが出るのか
tegalog.cgiを抜いたURLへのアクセス(https://~/tegalog/tegalog.cgiではなく、https://~/tegalog/)で500エラーを吐く状態でした。
(htmlのリンクでジャンプした場合、URL直接入力した場合共に)
>>もしDirectoryIndexが効かないのであれば、てがろぐパッケージに含んでいる(またはここからダウンロードできる) (Recommend).htaccess ファイルを使ってアップロードし直してみて下さい。
改めてダウンロードさせていただいた.htaccessをアップロードしたところ無事tegalog.cgiを抜いた状態でアクセスができました。
もともと使っていた.htaccessですが、にしし様が配布されている.htaccessに
ErrorDocument 403(以下独自に設定したエラー画面の場所)
ErrorDocument 404(以下独自に設定したエラー画面の場所)
を追加したものになります。
この二行がサーバーと相性が悪かったのかもしれません。
お騒がせいたしました。
by admin. ⌚2025年4月15日(火) 22:37:36〔116日前〕 回答/返信 <716文字> 編集
🥐Re:5104◆情報ありがとうございます~。(╹◡╹)ノ
🥐Re:5105◆.htaccessは、てがろぐ側が解釈するわけではなく、Webサーバ側が解釈するので、「DirectoryIndexの指定が、てがろぐのバージョンによって適用されたりされなかったりする」ということはありません。なので、もしそのような動作になるのなら別のところ(サーバの設定や、.htaccessの書き方や、他のディレクトリにある.htaccessファイルなど)が影響しています。
効かなくなっているのはDirectoryIndexだけでしょうか? 他のiniファイルやxmlファイルへのアクセスを拒否する設定は、ちゃんと403エラーを返すでしょうか?(500エラーではなく)
もしDirectoryIndexが効かないのであれば、てがろぐパッケージに含んでいる(またはここからダウンロードできる) (Recommend).htaccess ファイルを使ってアップロードし直してみて下さい。
なお、.htaccessとは関係なく、てがろぐの動作によって500エラーが出る可能性はあります。
なので、「どのような操作をしたときに(または、どのようなURLにアクセスしたときに)500エラーが出るのか」について詳しく教えて頂ければ、何らかの回答ができるかもしれません。
by nishishi. ⌚2025年4月15日(火) 10:55:46〔116日前〕 回答/返信 <622文字> 編集
🥐Re:5099◆ご指摘ありがとうございます。確かにPixivは文字化けしますね。いーろいろ実験して確認したところ、pixivは『ログイン状態で閲覧した場合はHTMLに文字コードの情報が含まれる』のに『ログアウト状態で閲覧するとHTMLに文字コードの情報が含まれていない』ことに気付きました。┌(:3」└)┐ ずっと、ログイン状態で確認していたんですけども、PHPプログラムは当然ログアウト状態のHTMLしか取得できませんからね……。^^; とりあえず、こちらのローカルにあるプログラムでは対処しました。次の 4.5.7β では、少なくともPixivの文字化けは解消します。もうしばらくお待ち下さい~。
by nishishi. ⌚2025年4月13日(日) 21:09:59〔118日前〕 回答/返信 <502文字> 編集
昨日の4.5.5βにあった3点の不具合を修正しました。
- カード型リンクが文字化けするケースがある。
- リスト記法で何らかのオプションを加えると表示されなくなる(記法によっては先頭項目だけ見える)。
- 鍵入力窓を自由な位置に配置する機能が無効になる。(指定位置ではなく先頭に鍵入力窓が出て、すべて隠されてしまう。)
🍘SNSでのアナウンス:
Mastodon(Pawoo)
Bluesky
Twitter:
(ツイート埋め込み処理中...)Twitterで見る
by nishishi. ⌚2025年4月13日(日) 19:29:05〔118日前〕 アップデート✨ <289文字> 編集

正規表現では、角括弧や丸括弧に特殊な意味があるので、角括弧や丸括弧そのものに一致させたい場合には \[ や \( のようにエスケープしないといけないので、ちょっと見た目がややこしいですが。(^_^;)
テキストエディタによって微妙に書き方が異なる可能性がありますが、例えばEmEditorだと以下のような正規表現でいけます。
検索語: \[(.+?)\](\(?http)
置換後: [\1:CARD]\2
※書き換えてはいけないケース(書き換えたくないケース)を除外するためにも、「すべて置換」ボタンで一括処理するのではなく、「置換」ボタンの方を押して1つずつ確認しながら処理する方が望ましいと思います。
※お試しになる場合には、事前に tegalog.xml ファイルをローカルにバックアップするのを忘れないようご注意下さい。
by nishishi. ⌚2025年4月13日(日) 15:03:56〔118日前〕 回答/返信 <460文字> 編集
また、不具合報告もありがとうございます。助かります。
今のところ Ver 4.5.5βで認識している不具合は以下の3点です。
1. カード型リンクが文字化けするケースがある。
2. リスト記法で何らかのオプションを加えると表示されなくなる(記法によっては先頭項目だけ見える)。
3. 鍵入力窓を自由な位置に配置する機能が無効になる。(指定位置ではなく先頭に鍵入力窓が出て、すべて隠されてしまう。)
カード型リンクが文字化けするケースは、おそらく「HTMLソース内に <meta charset="UTF-8"> のような文字コードを表す記述が出るよりも前の段階で、日本語文字などの非ASCII文字が出現している場合」に発生しているような気がします。
とりあえず、こちらのローカルにあるファイルでは(たぶん)解消しましたので、今日の内には Ver 4.5.6β を出します。もうしばらくお待ち下さい。
あと、上記の3点以外に何らかの不具合を目撃していらっしゃれば、教えて下さい。(今のところ、上記の3点しか認識していませんので。)
by nishishi. ⌚2025年4月13日(日) 14:34:16〔118日前〕 回答/返信 <492文字> 編集
(たとえ画像URLがHTTPで出力されていても、同じURLでプロトコルをHTTP→HTTPSに変えるだけで閲覧できるのであれば、(最近のChromeなら)ブラウザ側が内部で切り替えて表示してくれるのですけども。HTTPとHTTPSとでURLが異なる場合には(存在を認識しようがないので)ブロックされます。)
で、解決策ですが、てがろぐ管理画面の[設定]→[システム設定]→【フルパス設定】で『固定』の方に切り替えた上で、その入力欄に『 https://ss1.xrea.com/ から始まっているURLで表記した場合の、てがろぐが存在するディレクトリまでのURL』(※)を入力して保存してみて下さい。そうすると、プログラム側が認識する「自分の位置」を強制的に固定できますので、おそらく問題はなくなると思います。
※具体的にどう指定する必要があるかは実際に見ないとわかりませんが、たぶん https://ss1.xrea.com/hogehoge/higehige/tegalog/ のような感じではないかと思います。最後の文字は「/」になります。)
なお、一番良いのは、共有SSLを使わずに、「独自ドメイン」または「サーバ会社提供の、自分だけが権利を持てるサブドメイン( hogehoge.なんたら.com みたいな)」で自分専用のSSLを使う方法です。(ご契約のサーバでそれが可能なのかどうかは分かりませんが。)
by nishishi. ⌚2025年4月3日(木) 23:06:39〔128日前〕 回答/返信 <852文字> 編集
by nishishi. ⌚2025年4月3日(木) 17:07:29〔128日前〕 回答/返信 <88文字> 編集
🌳Re:5062◆てがろぐが出力するHTMLソースに、どんなURLが出力されているのかを確認してみて下さい。
例えば、 sample1.jpg という画像なら、てがろぐは、 <img class="embeddedimage" src="images/sample1.jpg" width="~" height="~" loading="lazy" alt="~"> のようなHTMLを出力します。
画像が表示されないということは、このURLの出力結果に問題があるということでしょうから、まずはこの点を確認してみる必要があります。
どんなHTMLが出力されていますか?
by nishishi. ⌚2025年4月3日(木) 13:12:38〔128日前〕 回答/返信 <342文字> 編集
🍔Re:5055◆その適用順序は半分(前半が)間違っていますのでご注意下さい。robots.txtでクローラーをブロックすると検索避けができなくなる点は、Google自身が公式ヘルプで明言しています。(「インデックスに登録してはいけない」という指示自体が読めなくなるため)
robots.txt ファイルでページのクロールが許可されていない場合、インデックス登録や表示に関するルールについての情報は検出されず、その結果無視されます。
後半の「metaタグ→それでも読まないお行儀悪いものは.htaccess」は正しい順序ですが、最初に「まずはrobots.txtを読んでもらう」とすると、Googleでは検索避けに失敗します。(※robots.txtでGoogle等の紳士的なクローラーをブロックしていないなら問題ありませんが。)
🍔Re:5053◆Googleに関してはその通りです。.htaccessでブロックしてもいけないし、robots.txtでブロックしてもいけません。なぜなら、ブロックされると「登録するな」という指示自体も読めないからです。
- もちろん、robots.txtでブロックされているならクローラーはページの内容を読みませんから、(ページ内に何が書かれているのかの情報は得られないため)インデックスに登録される可能性は減りはします(※なので「この方法で検索避けは成功する」と思えるケースもあるでしょう)。
- しかし、登録禁止だという指示自体も伝わっていないため、よほど評価値の高い外部サイトからリンクされている場合などの外部要因次第では(リンク元ページにあるリンクテキストなどのように「読むことを禁止されていない場所にある情報」を用いて)インデックスに登録される可能性が残ります。
※2000年代からある古典的な話ですが、「出口」という検索語でググると、Yahoo! Japanがヒットします。これは「出口」というリンクテキストを使ってYahoo!にリンクしているサイトが多いことによる影響です。つまり、「どんなリンクテキストを使ってリンクされているのか」という情報も検索サイトに反映される(要素の1つになる)のです。なので、robots.txtでページの中身を読むことだけを禁止しても(&.htaccessでページ自体を読めなくしても)、インデックスに登録される可能性はあります。
したがって、インデックス登録を避けるには、ページそのものに書かれた登録禁止の指示を確実に読ませる必要があるため、ブロックしてはいけないのです。
……とはいえ、世の中に存在するクローラーはGoogleやBingのような比較的紳士的に動作するものだけではありません(※検索のシェアはGoogleが1強ですが)。metaタグの存在を無視してインデックスに登録しようとするクローラーも存在するでしょう。なので、metaタグを読まないような無作法なクローラーに対しては、何らかのブロックをするほかありません。(そのような無作法なクローラーはrobots.txtだって読まないでしょうから、.htaccessでサーバ側に応答を拒否させるしかないでしょう。)
したがって、検索避けを厳密にしたいなら、以下のような方策が必要です。
- まずは、metaタグを読ませる。(←紳士的なクローラーはこの指示に従うので、まずはこれを確実に読ませる必要がある。)
- (次に、metaタグを無視するようなBotだけに限定して、robots.txtでブロックする。)
- 最後に、1も2も無視するようなBotだけに限定して、.htaccessでブロックする。
この順序を逆にしてしまうと(=あらゆるクローラーを.htaccessでブロックすると)、そもそもmetaタグを書く意味がなくなってしまいますから注意して下さい。なぜなら『あらゆるクローラーがmetaタグを読めなくなる』からです。
Googleだけを対象にするなら、そもそもmetaタグだけで充分です。他の無作法なBotも対象にしたい場合は、「Googleのような紳士的なクローラーにはアクセスを許可しつつ、無作法なクローラーだけを拒否するような .htaccessを書く」必要があります。
※なお、robots.txt自体に意味がないわけではありません。検索サイト以外のクローラー(最近ではAI学習用のBotも多いですね)をブロックする用途や、「クロールそのものは許可したいがクロール頻度を低く抑えたい(=負荷軽減)」場合などの指示には役立ちます。
とはいえ、Googleはrobots.txtに書かれた「クロール頻度の指示」は無視するんですけども……。┌(:3」└)┐
🍔Re:5054◆その場合は、2つの方法があります。
- 『サイトマップページモードをカテゴリ限定で表示させたページ』をiframeで読み込んで並べるページを作る。
- 『サイトマップページモードをカテゴリ限定で表示させたページ』の中身をJavaScriptで読み込んで1ページに合成するページを作る。
by nishishi. ⌚2025年3月29日(土) 10:39:17〔133日前〕 回答/返信 <2393文字> 編集
☕Re:5049◆検索避けには、まさしくそのmeta要素を使う必要があります。
.htaccessやrobots.txtを使ってクローラーからのアクセスをブロックしてしまうと、「検索インデックスに登録するな」という指示そのものが読めなくなるので、結果として検索避けに失敗します。(他サイトからのリンクを経由してクローラーが来た場合、そのページに書かれている情報は読めないため取得されませんが、リンク元ページにあるリンクラベル等を使ってインデックスに登録される可能性があります。)
なので、検索避けのためには「『登録するな』という指示(<meta name="robots" content="noindex">)自体はクローラーにも読めるように」しておく必要があります。
※参考:このGoogle検索セントラルHelpページ末尾の「robots.txt ルールとインデックス登録および表示に関するルールとの組み合わせ」項目には、「クロール禁止の情報自体が読めなかったら、指示は無視されるよ」的なことが書いてあります。
なお、IPアドレスは明確に対象国が分割されているわけではありません。「今は日本国内に割り当てられているIPアドレスが、来月は海外で使用されている」というケースもあり得ます(もちろんその逆も)。なので、IPアドレスを使ってアクセス元を判断するには常に最新の情報にアップデートし続ける必要があり、個人ではあまり現実的ではなさそうに思います。
by nishishi. ⌚2025年3月27日(木) 11:11:13〔135日前〕 回答/返信 <667文字> 編集
まだ今週末はまた寒くなるっぽい予報ですけども。
🌸Re:5047◆なるほど。
普通の半角「 # 」記号は、Unicodeで U+0023 で、
キーキャップ化した「 #️⃣ 」は、UnicodeでU+0023 U+FE0F U+20E3 なのでそういう動作になるんですね。
- U+0023 : #
- U+FE0F : (Emoji Variation Selector)
- U+20E3 : (Combining Enclosing Keycap)
- #️⃣ ← # + U+FE0F + U+20E3
- 1️⃣ ← 1 + U+FE0F + U+20E3
- 9️⃣ ← 9 + U+FE0F + U+20E3
最初の例では、『 #️⃣これってハッシュタグになる…?』の先頭はあくまでも「 # 」で、その続きが「 U+FE0F、 U+20E3、こ、れ、っ、て…… 」になるので、『U+FE0F (Emoji Variation Selector)』から「?」までがハッシュタグだと認識されると。
U+FE0F と U+20E3 は半角文字の範囲に含まれていないので、U+FE0F から ? までを一連のハッシュタグだと認識するんですね。
次の2つの例では、先頭の「 # 」と「 [ 」や「 - 」とにある U+FE0F U+20E3 だけがハッシュタグだと認識されるので、「 #️⃣ 」だけがクリックできるわけですね。^^;
※ハッシュタグを角括弧で囲む場合は、「 # 」と「 [ 」記号が連続している必要がありますが、ここではその間に U+FE0F U+20E3 が含まれていますから、連続していません。
※隠れハッシュタグとして扱う場合は、「 # 」と「 - 」記号が連続している必要がありますが、ここではその間に U+FE0F U+20E3 が含まれていますから、連続していません。
とりあえず、「 # 」の後に U+FE0F が続いている場合はハッシュタグにしないような仕様が必要でしょうね。(^_^;)
by nishishi. ⌚2025年3月26日(水) 09:23:02〔136日前〕 回答/返信 <950文字> 編集
パエリアには、まさしくそれ用の絵文字が定義されているのか……。🥘🥘🥘
……と思ったけども、Unicodeでの定義の名称は SHALLOW PAN OF FOOD(浅い鍋の食べ物)なので環境によってはパエリアとは限らないかもしれない……?
🥘Re:5042◆反応ありがとうございます。需要がありそうだと分かってありがたいです。^^
🥘Re:5043◆計画はしましたが、どうなるかは作ってみないと分からないので、気長にお待ち下さい~。^^;
🥘Re:5044◆日本国内に割り当てられているIPアドレスからのみ閲覧を許可するには、『日本国外からのアクセスを制限する.htaccess』を使うと良さそうです。ただし、検索サイトのクローラーはたいてい海外から来ますので、それを弾きたくない場合は、このページの『5.Apache「.htaccess」設定』を参考にすると良いです。
ただ、国内のユーザが必ず日本に割り当てられているIPアドレスから来るとは限りませんし、海外からのアクセスが必ずしもそれ以外のIPアドレスから来るとは限らない(VPNもありますし)点や、海外に住んでいる日本人もブロックしてしまう点にもご注意下さい。たぶん、「国内/国外」ではなく、本当に弾きたいものに限定して弾く方が望ましいと思います。
- なお、てがろぐには「高頻度アクセス制限機能 (迷惑Bot対策機能)」を用意していますので、ご活用下さい。(使うには事前準備が必要です。)
- また、管理画面への不正ログインを警戒する場合は、「ログインセキュリティ関連機能」もありますのでご活用下さい。(一部はデフォルトで有効になっています。)
by nishishi. ⌚2025年3月22日(土) 22:04:12〔140日前〕 回答/返信 <736文字> 編集
🌸Re:5037◆β版のご試用をありがとうございます。No.4389でご要望頂いてから11ヶ月経っていましたね。^^; お役に立ったようで良かったです。(╹◡╹)
🌸Re:5039◆いいねボタン機能は、「てがろぐアドオンとしても使えて、単独でも使える、汎用Web拍手(いいねボタン)ツール」として開発しようかと計画しています。すごくうまく行ったとして、6月頃に最初のβ版が出せるといいな……と、なんとなく思ってはいます。^^; とりあえず、開発はする予定です。もうしばらく(数ヶ月)お待ち下さい~。(とはいえ、初回のβ版からいろいろ機能を盛るわけではないので、本格的に活用できるようになるにはもっとかかるかもしれませんが。)
by nishishi. ⌚2025年3月18日(火) 19:59:31〔144日前〕 回答/返信 <370文字> 編集
🥞Re:5030◆ご要望をありがとうございます。たしかに、1画像だけを消したいときには、現状のUIだと操作が面倒ですね。
🥞Re:5033◆ご要望をありがとうございます。なお、[[COMMENT:TITLE]] の代わりに [[COMMENT:LINE:1]] を使うと、1行目が空行のときには何も出力されませんのでお試し下さい。(ただし、1行目に画像等のオブジェクトがあると、それをそのまま出力してしまいますが。)
by nishishi. ⌚2025年3月14日(金) 19:53:10〔148日前〕 回答/返信 <255文字> 編集
🆕 Ver 4.5.4βの更新点(概要):
《▼新機能》
●ユーザ一覧を出力できる記法 [[USERLIST]] と [[USERLIST:識別子]] を追加。
《▼仕様改善》
●投稿削除ボタンやカテゴリ削除枠の配色を(目立ちすぎる赤色から)灰色に変更。
《▼不具合修正》
(なし)
詳しい使い方などは、上記の開発進捗状況報告ページの記事をご覧下さい。
🍘SNSでのアナウンス:
Mastodon(Pawoo)
Bluesky
Twitter:
(ツイート埋め込み処理中...)Twitterで見る
by nishishi. ⌚2025年3月14日(金) 18:28:54〔148日前〕 アップデート✨ <323文字> 編集
by admin.
⌚2025年3月11日(火) 23:41:32〔151日前〕
つぶやき
<48文字>
編集
🍛Re:5022◆情報ありがとうございます。WAF(Web Application Firewall)は、SQLインジェクションとかクロスサイトスクリプティング(XSS)とかに使われるような感じの投稿本文をチェックしてブロックしますからね。長い英文を貼り付けて投稿するだけでも、そこに「or」があって、遠く離れた位置に「=」とかの記号があるだけでもダメだったりしますし。とはいえ、WAFが使えるのならあえてOFFにはしない方が良いですから、いろいろ試していくしかないですね。^^;
🍛Re:5023◆てがろぐのご活用をどうもありがとうございます! 末永くご愛用頂ければ幸いです!(╹◡╹)ノ
🍛Re:5024◆情報ありがとうございます。WAFは、サーバに送信された文字列から「攻撃の可能性」を判断して通信をブロックするか通すかを決めますので、基本的にはスキンは無関係です。ただ、お使いのスキンに、何か必ず特定の文字列を付加して送信させるような特別なスクリプトがあるなら話は別ですが、たぶんそういうケースは滅多にないでしょうね。^^; なので、403になるパターンは、おそらく他のスキンを使っても403になります。半角の丸括弧 ( ) 記号の存在も誤判定によく影響します。(^_^;) 今更なんですけども、てがろぐの各種記法では、区切りに「/」を使って、オプションのカッコには < > を使うような、「攻撃だと誤解されにくい」書き方を採用していれば良かったな……、とは思います。(仕様を考えたときには、WAFにブロックされる可能性は全く想定していなかったもので。)
🍛Re:5025◆分かりやすい画像をありがとうございます。WAFのログをリアルタイムで確認できると、「何だと誤解されたのか」がハッキリするので良いですね。
by nishishi. ⌚2025年3月10日(月) 21:20:12〔152日前〕 回答/返信 <805文字> 編集
🍵Re:5017◆ここのてがろぐはデモモードで動作していますので、管理者権限のあるIDでログインしていても設定の変更等はできない仕様になっています(既存投稿の削除は可能ですが)。なので、どのIDでお試し下さっても構いません。
🍵Re:5016◆β版のご試用をどうもありがとうございます。(╹◡╹)ノ
🍵Re:5013◆β版のご試用をどうもありがとうございます。問題なく動作しているようで良かったです。重複投稿のNo.5014は削除しておきました。
🍵Re:5012◆ついこの前、正月だったのに……。┌(:3」└)┐
🍵Re:5011◆私は使っていないので直接の回答はできないのですが、何らかの有効な回答を得るためには、状況の説明が具体的である必要があります。設置している場所のURLを示すのが最も望ましいですが、そうできないのであれば、もうちょっと具体的な状況の説明が必要だろうと思います。「人参を買ってきましたがカレーライスになりません」と言われているような感じで、もうちょっとその中間を説明してくれないと……というような。(笑)
とりあえず、「カスタマイズせずに、スクリプト側の説明書の通りにスキンを書いた場合なら動くのか、それでも動かないのか」あたりから調べてみると良いのではないかと思います。
by nishishi. ⌚2025年3月3日(月) 13:16:26〔159日前〕 回答/返信 <603文字> 編集
🆕 Ver 4.5.3βの更新点(概要):
《▼新機能》
●カテゴリごとに「1ページあたりの表示件数」を別設定できる機能
●カテゴリごとに「表示に使うスキン」を別指定できる機能
●カテゴリごとに「先頭に固定する投稿」を別指定できる機能
●現在ログインしているユーザの情報を取得できる簡易API機能
《▼仕様改善》
●カテゴリ管理画面の一覧表が崩れないように、概要文のプレビュー文字数を少なめに固定。
●カテゴリ登録データの保存形式を(拡張性の高いものに)改善
●カテゴリ生データ編集機能を新データ仕様に更新
《▼不具合修正》
❎サーバのエラーログに「Use of uninitialized value $3 in concatenation (.) or string at tegalog.cgi」というアラートが記録されるケースがあった点を解消。
詳しい使い方などは、上記の開発進捗状況報告ページの記事をご覧下さい。
🍘SNSでのアナウンス:
Mastodon(Pawoo)
Bluesky
Twitter:
(ツイート埋め込み処理中...)Twitterで見る
by nishishi. ⌚2025年2月28日(金) 20:06:46〔162日前〕 アップデート✨ <558文字> 編集
🍚Re:5006◆それは「?」という1文字をリンク先にしているためです。あらゆる環境で確実にHOMEに戻すために、そのような仕様になっています。
もし仮に、<a href="tegalog.cgi"> のようにファイル名を直接リンク先として書いたとしましょう。すると、以下のような動作になります。
- ⭕てがろぐを tegalog.cgi というファイル名で使っている場合: リンク先は tegalog.cgi になるので問題なくHOMEへ移動できる。
- ❌てがろぐを index.cgi というファイル名で使っている場合: リンク先が tegalog.cgi になるので Not Found になる。
- 🔺てがろぐを / で終わるURLで使えるように設定している場合: リンク先は tegalog.cgi になるので問題なくHOMEへ移動できるが、せっかく「/」で終わるURLで使えるように設定しているのに、その設定を無駄にしてしまう。
ところが、<a href="?"> のように「?」1文字をリンク先にすると、以下のような動作になります。
- ⭕てがろぐを tegalog.cgi というファイル名で使っている場合: リンク先は tegalog.cgi? になるので問題なくHOMEへ移動できる。
- ⭕てがろぐを index.cgi というファイル名で使っている場合: リンク先が index.cgi? になるので問題なくHOMEへ移動できる。
- ⭕てがろぐを / で終わるURLで使えるように設定している場合: リンク先は /? になるので問題なくHOMEへ移動できる。
というわけで、そんな仕様になっているのです。
by nishishi. ⌚2025年2月28日(金) 20:03:22〔162日前〕 回答/返信 <764文字> 編集
- 1ページの表示件数を別指定したり、
- 表示に使うスキンを別指定したり、
- 先頭固定投稿を別指定したり
by nishishi.
⌚2025年2月27日(木) 22:31:10〔163日前〕
つぶやき
<111文字>
編集
パラメータで直接表示用スキンを指定した場合は、カテゴリ側の設定は無視されて指定スキンで表示されますが、カテゴリ側で先頭固定に指定した投稿はその場合でも先頭に固定されます(RSSモードの場合を除く)。
by nishishi.
⌚2025年2月27日(木) 22:28:06〔163日前〕
つぶやき
<191文字>
編集
ログインセキュリティ機能、カスタム絵文字機能、リンク・文字装飾記法の仕様拡充など、てがろぐ側にある便利機能をこちらにも実装しました。あと、若干の不具合修正も。
さんごよみをお使いの方は、ぜひバージョンアップして下さい。
設定もデータもすべてそのまま引き継げます。
バージョンアップするには、パッケージZIPから sangoyomi.cgi と fumycts.pl の2ファイルを上書きUPするだけです。
ヘルプドキュメントも増量して、てがろぐサイトと同様に、セットアップ(設置)方法・使い方・設定方法・カスタマイズ方法ページを個別に設けました。
さんごよみは(てがろぐCGIをベースにして作ったので)てがろぐと仕様がかなり共通しています。てがろぐをカスタマイズした経験があれば、さんごよみのスキンカスタマイズも難なくできるだろうと思います。
by nishishi. ⌚2025年2月21日(金) 19:40:38〔169日前〕 情報,アップデート✨ <448文字> 編集
➡ https://www.nishishi.com/cgi/tegalog/tegup/
- てがろぐと同時にTegUp自身のバージョンアップもできるようになりました(Ver.1だとTegUp自身の更新はできません)。
- 設定は独立ファイルに保存するように改善しました。
※てがろぐβ版同梱のTegUp Ver 2.0.x を既に設置している方々には特に新しくありませんので、あえて更新して頂く必要性はありません。ただ、OGP情報の取得先WebページのHTMLソースに望ましくない文字列が含まれている場合でも何らかの情報を取得できるよう改善しました。
カード型リンクで、「エラーは出ないのに情報が表示されない」というケースがもしあった場合は、キャッシュファイル(ogp-cache.ini)を削除した上で、この Ver 2.1.0 に更新すると、解決するかもしれません。