てがろぐ
- Fumy Otegaru Memo Logger -
カテゴリ「回答/返信」に属する投稿［660件］（12ページ目）
お腹が減ったのでチーズを食べました。🧀🧀🧀
🧀Re:3279◆内側スキンに「前後の投稿へ移動するリンク」を表示させてしまうと、例えば『1ページに30件の投稿を表示する』設定のとき、「前後の投稿へ移動するリンク」も30個表示されてしまいます。^^;（いや、「それで良い」というケースもある気もしますけども、たぶんご希望はそうではないですよね？^^;）No.3282さんがCSSで掲載順序を変更する方法をご提案下さいましたから、私は別解としてJavaScriptで解決する方法をご紹介致します。↓
▼記述するJavaScriptソース #🌱豆知識
外側スキンの末尾（※内側スキンではありません）に以下の9行を書くと（コメントを除けば7行ですし、scriptタグも除けば5行ですが）、ユーティリティリンクの冒頭に「前後の投稿へ移動するリンク」等がコピーされて表示されます。
<script>
let uElm = document.querySelector(".utilitylinks");
if( uElm ) {
// ユーティリティリンク枠が存在する場合のみ
let pnElm = document.querySelector(".pagenavi");
// ナビゲーションリンクのコピーを、ユーティリティリンクの頭に挿入する
uElm.innerHTML = pnElm.innerHTML + uElm.innerHTML;
}
</script>
※変数名 uElm は utility Element の略で、pnElm は page navi Element の略のつもりです。
▼簡単な解説
やっていることは簡単で、
この結果、ユーティリティリンクの冒頭に「前後の投稿へ移動するリンク」等がコピーされて表示されます。（元々あるナビゲーションリンクは元のまま存在し続けます。）
▼class名の注意
なお、ナビゲーションリンクを作っている要素のclass名が .pagenavi なのは、標準添付の各スキンでの例なので、お使いのスキンで記述されているclass名が異なる場合には、5行目の .pagenavi の部分はそれに合わせて書き換える必要があります。（同一ページ内に2回以上使われているclass名の場合は、最初の方の中身だけが取得されます。）
▼補足
上記のソースをそのまま使うと、「ユーティリティリンク枠の冒頭」にナビゲーションリンクが加わります。
そうではなくて、ユーティリティリンク枠よりも前にナビゲーションリンクを表示したい場合は、6～7行目を以下のように差し替えて下さい。
// ナビゲーションリンクのコピーを、ユーティリティリンクの前に挿入する
uElm.outerHTML = pnElm.outerHTML + uElm.outerHTML;
さらに、「元々存在していた方のナビゲーションリンクを消したい場合は、さらに続けて以下の1行を加えて下さい。
pnElm.outerHTML = '';
以上です。
……ここまで書いてから思ったんですが、「ナビゲーションリンクをコピーしてユーティリティリンク枠の上に加える」よりも、「ユーティリティリンク枠をコピーして、ナビゲーションリンクの下に貼り付けて、元々のユーティリティリンク枠は消す」という方が（スキンの作り方によっては）配置調整の自由度が高いかもしれないな……、とふと思いました。^^;
🧀Re:3281◆ご期待に添えなくてすみません。最近のリッチなCMSだとそういうのはできて当然だとも思うのですけども、その分たくさんのJavaScriptが動いているのだろうな……と思います（調べてはいませんが）。てがろぐは、使用面での手軽さもそうですが、動作面の軽さも重視したいと思っておりまして、かつ、開発者(＝私)の手軽さもそこそこ重視しながら開発しております(^_^;)のでご理解頂ければ幸いです。需要はあるとは思いますので、何か良い実装方法が思いついたら試してみます。(╹◡╹)
🧀Re:3282,3280◆サンプルソースのご提示をどうもありがとうございます！ 最初、CSSでどうにかならんかな……と思いつつも思いつかなかったのでJavaScriptでの解決方法で試してしまいましたが、たしかにページ全体に対して順序を指定し直せばCSSだけで実現できますね！
🧀Re:3279◆内側スキンに「前後の投稿へ移動するリンク」を表示させてしまうと、例えば『1ページに30件の投稿を表示する』設定のとき、「前後の投稿へ移動するリンク」も30個表示されてしまいます。^^;（いや、「それで良い」というケースもある気もしますけども、たぶんご希望はそうではないですよね？^^;）No.3282さんがCSSで掲載順序を変更する方法をご提案下さいましたから、私は別解としてJavaScriptで解決する方法をご紹介致します。↓
▼記述するJavaScriptソース #🌱豆知識
外側スキンの末尾（※内側スキンではありません）に以下の9行を書くと（コメントを除けば7行ですし、scriptタグも除けば5行ですが）、ユーティリティリンクの冒頭に「前後の投稿へ移動するリンク」等がコピーされて表示されます。
<script>
let uElm = document.querySelector(".utilitylinks");
if( uElm ) {
// ユーティリティリンク枠が存在する場合のみ
let pnElm = document.querySelector(".pagenavi");
// ナビゲーションリンクのコピーを、ユーティリティリンクの頭に挿入する
uElm.innerHTML = pnElm.innerHTML + uElm.innerHTML;
}
</script>
※変数名 uElm は utility Element の略で、pnElm は page navi Element の略のつもりです。
▼簡単な解説
やっていることは簡単で、
- 2行目は、ユーティリティリンク枠を作っている要素 <div class="utilitylinks"> を取得しています。
- 3行目は、ユーティリティリンク枠が存在するかどうかを調べています。（存在しないときは何も処理しません。）
- 5行目は、ページナビゲーション(移動リンク)部分を作っている <div class="pagenavi"> を取得しています。
- 7行目は、『ユーティリティリンク枠の中身(HTML)』を、『ページナビゲーションの中身(HTML) ＋ ユーティリティリンク枠の中身(HTML)』に差し替えています。
この結果、ユーティリティリンクの冒頭に「前後の投稿へ移動するリンク」等がコピーされて表示されます。（元々あるナビゲーションリンクは元のまま存在し続けます。）
▼class名の注意
なお、ナビゲーションリンクを作っている要素のclass名が .pagenavi なのは、標準添付の各スキンでの例なので、お使いのスキンで記述されているclass名が異なる場合には、5行目の .pagenavi の部分はそれに合わせて書き換える必要があります。（同一ページ内に2回以上使われているclass名の場合は、最初の方の中身だけが取得されます。）
▼補足
上記のソースをそのまま使うと、「ユーティリティリンク枠の冒頭」にナビゲーションリンクが加わります。
そうではなくて、ユーティリティリンク枠よりも前にナビゲーションリンクを表示したい場合は、6～7行目を以下のように差し替えて下さい。
// ナビゲーションリンクのコピーを、ユーティリティリンクの前に挿入する
uElm.outerHTML = pnElm.outerHTML + uElm.outerHTML;
さらに、「元々存在していた方のナビゲーションリンクを消したい場合は、さらに続けて以下の1行を加えて下さい。
pnElm.outerHTML = '';
以上です。
……ここまで書いてから思ったんですが、「ナビゲーションリンクをコピーしてユーティリティリンク枠の上に加える」よりも、「ユーティリティリンク枠をコピーして、ナビゲーションリンクの下に貼り付けて、元々のユーティリティリンク枠は消す」という方が（スキンの作り方によっては）配置調整の自由度が高いかもしれないな……、とふと思いました。^^;
🧀Re:3281◆ご期待に添えなくてすみません。最近のリッチなCMSだとそういうのはできて当然だとも思うのですけども、その分たくさんのJavaScriptが動いているのだろうな……と思います（調べてはいませんが）。てがろぐは、使用面での手軽さもそうですが、動作面の軽さも重視したいと思っておりまして、かつ、開発者(＝私)の手軽さもそこそこ重視しながら開発しております(^_^;)のでご理解頂ければ幸いです。需要はあるとは思いますので、何か良い実装方法が思いついたら試してみます。(╹◡╹)
🧀Re:3282,3280◆サンプルソースのご提示をどうもありがとうございます！ 最初、CSSでどうにかならんかな……と思いつつも思いつかなかったのでJavaScriptでの解決方法で試してしまいましたが、たしかにページ全体に対して順序を指定し直せばCSSだけで実現できますね！
つい最近2022年になったような気がするのですけども、もうあと1ヶ月ちょっとで終わるの……？🤔
🧀Re:3274◆眺めて下さってありがとうございます。セットアップ時に1回だけしか閲覧されないページにここまで力を入れる意味があるかどうかはあえて考えないようにして作りました。(笑) 楽しんで頂けたなら嬉しいです。
🧀Re:3275◆長年のご愛用をどうもありがとうございます。画像投稿前に画像挿入記法を挿入するのは、画像投稿前だとファイル名が確定できないので、少なくとも今のところは無理なのです。隠したい画像が含まれる場合や、画像掲載位置を調整なさりたい場合は、少々ご面倒ですが一旦「下書き」状態で投稿して頂いて、編集してから「下書き」指定を外して公開頂くなどの方法でご対処頂けますと幸いです（おそらく既にそうなさっているのだと思いますが）。ファイル名が確定していなくても、[PICT:1]、[PICT:2]、[PICT:3]……みたいな仮記法をプレースホルダ的に挿入しておいて、投稿処理時に内部で自動変換する手もあるとは思うのですが、処理が複雑になりますので（画像挿入をやめる操作をされたときに編集領域から動的に消さないといけないとか）よほど莫大な需要があったら話は別ですが、今のところは下書きを経由してご投稿頂けるとありがたいなあ……という考えでおります。^^; （続く➡No.3278）
🧀Re:3274◆眺めて下さってありがとうございます。セットアップ時に1回だけしか閲覧されないページにここまで力を入れる意味があるかどうかはあえて考えないようにして作りました。(笑) 楽しんで頂けたなら嬉しいです。
🧀Re:3275◆長年のご愛用をどうもありがとうございます。画像投稿前に画像挿入記法を挿入するのは、画像投稿前だとファイル名が確定できないので、少なくとも今のところは無理なのです。隠したい画像が含まれる場合や、画像掲載位置を調整なさりたい場合は、少々ご面倒ですが一旦「下書き」状態で投稿して頂いて、編集してから「下書き」指定を外して公開頂くなどの方法でご対処頂けますと幸いです（おそらく既にそうなさっているのだと思いますが）。ファイル名が確定していなくても、[PICT:1]、[PICT:2]、[PICT:3]……みたいな仮記法をプレースホルダ的に挿入しておいて、投稿処理時に内部で自動変換する手もあるとは思うのですが、処理が複雑になりますので（画像挿入をやめる操作をされたときに編集領域から動的に消さないといけないとか）よほど莫大な需要があったら話は別ですが、今のところは下書きを経由してご投稿頂けるとありがたいなあ……という考えでおります。^^; （続く➡No.3278）
備蓄ピザを買いに行ったら（安売りが今日までだったためか）在庫僅少でした……😢
🍪Re:3271◆ご活用ありがとうございます。お役に立っているようで嬉しいです。(╹◡╹) 創作サイトでご活用下さっている方々も結構いらっしゃるようですね。
🍪Re:3271◆ご活用ありがとうございます。お役に立っているようで嬉しいです。(╹◡╹) 創作サイトでご活用下さっている方々も結構いらっしゃるようですね。
寝るぅ。(:3[_____]
🍪Re:3268◆完璧なサポートをありがとうございます！(╹◡╹)ﾉ
🍪Re:3267-3269◆投稿番号の再採番は開発のToDoリストには入っているのですが、そうそう直近には実現しなさそうな感じです。将来的には（手動入力した日付でのソート機能と一緒に）実装したいとは思っているのですが。気長にお待ち頂ければ幸いです。で、今すぐに投稿番号を振り直したい場合は、No.3268さんのサポートの通り、データファイル(tegalog.xml)を直接編集頂く方法しかないです（←リンク先のFAQ記事もご参照下さい）。投稿番号は重複しさえしなければ、好きに割り振れます。
🍪Re:3268◆完璧なサポートをありがとうございます！(╹◡╹)ﾉ
🍪Re:3267-3269◆投稿番号の再採番は開発のToDoリストには入っているのですが、そうそう直近には実現しなさそうな感じです。将来的には（手動入力した日付でのソート機能と一緒に）実装したいとは思っているのですが。気長にお待ち頂ければ幸いです。で、今すぐに投稿番号を振り直したい場合は、No.3268さんのサポートの通り、データファイル(tegalog.xml)を直接編集頂く方法しかないです（←リンク先のFAQ記事もご参照下さい）。投稿番号は重複しさえしなければ、好きに割り振れます。
不思議なことに🍪🍪🍪、なぜか体重が増え続けているような……？🤔
🍪Re:3263◆たしかに、最初はその文章を読んだ気がします。（過去投稿が知らないうちにスパムに書き換えられていると困るので）ここでは14日以上前の投稿は再編集できない設定にしてあったのですが、（最近は投稿頻度も高いので14日だと結構簡単に流れて行ってしまうこともありますし）とりあえず投稿から18時間経つと再編集できないように設定を変更してみました。18時間にしたのは、朝に投稿したのを夜になって修正したくなることくらいはあるかな、と思いまして。再編集画面が出せないと記法を案内しにくくなるデメリットがありますが、まあその辺は第2試験場を使えば良いでしょうね。
🍪Re:3264◆なるほどライトプラン。そういえば、さくらインターネットではドメイン関連の仕様がプランで微妙に異なっていた気がしますから（アクセスログにドメインが記録されるかされないかとか）、その辺が影響していそうですね。情報ありがとうございます。
🍪Re:3263◆たしかに、最初はその文章を読んだ気がします。（過去投稿が知らないうちにスパムに書き換えられていると困るので）ここでは14日以上前の投稿は再編集できない設定にしてあったのですが、（最近は投稿頻度も高いので14日だと結構簡単に流れて行ってしまうこともありますし）とりあえず投稿から18時間経つと再編集できないように設定を変更してみました。18時間にしたのは、朝に投稿したのを夜になって修正したくなることくらいはあるかな、と思いまして。再編集画面が出せないと記法を案内しにくくなるデメリットがありますが、まあその辺は第2試験場を使えば良いでしょうね。
🍪Re:3264◆なるほどライトプラン。そういえば、さくらインターネットではドメイン関連の仕様がプランで微妙に異なっていた気がしますから（アクセスログにドメインが記録されるかされないかとか）、その辺が影響していそうですね。情報ありがとうございます。
昼食はチャーハン。おなかいっぱいになったものの、Twitterにクッキーまんがが流れてきたのでクッキーが食べたくなりました。
🍪Re:3253◆もしかして、ここの存在が認識されていない可能性もあるかな……という気もしてきました。使うCGIの動作サンプルは誰でも見るんじゃないかと思っていたのですけども、「他のユーザさんが使っているのを見て導入を決めた」という場合は、わざわざ公式サイトで動作サンプルを見る必要もないでしょうしね……。ユーザさんが増えて、SNSで話題にして下さる頻度も増加しているなら、たいへんありがたいことです。（開発モチベーションが向上するので。）
🍪Re:3254-3256◆たしかに、そのテキストエディタだと見やすそうですしスマートフォンだけでも設置のための書き換えくらい楽々そうですね！
🍪Re:3258◆てがろぐのご愛用をどうもありがとうございます。(╹◡╹) 「能動的に読みに来られない限り誰の目にも触れない」環境というのは気楽に放言しやすいですね。(笑)
🍪Re:3253◆もしかして、ここの存在が認識されていない可能性もあるかな……という気もしてきました。使うCGIの動作サンプルは誰でも見るんじゃないかと思っていたのですけども、「他のユーザさんが使っているのを見て導入を決めた」という場合は、わざわざ公式サイトで動作サンプルを見る必要もないでしょうしね……。ユーザさんが増えて、SNSで話題にして下さる頻度も増加しているなら、たいへんありがたいことです。（開発モチベーションが向上するので。）
🍪Re:3254-3256◆たしかに、そのテキストエディタだと見やすそうですしスマートフォンだけでも設置のための書き換えくらい楽々そうですね！
🍪Re:3258◆てがろぐのご愛用をどうもありがとうございます。(╹◡╹) 「能動的に読みに来られない限り誰の目にも触れない」環境というのは気楽に放言しやすいですね。(笑)
チーズの値段が上がっていた……！🧀🧀🧀 _(┐｢ε:)_
🍩Re:3247◆ドーナツを買ったら我慢できずにその場で食べてしまうために備蓄ができないので大丈夫でした！（大丈夫とは）
🍩Re:3248◆ダークモードは過去にも軽くご要望頂いたような気もするのですけども、書き換えないといけないCSS量が多くて先送りになっております。気長にお待ち頂ければ幸いです。
🍩Re:3249◆設置方法の見やすさをどうにかしたのは1年くらい前かな……という気がなんとなくします。もはや覚えていませんが。^^;◆スキンを配布して下さる方が増えると私も嬉しいです。(╹◡╹)
🍩Re:3250◆てがろぐユーザは、最近は「てがろぐの民」と呼ばれるのですか。(笑) 解決はできたっぽいですね。参考までにここにも書いておきますと、管理画面の「設定」→「補助出力」→【OGP＋Twitter Cardの出力】の「共通画像のURL」項目です。ただ、そこの設定を弄らなくても投稿本文内に画像があれば、その画像が使われますけどもね。
🍩Re:3247◆ドーナツを買ったら我慢できずにその場で食べてしまうために備蓄ができないので大丈夫でした！（大丈夫とは）
🍩Re:3248◆ダークモードは過去にも軽くご要望頂いたような気もするのですけども、書き換えないといけないCSS量が多くて先送りになっております。気長にお待ち頂ければ幸いです。
🍩Re:3249◆設置方法の見やすさをどうにかしたのは1年くらい前かな……という気がなんとなくします。もはや覚えていませんが。^^;◆スキンを配布して下さる方が増えると私も嬉しいです。(╹◡╹)
🍩Re:3250◆てがろぐユーザは、最近は「てがろぐの民」と呼ばれるのですか。(笑) 解決はできたっぽいですね。参考までにここにも書いておきますと、管理画面の「設定」→「補助出力」→【OGP＋Twitter Cardの出力】の「共通画像のURL」項目です。ただ、そこの設定を弄らなくても投稿本文内に画像があれば、その画像が使われますけどもね。
お腹が減ってきました。ドーナツがあったら食べてしまいそうですが、ないので太らずに済みます。やった。_(┐｢ε:)_
🍩Re:3242◆情報をどうもありがとうございます。何も選択していなくてもアラートが記録されていましたか……。とりあえず、そのアラートが記録されない仕組みを追加しても古いサーバでも問題なく動作することが確認できましたので、次のバージョンからは記録されずに動作するように改善します。
🍩Re:3245◆なるほど、さくらインターネットのサーバでもそのような動作になるケースがあるのですね……。情報ありがとうございます。絶対パスで画像が指定された場合でエラーを表示する状況になった際には、その辺の情報も併せて表示することで対処を促せるような感じに改善しようかな……と考えています。とりあえず、手動で設定頂けたなら何も問題はありませんので、そのまま(今後のバージョンでも)ご使用下さい。
🍩Re:3242◆情報をどうもありがとうございます。何も選択していなくてもアラートが記録されていましたか……。とりあえず、そのアラートが記録されない仕組みを追加しても古いサーバでも問題なく動作することが確認できましたので、次のバージョンからは記録されずに動作するように改善します。
🍩Re:3245◆なるほど、さくらインターネットのサーバでもそのような動作になるケースがあるのですね……。情報ありがとうございます。絶対パスで画像が指定された場合でエラーを表示する状況になった際には、その辺の情報も併せて表示することで対処を促せるような感じに改善しようかな……と考えています。とりあえず、手動で設定頂けたなら何も問題はありませんので、そのまま(今後のバージョンでも)ご使用下さい。
返信が遅くなってすみません。昨日は脳がうまく回転していなかったので。_(┐｢ε:)_
🍵Re:3235◆それは良いアイデアですね！ 採用します！
🍵Re:3236◆ご確認をありがとうございました。なるほと、ディレクトリが1つ足りませんでしたか。参考までにお尋ねしたいのですけども、もしかしてその足りないディレクトリというのは、「特定のドメイン用のディレクトリのHOME」を表すディレクトリでしょうか？ 例えば、/home/username/www がレンタルサーバ初期ドメインのHOMEとしてアクセスできるディレクトリで、/home/username/www/example.com が独自ドメイン example.com のHOMEとしてアクセスできるディレクトリ……というような。その /example.com ディレクトリが抜けていた、とかそういう現象ですかね？（だとすると、環境変数からドキュメントルートを取得する方法ではバーチャルドメイン環境では使えないことになるので、何か別の対策が必要ですね……。） なお、実践して下さったように、「ドキュメントルートの位置」項目の値を「固定」に切り替えて、足りないディレクトリ名を補って使って頂く方法で問題ありません。今後もその方法でご使用下さい。
🍵Re:3237◆私も待っています。(笑)
🍵Re:3238◆参考までに教えて頂きたいのですが、てがろぐのバージョンと、Perlのバージョンは何でしょうか？ そのアラートは「この書き方は脆弱性に繋がる可能性がある」と警告するものですが、てがろぐのソースでは大丈夫ですので無視して頂いて問題ないのですけども（※新しい書き方をすれば回避できるのですが、古い環境でも実行できるようにするために、あえてこの書き方を使っています）、たしかに投稿のたびにアラートが記録されるのはあまり気持ちよくはないですね（たぶん複数のカテゴリを指定して投稿した場合等に記録されるのだと思いますが）。tegalog.cgiの91行目付近に use CGI; という行がありますが、この直後に $CGI::LIST_CONTEXT_WARN = 0; という1行を追記しておくとそのアラートは出なくなります。次のバージョンからはデフォルトで書き加えておくか何か考えます。なお、さくらインターネットでPerlのバージョンを知るには、下図の場所（スクリプト設定→言語バージョン設定）をご参照下さい。
🍵Re:3240◆ご要望をどうもありがとうございます。そういえば、記事一覧画面では全部のチェックボックスに一気にチェックを入れたり外したりする機能がありませんでしたね（画像管理画面にはあるのですが）。次のバージョンで加えておきます。
🍵Re:3235◆それは良いアイデアですね！ 採用します！
🍵Re:3236◆ご確認をありがとうございました。なるほと、ディレクトリが1つ足りませんでしたか。参考までにお尋ねしたいのですけども、もしかしてその足りないディレクトリというのは、「特定のドメイン用のディレクトリのHOME」を表すディレクトリでしょうか？ 例えば、/home/username/www がレンタルサーバ初期ドメインのHOMEとしてアクセスできるディレクトリで、/home/username/www/example.com が独自ドメイン example.com のHOMEとしてアクセスできるディレクトリ……というような。その /example.com ディレクトリが抜けていた、とかそういう現象ですかね？（だとすると、環境変数からドキュメントルートを取得する方法ではバーチャルドメイン環境では使えないことになるので、何か別の対策が必要ですね……。） なお、実践して下さったように、「ドキュメントルートの位置」項目の値を「固定」に切り替えて、足りないディレクトリ名を補って使って頂く方法で問題ありません。今後もその方法でご使用下さい。
🍵Re:3237◆私も待っています。(笑)
🍵Re:3238◆参考までに教えて頂きたいのですが、てがろぐのバージョンと、Perlのバージョンは何でしょうか？ そのアラートは「この書き方は脆弱性に繋がる可能性がある」と警告するものですが、てがろぐのソースでは大丈夫ですので無視して頂いて問題ないのですけども（※新しい書き方をすれば回避できるのですが、古い環境でも実行できるようにするために、あえてこの書き方を使っています）、たしかに投稿のたびにアラートが記録されるのはあまり気持ちよくはないですね（たぶん複数のカテゴリを指定して投稿した場合等に記録されるのだと思いますが）。tegalog.cgiの91行目付近に use CGI; という行がありますが、この直後に $CGI::LIST_CONTEXT_WARN = 0; という1行を追記しておくとそのアラートは出なくなります。次のバージョンからはデフォルトで書き加えておくか何か考えます。なお、さくらインターネットでPerlのバージョンを知るには、下図の場所（スクリプト設定→言語バージョン設定）をご参照下さい。
🍵Re:3240◆ご要望をどうもありがとうございます。そういえば、記事一覧画面では全部のチェックボックスに一気にチェックを入れたり外したりする機能がありませんでしたね（画像管理画面にはあるのですが）。次のバージョンで加えておきます。
備蓄の冷凍ピザを買いに行かなければ……。🍕🍕🍕
🍮Re:3229◆配布も期待しております。(╹◡╹)ﾉ
🍮Re:3230◆なかなかユーザさんがどんなことを実現しようとなさっているのかを知る機会がないので（知る機会がなくても、それができているなら問題ないんですが）「こうしようと思ったけどできなかったので諦めた」という状況は（実際には方法が存在する場合には）大変もったいないので、いろいろ解説を書いて下さるのはとてもありがたいです。当初は、「クッション画像を置きたい」という需要があることにすら微塵も気付きませんでしたし。^^;
🍮Re:3231◆ありゃ……。そんな問題がありましたか！ 原因を究明するために、もし可能でしたら教えて頂きたいのですが、管理画面の「設定」→「システム設定」→【サーバパス設定】→「ドキュメントルートの位置」の値は、「環境変数から自動取得で設定」ですか？ それともご自身で何か設定されていますか？ （どちらを選んでいる場合でも）そこの「固定」欄に入っている文字列（例えば /home/username/www ）と、[PICT:～]記法で指定したファイルパス（例えば /materials/photo/sakura.jpg ）を加えると、正しくサーバ上の位置を示しますか？（例の場合は /home/username/www/materials/photo/sakura.jpg がサーバ上の正しい位置(PATH)でしょうか？）Ver 3.8.5ではこのフルパスにファイルが実在するかどうかをチェックするようになりましたので。
あと、それはサムネイル画像の表示機能を使っている場合でしたか？ それとも、サムネイルではなくオリジナル画像だけが表示される状況でしたか？
🍮Re:3232◆もちろんどうぞー。歓迎致します🎉🎈 配布用スキンでなくても、てがろぐの解説とか、設置したてがろぐの宣伝でも歓迎致します！
🍮Re:3229◆配布も期待しております。(╹◡╹)ﾉ
🍮Re:3230◆なかなかユーザさんがどんなことを実現しようとなさっているのかを知る機会がないので（知る機会がなくても、それができているなら問題ないんですが）「こうしようと思ったけどできなかったので諦めた」という状況は（実際には方法が存在する場合には）大変もったいないので、いろいろ解説を書いて下さるのはとてもありがたいです。当初は、「クッション画像を置きたい」という需要があることにすら微塵も気付きませんでしたし。^^;
🍮Re:3231◆ありゃ……。そんな問題がありましたか！ 原因を究明するために、もし可能でしたら教えて頂きたいのですが、管理画面の「設定」→「システム設定」→【サーバパス設定】→「ドキュメントルートの位置」の値は、「環境変数から自動取得で設定」ですか？ それともご自身で何か設定されていますか？ （どちらを選んでいる場合でも）そこの「固定」欄に入っている文字列（例えば /home/username/www ）と、[PICT:～]記法で指定したファイルパス（例えば /materials/photo/sakura.jpg ）を加えると、正しくサーバ上の位置を示しますか？（例の場合は /home/username/www/materials/photo/sakura.jpg がサーバ上の正しい位置(PATH)でしょうか？）Ver 3.8.5ではこのフルパスにファイルが実在するかどうかをチェックするようになりましたので。
あと、それはサムネイル画像の表示機能を使っている場合でしたか？ それとも、サムネイルではなくオリジナル画像だけが表示される状況でしたか？
🍮Re:3232◆もちろんどうぞー。歓迎致します🎉🎈 配布用スキンでなくても、てがろぐの解説とか、設置したてがろぐの宣伝でも歓迎致します！
久しぶりに烏龍茶を飲みました。
🍵Re:3218◆ご試用ありがとうございます！ デフォルト入力色の変更は個人的に欲しかったので実装したのですが、お役に立ったようで嬉しいです。(╹◡╹)
🍵Re:3219◆スキンの選択肢を増やして下さるのは、私にとっても大変ありがたいです。
🍵Re:3220◆ご報告ありがとうございます。高画質な画像を掲載したい場合には、たしかに(通信)容量に気を遣いますものね。
🍵Re:3221◆β版のご試用ありがとうございます。問題ないようで良かったです。
🍵Re:3223◆ご報告をどうもありがとうございます。たしかに、SSIで埋め込んで使う場合に問題がありますね。こちらでも確認しました。設定で「画像パスに絶対URL(フルパス)を使う」項目をONにしていても、サムネイル画像に関しては相対パスで出力されてしまう不具合がありました。なので、SSIで合成している場合には相対パスのまま出てしまって、何も画像が表示されなくなる問題がありました。ローカルのソースは修正しましたので、この後、配布します。
🍵Re:3218◆ご試用ありがとうございます！ デフォルト入力色の変更は個人的に欲しかったので実装したのですが、お役に立ったようで嬉しいです。(╹◡╹)
🍵Re:3219◆スキンの選択肢を増やして下さるのは、私にとっても大変ありがたいです。
🍵Re:3220◆ご報告ありがとうございます。高画質な画像を掲載したい場合には、たしかに(通信)容量に気を遣いますものね。
🍵Re:3221◆β版のご試用ありがとうございます。問題ないようで良かったです。
🍵Re:3223◆ご報告をどうもありがとうございます。たしかに、SSIで埋め込んで使う場合に問題がありますね。こちらでも確認しました。設定で「画像パスに絶対URL(フルパス)を使う」項目をONにしていても、サムネイル画像に関しては相対パスで出力されてしまう不具合がありました。なので、SSIで合成している場合には相対パスのまま出てしまって、何も画像が表示されなくなる問題がありました。ローカルのソースは修正しましたので、この後、配布します。
おなかいっぱい。_(┐｢ε:)_
🍕Re:3214◆早速のご試用をどうもありがとうございます！ てがろぐ上でサムネイル画像をUPできるようにする際には、自動で元のファイル名と同じになるようにします。たぶん、画像管理画面で「この画像用のサムネイルをアップロードする」みたいな機能を用意すると思います。ただ、その機能を用意するのは、今計画している（画像キャプションとかをあらかじめ登録しておける）画像インデックス生成機能を実装した後になりますので、まだもっと先になる予定です。気長にお待ち頂ければ幸いです。
🍕Re:3214◆早速のご試用をどうもありがとうございます！ てがろぐ上でサムネイル画像をUPできるようにする際には、自動で元のファイル名と同じになるようにします。たぶん、画像管理画面で「この画像用のサムネイルをアップロードする」みたいな機能を用意すると思います。ただ、その機能を用意するのは、今計画している（画像キャプションとかをあらかじめ登録しておける）画像インデックス生成機能を実装した後になりますので、まだもっと先になる予定です。気長にお待ち頂ければ幸いです。
いま何を食べたいか書こうかな……と思ったのだけど、すごくおなかいっぱいだった。ピザを食べたから。ぐふぅ。_(┐｢ε:)_
🍕Re:3207◆スマートフォンでも不便ではないと聞いて安心しました。私自身がほとんど常にPCの前に居る生活なので、モバイル端末であまりアクセスしないものですから、小型端末での使用感を把握できていないので、どうなのかな……と思っていたのでした。
🍕Re:3207◆スマートフォンでも不便ではないと聞いて安心しました。私自身がほとんど常にPCの前に居る生活なので、モバイル端末であまりアクセスしないものですから、小型端末での使用感を把握できていないので、どうなのかな……と思っていたのでした。
脂肪を減らさねば……。🍔🍩🍫
🍪Re:3193◆アドバイスをありがとうございます。こうして見ると、BBCのclass名の付け方が謎ですね。本当にそこまでclass分けする必要があるのかと。たぶんCMSがランダムに割り振っているだけなんでしょうけども、16pexesとかwoxom8とか、ぱっと見て何か意味があるのかな、と思ってしまいます。(^_^;)
🍪Re:3192◆管理画面もスキン式にとは斬新なアイデアですね！ そこには思い至りませんでした。面白そうですね。ただ、実装が大変そうですけども。^^; それこそ >>3193 さんの方法が役に立たないでしょうか？ CSSだけで実現可能な範囲でなら何でも対処できそうな気がします。
🍪Re:3193◆アドバイスをありがとうございます。こうして見ると、BBCのclass名の付け方が謎ですね。本当にそこまでclass分けする必要があるのかと。たぶんCMSがランダムに割り振っているだけなんでしょうけども、16pexesとかwoxom8とか、ぱっと見て何か意味があるのかな、と思ってしまいます。(^_^;)
🍪Re:3192◆管理画面もスキン式にとは斬新なアイデアですね！ そこには思い至りませんでした。面白そうですね。ただ、実装が大変そうですけども。^^; それこそ >>3193 さんの方法が役に立たないでしょうか？ CSSだけで実現可能な範囲でなら何でも対処できそうな気がします。
落花飴が美味しいので2日で1袋くらい舐めきってしまう……。🍬🍬🍬
🍪Re:3188◆詳しい分析と背景と解説をありがとうございます。どんな動作になると望ましいかがよく分かって参考になります。[[NO-LINKADJUSTMENT]] に関しては、外側スキンと内側スキンで別々に記述でき、それぞれお互いには影響しない仕様で行こうと思います。本文からハッシュタグだけを抽出して掲載する [[COMMENT:TAGS]] に関しては、[[COMMENT:TAGS:PURE]] というオプションを設けると便利かもしれませんね。（ただ、「本文中に挿入されているハッシュタグリンクからはskinパラメータを抜く」というJavaScriptを用意している場合は、それがそのまま [[COMMENT:TAGS]] で出力される内容も対象にして処理するでしょうから、記法として存在してもあまり意味はないかもしれませんけども。^^;）
🍪Re:3188◆詳しい分析と背景と解説をありがとうございます。どんな動作になると望ましいかがよく分かって参考になります。[[NO-LINKADJUSTMENT]] に関しては、外側スキンと内側スキンで別々に記述でき、それぞれお互いには影響しない仕様で行こうと思います。本文からハッシュタグだけを抽出して掲載する [[COMMENT:TAGS]] に関しては、[[COMMENT:TAGS:PURE]] というオプションを設けると便利かもしれませんね。（ただ、「本文中に挿入されているハッシュタグリンクからはskinパラメータを抜く」というJavaScriptを用意している場合は、それがそのまま [[COMMENT:TAGS]] で出力される内容も対象にして処理するでしょうから、記法として存在してもあまり意味はないかもしれませんけども。^^;）
たこ焼きの絵文字の追加が待たれる。誰かUnicodeの偉い人に提案しているだろうか？
🍪Re:3187◆アンケートへのご回答もどうもありがとうございました！β版の新機能もご活用頂けているようで嬉しいです。◆レンタルサーバは、同じコースでも契約時期によって収容サーバが異なりますけども、ロリポップはそのサーバ間での仕様に開きがあるっぽいような感じですね。なんとなく、公式の「言語のパスはサーバーにより異なります」のあたりとかを読むと。その辺で違いがあるのかもしれません。何にせよ、suEXECのパーミッションで動作しているなら、（既に実践頂いている通り）全部suEXECの値にするのが良いです。
🍪Re:3187◆アンケートへのご回答もどうもありがとうございました！β版の新機能もご活用頂けているようで嬉しいです。◆レンタルサーバは、同じコースでも契約時期によって収容サーバが異なりますけども、ロリポップはそのサーバ間での仕様に開きがあるっぽいような感じですね。なんとなく、公式の「言語のパスはサーバーにより異なります」のあたりとかを読むと。その辺で違いがあるのかもしれません。何にせよ、suEXECのパーミッションで動作しているなら、（既に実践頂いている通り）全部suEXECの値にするのが良いです。
昼食は明太子ピザ(198円)。🍕🍕🍕
🍪Re:3185◆β版のご試用をどうもありがとうございます。そして、ご指摘もありがとうございます！ たしかに、おっしゃる動作になりますね……。各機能は行き当たりばったりでその都度追加しているので、1カ所でまとめて処理するようなスマートな仕組みになっていないために漏れていたようです。(^_^;;; 調べたところ、どうもハッシュタグに関しては、「本文中に挿入するハッシュタグリンク」と「ハッシュタグ一覧として出力するハッシュタグリンク」を同じ処理で出力していることが原因っぽいことが分かりました。次のバージョンでは修正します。
それと同時に気付いたんですけども、[[NO-LINKADJUSTMENT]] の記述は投稿本文とか「内側スキンで生成される内容」に含まれるリンクには影響しないのですよね……。これは、影響するように仕様を修正する方が良いか、それとも、内側スキンにも [[NO-LINKADJUSTMENT]] を書けるようにして、その場合にだけリンクを修正するか、検討しています。『外側スキンで [[NO-LINKADJUSTMENT]] を書いておきながら、内側スキンではリンクを修正されたくない』というケースはあまりなさそうな気がするので、手間を省くためにも前者（＝外側スキンに書いていれば内側スキンにも影響する）の方が良いかな、という気もしますが。でも、そういうケースがある可能性もないとは言い切れないかもしれませんから、後者（＝内側スキンにも [[NO-LINKADJUSTMENT]] を書ける）の方が自由度が高くて良いのかな……という気もしているのですけども。
🍪Re:3185◆β版のご試用をどうもありがとうございます。そして、ご指摘もありがとうございます！ たしかに、おっしゃる動作になりますね……。各機能は行き当たりばったりでその都度追加しているので、1カ所でまとめて処理するようなスマートな仕組みになっていないために漏れていたようです。(^_^;;; 調べたところ、どうもハッシュタグに関しては、「本文中に挿入するハッシュタグリンク」と「ハッシュタグ一覧として出力するハッシュタグリンク」を同じ処理で出力していることが原因っぽいことが分かりました。次のバージョンでは修正します。
それと同時に気付いたんですけども、[[NO-LINKADJUSTMENT]] の記述は投稿本文とか「内側スキンで生成される内容」に含まれるリンクには影響しないのですよね……。これは、影響するように仕様を修正する方が良いか、それとも、内側スキンにも [[NO-LINKADJUSTMENT]] を書けるようにして、その場合にだけリンクを修正するか、検討しています。『外側スキンで [[NO-LINKADJUSTMENT]] を書いておきながら、内側スキンではリンクを修正されたくない』というケースはあまりなさそうな気がするので、手間を省くためにも前者（＝外側スキンに書いていれば内側スキンにも影響する）の方が良いかな、という気もしますが。でも、そういうケースがある可能性もないとは言い切れないかもしれませんから、後者（＝内側スキンにも [[NO-LINKADJUSTMENT]] を書ける）の方が自由度が高くて良いのかな……という気もしているのですけども。
昼食はピザ。（198円）🍕🍕🍕
🍘Re:3179◆詳しいご報告をどうもありがとうございます。参考になって助かります。$howtogetpathの値で動作が変わるのは、CGIモジュールのバージョンも影響していそうな気がします。前は正しく動作しなかった、とすると、前のサーバ（マイグレーション前のサーバ）では、CGIモジュールが古かったとか何かそういうことも影響しているのかもしれません。今まであまり気にしてきませんでしたが、Perlにバージョンがあるのと同じように、各Perlモジュールにもバージョンがあるんですよね。^^; 同じレンタルサーバ会社で、同じコース（プラン）でも、契約時期によって収容サーバの仕様が異なる可能性はあるので、他者の情報が参考にできるときとできないときがあって、いざトラブルに見舞われるとなかなか一筋縄にはいかないものですね……。^^; とりあえず、無事に動作するようになったとのことですし、引き続きご愛用頂ければ幸いです。
🍘てがろぐ稼働サーバアンケートにご回答下さった方々もどうもありがとうございます。ご回答頂いた情報もまとめて、セットアップ面でのヘルプ情報を増やしておこうと思います。とはいえ、大半の方は「何も書き換えずにそのまま動いた」的な感じなのですけども（もちろん、その情報も役に立ちます）。回答はまだ（というかずっと）受け付けておりますので、よろしければご回答をお願い致します。
🍘Re:3179◆詳しいご報告をどうもありがとうございます。参考になって助かります。$howtogetpathの値で動作が変わるのは、CGIモジュールのバージョンも影響していそうな気がします。前は正しく動作しなかった、とすると、前のサーバ（マイグレーション前のサーバ）では、CGIモジュールが古かったとか何かそういうことも影響しているのかもしれません。今まであまり気にしてきませんでしたが、Perlにバージョンがあるのと同じように、各Perlモジュールにもバージョンがあるんですよね。^^; 同じレンタルサーバ会社で、同じコース（プラン）でも、契約時期によって収容サーバの仕様が異なる可能性はあるので、他者の情報が参考にできるときとできないときがあって、いざトラブルに見舞われるとなかなか一筋縄にはいかないものですね……。^^; とりあえず、無事に動作するようになったとのことですし、引き続きご愛用頂ければ幸いです。
🍘てがろぐ稼働サーバアンケートにご回答下さった方々もどうもありがとうございます。ご回答頂いた情報もまとめて、セットアップ面でのヘルプ情報を増やしておこうと思います。とはいえ、大半の方は「何も書き換えずにそのまま動いた」的な感じなのですけども（もちろん、その情報も役に立ちます）。回答はまだ（というかずっと）受け付けておりますので、よろしければご回答をお願い致します。
サッポロポテトとポテチを食べたのでおなかいっぱいになりました。🍠🍠🍠
🍟Re:3162◆アンケート回答ありがとうございます。アップデートもスマートフォンだけで済むのはなかなかすごいですね。
🍟Re:3163,3167◆無事に動きましたか。良かったです。私が寝ている間にすべてが解決していて驚きました。^^; mixhostではコントロールパネルからPerlモジュールを追加可能なのですね。だから標準モジュールすらも最初からは入れない方針なのかもしれませんが、せめて標準モジュールくらいは最初から入れておいて欲しかったですね。^^;（事実、マイグレーション前のサーバには標準で入っていたようですし。） いずれにせよ、お疲れさまでした。無事に復活頂けて私も嬉しいです。詳しい情報もどうもありがとうございます。後日、アンケート結果も参照しつつサーバ別のセットアップ情報を公開するつもりですが、その際にもご報告頂いた対処方法を活用させて頂きます。
🍟Re:3165◆Perl 5.26で「@INCからカレントディレクトリが削除された」仕様は、初期の頃のてがろぐなら影響を受けていたのですが、（いつかは忘れましたが）いつかのバージョンからは対策しまして、今では影響を受けなくなっているのでした。
【緩募】アンケートは継続して受け付けておりますので、もしよろしければ（まだの方は）ご回答をお願いできるとありがたいです。
➡緩募：てがろぐ稼働サーバについてアンケート回答のお願い
既にアンケートにご回答下さった皆様、どうもありがとうございます！ とても参考になります。
🍟Re:3162◆アンケート回答ありがとうございます。アップデートもスマートフォンだけで済むのはなかなかすごいですね。
🍟Re:3163,3167◆無事に動きましたか。良かったです。私が寝ている間にすべてが解決していて驚きました。^^; mixhostではコントロールパネルからPerlモジュールを追加可能なのですね。だから標準モジュールすらも最初からは入れない方針なのかもしれませんが、せめて標準モジュールくらいは最初から入れておいて欲しかったですね。^^;（事実、マイグレーション前のサーバには標準で入っていたようですし。） いずれにせよ、お疲れさまでした。無事に復活頂けて私も嬉しいです。詳しい情報もどうもありがとうございます。後日、アンケート結果も参照しつつサーバ別のセットアップ情報を公開するつもりですが、その際にもご報告頂いた対処方法を活用させて頂きます。
🍟Re:3165◆Perl 5.26で「@INCからカレントディレクトリが削除された」仕様は、初期の頃のてがろぐなら影響を受けていたのですが、（いつかは忘れましたが）いつかのバージョンからは対策しまして、今では影響を受けなくなっているのでした。
【緩募】アンケートは継続して受け付けておりますので、もしよろしければ（まだの方は）ご回答をお願いできるとありがたいです。
➡緩募：てがろぐ稼働サーバについてアンケート回答のお願い
既にアンケートにご回答下さった皆様、どうもありがとうございます！ とても参考になります。
🍩Re:3157◆なかなか一筋縄にはいきませんな……。^^;
次に、以下の5行を（改行LFで）保存してUPしてブラウザでアクセスしてみて頂けますでしょうか。
てがろぐを実行するには、CGIモジュールとTime::Localモジュールが必須なので、この2つを呼び出せるかどうかを確認するためです。（これらは標準モジュールなので普通は「最初から入っている」と考えて良いとは思うのですが。最初に転載して頂いたサーバのサポートさんの回答に「@INCの仕様変更があり～」という内容がありましたよね。これはつまり、「必要なモジュールが入っていないから、自力でモジュールを入れている」みたいな状況を前提としてそう語っているのかな、とちょっと思いました。だとしたら、『マイグレーション後のty10003サーバー』にはこれらのモジュールが存在しない可能性もあるな、と思いまして。）
あとこれは参考までの話ですが、改行コードは1ファイル内で混在ができます。「大半の行は[LF]だが、ある特定の行だけ[CR+LF]になっている」みたいなこともあり得ます。なので、転載して頂いた1枚目のMeryの画面では、そのファイル内の全部の改行コードが[LF]かどうかは分からない可能性があります。2枚目の画面のように、保存画面で[LF (UNIX)]を選択した上で上書き保存して頂ければ確実です。
次に、以下の5行を（改行LFで）保存してUPしてブラウザでアクセスしてみて頂けますでしょうか。
#! /usr/bin/perl
use CGI;
use Time::Local;
print "Content-type: text/html \n\n";
print "Hello World!";
てがろぐを実行するには、CGIモジュールとTime::Localモジュールが必須なので、この2つを呼び出せるかどうかを確認するためです。（これらは標準モジュールなので普通は「最初から入っている」と考えて良いとは思うのですが。最初に転載して頂いたサーバのサポートさんの回答に「@INCの仕様変更があり～」という内容がありましたよね。これはつまり、「必要なモジュールが入っていないから、自力でモジュールを入れている」みたいな状況を前提としてそう語っているのかな、とちょっと思いました。だとしたら、『マイグレーション後のty10003サーバー』にはこれらのモジュールが存在しない可能性もあるな、と思いまして。）
あとこれは参考までの話ですが、改行コードは1ファイル内で混在ができます。「大半の行は[LF]だが、ある特定の行だけ[CR+LF]になっている」みたいなこともあり得ます。なので、転載して頂いた1枚目のMeryの画面では、そのファイル内の全部の改行コードが[LF]かどうかは分からない可能性があります。2枚目の画面のように、保存画面で[LF (UNIX)]を選択した上で上書き保存して頂ければ確実です。
🍩Re:3152◆うーむ。サーバのサポートさんの指摘は的を射ていなかったようですね。(^_^;)
▼改行コードかな……？
なんとなく改行コードが問題の可能性もあるかな……という気もしてきました。
サーバのファイルマネージャが、どんな改行コードを出力しているのかが分かりませんので。
🍘対処方法1：
サーバのファイルマネージャの編集機能に、改行コードを指定して保存する機能はありますでしょうか？ あれば LF だけにして保存した上で再度アクセスを試して頂きたいのですが。
🍘対処方法2：
もし、そのような機能がない場合は、
一度、ローカルで tegalog.cgi を編集して、改行コードが LF だけになるようにして上書き保存した上で、FTPのバイナリモードでアップロードしてみて頂けますでしょうか。
お使いのPCは、Windowsでしょうか？
タイムリーなことに、昨夜、WitchServerのサポートさんがその具体的な操作手順を案内して下さっていますので参考になさって下さい。
※文字コードを UTF-8 にしているとき、BOM（Byte Order Mark）が先頭に付与されるとたぶんマズいので、UTF-8で保存する際には、「UTF-8（BOMなし）」とか「UTF-8N」のような選択肢を選択して保存する必要がある点にもご注意下さい。
🍘対処方法3：
tegalog.cgi の1行目を #! /usr/bin/perl -- にしてみて下さい。「perl」の後に半角空白を開けてから半角ハイフン記号を2つ並べます。
それでもダメな場合は、
tegalog.cgi の1行目を #!!/usr/bin/perlml にしてみて下さい。mixhostで「lscgid: execve():〜〜〜: No such file or directory」というエラーが報告される場合の対処法としてググったら出てきましたので。^^;
▼.htaccessはどうかな
500エラーが出るときの、ブラウザのアドレス欄には、tegalog.cgi というファイル名が見えていますか？
もしかして、 500.shtml というファイル名が見えていないでしょうか。（お書き下さったエラーは、「500.shtml がない」というエラーですので……。）
もし、500エラーが出るときに「元々のURL」ではなく「エラー画面専用のURL」に移動してしまっている場合は、.htaccessの書き方に問題があります。
エラーページに恒久的に転送するよう記述してしまうと、ブラウザが「500エラーページへの転送」をキャッシュしてしまうので、CGIの動作に問題がなくなった以後でも最初から問答無用で500エラーページに転送されてしまいます。
🍘対処方法：
今まで tegalog.cgi にアクセスしたことのないブラウザを使ってアクセスして見て下さい。
もしくは、ブラウザのキャッシュを全削除してからアクセスしてみて下さい。
▼ただの転記ミスだとは思うのですが
tegalog.cgi の1行目を編集なさったということで 「 #! /usr/local/bin/per 」とお書き頂いていますが、これは「 #! /usr/local/bin/perl 」の転記ミスでしょうかね？
もし転記ミスではなくて本当に「 per 」と書いているなら、「 perl 」にして下さい。
（ただ、mixhost側が指定しているPerlパスは /usr/bin/perl のようです。）
▼他のCGIは動作していますか？
てがろぐ以外に何かCGIはお使いでしょうか。それらは動作していますか？
てがろぐ以外にCGIがない場合は、以下の3行を test.cgi 等のファイル名で保存してUPして、パーミッションを 700 または 705 または 755 にして、ブラウザでアクセスしてみて下さい。
#! /usr/bin/perl
print "Content-type: text/html \n\n";
print "Hello World!";
これで、ブラウザに「Hello Wold!」と表示されるかどうかを確かめてみて下さい。
これでも500エラーが出る場合、改行コードが LF だけになっているかどうかを確かめてみて下さい。
それでも500エラーになる場合は、もっと何か根本的なところに問題がある気がします。
▼改行コードかな……？
なんとなく改行コードが問題の可能性もあるかな……という気もしてきました。
サーバのファイルマネージャが、どんな改行コードを出力しているのかが分かりませんので。
🍘対処方法1：
サーバのファイルマネージャの編集機能に、改行コードを指定して保存する機能はありますでしょうか？ あれば LF だけにして保存した上で再度アクセスを試して頂きたいのですが。
🍘対処方法2：
もし、そのような機能がない場合は、
一度、ローカルで tegalog.cgi を編集して、改行コードが LF だけになるようにして上書き保存した上で、FTPのバイナリモードでアップロードしてみて頂けますでしょうか。
お使いのPCは、Windowsでしょうか？
タイムリーなことに、昨夜、WitchServerのサポートさんがその具体的な操作手順を案内して下さっていますので参考になさって下さい。
※文字コードを UTF-8 にしているとき、BOM（Byte Order Mark）が先頭に付与されるとたぶんマズいので、UTF-8で保存する際には、「UTF-8（BOMなし）」とか「UTF-8N」のような選択肢を選択して保存する必要がある点にもご注意下さい。
🍘対処方法3：
tegalog.cgi の1行目を #! /usr/bin/perl -- にしてみて下さい。「perl」の後に半角空白を開けてから半角ハイフン記号を2つ並べます。
それでもダメな場合は、
tegalog.cgi の1行目を #!!/usr/bin/perlml にしてみて下さい。mixhostで「lscgid: execve():〜〜〜: No such file or directory」というエラーが報告される場合の対処法としてググったら出てきましたので。^^;
▼.htaccessはどうかな
500エラーが出るときの、ブラウザのアドレス欄には、tegalog.cgi というファイル名が見えていますか？
もしかして、 500.shtml というファイル名が見えていないでしょうか。（お書き下さったエラーは、「500.shtml がない」というエラーですので……。）
もし、500エラーが出るときに「元々のURL」ではなく「エラー画面専用のURL」に移動してしまっている場合は、.htaccessの書き方に問題があります。
エラーページに恒久的に転送するよう記述してしまうと、ブラウザが「500エラーページへの転送」をキャッシュしてしまうので、CGIの動作に問題がなくなった以後でも最初から問答無用で500エラーページに転送されてしまいます。
🍘対処方法：
今まで tegalog.cgi にアクセスしたことのないブラウザを使ってアクセスして見て下さい。
もしくは、ブラウザのキャッシュを全削除してからアクセスしてみて下さい。
▼ただの転記ミスだとは思うのですが
tegalog.cgi の1行目を編集なさったということで 「 #! /usr/local/bin/per 」とお書き頂いていますが、これは「 #! /usr/local/bin/perl 」の転記ミスでしょうかね？
もし転記ミスではなくて本当に「 per 」と書いているなら、「 perl 」にして下さい。
（ただ、mixhost側が指定しているPerlパスは /usr/bin/perl のようです。）
▼他のCGIは動作していますか？
てがろぐ以外に何かCGIはお使いでしょうか。それらは動作していますか？
てがろぐ以外にCGIがない場合は、以下の3行を test.cgi 等のファイル名で保存してUPして、パーミッションを 700 または 705 または 755 にして、ブラウザでアクセスしてみて下さい。
#! /usr/bin/perl
print "Content-type: text/html \n\n";
print "Hello World!";
これで、ブラウザに「Hello Wold!」と表示されるかどうかを確かめてみて下さい。
これでも500エラーが出る場合、改行コードが LF だけになっているかどうかを確かめてみて下さい。
それでも500エラーになる場合は、もっと何か根本的なところに問題がある気がします。
🍏Re:3149◆ああ、なるほど。サポートの回答を転載下さって助かりました。たぶん、以下の方法で解決します。
tegalog.cgiの89行目付近に、以下のような行があります。
この行の先頭にある「 # 」記号を消して、以下のようにして上書き保存して下さい。
この状態で tegalog.cgi をアップロードすると、解決すると思います。（解決できなかった場合は、サーバのエラーログをもし閲覧可能なら、どんなエラーが出ているのかを教えて頂けるとありがたいです。）
参考までに教えて頂けるとありがたいのですが、「CGIモジュール」か「Time::Localモジュール」のファイルを、てがろぐ設置ディレクトリに自力で置かれたりしましたでしょうか？（上記の89行目は、本来は「サーバにインストールされていないモジュールを自力で置いた場合に、それを読み込ませるための対処方法」として用意しているものなのですが。） 自力でそのようなことをしていないにも関わらず、この89行目のような修正が必要になるケースがあるのだろうか……？ とちょっと疑問に思ったもので。
tegalog.cgiの89行目付近に、以下のような行があります。
#use lib '.'; # サーバにインストールされていないモジュールを自力で置いた場合は～(略)
この行の先頭にある「 # 」記号を消して、以下のようにして上書き保存して下さい。
use lib '.';
この状態で tegalog.cgi をアップロードすると、解決すると思います。（解決できなかった場合は、サーバのエラーログをもし閲覧可能なら、どんなエラーが出ているのかを教えて頂けるとありがたいです。）
参考までに教えて頂けるとありがたいのですが、「CGIモジュール」か「Time::Localモジュール」のファイルを、てがろぐ設置ディレクトリに自力で置かれたりしましたでしょうか？（上記の89行目は、本来は「サーバにインストールされていないモジュールを自力で置いた場合に、それを読み込ませるための対処方法」として用意しているものなのですが。） 自力でそのようなことをしていないにも関わらず、この89行目のような修正が必要になるケースがあるのだろうか……？ とちょっと疑問に思ったもので。
🌰Re:3140◆残念ながら、今のところ欠番ができるのを回避する方法はありません。（下書き機能とは関係なく）全投稿を1から採番し直す機能の実装を計画はしていますので、それができれば欠番をなくすことはできます。気長にお待ち頂ければ幸いです。
おなかすいた……。_(┐｢ε:)_
🌰Re:3132◆できるだけ説明なくても直感だけで使えるようなツールを目指したいとは思っているのですけどもね。^^; 機能が増えてくると、なかなか難しいものですね。
🌰Re:3136◆下書きを本番公開するときに、投稿番号を新たに採番するには、公式ヘルプの「使い方：下書き状態を解除して公開する方法」にある図で、水色矢印の方を選択した上で、紫色矢印の部分にチェックを入れた状態（※デフォルトでチェックが入っていますが）で投稿して下さい。すると、最新投稿として先頭に投稿されます。
🌰Re:3132◆できるだけ説明なくても直感だけで使えるようなツールを目指したいとは思っているのですけどもね。^^; 機能が増えてくると、なかなか難しいものですね。
🌰Re:3136◆下書きを本番公開するときに、投稿番号を新たに採番するには、公式ヘルプの「使い方：下書き状態を解除して公開する方法」にある図で、水色矢印の方を選択した上で、紫色矢印の部分にチェックを入れた状態（※デフォルトでチェックが入っていますが）で投稿して下さい。すると、最新投稿として先頭に投稿されます。
ね……、む……、い……。_(┐｢ε:)_
🌰Re:3128◆ご要望をありがとうございます。検討します。現状ではとりあえず「日付の自由入力ボタン」を表示させて、日付入力欄を空っぽにしてから投稿すると、投稿した瞬間の日時で投稿できますのでご活用頂ければ幸いです。
🌰Re:3129◆WYSIWYG編集(＝見たままに編集できる機能)を実装しようとすると、読み込むファイル数も増えて重たくなる上に実装が大変だと思いますので、てがろぐでは（将来的にも）実装はしない考えでおります。ご期待に添えず申し訳ありませんが、軽さ第一で考えておりますのでご理解頂ければ幸いです。。既存のライブラリを読み込むことでもっと簡単に実装できる可能性もありますが、そうすると記法の仕様を修正しないといけないでしょうし、読み込むファイルが増えて重たくなる点には変わりないでしょうから。◆リスト機能は、もう間もなくβ版としてご提供できる予定です。
🌰Re:3130◆非公開、下げる、鍵付きでの絞り込み機能は既にありますので、公式ヘルプの「下書き、鍵付き、下げる投稿だけを探す検索コマンド」をご覧下さい。検索コマンドを使わなくても、「 draft 」や「 lock 」等とだけ検索してもヒットします（※検索コマンドを使わない場合は、余分な投稿も同時にヒットしてしまう可能性はありますが）。絞り込み検索窓に自力で入力しなくても、例えば「下書き」投稿のカテゴリID欄に表示されている「下書き」というリンクをクリックすることでも、下書き投稿の絞り込み検索ができます。（「下げる」や「鍵付き」も同様です。）ご活用頂ければ幸いです。
🌰Re:3128◆ご要望をありがとうございます。検討します。現状ではとりあえず「日付の自由入力ボタン」を表示させて、日付入力欄を空っぽにしてから投稿すると、投稿した瞬間の日時で投稿できますのでご活用頂ければ幸いです。
🌰Re:3129◆WYSIWYG編集(＝見たままに編集できる機能)を実装しようとすると、読み込むファイル数も増えて重たくなる上に実装が大変だと思いますので、てがろぐでは（将来的にも）実装はしない考えでおります。ご期待に添えず申し訳ありませんが、軽さ第一で考えておりますのでご理解頂ければ幸いです。。既存のライブラリを読み込むことでもっと簡単に実装できる可能性もありますが、そうすると記法の仕様を修正しないといけないでしょうし、読み込むファイルが増えて重たくなる点には変わりないでしょうから。◆リスト機能は、もう間もなくβ版としてご提供できる予定です。
🌰Re:3130◆非公開、下げる、鍵付きでの絞り込み機能は既にありますので、公式ヘルプの「下書き、鍵付き、下げる投稿だけを探す検索コマンド」をご覧下さい。検索コマンドを使わなくても、「 draft 」や「 lock 」等とだけ検索してもヒットします（※検索コマンドを使わない場合は、余分な投稿も同時にヒットしてしまう可能性はありますが）。絞り込み検索窓に自力で入力しなくても、例えば「下書き」投稿のカテゴリID欄に表示されている「下書き」というリンクをクリックすることでも、下書き投稿の絞り込み検索ができます。（「下げる」や「鍵付き」も同様です。）ご活用頂ければ幸いです。
