てがろぐ - Fumy Otegaru Memo Logger -

🌭Re:5857◆ご報告をどうもありがとうございます。なるほど、たしかに（内部でキャッシュせずに）動的に生成されるオブジェクトはすべてそのような動作になってしまいますね。次のバージョンで何とかします。

🌭Re:5858◆β版のご試用をどうもありがとうございます。(╹◡╹) 以下、使用感への返信です。

• IF文の条件やCSSのclassは mode-about です。カテゴリIDがaboutの場合は cat-about です。この mode- や cat- を省略しなければ重複はしません。
• Aboutページは、複数のスキンを使い分けたり、カテゴリ等と併せて使うことで、複数用意できます。詳しくは、ヘルプドキュメントの『Aboutページモード用スキンの作り方・使い方』区画内にある、
  • 「複数のAboutページモード用スキンを併用する方法」項目や
  • 「ユーザやカテゴリやハッシュタグ別のAboutページを作る方法」項目
  をご覧下さい。

β版を使用したときの使用感をメモいたします（自分のサイトより転載）

• Aboutページのタイトルは[[SITUATION]]で出せる。
• IFで指定する・出力されるclassは「about」、IF構文がカテゴリー名などと被る場合は重複して適用されるため、適宜変更すること。
• aboutページは一つだけしか作れないため、一つのてがろぐが複数サイトを兼ねている場合は別途カテゴリとして作成する必要がある。（※要望ではないです）

これは、サーバ側で導入されたセキュリティモジュールが、特定のルールに抵触することを検出した結果のようです。
サーバ管理者さんへ直接ご連絡頂けば、ご使用のアカウントに限って当該ルールの無効化をして頂け、それによって保存処理が可能になるようですので、usamimi.infoサーバをご使用の方々はお手数ですがサーバ管理者さんに問い合わせてみて下さい。

🍫Re:5834◆実験をどうもありがとうございます！ おかげさまで状況がよく分かりました。
初期状態でもそうなるのであれば、usamimi.infoサーバと同じ環境を用意して、ログを確認しながら1つずつ実験してみる以外にないので、サーバ側で当該ルールを無効化して頂くのが現実的だと（少なくとも今のところは）思います。

🍫てがろぐCGIのサーバ別セットアップ方法解説内の「usamimi.infoでのセットアップ手順」にも『usamimi.info特有の補足情報』に情報を加えておきました。

小説を掲載しているなどで、第1話から読ませるために「特定のカテゴリだけは昇順（古い投稿から順に）表示させたい」という場合は、そのカテゴリへのリンクURLの末尾に &order=reverse を加えれば良いです。
もし、てがろぐ側が出力するカテゴリツリーのリンク先もそのように変えたい場合は、下記のようなJavaScriptを（HTMLの末尾に）書いておくと、『指定のカテゴリだけは「昇順で表示されるページ」にリンクされる』カテゴリツリーになります。

例えば、そのカテゴリIDが「novel」の場合、カテゴリツリーのリンクは <a href="?cat=novel" class="catlink cat-novel">～</a> のようなa要素で出力されています。
このリンク先である ?cat=novel に &order=reverse を加えて ?cat=novel&order=reverse とすれば、昇順（古い投稿から順）の表示になります。

下記のJavaScriptは、class名にcat-novelが付いたすべてのa要素のリンク先URLの末尾にだけ、 &order=reverse という文字列を追加するスクリプトです。
同一ページ内にカテゴリツリーが複数個出力されている場合でも全部書き換わります。

<script>
document.addEventListener("DOMContentLoaded", function () {
  // cat-novelクラスを持つa要素をすべて取得
  const links = document.querySelectorAll("a.cat-novel");
  links.forEach(function(link) {
    // リンク先を取得して order=reverse を追加
    const href = link.getAttribute("href");
    link.setAttribute("href", href + "&order=reverse");
  });
});
</script>

カテゴリID部分（上記のソース中に赤色太字で書かれた箇所）を、ご自身でお使いのカテゴリID名に書き換えてご使用下さい。

