検索語「〔除外:$ci=;〕」の検索結果[1186件](2ページ目)
➡ 2025年4月25日(金) 15時19分 〔51日前〕 回答/返信 No.5133 ✎ !
カテゴリ名が欲しい場合は、HTMLを含む内容を一旦JavaScriptで受け取って、HTMLタグだけを除外して使えば良いのではないかと思います。例えば、
<script>
let htmlstr = '[[CATEGORYLINKS:T]]';
let plainText = htmlstr.replace(/<[^>]*>/g, "");
</script>
……とすれば、変数plainTextにカテゴリ名がプレーンテキストで入ります。
後は、この変数の中身を指定の要素に送るなり、フォーム自体をJavaScriptで生成するなりすれば良さそうに思います。(たぶん後者の方が簡単でしょう。同一ページ内に複数のフォームが現れる可能性があるのなら特に。)
この方法なら、カテゴリ名の間に挿入されるカンマ記号を取り除いたり他の文字に変換したりもできますから、より望みの文字列に加工できるでしょう。
なお、[[INFO:NOWCAT:NAME]] ※ は外側スキン用の記法なので、これを使いたい場合は、一旦外側スキン側でJavaScriptを使ってプレーンテキストにした上で、その変数を内側スキンで使う……というような感じにする必要がありますから、内側スキンで[[CATEGORYLINKS:T]] ※ を使う方が良いと思います。JavaScriptを使えば、親カテゴリ名を取り除く加工もできますから、お好きなように加工なされば良いと思います。
➡ 2025年4月25日(金) 14時10分 〔51日前〕 回答/返信 No.5132 ✎ !
にししさんが整理してくださった三点ですが、概ね合っています。
現状、IF文では
<input type="hidden" name="entry.固有番号" value="作品名">
のタグをカテゴリごとに作っているのですが、それでは何話目に対する感想なのかが分からないのです。
また、作品数が多いので、HTMLに書き込むIF文も増えてあまり見栄えがよろしくありません。
そのため、value=""部分に作品名(カテゴリ名)と第何話([[COMMENT:TITLE]])なのか、自動で挿入されるとありがたいと思った次第です。
今日もいろいろと試していたのですが、昨日の書き込みに誤りがあったことに気づきました。
[[INFO:NOWCAT:NAME]]ではなく、[[CATEGORYNAMES]] でした。失礼いたしました。
skin-onelog.htmlにフォームタグを置いているのですが、value=""部分に[[CATEGORYNAMES]][[COMMENT:TITLE]]と入力すると、class名が付与されるため添付した画像のようになってしまいます。しかも、カテゴリ名は親と子(モザイク部分)が併記されています。
この状態でも送信はできるものの、届いたメールのタイトルは「<span class=」となっています。
これは、skin-cover.htmlにフォームタグを置いて、value=""部分に[[INFO:NOWCAT:NAME]]を入力した場合も、同様です。ただし、[[COMMENT:TITLE]]は無効になっているものの、カテゴリ名の表示(モザイク部分)は希望のものです。
以上のことから、[[INFO:NOWCAT:NAME]]で取れるカテゴリ名と、[[COMMENT:TITLE]]で取れる情報が、プレーンテキストの形で出力された上で併用できれば、望む形になるのではないかと思います。
とはいえ、IF文で「value="作品名[[COMMENT:TITLE]]"」にしておけば、望む情報は送られてくるので、単純にHTMLの見栄えを良くしたいというわがままです。
もし、IF文を使わずに済む方法や工夫があれば、教えていただけると幸いです。


