ユーザから、コース内のいくつかのリソース（ウェブページやテキストページなど）にある文字列を検索することが可能か質問されて、確かにフォーラム内のテキストサーチはあるけど、リソースや、課題の文章などでははたしてどうすれば検索できる？ということになりました。
長い間Moodle使っているのに考えたことがありませんでした。
それで、調べてみたところ、グローバルサーチという機能が1.9からついたんですね？
http://docs.moodle.org/en/Global_Search
管理者設定（実験用）で、グローバルサーチも有効にし、コース内にグローバルサーチブロックを設置し、インデックスの作成を行ってみました。
確かに、単語などで検索できているような感じはするのですが、日本語の文字列ではぜんぜん検索結果が得られません。
PHPのバージョンにも確認しましたが、5.2.9なので、「PHP4に互換性がありません」という問題はないということかと思います。
このグローバルサーチを使われている方、あるいは、こうすれば、コース内のいろいろな場所の文字列を、簡単に検索できる方法などご存じの方ご教示ください。
まだ何も試していませんが，予想としてはインデックスのキーを切り出すことができないのではないでしょうか？
英文でしたら一つ以上の半角空白で単語が区切られています．したがって事前にインデックスのデータベースを作成する際に，キーを容易に見つけ出すことができます．日本語の文書では単語の切り出しが難しいですよね．namazuでも別プログラム（kakashi，でしたか）を使って切り出しを行いますよね．
それに対してフォーラムの検索の場合は検索用のキーを入力されたら，それをキーとしてフォーラムのデータベースをサーチします．
ポイントは事前にデータベースを作成できるかどうか．多分，ラテン系バリバリにコーディングされているのではないでしょうか？ 'a'とか'the'とかは無視するなどなど．
データベースをちょっと調べてみて，ソースの文字化けする箇所をチョチョっとパッチを当てれば文字化けは収まるだろう．インデックスの作成に関しても日本語ルールを追加（ひらがな，カタカナ，漢字，ANKで区切るなど）すれば少しはマシになるだろう．
当初はそのように軽く考えていたのですが，どうもそこまで甘くないらしい．
検索のインタフェースはsearch/query.phpです．
検索を行うための$sqというインスタンスのクラスは，search/querylib.phpの中で定義されているclass SearchQuery です．ここまでは調べました．コンストラクタの中身を見ると，
$index_path = SEARCH_INDEX_PATH;
try {
$this->index = new Zend_Search_Lucene($index_path, false);
} catch(Exception $e) {
$this->validindex = false;
return;
}
こうあります．Zend...どうやらZend社のライブラリを使っているようですね．少し検索して調べました．
-
Zend_Search_Luceneは日本語では使い物にならなかった話
（http://nonn-et-twk.net/twk/node/153） -
Zend_Search_Lucene用日本語解析器
（http://nonn-et-twk.net/twk/zend-search-lucene-analyzer） -
ライブラリーとして使うZend Framework - PHPから日本語全文検索（形態素解析篇）
（http://nonn-et-twk.net/twk/php-lucene-japanese-search） -
Zend_Search_Luceneによる単純な検索処理
（http://www.oplabo.jp/article/46）
上の３つは同じ方のblogです．日付順というわけではありません．
このライブラリがPHPに付属する（PHPのバージョンに依存する）ものなのか，PHPソースで提供されているのかはわかりませんが，多分，前者じゃないでしょうか．（それすら調べていない状態での報告です）．
どうも，インデックス作成時に著者などの情報が既に化けているような気がします．データベースの名前が分かれば確認できるのですが...
search/Zend以下に沢山のphpソースがあります．
ここを解析しないと，データベースの日本語が文字化けする問題や，インデックスに日本語が含まれない問題などは改善しないのかも知れません．
少なくともデータはUTF-8だよ！と教えてあげる部分さえハッキリすれば，第一のステップはクリアですね．
UTF-8である，という初期設定はきちんと行われているようです．
search/indexer.phpの中で，
Zend_Search_Lucene_Analysis_Analyzer::setDefault(new Zend_Search_Lucene_Analysis_Analyzer_Common_Utf8_CaseInsensitive());
$index = new Zend_Search_Lucene($index_path, true);
もしインデックス作成時と検索時に共にこのコードが実行されているならば．
次のステップは，
http://nonn-et-twk.net/twk/node/153
のサンプルにあるように，Zend_Search_Lucene_Fieldなにがし等に文字列エンコーディングがUTF-8だと教えてあげる必要が最低限ありますね．
ほんの少しだけ改善しました．著者名だけは文字化けしません．でも，著者名をフルネームでインデックス化するのは仕様としておかしいですね．ユーザIDをインデックスファイルに保存し，表示時に名前をデータベースから読み出さないと，インデックス作成時と現在とで名前を変えている恐れがあります．
なお，以下の修正は”理屈を理解して行ったもの”ではなく，参考にしたWebページを単に真似しただけです．
search/documents/document.phpのclass SearchDocument, function __construct()
// caches the context of this information. i-e, the context in which this information
// is being produced/attached. Speeds up the "check for access" process as context in
// which the information resides (a course, a module, a block, the site) is stable.
// (Shirai135): ここから修正
// $this->addField(Zend_Search_Lucene_Field::UnIndexed('context_id', $doc->contextid));
$this->addField(Zend_Search_Lucene_Field::UnIndexed('context_id', $doc->contextid, 'UTF-8'));
// (Shirai135): ここまで修正
//data for document
// (Shirai135): ここから修正
// $this->addField(Zend_Search_Lucene_Field::Text('title', $doc->title));
$this->addField(Zend_Search_Lucene_Field::Text('title', $doc->title, 'UTF-8'));
// $this->addField(Zend_Search_Lucene_Field::Text('author', $doc->author));
$this->addField(Zend_Search_Lucene_Field::Text('author', $doc->author, 'UTF-8'));
// (Shirai135): ここまで修正
$this->addField(Zend_Search_Lucene_Field::UnStored('contents', $doc->contents));
// (Shirai135): ここから修正
// $this->addField(Zend_Search_Lucene_Field::UnIndexed('url', $doc->url));
$this->addField(Zend_Search_Lucene_Field::UnIndexed('url', $doc->url, 'UTF-8'));
// $this->addField(Zend_Search_Lucene_Field::UnIndexed('date', $doc->date));
$this->addField(Zend_Search_Lucene_Field::UnIndexed('date', $doc->date, 'UTF-8'));
// (Shirai135): ここまで修正
//additional data added on a per-module basis
$this->addField(Zend_Search_Lucene_Field::Binary('data', serialize($data)));
// adding a path allows the document to know where to find specific library calls
// for checking access to a module or block content. The Lucene records should only
// be responsible to bring back to that call sufficient and consistent information
// in order to perform the check.
// (Shirai135): ここから修正
// $this->addField(Zend_Search_Lucene_Field::UnIndexed('path', $path));
$this->addField(Zend_Search_Lucene_Field::UnIndexed('path', $path, 'UTF-8'));
// (Shirai135): ここまで修正
まだリソースのファイル名などが文字化けしているので，これでは完璧ではない．ただ，以前にインデックスを作成した時にはiconv関係のワーニングが大量に発生していたのが一つも発生していなくなった．
まだ別のワーニング（これはオリジナルのMoodleのバグっぽい）も残っています．それと，Windows環境に関しては，fs化が必要．リソースのファイルの実体が存在しないと言われる．
このあたりを解決すれば，リソース名にターゲットとなる英単語を含む場合，そのリソースを見つけ出すことはできそう．ただ，本来はPDFやPowerPointなどのファイルの中身もインデックス作成のためにチェックされるはずだが，それはうまく機能していないような感じ．
とりあえず上記の修正（とfs化）で，添付ファイルのように，forum, glossary, wikiの中から"PIC"という単語を含むデータをヒットさせることができました．とはいえ，このmechMoodle上にはもっと沢山のPIC関連データがあります．インデックスとしてPICと認識されたのはこの５つだけなのでしょう．
ところで実はアイコンの右横の文字列（”PIC16F88の_CONFIGについて”など）の文字化けを直すのに少し苦労しました．結局は，$title_post_processing_function = $listing->doctype.'_link_post_processing';で生成される関数名の後処理関数（wikiのタイトルならば，search/documents/wiki_document.php中のfunction wiki_link_post_processing()が呼ばれる）の奇妙なコードが原因でした．このような記述に何か意味があるのでしょうか？？？
function wiki_link_post_processing($title){
global $CFG;
if ($CFG->block_search_utf8dir){
return mb_convert_encoding($title, 'UTF-8', 'auto');
}
return mb_convert_encoding($title, 'auto', 'UTF-8');
}
$titleをUTF-8から'auto'へ文字コードを変換しろ！です．アリですかね，これは．$CFG->block_search_utf8dirは，「サイト管理」－「プラグイン」－「ブロック」－「グローバルサーチ」の中の”UTF8 transcoding direction of results:”のことだと思います．これをデフォルトのEnableからDisableに変えたところ，文字化けしなくなりました．つまり青い行ではなくその上の行が実行されたのでしょう．元もとの文字列はUTF-8だと思うのでこんな後処理不要で，実はこの関数のコールを一時的にコメントアウトしたら文字化けしませんでした．まったく後処理になっていない．
さて，これでとりあえず「無いよりマシ」の状態にはなりました．あとはワーニング（$cm->idが見付からないみたい）などを解決し，日本語向けのインデックス作成用の構文解析を追加（これは難しそう）ができれば，ヒット数がどんどんと増えていくでしょう．
＃でも一旦，ここで休憩です^^;
おっと，一瞬でした．
search/Zend/Search/Lucene/Search/QureryLexer.phpのfunction tokenize($inputString, $encoding)の，二つ目の引数である$encodingが''です．上位の関数から正しく'UTF-8'を渡されていない．
public function tokenize($inputString, $encoding)
{
$this->reset();
$this->_lexemes = array();
$this->_queryString = array();
$encoding='UTF-8';
$strLength = iconv_strlen($inputString, $encoding);// Workaround for iconv_substr bug
$inputString .= ' ';
かなり乱暴ですが，上記のように強制的にUTF-8だ，と指示したら，日本語のキーワードにもヒットしました．「白井」というキーワードで１件しかヒットしなかったので，かなり寂しい状況ですが，先ほどよりは少しだけ「無いよりマシ」感が向上しました（笑）．そうかぁ，日本語のインデックスが全く無いわけでは無いのですね．
＃上記修正は一時的なものです．根本的な原因（バグ）は別にあります．試験的に追加するだけにして下さい．
「白井」が1,843件ヒットしました．
先ほどの箇所ではなく（その上位の呼び出しを探していた），search/Zend/Search/Lucene/Search/QueryParser.phpの
public static function parse($strQuery, $encoding = null)：377行あたり．
どうやらこいつ引数が指定されていないようです．
やはり同じく乱暴に，
public static function parse($strQuery, $encoding = null)
{
$encoding = 'UTF-8';
self::_getInstance();
// Reset FSM if previous parse operation didn't return it into a correct state
self::$_instance->reset();
このようにしたところ，一気にヒット数が1,843倍に増えました．とはいえこれは少々，うそっぽい．バグで画面表示がおかしなことになっているような雰囲気．実は１件なのかも知れない．
大量にヒットした理由の一つにblogの著者である「白井」もヒットしていたようです．
しかし，blogのidが指定されていないのであまり意味が無い．
さらに，doctype='user'（blogと思われる）の場合，アイコンにユーザの顔写真を出そうと試みているようなのだが，authorとしてフルネームをインデックスファイルに記録しているものだから，print_user_picture()がエラーを出す．だからユーザーIDにすれば良いのに！
あれ？ でもユーザIDもフィールドに追加していますね．
$this->addField(Zend_Search_Lucene_Field::Keyword('user_id', $user_id));
これを使えばいいのじゃないのか？
入れ忘れているじゃないか．．．
search/documents/user_document.php, function __construct()
// construct the parent class
// (Shirai135): ここから修正
// parent::__construct($doc, $data, 0, 0, 0, PATH_FOR_SEARCH_TYPE_USER);
parent::__construct($doc, $data, 0, 0, $user_id, PATH_FOR_SEARCH_TYPE_USER);
// (Shirai135): ここまで修正
}
}
うーん，あとは$dataにblogのidを入れて，それを受け渡さないと．urlも細工しないとリンクが意味ないし．．．まぁ，エラーをまずは押さえ込もう．
search/query.php, 340行目近辺
foreach ($hits as $listing) {
if ($listing->doctype == 'user'){ // A special handle for users
// (Shirai135): ここから修正
// $icon = print_user_picture ($listing->author, 0, true, 0, true, false) ;
$icon = print_user_picture ($listing->user_id, 0, true, 0, true, false) ;
// (Shirai135): ここまで修正
} else {
$iconpath = $CFG->modpixpath.'/'.$listing->doctype.'/icon.gif';
$icon = "<img align=\"top\" src=\"".$iconpath."\" class=\"activityicon\" alt=\"\"/>";
}
実際には，user_idを折角，インデックスファイルに追加しても，それを読み出す際にresultとして返し忘れている....意味ない！
search/querylib.phpのfunction process_results()
if ($i >= ($page - 1) * $this->results_per_page){
$resultdoc->number = $realindex;
$resultdoc->url = $hit->url;
$resultdoc->title = $hit->title;
$resultdoc->score = $hit->score;
$resultdoc->doctype = $hit->doctype;
$resultdoc->author = $hit->author;
$resultdoc->courseid = $hit->course_id;
// (Shirai143): グローバルサーチにおいてインデックスファイルからの検索結果の取得時に，折角，フィールドにユーザIDが含まれるのにリターンしていないバグの改善 (2009/05/29) c.f.(Shirai137)
// (Shirai143): ここから追加
$resultdoc->user_id = $hit->user_id;
// (Shirai143): ここまで追加
//and store it
$resultdocs[] = clone($resultdoc);
Trackerに報告しました（MDL-19341）．
でも，これだけだと何のために報告されたか分からないでしょうね．
辿りついたのは，function find()．
search/Zend/Search/Lucene.phpの
public function find($query)
{
if (is_string($query)) {
// (Shirai144): グローバルサーチにおいて検索キーワードに日本語を入力するとiconvのエラーが発生して検索に失敗するバグの改善 (2009/05/29)
// (Shirai144): ここから修正
// $query = Zend_Search_Lucene_Search_QueryParser::parse($query);
$query = Zend_Search_Lucene_Search_QueryParser::parse($query, 'UTF-8');
// (Shirai144): ここまで修正
}
Trackerに報告しました（MDL-19342）．
要するに，インデックスファイル作成のインタフェースであるsearch/documents/document.phpでUTF-8を指定しないからインデックスファイル中の日本語が化け，日本語検索キーワードを入力してもそれがUTF-8だと指定してし忘れているのでiconvがエラーを出力するので検索もできない．
日本語での検索が出来なかった根本的な原因はこの二つの”UTF-8の指定し忘れ"ということでした．
これもケアレスミスですね．
search/documents/wiki_document.phpのfunction wiki_get_content_for_index()で，
if (is_array($pages)) {
foreach($pages as $page) {
if (strlen($page->content) > 0) {
// (Shirai135): ここから修正
// $documents[] = new WikiSearchDocument(get_object_vars($page), $entry->wikiid, $entry->course, $entry->groupid, $page->userid, $context->id);
$documents[] = new WikiSearchDocument(get_object_vars($page), $entry->wikiid, $wiki->course, $entry->groupid, $page->userid, $context->id);
// (Shirai135): ここまで修正
}
}
}
ちょっと修正するたびにインデックスを作り直して確認する必要があるので作業効率が悪いですねぇ．でも，随分とマシになってきましたよ．
うん，結構，日本語での検索もうまくできるようです．（字句解析は全く手を入れていません）
さすがに日本語の文章中からの単語の切り出しは全く行われていませんが，「0 : 黒」といったように半角文字で区切られていたりすると，一単語と認識されるようで，「黒」という文字列を本文中に含むWikiを全コースの中から探し出してくれます．
検索結果のblogのタイトルをきちんとblogのsubjectにしたり，リンク先がpostidになるようにしましたので，blogの検索用という使い方もできそうですね．
修正箇所を整理したらdiffをアップします（できるかな？）．
次のバージョンのfs_moodleでは一応ながら改善済みの状態で公開します．
あれ？ 検索オプション（検索項目を指定可能）がうまく機能しない．
ん？ クエリ文字列（titleとか）がget_string()で翻訳されている．なんでそんなことを？
search/query.phpのif ($advanced)のブロック中の以下の箇所を直したら機能しました．
// this field is left untouched, apart from whitespace being stripped
if (strlen(trim($adv->canappear)) > 0) {
$query_string .= ' '.implode(' ', preg_split("/[\s,;]+/", $adv->canappear));
}
// add module restriction
// (Shirai135): ここからコメントアウト
// $doctypestr = get_string('doctype', 'search');
// $titlestr = get_string('title', 'search');
// $authorstr = get_string('author', 'search');
// (Shirai135): ここから追加
$doctypestr = 'doctype';
$titlestr = 'title';
$authorstr = 'author';
// (Shirai135): ここまで追加
if ($adv->module != 'all') {
$query_string .= " +{$doctypestr}:".$adv->module;
}
ちなみにlang_enの言語ファイルですと，doctype, title, authorはそれぞれDoctype, Title, Authorに翻訳されます．そして頭一文字目が大文字だと機能しません．したがって英語圏でも機能していないはず．
午後はドキュメント化をしていたらアッと言う間に過ぎ去りました．
パッチを作成するにはfs_moodleユーザ以外には関係の無いコードを省いて差分を取らなくてはならないので，少々お待ち下さい．明日かな？この第１ステップを元にして，第二ステップ（検索キーワードの切り出しや，外部プログラムによるWord，PDFのインデックス化）を進めて行きましょう．デバッグ等のご協力＆第二ステップのパッチ提供頼みます！
とりあえずこちらでまとめた今回のグローバルサーチ関連の修正箇所のドキュメントのURLです．
(Shirai135): グローバルサーチで作成されるインデックスファイルの中身が文字化けする問題 (2009/05/28)
(Shirai136): mdl_course_modulesに存在しないモジュールを処理しようとした際にSQLのエラー発生を抑えてエラーメッセージを表示する改良 (2009/05/29)
(Shirai137): グローバルサーチにおいてblogの検索結果表示で顔写真が表示されないバグの改善 (2009/05/29)
(Shirai138): グローバルサーチにおいてblogの検索結果表示でタイトルを投稿者名から正しいタイトルに変更する改良 (2009/05/29)
(Shirai139): グローバルサーチにおいてblogの検索結果表示でリンク先がユーザのblogエントリ一覧表示になっているのを個別のblogを正しくリンクするアドレスに変更する改良 (2009/05/29)
(Shirai140): グローバルサーチにおいてeWikiの検索結果表示でコース名が表示されないバグの改善 (2009/05/29)
(Shirai141): グローバルサーチの検索オプション（少し高度な検索機能）でドキュメントタイプ，タイトル，著者名で検索できないバグの修正 (2009/05/29)
(Shirai142): グローバルサーチの検索結果一覧表示おいてページ指定のダイレクトリンクアドレス中の検索条件文字列が文字化けする問題 (2009/05/29)
(Shirai143): グローバルサーチにおいてインデックスファイルからの検索結果の取得時に，折角，フィールドにユーザIDが含まれるのにリターンしていないバグの改善 (2009/05/29) c.f.(Shirai137)
(Shirai144): グローバルサーチにおいて検索キーワードに日本語を入力するとiconvのエラーが発生して検索に失敗するバグの改善 (2009/05/29)
(Debug004): グローバルサーチにおいてPowerPointファイルの中身をUTF-8に変更する際の指定をUTF8としている軽微なバグ (2009/05/29)
意外と多かったですね．１１項目でした．通常は調査とデバッグよりもWikiにドキュメントを残す作業が時間を要するのですが，今回はソースを直すたびにインデックスファイルを全てゼロから作成し直す必要があったので時間掛かりましたねぇ．
そうそう，もし古いインデックスファイルが残っているならばmoodledataのsearchフォルダごと一旦，削除した方が良いかも知れません．一応，インデックス作成の際に古いファイルは削除しているようですが．もしsearchフォルダが無ければゼロから作り直してくれます．
それとcron.phpとの関係はどうなっているのでしょう．自動的にインデックスファイルの更新を１日に１回くらい行ってくれるのかな？
色々と不十分なところもあると思いますが，この数日の間の記憶が薄れる前にWindows系OSをサーバとしてグローバルサーチを使い始めるまでの手順をWikiにまとめました．
うーん，まだantiwordが正常に動作しないのですけれども（パスの設定がおかしい．Moodle側の問題），そこのところは見切り発車です．
未だにdiffの使い方に精通していないので間違えている可能性があります．
そこで怖いので，searchフォルダごとアーカイブにしました．
- search_original：対策前のもの
- search：対策済み（オリジナル，三重大版など用）
- search_fs：対策済み（fs_moodle用）
です．readme.txtを転記します．
Moodle1.9.5+(2009/05/20)のグローバルサーチ機能の改善
・GlobalSearch-diff.txt : diff
・search_originalフォルダ：Moodle1.9.5+のオリジナル
・searchフォルダ：対策済みのフォルダ
・search_fs：fs_moodle用の対策済みフォルダ．
（未公開のfs_moodle用ライブラリ）
・fs_no_override.php
・fs_override.php
［１］三重大学版などのMoodleを使用している方
もしMoodle1.9.5+ (2009/05/20)を使用しているのであればsearchフォルダをこのアーカイブ内のものと差し替えるだけでＯＫなはずです．でも，それは危険だと思う方は差分を調べながらパッチを当てて下さい．私が修正した箇所には，(Shirai***)あるいは(Debug***)のコメントが全て付けられています．
［２］fs_moodleを使用している方
fs_moodle3.13.00(2009/05/21公開)を使用している方はsearchフォルダをsearch_fsフォルダに差し替えるだけでＯＫです．fs版ではコメントに(Shirai***)と(Debug***)以外にも(FS_CONVERTER)が加わっています．
search_fsを使用するには未公開のfs_no_override.phpとfs_override.phpをlib/fs_moodleフォルダにコピーする必要があります．fs_shell_exec()コマンドが追加されています．なお，６月上旬には新しいfs_moodle3.13.01かfs_moodle3.14.00を公開します．fs_moodle3.13.00以降のバージョンであればこれらの改良は全て組み込まれていますのでパッチを当てたりライブラリを差し替える必要はありません．
鈴鹿工業高等専門学校・機械工学科・白井 達也
2009/05/30
アップロードサイズの制限に掛かったので分割します．こちらはfs_moodleユーザで今すぐに試したい方用です．fs_moodle3.13.00が最新版ですので，それ以降のバージョンではこの改良は全て組み込まれますのでこのパッチは不要です（diffは入っていません）．
Windows版だけの問題かも知れません．
mapping用の設定ファイル（UTF-8.txt）をantiword.exeが読むには，環境変数HOMEを利用します．ところが単にHOMEを利用するのではなく，%HOME%\antiwordというように後ろにantiwordをくっつけて探そうとします．
OSがWindowsの場合に，グローバルサーチブロックの設定画面では，lib/antiword/win32/antiword/antiword.exeをパスとして初期設定地が指定されています．変なパス．そう思って私は，C:\xampplite\htdocs\mech\moodle\lib\antiword\win32\antiword.exeとなるようにフォルダを構成し，そのように指定しました．これではダメです，antiword.exeが動きません．必ずantiword.exeはantiwordというフォルダの下に無くてはいけません．
気付くのにちょっと時間が掛かりました．
それに対して，pdstotext.exeは，lib/xpdf/win32/pdftotext.exeが初期設定ですし，このようにフォルダを構成します．このルールを真似し，antiwordの初期設定が間違えている，と早合点したのが敗因です．antiword.exeの変な仕様には困ったものです．もし見当たらなかったりHOMEが設定されていない場合はantiword.exeのあるフォルダのUTF-8.txtを探す，そういう仕様ならばとても楽なのに．
Hello Tatsuya,
I'm trying to install on a windows server antiword, but always get the following error:
Error with MSWord to text converter command : execution failed.
exemplo when i execute : ../moodle//search/tests/
Executing : C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\moodle/lib/antiword/win32/antiword/antiword.exe -m UTF-8.txt "C:\Program Files\Apache Software Foundation\Apache2.2/moodledata/5461/PE_-_Filosofia_-_1a_Etapa_2011_-_2o_Perio.doc" Error with MSWord to text converter command : execution failed.
Moodle version: 1.9.10
my variables in file ..moodle/admin/block.php?block=24
where block 24 is global_search
lib/xpdf/win32/pdftotext.exe -eol dos -enc UTF-8 -q
lib/antiword/win32/antiword/antiword.exe
HOME=C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\moodle\lib\antiword\win32
in database, table mdl_config, i have:
block_search_pdf_to_text_cmd= lib/xpdf/win32/pdftotext.exe -eol dos -enc UTF-8 -q
block_search_word_to_text_cmd= lib/antiword/win32/antiword/antiword.exe
block_search_word_to_text_env= HOME=C:\\Program Files\\Apache Software Foundation\\Apache2.2\\htdocs\\magnumsol\\lib\\antiword\\win32
when i execute antiword in shell (cmd) its ok
exemplo:
C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\moodle/lib/antiword/win32/antiword> antiword.exe -m UTF-8.txt "C:\Program Files\Apache Software Foundation\Apache2.2/moodledata/5461/PE_-_Filosofia_-_1a_Etapa_2011_-_2o_Perio.doc"
in this case show me the file normal.
Have an idea? antiword and xpdf i did download from cvs contrib moodle and uzip in ../moodle/lib/xpdf ../moodle/lib/antiword/win32/antiword thanks
Hi Gisele.
I'm aware of two suspeced points in your setting.
(1) magnumsol
Environment setting for the MSWord converter in Modules/Blocks/GlobalSearch :
HOME=C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\moodle\lib\antiword\win32
in database, table mdl_config :
HOME=C:\\Program Files\\Apache Software Foundation\\Apache2.2\\htdocs\\magnumsol\\lib\\antiword\\win32
Is this a little mistake when you transcribed the strings?
(2) path including white space
c.f. : Path of antiword is 'C:\xampplite\htdocs\mech\moodle\lib\antiword\win32' In my environment.
Executing : C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\moodle/lib/antiword/win32/antiword/antiword.exe -m UTF-8.txt "C:\Program Files\Apache Software Foundation\Apache2.2/moodledata/5461/PE_-_Filosofia_-_1a_Etapa_2011_-_2o_Perio.doc" Error with MSWord to text converter command : execution failed.
The handling of space character on cmd.exe is not so perfect. I'v tried on WindowsXP(SP3, Japanese version).
For example, I'm on C:\usr\shirai folder in cmd.exe and I want to move current folder to \program files\apache software foundation\apache2.2\bin.
It's NG : %> cd /program files/apache software foundation/apache2.2/bin
It's OK : %> cd \program files\apache software foundation\apache2.2\bin
For exacmple, I'm on C:\usr\shirai folder too, and I want to run \program files\apache software foundation\apache2.2\bin\ab.exe.
It's NG : %> C:\program files\apache software foundation\apache2.2\bin\ab.exe -> 'C:\program' is not an inernal/external command.
It's OK : %> "C:\program files\apache software foundation\apache2.2\bin\ab.exe"
It's NG : %> C:/program files/apache software foundation/apache2.2/bin/ab.exe -> 'C:/program' is not an inernal/external command.
It's OK : %> "C:/program files/apache software foundation/apache2.2/bin/ab.exe"
Above examples is testing on commapnd prompt and type these commands by using keyboard.
Next, I'v tried some tests on php via web browser. Test code is as following,
<?php
$moodleroot = 'C:/program files/apache software foundation/apache2.2/bin/';
$CFG->block_search_word_to_text_cmd = 'ab.exe';
$command = trim($CFG->block_search_word_to_text_cmd);
//// $text_converter_cmd = "{$moodleroot}{$command} -m UTF-8.txt $file";
//$text_converter_cmd = "{$moodleroot}{$command} -V"; // (a) Original
//$text_converter_cmd = escapeshellcmd("{$moodleroot}{$command}")." -V"; // (b) escape special characters
$text_converter_cmd = '"'."{$moodleroot}{$command}".'"'." -V"; // (c) Fullpath includeing white space character
$result = shell_exec($text_converter_cmd.' -V');
echo $text_converter_cmd.'<br />';
echo $result;
?>
This test code is based on moodle/search/documents/physical_doc.php, function get_text_for_indexing_doc()
In Type (a) and Type (b), 'NULL' is returned from shell_exec() function.
In Type (c), we can obtain suitable strings(version number of ab.exe).
Conclusion of (2).
Let try modifying source code 'physical_doc.php' as follows;
----
$command = trim($CFG->block_search_word_to_text_cmd);
// $text_converter_cmd = "{$moodleroot}{$command} -m UTF-8.txt $file";
$text_converter_cmd = '"'."{$moodleroot}{$command}".'"'." -m UTF-8.txt $file";
if ($CFG->block_search_word_to_text_env){
putenv($CFG->block_search_word_to_text_env);
}
mtrace("Executing : $text_converter_cmd");
----
" + $moodleroot + $command + " + arguments
Very many thanks !!!!!
1) sorry, magnumsol is rename for moodle directory, i forgot to change name im my post.
2) Your second conclusion its correct :
in physical_doc.php a changed line
$text_converter_cmd = "{$moodleroot}{$command} -m UTF-8.txt $file";
to
$text_converter_cmd = '"'."{$moodleroot}{$command}".'"'." -m UTF-8.txt $file"; // (c) Fullpath includeing white space character
The problem was spaces in path windows...
I hate windows, but customer required installation in windows
Many thanks again
Thank you for you report !
I think, it's a little (but serious...) bug of Global Search.
I'll post the bug report based on your report for Moodle Tracker.
一応，動くようになりましたが，逆にもっとこうしたい，という要望も出てきました．
ここから先は，フォーラムを以下に移します．
以前の話題への返信で申し訳ないですが...
このグローバルサーチ、トピックをたてて、白井先生の貴重な対応をいただいていたのですが、まだ、当方のサイトで対応は進んでいません。
それはさておき、今回、どうも管理画面でグローバルサーチを有効にしてあることが原因と思われる、RSSのエラーが見つかりました。
これと同じ？
http://moodle.org/mod/forum/discuss.php?d=104760
フォーラムやデータベースモジュールにRSSを出力させるのですが、どうもcron.phpが吐くrss.xmlに、内容が含まれず、エラーが出力されていました。
今後先生の対応されたグローバルサーチへの対応も考えているのですが、RSSとの併用に問題があるとすると困るので、一応こちらに話題を投げておきます。
このグローバルサーチ、トピックをたてて、白井先生の貴重な対応をいただいていたのですが、まだ、当方のサイトで対応は進んでいません。
それはさておき、今回、どうも管理画面でグローバルサーチを有効にしてあることが原因と思われる、RSSのエラーが見つかりました。
これと同じ？
http://moodle.org/mod/forum/discuss.php?d=104760
フォーラムやデータベースモジュールにRSSを出力させるのですが、どうもcron.phpが吐くrss.xmlに、内容が含まれず、エラーが出力されていました。
今後先生の対応されたグローバルサーチへの対応も考えているのですが、RSSとの併用に問題があるとすると困るので、一応こちらに話題を投げておきます。