🍘なお、もし対象にしたいカテゴリIDが複数個ある場合は、上記スクリプトの3行目にある querySelectorAll の引数にカンマ区切りで全部列挙すれば良いです。例えば以下のように。
const links = document.querySelectorAll("a.cat-novel, a.cat-journal");

🍘もし、カテゴリツリー以外の部分にも同じclass名でリンクを作っていて、そちらのリンクは対象にしたくない場合は、カテゴリツリーの大外枠が <ul class="cattree">～</ul> で出力されていることを利用して、以下のように書けば良いです。
const links = document.querySelectorAll("ul.cattree a.cat-novel, ul.cattree a.cat-journal");

※カテゴリツリーのHTML構造は、ヘルプドキュメント「カスタマイズ方法」内のカテゴリツリーの装飾方法あたりで解説していますので参考にして下さい。

---(追記)---
上記の(最初の方の)JavaScriptだと、カテゴリツリー内のリンクだけでなく、『各投稿に表示される所属カテゴリ名』のリンク先も同様に書き換わります。たぶんその方が都合が良いのではないかと思いますが、もしそこは変更したくない（降順のままにしたい）という場合は、上記の最後に紹介した ul.cattree を加える書き方を使うと良いです。

標準スキン以外のスキンをお使いの場合で、（てがろぐ管理画面での）Faviconの設定を反映させたい場合は、とりあえず自力で skin-cover.html 内のhead要素内に [[FAVICON]] を書いて下さい。
次のバージョンでは、加えておきます。

(Loading...)...
主に前回以降に実装した機能（お礼メッセージ管理機能）の話を書きました。出現頻度を3通り設定できる話とか、てがろぐ側とは違って(ツール上でUPした)画像はお礼メッセージと1対1で紐付く仕様にした話とか。

いま作りつつある汎用いいね拍手ボタン的なツールの話...
今の時点でできている部分とか、なんでこんな仕様にしたのかの理由とか、スキンの作り方がどんな感じになりそうかとか、てがろぐアドオン稼働だとどうなるのかとか、何かそんな感じの話をまとめて書きました。

➡てがろぐ解説 notebook （使うには、Googleアカウントが必要だと思いますが、無料で使えます。）#🌱豆知識

（ツイート埋め込み処理中...）Twitterで見る

Bluesky

ただ、これはヘルプの書き方や構造の問題もありそうですが、実際には解説は存在するのに「ない」と回答されることもありますので、（返ってきた解説自体は参考にできそうですが）「ない」と言われた場合には信用しないで、質問を変えるか、もしくは自力でWebをご覧下さい。(笑)
「こう質問したのに、適切な回答はなかった」みたいな情報があれば教えて下さい。もしかしたら、ヘルプドキュメントの改善の参考になるかもしれませんので。

※これは、リアルタイムにWebから情報を取ってくれるわけではなくて、ソース(資料)としてURLを指定した瞬間のHTMLソースからテキストデータを抽出して取り込む仕様っぽいので、（私が今後もメンテナンスをすれば別ですが）2025年6月3日時点のヘルプドキュメントを元にして回答されます。

ログインセキュリティ機能、カスタム絵文字機能、リンク・文字装飾記法の仕様拡充など、てがろぐ側にある便利機能をこちらにも実装しました。あと、若干の不具合修正も。
さんごよみをお使いの方は、ぜひバージョンアップして下さい。

設定もデータもすべてそのまま引き継げます。
バージョンアップするには、パッケージZIPから sangoyomi.cgi と fumycts.pl の2ファイルを上書きUPするだけです。

ヘルプドキュメントも増量して、てがろぐサイトと同様に、セットアップ(設置)方法・使い方・設定方法・カスタマイズ方法ページを個別に設けました。
さんごよみは（てがろぐCGIをベースにして作ったので）てがろぐと仕様がかなり共通しています。てがろぐをカスタマイズした経験があれば、さんごよみのスキンカスタマイズも難なくできるだろうと思います。

スキンのカスタマイズがうまくいかない場合のご質問をしようとするすべての方へのお願いですが、質問する前に、