➡ 2025年4月25日(金) 10時55分 〔51日前〕 回答/返信 No.5131 ✎ !
- カテゴリ名が作品名。
- 投稿内容の1行目には「第〇話 副題」が書かれているだけ(なので [COMMENT:TITLE] を使っても意味がない)
- Googleフォーム用の何らかのHTMLに、作品名だけを入れたい。
カテゴリ限定表示を使っているとのことですが、それは「ある親カテゴリとある子カテゴリを両方同時に表示する」というような仕組みで実現しているのですか? それとも別の方法ですか? その辺をもう少し具体的に教えて下さい。
デフォルト設定のままだと、カテゴリ限定表示時には『カテゴリ「雑記」に属する投稿[12件]』のような感じでSITUATIONに出てきますから、おそらく何らかのカスタマイズをなさっているのだと思います。
その辺をどうなさっているのかも教えて頂ければ、何らかの回答ができるかもしれません。
要するに、「どこの情報が取れれば『お望みの過不足ない作品名』になるのか?」が分からないので、そこを教えて下さい、ということです。
➡ 2025年4月24日(木) 21時06分 〔52日前〕 アップデート✨ No.5129 ✎ !
➡ https://www.nishishi.com/cgi/tegalog/tegup/
- てがろぐと同時にTegUp自身のバージョンアップもできるようになりました(Ver.1だとTegUp自身の更新はできません)。
- 設定は独立ファイルに保存するように改善しました。
ただ、OGP情報の取得先WebページのHTMLソースに望ましくない文字列が含まれている場合でも何らかの情報を取得できるよう改善しました。
カード型リンクで、「エラーは出ないのに情報が表示されない」というケースがもしあった場合は、キャッシュファイル(ogp-cache.ini)を削除した上で、この Ver 2.1.0 に更新すると、解決するかもしれません。
➡ 2025年4月20日(日) 20時19分 〔56日前〕 回答/返信 No.5121 ✎ !
🍨Re:5118-5119◆ご確認ありがとうございます。問題が解消していて良かったです~。(╹◡╹)ノ これで次は正式版(4.6.0)リリースで問題なさそうな感じですね。^^
➡ 2025年4月18日(金) 21時07分 〔58日前〕 回答/返信 No.5113 ✎ !
➡ 2025年4月18日(金) 19時46分 〔58日前〕 アップデート✨ No.5111 ✎ !
🆕 Ver 4.5.7βの更新点(概要):
《▼新機能》
●投稿欄下部のボタンでカード型リンクを挿入できるようにする「OGPカード」ボタンの表示機能を追加。
《▼不具合修正》
❎カード型リンクが文字化けするケースがある問題を(さらに)修正。
詳しい使い方などは、上記の開発進捗状況報告ページの記事をご覧下さい。
🍘SNSでのアナウンス:
Mastodon(Pawoo)
Bluesky
Twitter:
(ツイート埋め込み処理中...)Twitterで見る
➡ 2025年4月15日(火) 22時37分 〔61日前〕 回答/返信 No.5107 ✎ !
>>効かなくなっているのは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(以下独自に設定したエラー画面の場所)
を追加したものになります。
この二行がサーバーと相性が悪かったのかもしれません。
お騒がせいたしました。
➡ 2025年4月15日(火) 10時55分 〔61日前〕 回答/返信 No.5106 ✎ !
🥐Re:5104◆情報ありがとうございます~。(╹◡╹)ノ
🥐Re:5105◆.htaccessは、てがろぐ側が解釈するわけではなく、Webサーバ側が解釈するので、「DirectoryIndexの指定が、てがろぐのバージョンによって適用されたりされなかったりする」ということはありません。なので、もしそのような動作になるのなら別のところ(サーバの設定や、.htaccessの書き方や、他のディレクトリにある.htaccessファイルなど)が影響しています。
効かなくなっているのはDirectoryIndexだけでしょうか? 他のiniファイルやxmlファイルへのアクセスを拒否する設定は、ちゃんと403エラーを返すでしょうか?(500エラーではなく)
もしDirectoryIndexが効かないのであれば、てがろぐパッケージに含んでいる(またはここからダウンロードできる) (Recommend).htaccess ファイルを使ってアップロードし直してみて下さい。
なお、.htaccessとは関係なく、てがろぐの動作によって500エラーが出る可能性はあります。
なので、「どのような操作をしたときに(または、どのようなURLにアクセスしたときに)500エラーが出るのか」について詳しく教えて頂ければ、何らかの回答ができるかもしれません。
➡ 2025年4月13日(日) 21時09分 〔63日前〕 回答/返信 No.5103 ✎ !
🥐Re:5099◆ご指摘ありがとうございます。確かにPixivは文字化けしますね。いーろいろ実験して確認したところ、pixivは『ログイン状態で閲覧した場合はHTMLに文字コードの情報が含まれる』のに『ログアウト状態で閲覧するとHTMLに文字コードの情報が含まれていない』ことに気付きました。┌(:3」└)┐ ずっと、ログイン状態で確認していたんですけども、PHPプログラムは当然ログアウト状態のHTMLしか取得できませんからね……。^^; とりあえず、こちらのローカルにあるプログラムでは対処しました。次の 4.5.7β では、少なくともPixivの文字化けは解消します。もうしばらくお待ち下さい~。
➡ 2025年4月13日(日) 19時29分 〔63日前〕 アップデート✨ No.5100 ✎ !
昨日の4.5.5βにあった3点の不具合を修正しました。
- カード型リンクが文字化けするケースがある。
- リスト記法で何らかのオプションを加えると表示されなくなる(記法によっては先頭項目だけ見える)。
- 鍵入力窓を自由な位置に配置する機能が無効になる。(指定位置ではなく先頭に鍵入力窓が出て、すべて隠されてしまう。)
🍘SNSでのアナウンス:
Mastodon(Pawoo)
Bluesky
Twitter:
(ツイート埋め込み処理中...)Twitterで見る
➡ 2025年4月13日(日) 15時03分 〔63日前〕 回答/返信 No.5096 ✎ !

