にしし らぼらとりー

「suEXECで使えている人が居る」場合には「suEXEC」だと案内した上で、補足的にsuEXECではない方のパーミッションで動いている人も居るので、もしうまくいかなかったら云々……みたいに書いておけば良いか。

うーむ。アンケートを採れば、たちどころに各サーバの状況が判明するに違いない！ ……みたいに考えていたのだが、そうも言えない結果が出てきて、どうしたものか。
リトルサーバー（回答者13名）、スターサーバー（回答者9名）、XREA（回答者4名）で、決断しにくい感じに報告が割れている……。

■リトルサーバー13名（ミニプラン5名、ワードプラン5名、リトルプラン2名、ライトという回答1名）のうち、パーミッションの設定は、
●suEXEC（700等）が 5名
●一般（755等）が 5名（内1名はサポートに依頼したら755になったと）
●パーミッションの設定記憶がない 2名
※残りの1名は「suEXECのでは動かなかった」で 705にしたとのことだが、この方は「WordPress配下のディレクトリに置いた」とのことなので、その辺の問題があったっぽい。
suEXECと一般とで見事に半々なので、実際のところどうなのかの判断がしにくい。suEXECで動いている人がいるのだから、suEXECで良いとは思うけども。

■スターサーバー 9名（エコノミー2名、ライト1名、ハイスピード2名、無料サーバ4名）のうち、パーミッションの設定は、
●suEXEC（700等）が 3名
●一般（755等）が 5名
●一般（705等）が 1名
多数決だと「一般」になるけども、まあ「suEXECでいけている」ならsuEXECということで良いんだと思うのだが。たぶん。無料サーバ（スタードメインに付いてくる無料サーバ）の4名に限っても、755が2名、705が1名、700が1名で割れている。どれでもいけるのか……？（プログラムはどっちでも良いとしても、画像保存用ディレクトリのパーミッションは「どっちでも良い」ということはないのではないかと思うのだけども。どうだろう？）

■XREA 4名（フリー 4名）のうち、パーミッションの設定は、
●suEXEC（700等）が 2名
●一般（755等）が 2名
4人居て、見事に半々。
内1名は、$howtogetpath の値が 1 でないとダメだったとの報告。（残りは変更なし）

まあ、「suEXECで動かせている」という回答が存在するなら「suEXECということにする」という決断で良いと思ってはいるのだけども、リトルサーバーの報告が迷う。自由入力欄に「サポートに依頼したら755になった」という感じのことが書いてあった点で。プランとか収容サーバによって仕様が異なる可能性もあるかもしれない。

あと、新規にセットアップする場合、とりあえずWordPressの配下にあるディレクトリは避けてくれ、という話も書いておいた方が良いかもしれない。WordPressの配下にあるディレクトリで動かせないわけではないと思うが、何の工夫もなくそのままアップロードしたのではダメっぽいから。

mixhostは、$howtogetpath を 0 に変えないといけない点では確定みたいな結果だった。

てがろぐの設定のバックアップは、データファイルと同様にbackupディレクトリに自動出力するよりも、ファイルとして（ローカルに）エクスポートできる機能の方が便利かもしれない。インポート機能もあるとなお良さそう。インポート機能があれば、単にバックアップの復元だけでなくて、スキンに合わせた設定の上書き用途にも使えるかもしれない。いや、全項目を一括して上書きする仕様だったら（バックアップならそれで充分だ）使えないけども。

$howtogetpath変数って、「滅多に使われるケースはないだろうけども念のために用意しておくか」みたいな感じで用意しておいたのだが、そこそこ使われている（使わないとうまく動かない）みたいなことになっているような気がしてきた。

まじか……。私が契約しているさくらインターネットのサーバだと、既定のドキュメントルート用ディレクトリ以外をドキュメントルートにしたドメインがあっても、ドキュメントルートは（そのドメイン用のルートが）正しく取得できているのだが、同じさくらインターネットのサーバでもそうではないサーバがあるのか……。（>>2279 , 試験場No.3245）

Perlがコアモジュール群からCGIモジュール(CGI.pm)を外したのは良いとしても（良くないが）、明確な1つの代わりを用意せずに外してしまうのは乱暴なのでは……。てがろぐのソースではCGIモジュールの機能はほんの一部しか使っていないので、CGIモジュールが不要なように書き換えることも可能ではあるのだが、面倒くさい。_(┐｢ε:)_ いや、最初の最初に「てがろぐVer.1」を開発しようとする段階で「CGIモジュールは使わない」と決めていたら、もうちょっとうまい感じにできたとは思うのだけども。もはやCGIモジュールが使えることを前提に山ほどソースを書いている今更修正するのは気力面でしんどい気がする。たぶん。tegalog.cgiの中だけでも429回使っているし……。

mixhostの新サーバにPerlモジュールがさっぱり入っていないのは、もはやフリーCGIとか使わせる気がないということなのだろうか。Perlは使えるし、Perlモジュールを自力でインストールする機能も提供されているので、Perl自体を拒否しているわけではないけども。「自作のPerlで何かをしたい人は自由にすれば良いが、一般公開されているフリーCGI的なものを使うことはもはや考慮していない」みたいな？ とりあえず、mixhostの新サーバ向けの対策はFAQとかに書いておいた方が良さそうだ。