• その「うまくいかない方法」を、標準スキンに書いても同様にうまくいかないのか？

を先にご確認下さい。

もし標準スキンではうまくいくなら、お使いのスキンの問題です。
その場合は、「スキンのソース全体」や「稼働しているページ」を一緒に見せて頂かないと何も判断ができない可能性があります。

また、第三者が作成なさったスキン独自の機能に関するご質問は、まずはそのスキンの作者さんへお願いします。（※「○○で配布されているスキンに変えたら、××が適用されなくなった」というような感じのご質問は特に。）

あんまり詳しくは検証していないんですが、現在のてがろぐの仕様では、

• ハッシュタグの数が多いと重たくなりやすい

……ので、「カテゴリで分類しようかな～？ それともハッシュタグで分類しようかな～？」と迷っている場合は、カテゴリを採用する方が望ましいと思います。
カテゴリは専用項目で分類できるのに対して、ハッシュタグは本文全体の中身を走査しないと分類できないので、負荷がずいぶん異なります。

ハッシュタグがたくさんある場合に重たくなるのは主に「ハッシュタグを集計するタイミング」なので、たとえハッシュタグを使う場合でも、下図のように集計しない設定にしておけば、重たくなるのを回避できます。（たぶん）

※この設定をしていても、その下にある『本文中のハッシュタグをリンクにする』項目の方がONなら、ハッシュタグそのものは機能します。（単に個数を数えなくなるだけです。）

➡ てがろぐ上で多量の画像を扱う際に、重たくなるのを防ぐ方法

Twitterアーカイブの移行とかで重たくなった場合に確認してみて下さい。

※現状でその問題に直面している場合は、とりあえず [ページの表示]→【ナビゲーションリンクの表示】→[▼ページ番号リンク]→「総ページ数が多ければ途中のページ番号リンクを省略する」をONにして頂けば遅くならずに済みます。

Twitter側の出力機能でダウンロードしたTwitter過去ログを、全部てがろぐ形式に変換してくれるスクリプト。

（ツイート埋め込み処理中...）Twitterで見る

2022年出力のTwitterログでも問題なく変換できました。
元データに3.6万ツイート含まれていて、リツイートを除いた2.5万ツイートでも、1秒掛からずに変換できた感じです。tweets_mediaフォルダをコピー（して images フォルダにリネームすると）ツイート本文中の画像もちゃんと表示できました。すごい。
ぜひ試してみて下さい。

※ツイート数が多い場合は、てがろぐ側で事前に以下のどちらかの設定をしておく方が良さそうです。

• [ページの表示]→【ナビゲーションリンクの表示】→[▼ページ番号リンク]→「総ページ数が多ければ途中のページ番号リンクを省略する」をONにしておく。
• [ページの表示]→【ページの表示／全体】→「▼1ページあたりの表示投稿数」を200とか400とか多めにして、総ページ数が莫大にならないような値にする。

何故なのかは今は分かっていないのですが、ページ数が莫大になると（てがろぐ側の処理で）ページネーションの生成に時間が掛かるっぽいです（1,000ページ超だと表示に20秒くらい待ち時間がありました）。途中のページを省略する設定にしていれば、ページ数が莫大でも問題ありません。

なお、私が試してみた感じでは、

• てがろぐのハッシュタグの仕様は、 # 記号の直前の文字が「英数字・&記号・スラッシュ記号・セミコロン記号」だとハッシュタグだとは認識されないので、本文末尾に自動付加されるハッシュタグの直前には空白文字を1つ入れてくれると望ましいかも。
• 投稿末尾に挿入される画像が行内にあるので、画像の直前に改行を入れてくれると見やすくなって嬉しいかも。

という感想を持ちました。
ただ、その辺は、生成された twitega.xml をテキストエディタで一括処理することで調整可能ですけども。

➡ TegUp ：てがろぐ本体を《1クリック》だけでバージョンアップできるPHPスクリプト