正規表現では、角括弧や丸括弧に特殊な意味があるので、角括弧や丸括弧そのものに一致させたい場合には \[ や \( のようにエスケープしないといけないので、ちょっと見た目がややこしいですが。(^_^;)
テキストエディタによって微妙に書き方が異なる可能性がありますが、例えばEmEditorだと以下のような正規表現でいけます。
検索語: \[(.+?)\](\(?http)
置換後: [\1:CARD]\2
※書き換えてはいけないケース(書き換えたくないケース)を除外するためにも、「すべて置換」ボタンで一括処理するのではなく、「置換」ボタンの方を押して1つずつ確認しながら処理する方が望ましいと思います。
※お試しになる場合には、事前に tegalog.xml ファイルをローカルにバックアップするのを忘れないようご注意下さい。
➡ 2025年4月13日(日) 14時34分 〔63日前〕 回答/返信 No.5094 ✎ !
また、不具合報告もありがとうございます。助かります。
今のところ Ver 4.5.5βで認識している不具合は以下の3点です。
1. カード型リンクが文字化けするケースがある。
2. リスト記法で何らかのオプションを加えると表示されなくなる(記法によっては先頭項目だけ見える)。
3. 鍵入力窓を自由な位置に配置する機能が無効になる。(指定位置ではなく先頭に鍵入力窓が出て、すべて隠されてしまう。)
カード型リンクが文字化けするケースは、おそらく「HTMLソース内に <meta charset="UTF-8"> のような文字コードを表す記述が出るよりも前の段階で、日本語文字などの非ASCII文字が出現している場合」に発生しているような気がします。
とりあえず、こちらのローカルにあるファイルでは(たぶん)解消しましたので、今日の内には Ver 4.5.6β を出します。もうしばらくお待ち下さい。
あと、上記の3点以外に何らかの不具合を目撃していらっしゃれば、教えて下さい。(今のところ、上記の3点しか認識していませんので。)
➡ 2025年4月3日(木) 23時06分 〔73日前〕 回答/返信 No.5069 ✎ !
(たとえ画像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を使う方法です。(ご契約のサーバでそれが可能なのかどうかは分かりませんが。)
➡ 2025年4月3日(木) 13時12分 〔73日前〕 回答/返信 No.5063 ✎ !
🌳Re:5062◆てがろぐが出力するHTMLソースに、どんなURLが出力されているのかを確認してみて下さい。
例えば、 sample1.jpg という画像なら、てがろぐは、 <img class="embeddedimage" src="images/sample1.jpg" width="~" height="~" loading="lazy" alt="~"> のようなHTMLを出力します。
画像が表示されないということは、このURLの出力結果に問題があるということでしょうから、まずはこの点を確認してみる必要があります。
どんなHTMLが出力されていますか?
➡ 2025年3月29日(土) 10時39分 〔78日前〕 回答/返信 No.5057 ✎ !
🍔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ページに合成するページを作る。
➡ 2025年3月27日(木) 11時11分 〔80日前〕 回答/返信 No.5050 ✎ !
☕Re:5049◆検索避けには、まさしくそのmeta要素を使う必要があります。
.htaccessやrobots.txtを使ってクローラーからのアクセスをブロックしてしまうと、「検索インデックスに登録するな」という指示そのものが読めなくなるので、結果として検索避けに失敗します。(他サイトからのリンクを経由してクローラーが来た場合、そのページに書かれている情報は読めないため取得されませんが、リンク元ページにあるリンクラベル等を使ってインデックスに登録される可能性があります。)
なので、検索避けのためには「『登録するな』という指示(<meta name="robots" content="noindex">)自体はクローラーにも読めるように」しておく必要があります。
※参考:このGoogle検索セントラルHelpページ末尾の「robots.txt ルールとインデックス登録および表示に関するルールとの組み合わせ」項目には、「クロール禁止の情報自体が読めなかったら、指示は無視されるよ」的なことが書いてあります。
なお、IPアドレスは明確に対象国が分割されているわけではありません。「今は日本国内に割り当てられているIPアドレスが、来月は海外で使用されている」というケースもあり得ます(もちろんその逆も)。なので、IPアドレスを使ってアクセス元を判断するには常に最新の情報にアップデートし続ける必要があり、個人ではあまり現実的ではなさそうに思います。
➡ 2025年3月26日(水) 09時23分 〔81日前〕 回答/返信 No.5048 ✎ !
まだ今週末はまた寒くなるっぽい予報ですけども。
🌸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 が続いている場合はハッシュタグにしないような仕様が必要でしょうね。(^_^;)
➡ 2025年3月22日(土) 22時04分 〔85日前〕 回答/返信 No.5045 ✎ !
パエリアには、まさしくそれ用の絵文字が定義されているのか……。🥘🥘🥘
……と思ったけども、Unicodeでの定義の名称は SHALLOW PAN OF FOOD(浅い鍋の食べ物)なので環境によってはパエリアとは限らないかもしれない……?
🥘Re:5042◆反応ありがとうございます。需要がありそうだと分かってありがたいです。^^
🥘Re:5043◆計画はしましたが、どうなるかは作ってみないと分からないので、気長にお待ち下さい~。^^;
🥘Re:5044◆日本国内に割り当てられているIPアドレスからのみ閲覧を許可するには、『日本国外からのアクセスを制限する.htaccess』を使うと良さそうです。ただし、検索サイトのクローラーはたいてい海外から来ますので、それを弾きたくない場合は、このページの『5.Apache「.htaccess」設定』を参考にすると良いです。
ただ、国内のユーザが必ず日本に割り当てられているIPアドレスから来るとは限りませんし、海外からのアクセスが必ずしもそれ以外のIPアドレスから来るとは限らない(VPNもありますし)点や、海外に住んでいる日本人もブロックしてしまう点にもご注意下さい。たぶん、「国内/国外」ではなく、本当に弾きたいものに限定して弾く方が望ましいと思います。
- なお、てがろぐには「高頻度アクセス制限機能 (迷惑Bot対策機能)」を用意していますので、ご活用下さい。(使うには事前準備が必要です。)
- また、管理画面への不正ログインを警戒する場合は、「ログインセキュリティ関連機能」もありますのでご活用下さい。(一部はデフォルトで有効になっています。)
➡ 2025年3月18日(火) 19時59分 〔89日前〕 回答/返信 No.5041 ✎ !
🌸Re:5037◆β版のご試用をありがとうございます。No.4389でご要望頂いてから11ヶ月経っていましたね。^^; お役に立ったようで良かったです。(╹◡╹)
🌸Re:5039◆いいねボタン機能は、「てがろぐアドオンとしても使えて、単独でも使える、汎用Web拍手(いいねボタン)ツール」として開発しようかと計画しています。すごくうまく行ったとして、6月頃に最初のβ版が出せるといいな……と、なんとなく思ってはいます。^^; とりあえず、開発はする予定です。もうしばらく(数ヶ月)お待ち下さい~。(とはいえ、初回のβ版からいろいろ機能を盛るわけではないので、本格的に活用できるようになるにはもっとかかるかもしれませんが。)
➡ 2025年3月14日(金) 19時53分 〔93日前〕 回答/返信 No.5035 ✎ !
🥞Re:5030◆ご要望をありがとうございます。たしかに、1画像だけを消したいときには、現状のUIだと操作が面倒ですね。
🥞Re:5033◆ご要望をありがとうございます。なお、[[COMMENT:TITLE]] の代わりに [[COMMENT:LINE:1]] を使うと、1行目が空行のときには何も出力されませんのでお試し下さい。(ただし、1行目に画像等のオブジェクトがあると、それをそのまま出力してしまいますが。)
➡ 2025年3月14日(金) 18時28分 〔93日前〕 アップデート✨ No.5034 ✎ !
🆕 Ver 4.5.4βの更新点(概要):
《▼新機能》
●ユーザ一覧を出力できる記法 [[USERLIST]] と [[USERLIST:識別子]] を追加。
《▼仕様改善》
●投稿削除ボタンやカテゴリ削除枠の配色を(目立ちすぎる赤色から)灰色に変更。
《▼不具合修正》
(なし)
詳しい使い方などは、上記の開発進捗状況報告ページの記事をご覧下さい。
🍘SNSでのアナウンス:
Mastodon(Pawoo)
Bluesky
Twitter:
(ツイート埋め込み処理中...)Twitterで見る
➡ 2025年3月10日(月) 21時20分 〔97日前〕 回答/返信 No.5029 ✎ !
🍛Re:5022◆情報ありがとうございます。WAF(Web Application Firewall)は、SQLインジェクションとかクロスサイトスクリプティング(XSS)とかに使われるような感じの投稿本文をチェックしてブロックしますからね。長い英文を貼り付けて投稿するだけでも、そこに「or」があって、遠く離れた位置に「=」とかの記号があるだけでもダメだったりしますし。とはいえ、WAFが使えるのならあえてOFFにはしない方が良いですから、いろいろ試していくしかないですね。^^;
🍛Re:5023◆てがろぐのご活用をどうもありがとうございます! 末永くご愛用頂ければ幸いです!(╹◡╹)ノ
🍛Re:5024◆情報ありがとうございます。WAFは、サーバに送信された文字列から「攻撃の可能性」を判断して通信をブロックするか通すかを決めますので、基本的にはスキンは無関係です。ただ、お使いのスキンに、何か必ず特定の文字列を付加して送信させるような特別なスクリプトがあるなら話は別ですが、たぶんそういうケースは滅多にないでしょうね。^^; なので、403になるパターンは、おそらく他のスキンを使っても403になります。半角の丸括弧 ( ) 記号の存在も誤判定によく影響します。(^_^;) 今更なんですけども、てがろぐの各種記法では、区切りに「/」を使って、オプションのカッコには < > を使うような、「攻撃だと誤解されにくい」書き方を採用していれば良かったな……、とは思います。(仕様を考えたときには、WAFにブロックされる可能性は全く想定していなかったもので。)
🍛Re:5025◆分かりやすい画像をありがとうございます。WAFのログをリアルタイムで確認できると、「何だと誤解されたのか」がハッキリするので良いですね。
➡ 2025年3月3日(月) 13時16分 〔104日前〕 回答/返信 No.5018 ✎ !
🍵Re:5017◆ここのてがろぐはデモモードで動作していますので、管理者権限のあるIDでログインしていても設定の変更等はできない仕様になっています(既存投稿の削除は可能ですが)。なので、どのIDでお試し下さっても構いません。
🍵Re:5016◆β版のご試用をどうもありがとうございます。(╹◡╹)ノ
🍵Re:5013◆β版のご試用をどうもありがとうございます。問題なく動作しているようで良かったです。重複投稿のNo.5014は削除しておきました。
🍵Re:5012◆ついこの前、正月だったのに……。┌(:3」└)┐
🍵Re:5011◆私は使っていないので直接の回答はできないのですが、何らかの有効な回答を得るためには、状況の説明が具体的である必要があります。設置している場所のURLを示すのが最も望ましいですが、そうできないのであれば、もうちょっと具体的な状況の説明が必要だろうと思います。「人参を買ってきましたがカレーライスになりません」と言われているような感じで、もうちょっとその中間を説明してくれないと……というような。(笑)
とりあえず、「カスタマイズせずに、スクリプト側の説明書の通りにスキンを書いた場合なら動くのか、それでも動かないのか」あたりから調べてみると良いのではないかと思います。