PEAK XOOPS - Warning メッセージについて 
Warning メッセージについて
- You cannot open a new topic into this forum
- Guests cannot post into this forum
Previous post
-
Next post
|
Parent
-
Children.1
|
Posted on 2006/3/6 10:56
sarah
Posts: 17
Posts: 17
GIJOE様
お世話になっております。
現在、デバックモードにすると以下のエラーが出ます。
Quote:
protector.php のソースを確認してみたのですが、私のスキルでは原因がわかりません。
このエラーが原因なのか、他の要因のせいなのか、まだ切り分けができていませんが、現在ログインできない状態になっています。
また、以下のエラーも合わせて発生しております。
Quote:
原因、どのような対応を行えばよいのかアドバイスいただけないでしょうか？
お忙しいところ恐れ入りますが、どうぞよろしくお願いいたします。
--- 環境 ---
SERVER : Apache
PHP : 4.3.9
MySQL : 4.1.12
XOOPS : XOOPS 2.0.13a JP
Protector：2.54
piCal：084b
------
経緯について簡単に説明します。
レンタルサーバ側でMySQL のバージョンアップがあり、その後、xoopsが正常動作しなくなりました。
MySQL 4.0.x から MySQL 4.1.x へのバージョンアップでしたが、xoops公式フォーラムでのGIJOEさんの「MySQL 4.1.xでもxoopsは動作する」との書き込みによりMySQL 4.1.x でも問題はないことがわかりましたので、原因を調査する為にデバックモードにしてみたところ上述のエラーが出ていたということになります。
xoops導入後、問題が発生したことはなかった為、MySQL 4.0.xの時点では一度もデバックモードにしたことはありませんでしたので、以前から出ていたエラーなのか、バージョンアップによって発生したエラーなのかはわかりません。
お世話になっております。
現在、デバックモードにすると以下のエラーが出ます。
Quote:
Warning [PHP]: Empty regular expression in file modules/protector/class/protector.php line 543
protector.php のソースを確認してみたのですが、私のスキルでは原因がわかりません。
このエラーが原因なのか、他の要因のせいなのか、まだ切り分けができていませんが、現在ログインできない状態になっています。
また、以下のエラーも合わせて発生しております。
Quote:
Warning: fopen(/xxxxxxxxxx/xoops/cache/piCal_minical_ex_c5f8ad_japanese_200603): failed to open stream: Permission denied in /xxxxxxxxxx/xoops/modules/piCal/blocks/pical_minical_ex.php on line 143
Warning: fwrite(): supplied argument is not a valid stream resource in /xxxxxxxxxx/xoops/modules/piCal/blocks/pical_minical_ex.php on line 144
Warning: fwrite(): supplied argument is not a valid stream resource in /xxxxxxxxxx/xoops/modules/piCal/blocks/pical_minical_ex.php on line 145
Warning: fwrite(): supplied argument is not a valid stream resource in /xxxxxxxxxx/xoops/modules/piCal/blocks/pical_minical_ex.php on line 146
Warning: fclose(): supplied argument is not a valid stream resource in /xxxxxxxxxx/xoops/modules/piCal/blocks/pical_minical_ex.php on line 147
原因、どのような対応を行えばよいのかアドバイスいただけないでしょうか？
お忙しいところ恐れ入りますが、どうぞよろしくお願いいたします。
--- 環境 ---
SERVER : Apache
PHP : 4.3.9
MySQL : 4.1.12
XOOPS : XOOPS 2.0.13a JP
Protector：2.54
piCal：084b
------
経緯について簡単に説明します。
レンタルサーバ側でMySQL のバージョンアップがあり、その後、xoopsが正常動作しなくなりました。
MySQL 4.0.x から MySQL 4.1.x へのバージョンアップでしたが、xoops公式フォーラムでのGIJOEさんの「MySQL 4.1.xでもxoopsは動作する」との書き込みによりMySQL 4.1.x でも問題はないことがわかりましたので、原因を調査する為にデバックモードにしてみたところ上述のエラーが出ていたということになります。
xoops導入後、問題が発生したことはなかった為、MySQL 4.0.xの時点では一度もデバックモードにしたことはありませんでしたので、以前から出ていたエラーなのか、バージョンアップによって発生したエラーなのかはわかりません。
Votes:3
Average:6.67
GIJOE
Posts: 4110
Posts: 4110
sarah さん、こんにちは。
いろいろ突っ込みどころはあるのですが、まずここから。
Quote:それは、そのレンタルサーバへの問い合わせ事項でしょう。
Quote:ちゃんと読みましたか？
MySQL 4.1.x で動作させるための条件がいろいろと書いてあったはずですが。
Quote:症状としては、configテーブルが読み出せてないように見えます。他のエラーや、サイトが表示されないのも、似たような理由でしょう。
とりあえず、データベースのフルダンプ・リストアもなしに、MySQL 4.0.x から 4.1.x にバージョンを上げてしまった時の症状にそっくりです。4.0と4.1では、バイナリに互換性はないので、かならず4.0の時点でダンプして、4.1に上げてからリストアする必要があります。
いずれにせよ、ProtectorやpiCalがどうこう、というレベルの問題ではありません。
最初にも書きましたが、まずはレンタルサーバに問い合わせるケースです。
いろいろ突っ込みどころはあるのですが、まずここから。
Quote:
レンタルサーバ側でMySQL のバージョンアップがあり、その後、xoopsが正常動作しなくなりました。
Quote:
MySQL 4.0.x から MySQL 4.1.x へのバージョンアップでしたが、xoops公式フォーラムでのGIJOEさんの「MySQL 4.1.xでもxoopsは動作する」との書き込みによりMySQL 4.1.x でも問題はないことがわかりましたので、原因を調査する為にデバックモードにしてみたところ上述のエラーが出ていたということになります。
MySQL 4.1.x で動作させるための条件がいろいろと書いてあったはずですが。
Quote:
現在、デバックモードにすると以下のエラーが出ます。
Quote:Warning [PHP]: Empty regular expression in file modules/protector/class/protector.php line 543
とりあえず、データベースのフルダンプ・リストアもなしに、MySQL 4.0.x から 4.1.x にバージョンを上げてしまった時の症状にそっくりです。4.0と4.1では、バイナリに互換性はないので、かならず4.0の時点でダンプして、4.1に上げてからリストアする必要があります。
いずれにせよ、ProtectorやpiCalがどうこう、というレベルの問題ではありません。
最初にも書きましたが、まずはレンタルサーバに問い合わせるケースです。
Votes:11
Average:8.18
sarah
Posts: 17
Posts: 17
GIJOEさん、返答ありがとうございます。
Quote:レンタルサーバ側へも問い合わせておりますが、他のMySQLを使用したシステムにはまったく問題がないようで、xoops側の問題ではないかと言われた為、私の方でもいろいろ調べている状況でした。
Quote:こちらの書き込みから、問題は 4.1の「自動エンコード変換」 と判断し、
/class/database/mysqldatabase.php に
$connect_chara = mysql_query("SET NAMES ujis;", $this->conn); の記述は行っています。
いずれにしても
Quote:とのことですので、数日分のデータは捨てることになりますが、幸い4.0の時点で数日前にエクスポートしていたsqlファイルがあるので、それでリストアを行います。
お忙しいところ、お手を煩わせてしまい申し訳ありませんでした。
Quote:
それは、そのレンタルサーバへの問い合わせ事項でしょう。
Quote:
ちゃんと読みましたか？
MySQL 4.1.x で動作させるための条件がいろいろと書いてあったはずですが。
/class/database/mysqldatabase.php に
$connect_chara = mysql_query("SET NAMES ujis;", $this->conn); の記述は行っています。
いずれにしても
Quote:
4.0と4.1では、バイナリに互換性はないので、かならず4.0の時点でダンプして、4.1に上げてからリストアする必要があります。
お忙しいところ、お手を煩わせてしまい申し訳ありませんでした。
Votes:7
Average:0.00
GIJOE
Posts: 4110
Posts: 4110
Quote:他ではまったく問題がない、というのは常套句ですよ 
明らかに、MySQLのバージョンアップでおかしくなっているのですから、レンタルサーバへのクレーム事項です。
Quote:それはちゃんと読んでいないと思いますよ。
少なくとも私は一度も、ujis をセットすることは勧めていません。
というのも、それだとMySQLの自動変換が出しゃばるケースがあるからです。
自動変換機能そのものを潰すために、SET NAMES binary` としておくのが、とりあえず無難だと常に書いてきたはずです。
サイト内検索などで、バイト境界の誤認識はあり得ますが、文字化けほど致命的ではないでしょう。
レンタルサーバ側へも問い合わせておりますが、他のMySQLを使用したシステムにはまったく問題がないようで、xoops側の問題ではないかと言われた為、私の方でもいろいろ調べている状況でした。
明らかに、MySQLのバージョンアップでおかしくなっているのですから、レンタルサーバへのクレーム事項です。
Quote:
Quote:こちらの書き込みから、問題は 4.1の「自動エンコード変換」 と判断し、ちゃんと読みましたか？
MySQL 4.1.x で動作させるための条件がいろいろと書いてあったはずですが。
/class/database/mysqldatabase.php に
$connect_chara = mysql_query("SET NAMES ujis;", $this->conn); の記述は行っています。
少なくとも私は一度も、ujis をセットすることは勧めていません。
というのも、それだとMySQLの自動変換が出しゃばるケースがあるからです。
自動変換機能そのものを潰すために、SET NAMES binary` としておくのが、とりあえず無難だと常に書いてきたはずです。
サイト内検索などで、バイト境界の誤認識はあり得ますが、文字化けほど致命的ではないでしょう。
Votes:8
Average:0.00
sarah
Posts: 17
Posts: 17
これはまったくの余談なのですが、、、。
Quote:
実は私自身、同じサーバにphpBBとphp-Nuke（どちらも文字コードはxoopsと同じEUC）を設置しているのですが、確認してみたところ、どちらも問題なく動作しました。（MySQLバージョンアップ後、特に何も対応は行っていません。）
xoopsでは、他のシステムではおこなっていないような何か特別な処理でもおこなっているのでしょうか？
特にphp-Nukeが動作するのにxoopsが動作しないというのがどうにも腑に落ちません。
Quote:
Quote:レンタルサーバ側へも問い合わせておりますが、他のMySQLを使用したシステムにはまったく問題がないようで、xoops側の問題ではないかと言われた為、私の方でもいろいろ調べている状況でした。
他ではまったく問題がない、というのは常套句ですよ
明らかに、MySQLのバージョンアップでおかしくなっているのですから、レンタルサーバへのクレーム事項です。
実は私自身、同じサーバにphpBBとphp-Nuke（どちらも文字コードはxoopsと同じEUC）を設置しているのですが、確認してみたところ、どちらも問題なく動作しました。（MySQLバージョンアップ後、特に何も対応は行っていません。）
xoopsでは、他のシステムではおこなっていないような何か特別な処理でもおこなっているのでしょうか？
特にphp-Nukeが動作するのにxoopsが動作しないというのがどうにも腑に落ちません。
Votes:8
Average:8.75
GIJOE
Posts: 4110
Posts: 4110
余談はともかく、その後、どうなったのでしょうか？
質問したなら、その回答に対して、何をしてどうなったかを報告しないと、今後の回答もつかなくなると思いますよ。
> 特にphp-Nukeが動作するのにxoopsが動作しないというのがどうにも腑に落ちません。
そのXOOPSがおかしければ動作しなくても不思議はないでしょう。
SET NAMES を入れる、というのもHackになるわけですが、その場所が間違っていない保証だってありません。
いずれにせよ、詳細な情報が与えられない限り、外部からは予想で書くしかないわけです。
そういう困難は想像できませんか？
質問したなら、その回答に対して、何をしてどうなったかを報告しないと、今後の回答もつかなくなると思いますよ。
> 特にphp-Nukeが動作するのにxoopsが動作しないというのがどうにも腑に落ちません。
そのXOOPSがおかしければ動作しなくても不思議はないでしょう。
SET NAMES を入れる、というのもHackになるわけですが、その場所が間違っていない保証だってありません。
いずれにせよ、詳細な情報が与えられない限り、外部からは予想で書くしかないわけです。
そういう困難は想像できませんか？
Votes:9
Average:0.00
sarah
Posts: 17
Posts: 17
言葉が足りず、申し訳ありませんでした。
もちろん結果についてはご報告するつもりですが、現在新たな問題が発生し、何も進捗していない状況です。
リストアを行いたいのですが、phpMyAdmin2.7.0-beta1 でEUCが選択できないため、そのままリストアを行っても文字化けが発生するので何も出来ない状態です。
現在、レンタルサーバ側に問い合わせ中です。
phpMyAdminの問題が解決し次第、リストアを行い動作確認をするつもりです。
Quote:MySQLのバージョンアップ後に行った対応は以下の１点のみです。
/class/database/mysqldatabase.php の以下の部分に赤字の記述を行いました。
いずれにしても、phpMyAdminの問題解決を待ってリストアを行います。
結果についてはまたご報告いたします。
もちろん結果についてはご報告するつもりですが、現在新たな問題が発生し、何も進捗していない状況です。
リストアを行いたいのですが、phpMyAdmin2.7.0-beta1 でEUCが選択できないため、そのままリストアを行っても文字化けが発生するので何も出来ない状態です。
現在、レンタルサーバ側に問い合わせ中です。
phpMyAdminの問題が解決し次第、リストアを行い動作確認をするつもりです。
Quote:
そのXOOPSがおかしければ動作しなくても不思議はないでしょう。
SET NAMES を入れる、というのもHackになるわけですが、その場所が間違っていない保証だってありません。
/class/database/mysqldatabase.php の以下の部分に赤字の記述を行いました。
function connect($selectdb = true)
{
if (XOOPS_DB_PCONNECT == 1) {
$this->conn = @mysql_pconnect(XOOPS_DB_HOST, XOOPS_DB_USER, XOOPS_DB_PASS);
} else {
$this->conn = @mysql_connect(XOOPS_DB_HOST, XOOPS_DB_USER, XOOPS_DB_PASS);
}
if (!$this->conn) {
$this->logger->addQuery('', $this->error(), $this->errno());
return false;
}
if($selectdb != false){
if (!mysql_select_db(XOOPS_DB_NAME)) {
$this->logger->addQuery('', $this->error(), $this->errno());
return false;
}
}
$connect_chara = mysql_query("SET NAMES binary;", $this->conn);
return true;
}いずれにしても、phpMyAdminの問題解決を待ってリストアを行います。
結果についてはまたご報告いたします。
Votes:15
Average:5.33
GIJOE
Posts: 4110
Posts: 4110
とりあえず、binaryの後のコロンは余計だと思いますよ。
MySQL 4.1あたりだと大丈夫かもしれませんが、少なくとも一部のバージョンのMySQLとの組み合わせでは、それだけでエラーになります。
そもそも、phpMyAdminみたいなツールしか使えないんでしょうか？
mysqlコマンドラインで流し込むのが一番の正攻法で確実だと思うのですが。
sshログインは許可してないホスティングサービスなのかな？
MySQL 4.1あたりだと大丈夫かもしれませんが、少なくとも一部のバージョンのMySQLとの組み合わせでは、それだけでエラーになります。
そもそも、phpMyAdminみたいなツールしか使えないんでしょうか？
mysqlコマンドラインで流し込むのが一番の正攻法で確実だと思うのですが。
sshログインは許可してないホスティングサービスなのかな？
Votes:1
Average:0.00
sarah
Posts: 17
Posts: 17
サーバ側で用意されているphpMyAdminではEUCが使用できず、ssh接続もNGのサーバで、ほとほと困り果てておりましたが、サーバ側でphpMyAdminが用意されていても、ユーザー側で個々にphpMyAdminをインストールできるということを知り、MySQL 4.1でもEUCを操作できるバージョン（2.5）のphpMyAdminをインストールし、リストアを行ったところ、MySQL 4.1でも正常に動作するようになりました。
GIJOEさん、いろいろとアドバイスをいただきましてありがとうございました。ここまで長かった〜。
ただ、１つのテーブルでリストア中にエラーが出ました。
これは、ニュースモジュールで使用しているテーブルではないかと思うのですが、調べたところ、どうやらMySQL 4.1系ではDb charactersetが binary だと（インストールできないなど）エラーになるモジュールがいくつかあるようです。（newsやnewbbなど）
newbbは使用していないし、newsもたいして使っていなかったので捨ててもよいのですが、恥ずかしながら勉強不足の為、エラーの原因がわからないので、Db charactersetがbinaryのまま使っていても他のモジュールには影響がないのかどうか判断が出来ません。
MySQL 4.1系でxoopsを使用するには、やはりDb characterset は ujisにしておくべきなのでしょうか？
GIJOEさん、いろいろとアドバイスをいただきましてありがとうございました。ここまで長かった〜。
ただ、１つのテーブルでリストア中にエラーが出ました。
CREATE TABLE `xoops_stories` (
`storyid` int( 8 ) unsigned NOT NULL AUTO_INCREMENT ,
`uid` int( 5 ) unsigned NOT NULL default '0',
`title` varchar( 255 ) NOT NULL default '',
`created` int( 10 ) unsigned NOT NULL default '0',
`published` int( 10 ) unsigned NOT NULL default '0',
`expired` int( 10 ) unsigned NOT NULL default '0',
`hostname` varchar( 20 ) NOT NULL default '',
`nohtml` tinyint( 1 ) NOT NULL default '0',
`nosmiley` tinyint( 1 ) NOT NULL default '0',
`hometext` text NOT NULL ,
`bodytext` text NOT NULL ,
`counter` int( 8 ) unsigned NOT NULL default '0',
`topicid` smallint( 4 ) unsigned NOT NULL default '1',
`ihome` tinyint( 1 ) NOT NULL default '0',
`notifypub` tinyint( 1 ) NOT NULL default '0',
`story_type` varchar( 5 ) NOT NULL default '',
`topicdisplay` tinyint( 1 ) NOT NULL default '0',
`topicalign` char( 1 ) NOT NULL default 'R',
`comments` smallint( 5 ) unsigned NOT NULL default '0',
`rating` double( 6, 4 ) NOT NULL default '0.0000',
`votes` int( 11 ) unsigned NOT NULL default '0',
`keywords` varchar( 255 ) NOT NULL default '',
`description` varchar( 255 ) NOT NULL default '',
PRIMARY KEY ( `storyid` ) ,
KEY `idxstoriestopic` ( `topicid` ) ,
KEY `ihome` ( `ihome` ) ,
KEY `uid` ( `uid` ) ,
KEY `published_ihome` ( `published` , `ihome` ) ,
KEY `title` ( `title` ( 40 ) ) ,
KEY `created` ( `created` ) ,
FULLTEXT KEY `search` ( `title` , `hometext` , `bodytext` )
) TYPE = MYISAM
#1283 - Column 'title' cannot be part of FULLTEXT index
newbbは使用していないし、newsもたいして使っていなかったので捨ててもよいのですが、恥ずかしながら勉強不足の為、エラーの原因がわからないので、Db charactersetがbinaryのまま使っていても他のモジュールには影響がないのかどうか判断が出来ません。
MySQL 4.1系でxoopsを使用するには、やはりDb characterset は ujisにしておくべきなのでしょうか？
Votes:13
Average:6.92
GIJOE
Posts: 4110
Posts: 4110
Quote:説明が悪かったでしょうか。
DBのキャラクターセットをbinaryにする、なんて書いていませんよ。
DB側はujisじゃなきゃ駄目です。そうじゃないと、格納サイズ問題が出てしまいます。
私が書いたのは、クライアント側をbinaryにすることで、MySQL4.1のエンコーディング変換を無効化する、といういわば「裏技」です。
これは、ニュースモジュールで使用しているテーブルではないかと思うのですが、調べたところ、どうやらMySQL 4.1系ではDb charactersetが binary だと（インストールできないなど）エラーになるモジュールがいくつかあるようです。（newsやnewbbなど）
newbbは使用していないし、 newsもたいして使っていなかったので捨ててもよいのですが、恥ずかしながら勉強不足の為、エラーの原因がわからないので、Db charactersetがbinaryのまま使っていても他のモジュールには影響がないのかどうか判断が出来ません。
DBのキャラクターセットをbinaryにする、なんて書いていませんよ。
DB側はujisじゃなきゃ駄目です。そうじゃないと、格納サイズ問題が出てしまいます。
私が書いたのは、クライアント側をbinaryにすることで、MySQL4.1のエンコーディング変換を無効化する、といういわば「裏技」です。
Votes:16
Average:3.75
sarah
Posts: 17
Posts: 17
いえいえ、こちらこそ説明が足りなかったようで申し訳ありません。
ホスティングサービス側で用意されているDBのキャラクターセットがbinaryだったのです。
やはりDBのキャラクターセットはujisでないとダメなんですね。
作り直してもらうようお願いしてみます。（自分で操作できないのは不便ですね）
Quote:はい。この件は、これまでのGIJOEさんの説明で十分理解できました。
たびたびすみませんでした。
ありがとうございました。
ホスティングサービス側で用意されているDBのキャラクターセットがbinaryだったのです。
やはりDBのキャラクターセットはujisでないとダメなんですね。
作り直してもらうようお願いしてみます。（自分で操作できないのは不便ですね）
Quote:
私が書いたのは、クライアント側をbinaryにすることで、MySQL4.1のエンコーディング変換を無効化する、といういわば「裏技」です。
たびたびすみませんでした。
ありがとうございました。
Votes:15
Average:4.67
sarah
Posts: 17
Posts: 17
GIJOEさん、お世話になっております。
たびたび申し訳ありません。
先日、別件の不具合調査の為、PHPデバグモードにしたところ、このスレッドの最初に投稿したメッセージと同じような以下のメッセージが出ているのに気づきました。（別件の不具合というのは解決済みなので、このメッセージとは関係ありませんでした。）
このWarningはどういった意味なのでしょうか？
現在、xoopsの動作は（モジュール等も含めて）特に問題はなさそうに思えますが、このまま使いつづけて大丈夫なものなのでしょうか。
お忙しいところ恐れ入りますが、ご教授いただけないでしょうか？
よろしくお願い致します。
--- 環境 ---
SERVER : Apache/1.3.34 (Unix)
PHP : 5.0.4
MySQL : 4.1.16-log
XOOPS : XOOPS 2.0.13a JP
Protector : 2.54
*** 追記 ***
投稿した後、ハタと気づきました。ひょっとしてProtectorをバージョンアップすればOKな話でしょうか？
Quote:
家に帰ったらとりあえず、Protectorをバージョンアップしてみます。
*** 追記2 ***
2.56にバージョンアップしてみましたが、Warningメッセージは消えませんでした。
というわけで、引き続きよろしくお願いします。
たびたび申し訳ありません。
先日、別件の不具合調査の為、PHPデバグモードにしたところ、このスレッドの最初に投稿したメッセージと同じような以下のメッセージが出ているのに気づきました。（別件の不具合というのは解決済みなので、このメッセージとは関係ありませんでした。）
Warning [PHP]: preg_match() [function.preg-match]: Empty regular expression in file /パス名/modules/protector/class/protector.php line 543このWarningはどういった意味なのでしょうか？
現在、xoopsの動作は（モジュール等も含めて）特に問題はなさそうに思えますが、このまま使いつづけて大丈夫なものなのでしょうか。
お忙しいところ恐れ入りますが、ご教授いただけないでしょうか？
よろしくお願い致します。
--- 環境 ---
SERVER : Apache/1.3.34 (Unix)
PHP : 5.0.4
MySQL : 4.1.16-log
XOOPS : XOOPS 2.0.13a JP
Protector : 2.54
*** 追記 ***
投稿した後、ハタと気づきました。ひょっとしてProtectorをバージョンアップすればOKな話でしょうか？
Quote:
変更履歴
2.56 (2006/03/30)
- コンフィグが取れないときのエラー処理を強制終了に変更した
家に帰ったらとりあえず、Protectorをバージョンアップしてみます。
*** 追記2 ***
2.56にバージョンアップしてみましたが、Warningメッセージは消えませんでした。
というわけで、引き続きよろしくお願いします。
Votes:10
Average:9.00
GIJOE
Posts: 4110
Posts: 4110
単にProtectorの一般設定の「拒否しない User-Agent」を空にしているだけでしょう。
そのままでもまったく問題ありませんが、あえて消したわけでないのなら、
/(msnbot|Googlebot|Yahoo! Slurp)/i
などと指定してください。
そのままでもまったく問題ありませんが、あえて消したわけでないのなら、
/(msnbot|Googlebot|Yahoo! Slurp)/i
などと指定してください。
Votes:27
Average:7.41
Previous post
-
Next post
|
Parent
-
No child
|
Posted on 2006/6/21 10:06
sarah
Posts: 17
Posts: 17
Quote:確かにそのとおりでした。
/(msnbot|Googlebot|Yahoo! Slurp)/i
を指定してWarningが消えることを確認しました。
どうもありがとうございました。
単にProtectorの一般設定の「拒否しない User-Agent」を空にしているだけでしょう。
/(msnbot|Googlebot|Yahoo! Slurp)/i
を指定してWarningが消えることを確認しました。
どうもありがとうございました。
Votes:7
Average:8.57
Login