従来のpixivFanbox上の公開ページからはダウンロードできませんので、今後は上記の専用ページからダウンロードして下さい。（というか、次のてがろぐ正式版からは、tegup.phpも同梱する予定ですが。）

※Ver 0.9.0からは、『作業ログをファイルに出力できるオプション』機能だけが加わっていますが、既に Ver 0.9.0 が問題なく使えているなら作業ログをファイルに出力する必要性はありませんから、TegUp自体を更新する必要性は特にありません。^^;（そのまま Ver 0.9.0 を引き続きお使い頂いても問題なく（てがろぐを）バージョンアップできます。）

以前に TegUp を使おうとして、何らかのエラーが出て使えなかった場合は、『作業ログをファイルに出力できるオプション』をONにした上で動作を試してみて下さい。もちろん以前と同様に動かないでしょうけども、作業ログがファイルに出力されていますので、それを見ると、どこの作業が失敗しているのかが把握できると思います。
詳しい設定方法は、「作業ログをファイルにも出力したい場合」をご覧下さい。

なんか「専用ページを作ろう」と思ったらいろいろ書かないといけない気になってしまったのでそこそこな分量がありますけども、ほぼ何も読まなくても使えます。
要は、tegup.php を tegalog.cgi と同じディレクトリにアップロードすれば良いだけです。

🍨Re:4471◆隠された範囲をSmooth展開するのは、現状のてがろぐの仕様で可能でしょうかね……？（どなたか実現なさっている方がいらっしゃったら教えて下さい！）なんとなく難しそうな気がします。デフォルト設定では、隠された範囲(のspan要素)は表示時に display:inline; のスタイルが付加されますしね（その値は設定で変更可能ですが）。

◆現状のような「JavaScriptで表示/非表示を切り替える」方法で隠す手段以外に、現在で(たぶん)主流な <details><summary>見せる部分</summary>折りたたむ部分</details> のようにHTMLだけで実現できる折り畳み機能で出力される記法も追加した方が良いかな……という気はなんとなくしています。今のところそのような要望は来ていないので、まだ「なんとなく思っているだけ」の状態ですけども。そちらの方がCSS（やJavaScript）で装飾しやすいだろうな、という気はします。

◆SNSシェアボタンで「特定のスキンを適用したURL」がシェアされるようにするには、[[PERMAURL]]系の記法の直後に（空白を挟まずに）&skin=skin-nameのような感じでパラメータを加えれば良いだけです。具体的にどのように書けば良いかは、お使いの「シェアボタン」の仕様次第ですので、（具体的な記述も知りたい場合は）まず現状の記述がどうなっているのかをお知らせ頂く必要があります。

🍨Re:4472◆てがろぐをご活用下さってありがとうございます。(╹◡╹)ﾉ
少なくとも（私が直接使っている範囲では）5千件や1万件程度の投稿総数では特に体感できるほどの変化は出ていません。
なお、今ご覧になっているこの動作試験場では、現状で4,350件近くの投稿数がありますので、実際に「5千件近くの投稿がある状態の動作」をご体感頂けています。(╹◡╹)

下記のⒶとⒷは私(だけ)が書いているページ（てがろぐ）で、Ⓒはここです。それぞれの大まかな総投稿数とデータサイズを調べてみました。

• Ⓐ 今日のひとことログ ：総投稿数 12,200件超　データファイル 6.27MB
• Ⓑ てがろぐリリースノート ：総投稿数　43件　データファイル 0.61MB
• Ⓒ 動作試験場（ここ） ：総投稿数 4,300件超　データファイル 2.94MB

実際に生成ページにアクセスしてみると、投稿総数が1万2千件を超えているⒶよりも、わずか43件しかないⒷの方が、むしろ表示までにかかる動作は比較的もっさりしている気がしませんか？ これは、Ⓑでは文字装飾記法が山ほど使われているために（てがろぐ内部で）独自記法をHTMLに展開する処理がたくさん発生するためだろうな……という気がしています。まあ、Ⓑはさすがに『1投稿に2万文字近くある』ような長文投稿ばかりなので、かなり極端な例ですが。(笑)

なお、管理画面の応答速度は、ⒶⒷⒸどれも同じ感じです。（ミリ秒単位で計測したら何らかの差はあるかもしれませんが、体感できるほどの差はありません。）

ただ、CGIなので、動作の重たさは『アクセスがどれくらい集中するか』の方が影響すると思います。
Botからの大量アクセスを受けると、あっという間に重たくなるケースはありました。

てがろぐは、ページを生成する際に(毎回)データファイルを全部読み込みますので、毎秒数十件みたいな極めて高い頻度でのアクセスが続いてしまうと、サーバ自体がかなり重たくなりますね。（その辺は、サーバ側の性能にも影響するとは思いますが。）
なので、アクセス数が多いサイトの場合は特にWAF（Web Application Firewall）を併用して、悪質なBotは（CGIに届く前にサーバ側で）排除される環境にしておく方が望ましいです。

というわけで、てがろぐは（データベースを使っていないシステムなので、極端にデータサイズが大きくなればそれに比例して重たくなるだろうと予想はしているのですけども）、1万2千件程度の投稿数なら特に気にならない、とは言えそうです。10万件だとどうなるのかはまだ分かりませんが。^^;（上記で述べたとおり、投稿の内容次第でもあります。）
投稿総数が莫大になる予想があるのであれば、その「即メモ」と「ライフログ」は、1つのてがろぐで運営するのではなく、最初から複数個のてがろぐに分散させておくと、なお安心かもしれません。
（とはいえ、1つのてがろぐで運営していた内容を、後から複数のてがろぐに分割するのは、テキストエディタでデータファイルを直接分離すれば簡単ですが。どの投稿をどこに分けるのかを判断しやすくするために、カテゴリ等を使って事前に分類されていると望ましいですね。）

➡『てがろぐに「簡易適用スキン」の設定が勝手に切り替わるバグがあった話』

簡単な説明簡単に述べると、以下の2条件を同時に満たしている場合にだけ、表示上の問題が発生します。

• 【条件①】未来の日時を『予約投稿として扱う』よう設定されている。（＝予約投稿機能をONに設定している）
• 【条件②】メインで使うスキン以外のスキンに、新着投稿リストを表示するための記法 [[LATESTLIST]] が記述されている。（＝メインで使うスキン以外のスキンで生成されるページ上に、新着投稿リストが表示されている）

なので、予約投稿機能をOFFにしているなら（※デフォルトでOFFです）全く問題は生じません。
次のバージョンで修正しますが、上記の2条件に現状で該当する場合には、一時的に予約投稿機能をOFFにしておくことをお勧め致します。
詳しくは上記の記事本文をご覧下さい。

ただ、Ver 4.0.0（※β版も含めると、Ver 3.9.3β）以降で発生していたバグですので、昨年の4月の時点で既に存在していたバグですから、『今まで問題がなかったなら、たぶん問題ない』と考えても良いとは思います。（1年間も問題が生じなかったわけですから。）
畳む

とりあえず、バグを解消した次のバージョン（4.3.1）は、おそらく今月末までには公開できると思っています。（今のところ）

追加しました、と言っても特別なことはなく、単に全ファイルをUPして、指定のパーミッションに設定するだけですけども。（要するに、ノーマルな設置方法で済む、という話です。^^;）

先頭固定機能だと掲載位置は先頭しかあり得ませんが、フリースペースなら上端でも下端でもサイドバーの形でもどこにでも表示できますので、掲載位置の自由度は（先頭固定よりも）高いです。その上、（スキンを直接編集しなくても）てがろぐ上から中身を更新できます。また、フリースペースの内部にはHTMLタグを何でも使えますから、掲載内容の自由度も高いです。

最近はサードパーティー製スキンをベースにしてお使いの方々も多そうですので、もしかすると（フリースペースが使われていないスキンをお使いだと）フリースペース機能の存在に気付きにくいかもしれませんが。
「何かをずっと表示しておきたい」という場合には、先頭固定機能以外にもフリースペース機能もありますので、それを使えないか検討してみて下さい。

例えば、「ある特定のカテゴリに限定されている状況でのみ、フリースペースを表示させたい」という場合には、IF文での出力条件分け記法を使ってフリースペースの表示場面を限定すると良いでしょう。フリースペースの入力欄は1つしかありませんが、専用の区切り文字を使うことで、複数のフリースペースを用意することもできます。詳しくは『フリースペースの書き方（複数のフリースペースを設ける方法）』で解説しています。

この「IF文」と「フリースペース」を併用すれば、

• カテゴリ info でのみ表示されるフリースペースⒶ
• カテゴリ diary でのみ表示されるフリースペースⒷ
• HOMEでのみ表示されるフリースペースⒸ

……のような感じで、ⒶⒷⒸ複数の条件限定フリースペースを用意することもできます。（数に上限はありません。）
※IF文を使わなくても、単純にCSSで表示分けすることもできます。掲載分量が少ない場合には、（IF文を列挙してどうにかするよりも）CSSで表示分けする方がシンプルで楽かもしれません。

パーミッション 700 でも動作に支障はないんですが、700だと mod_mime_magic: can't read ～tegalog.cgi というエラーが毎回エラーログに記録されてしまいますので。（余計なログは出力されないに越したことはありませんから。）

IF文の条件指定は（全文検索機能と同様に）「完全一致」ではなく「部分一致」で解釈されますので、
「1件以上が表示される場合」に限定しようとして [[IF(hit):～～～ のように書いたとしても、 「1件もヒットしなかった場合」の nohit にも同時に該当してしまうために意味がありません。^^;

なので、もし「1件以上が表示される場合」に限定したい場合は、[[IF(hit -nohit):～～～ のように、マイナス記号を付けて「-nohit」として除外する条件を同時に加える必要があります。

……という話を、一応ヘルプドキュメントにも加えておきました。
➡そのときの表示状況に応じてページ出力を、IF文で切り替える方法

先日、うちのサイトでも複数のBotから莫大なアクセスがあって（※てがろぐだけにあったわけではなくてサイト全体にあったんですが）、CGIにも高い頻度でのアクセスがあったためかサーバの負荷が高まって、てがろぐの管理画面を表示するだけでも20秒とか掛かるようになってしまったことがありました。（503エラーになるほどではなかったのですが。ただ、どのくらいの負荷まで許容してくれるかはサーバや契約コースに依ると思います。） その話は改めてブログに書こうかと思っているのですが。.htaccessやrobots.txtを併用してBotのアクセス頻度を低下させたことで、普通の状態に戻りましたけども、何もしなかったら過負荷なままだったのではないかと思います。

➡ TegUp：てがろぐ本体を1クリックでバージョンUpできるPHPスクリプト
てがろぐと同じディレクトリに置いてブラウザでアクセスするだけで、新バージョンが存在するかどうかを調べて、あればボタンクリックだけで自動バージョンアップされます。
まだ最小限の機能だけなので、とりあえず Ver 0.9.0 ということで公開しました。もうちょっと機能増強したいとは思っています。
最新版をお使いでない方々は、ご活用頂ければ幸いです。

アナウンス：Twitter、Pawoo(Mastodon)

1. Ver 4.1.1βの tegalog.cgi をテキストエディタで開きます。
2. 4409～4410行目に移動します。すると、以下のような記述が見えるハズです。（見えない場合は、バージョンが違います。）
# 新規ウインドウ
$addatt .= ' target="_blank"';
3. ここに1行追加して、以下のような3行になるようにします。
# 新規ウインドウ
$linklabel =~ s/(.+):NEW/$1/;
$addatt .= ' target="_blank"';
4. 上書き保存して、サーバにUPして下さい。

すると、リンクテキストに :NEW が出ないようになります。
この機能を今すぐ使う場合には、お手数ですが上記の手順をお試し下さい。この機能を使わないか、次のバージョンまで待てる場合には、何もしなくて大丈夫です。

2週間ほど実施してきました「てがろぐ機能追加検討リストの投票」はさきほど締め切らせて頂きました。たいへんありがたいことに147件の回答が得られまして、わりと需要の傾向が把握できました。投票頂いた回答は、今後の開発機能の優先度を判断する参考等に活用させて頂きます。ご協力下さった方々、誠にありがとうございました。また、作者宛にメッセージをお書き添え下さった方々もどうもありがとうございました。すべてありがたく読ませて頂きました。

で、最近はユーザさんも増えてきたような気配がしていますので、望みの機能(検討候補)に投票して頂いて、その得票数を参考に検討したら良いかな……と思いまして、追加検討機能リストと投票フォームを用意してみました。
お望みの機能への投票にご協力頂ければ、開発検討の参考になってたいへんありがたいです。

（ツイート埋め込み処理中...）Twitterで見る

ぜひ、よろしくお願い致しますです。(╹◡╹)ﾉ

　↓表示例

（ツイート埋め込み処理中...）Twitterで見る

これは、CSSに以下の4行を加えただけです。（4行というか、中身は3行ですし、そもそも1行で書ける分量ですけども。^^;）
/* ▼埋め込みツイートの横幅を強制的に制限 */
div.twitter-tweet {
   max-width: 350px !important;
}
埋め込みツイートは、横幅が350pxあたりを下回ると小さな文字で表示されるっぽいですので、とりあえず350pxにしてみました。!importantが付いているのは、これがないと、Twitter側が埋め込んでくる要素に直接書かれたスタイルを上書きできないからです。サイズはお好みに調節して頂ければ良いと思います。 #🌱豆知識

.htaccessを使用して除外設定する事が出来たので報告させて頂きます。
※頭に「spd」と「ent」がつくサーバだと、この対策はできないようです。

参考サイト
PHPやCGIでプログラムの記述変更をしたところ403errorが表示されます – ロリポップ！レンタルサーバー
https://support.lolipop.jp/hc/ja/articles/360048375814

シグネチャで除外設定する
コードの確認は、WAF設定のログ参照から確認する必要があります。
また私の環境ではてがろぐで投稿しWAFでエラーが出た場合、
1つ目のコードを除外設定した後にもエラーが発生しましたが、
ログ参照し、2つ目のコードも除外設定する事で回避出来ました。
なので、複数のコードを除外する必要があるようです。

コード例
# AAA-11,BBB-12を確認したコードに変更
SiteGuard_User_ExcludeSig AAA-11
SiteGuard_User_ExcludeSig BBB-12

IPアドレスで除外設定する
IPアドレスが固定なら、この方法が楽かもしれません。

コード例
# カッコ内のxxx.xxx.xxx.xxxをご自身のIPアドレスに変更
SiteGuard_User_ExcludeSig ip(xxx.xxx.xxx.xxx)

この2つのどちらかを.htaccessに記述すれば、
/etc/abcdのような文字列でも問題なく投稿できました。
ロリポップをお使いで403エラーにお困りの場合は、お試しください。

ネタの提供をありがとうございます！(╹◡╹)ﾉ

全体としては <p class="situation"><span class="situation-mode"></span></p> という出力になります。表示されるテキストがないことに違いはないのですが、外側のp要素 <p class="situation">～</p> には中身があることになります（emptyではなくなります）。すると、CSSで .situation に適用しているスタイルによっては、「状況に応じた見出し」部分が（見出しとしての文字列は何も出力されていなくても）意図しない装飾になってしまう可能性があります。

もし、「Ver 3.9.3βにバージョンアップしたことによって、状況に応じた見出しの位置に何か余計な装飾が現れた」という場合は、次のβバージョンで解消しますので、そのままお待ち下さい。m(_ _)m

標準添付スキンだと、ブログタイプスキンで下図のように余計なバーが出ます。ブログタイプスキンをそのままお使いの場合はもちろん、ブログタイプスキンをベースにしてカスタマイズしたり独自スキンを作ったりしている場合に同様の問題が出る可能性があります。今の段階でスキンを修正したりせず、次のβ版をお待ちください。（気になる場合は、3.9.2にバージョンダウンしても良いと思います。）