はじめて投稿させていただきます。よろしくお願いいたします。
メッセージ機能から送られたメールの本文が空になる現象が発生しました。
調べたところ、マイプロファイル設定で
メッセージを受け取る側の「メールフォーマット」が「プレインテキストフォーマット」、
メッセージを送る側の「テキスト編集」が「HTMLエディタ」の場合、空白のメールが届くようです。
この設定を変更すれば一応は空白にならないのですが、ユーザ個人に設定を変更させるというのは
今後サイトを運営していくことを考えるとあまり好ましくありません。
他のサイト全体の設定変更やソースコードの改変などで解決できないでしょうか。
(動作環境：Moodle2.0.3, PHP 5.3.5, Apache2.2.17)
2.0〜2.04 くらいの時、学生から、よく「空白メールが来ましたっ！」て言われました。根本的解決ではありませんが、学生には、「空白メールが来たら、ログインしろ」って、言ってました。ログインすれば、自らポップアップ通知を無効化していない限り、必ずメッセージが読めるはずです。
条件をいろいろ変えて、ダミー学生としての自分自身に種々のメッセージを送ってみましたが、その時の結論は、再現性がない、でした。同じ条件でも空白になったりならなかったりで、原因を追及するのは断念しました。そうこうしているうちに、2.1（数字は間違っているかもしれません。記憶によれば、です。）に上げたら、学生は何も言わなくなりました。まぁ、たぶん、そういうことなんだろうと、思います。
2.1.2+で確認しました。再現性がないと思っていたのは、どうやら場合分けがきっちりできていかったということのようです。以下の様になりました。
| 送信側 | 受信側 | |
| HTMLエディタを使用します | プレインテキストフォーマット | |
| 教師 | 学生 | 空 |
| 教師 | 教師 | OK |
| 学生 | 教師 | OK |
| Admin | 教師 | 空 |
|
標準ウェブフォームを使用します （送信時にプレインテキストフォーマットを指定） |
プレインテキストフォーマット | |
| 教師 | 学生 | OK |
| 教師 | 教師 | OK |
| 学生 | 教師 | OK |
| Admin | 教師 | |
受け手側がプレインテキストフォーマットにしておくと、空になるというのが、正しい仕様のような気がします。
メール送信はmoodle2でも，moodle/lib/moodlelib.php内のfunction email_to_user()のようですね．この関数の中にはいくつか魔物が潜んでいます＾＾；
substr()の使用，wordWrap機能．
特に，HTML形式でメッセージを送信する場合はワードラップ（一行の文字数制限）関係の機能は利用されません．自動的に画面上でレイアウトされて改行されるためです．それに対して，プレインテキスト形式の場合は適当な長さでメール本文を改行しないといけません．これは見易さの問題だけではなく，sendmailの仕様上の制限もあります．
以前にこのワードラップについて調べ，改良を行ったことがあります．そこで気付いた問題は，日本語文字コード（UTFでもシフトJISでも無く，ISOなんとか：すみません，ど忘れ）と英数記号の文字数の数え方の違いです．特に半角全角が混ざっている場合は，文字数のカウントがかなりややこしくなります．全角開始時に特殊なコードが挿入され，半角に戻るところでまた別の特殊なコードが挿入されます．
そう，もう一つ思いだしました．Moodle1系統の場合，メッセージ機能ではメールのSubjectをメッセージ本文から”インテリジェントに”切り出します．この切り出しは，単語数＋文字数だったか，ともかく半角空白記号でメッセージの一行名を分割して「ここまでをSubjectとする！」と決めます．これが半角空白記号で区切られていない日本語のメッセージの場合は正常に機能せず，やたらと長いSubjectのメッセージが送信されてくる原因になります．これが原因で正しく無い電子メールがMoodleから送信されて，メールサーバで何らかのエラー処理を施されている可能性もあります．
再現性のある状態で，半角英数文字のみのメッセージを送信して見て下さい．例えば以下のような感じに．
This is a test mail
Body ha mijikaku hankakude!
kokomade.
1行目がうまくすればSubjectになります．本文は２行．これが正しく届くかどうかです．
（関連するかも知れない情報）
http://www.suzuka-ct.ac.jp/mech/moodle/mod/wiki/view.php?id=320&page=Shirai104
http://www.suzuka-ct.ac.jp/mech/moodle/mod/wiki/view.php?id=320&page=Shirai106
http://www.suzuka-ct.ac.jp/mech/moodle/mod/wiki/view.php?id=320&page=Shirai107
http://www.suzuka-ct.ac.jp/mech/moodle/mod/wiki/view.php?id=320&page=Shirai109
以上は，こちらのページにリスト化したメッセージ関連の問題点・改善点より．
皆様、詳しい調査・情報をありがとうございます。
ユーザアップロードの方法は気づきませんでした。現時点では最も有効かもしれません参考にさせていただきます。
そして、Subjectの方ですが、白井様の例文を送信してもまたもや空白でした。
ただ、掲示されたURLからたどって”メッセージ”のSubjectはどこまで?を見つつ、moodle2.1のソースコードを確認したのですが
message/lib.phpのmessage_post_message()で
------------------------------------------------
if ($format == FORMAT_HTML) {
$eventdata->fullmessage = '';
$eventdata->fullmessagehtml = $message;
} else {
$eventdata->fullmessage = $message;
$eventdata->fullmessagehtml = '';
}
------------------------------------------------
という部分がありました。
もしかするとHTMLエディタで記述したときにはプレインテキストの本文がセットされないので
本文が空なのかもしれません。
あくまで現時点での可能性なので調査を続けてみます。
そのFORMAT_HTMLでfullmessageに入れるか，fullmessagehtmlに入れるかを分けるのは正しい動作です．
メッセージはデータベースにまず預けられて，それから一定時間，相手のユーザがアクセスしてこない場合は電子メールで送信します．これはcron.phpから実行されます．途中のplugin云々は追い切れなかったのですが，最終的には，moodle/message/output/email/message_output_email.phpの61行目辺り，class message_output_email のfunction send_message()で送信されるのだと思います．
$result = email_to_user($recipient, $eventdata->userfrom, $eventdata->subject, $eventdata->fullmessage, $eventdata->fullmessagehtml);
このように，email_to_user()には，プレインテキスト形式のメール本文を受け取る引数（fullmessage）とHTML形式のメール本文を受け取る引数（fullmessagehtml）が最初から用意されています．実際にはどちらか一方のみがデータが入っていて，もう一方はnullでしょう．
このemail_to_user()関数の中で，次はメールを受け取る側のユーザのメーラのタイプ（プレインテキストかHTML形式OKか）を見て，HTML→プレインテキストの変換やその逆を行います．
cronで起動する関数のデバッグは面倒ですね．一番効果的なのは，email_to_user()にデバッグのコードを仕掛けることです．この関数の入り口で$messagetext, $messagehtmlの引数の値をテキストファイルに出力してログを取る．でもこれは気を付けないと自分が送ったメッセージ以外のものも拾ってしまうかも知れません．Moodleをメンテナンスモードに変更してユーザがログインできない状態にした上で，（できれば３０分以上，放置してから）実験を行う必要があるでしょう．
しかし不思議ですね．ちなみにユーザプロファイルの”メール文字コード”はISO-2022-JP”ですよね？ 送信側も受信側も．
再現性がないとか、ブラウザ依存とか、そういう風に思い込んだ理由がようやく分かりました。メッセージを送る経路として、（１）送信先学生のプロファイルの下に表示される「メッセージを送信する」、（２）参加者リストから選択して「メッセージを送信する」を選ぶ方法の２通りがあります。（１）の場合、送信者プロファイルの「テキスト編集」がHTMLエディタであろうと、標準ウェブフォームであろうと、立ち上がるのは標準ウェブフォームです。（２）の場合は「テキスト編集」で選択されている方が立ち上がります。これら（１）（２）を場合分けしないで、ごちゃごちゃやっていたので、いろいろガセネタを流してしまいました。申し訳ありません。
そうすると、「標準ウェブフォーム」で送信すれば、プレインテキストなので、受信者プロファイルのメールフォーマットが「HTML」であろうと「プレインテキスト」であろうと、どちらでも良いということになります。このあたりを踏まえて、がちゃがちゃ試行錯誤したところ、対症療法として、
user/messageselect.php の172行目をコメントアウトする
172: # $usehtmleditor = can_use_html_editor();
に至りました。コメントをはずすと空白メールが送られ、コメントアウトすると中身のあるメールが送られることを確認しました。メッセージ送信以外には影響しないようです。
ソースを眺めていると、その場で、エディタを選択できるようにしようとしているのでは？ と思える部分があるので、ひょっとするともっとエレガントに改修できるかもしれません。user/message.html 24行目の choose_from_menu(format_text_menu(), "format", $format, ""); です。間違ってたら、ごめんなさい。今回は予め謝っておきます^_^;)
なるほど，私はMoodle1.9を使用しているのですが，今までメッセージ機能でHTMLエディタを使用したこと，いえ，HTMLエディタが立ちあがったことがありませんでした．HTML形式のメッセージを送信する機能が元からあるのか，はたまた将来的に有効にする予定のつもりだったのに誤ってHTMLエディタが立ちあがってしまうのか，は分かりませんが，とりあえずHTMLエディタを無効にすれば状況は沈静化する訳ですね．
フォーラム投稿がHTML形式だろうと標準ウェブフォームだろうとダイジェストメールが正常にプレインテキストを指定した相手にはプレインテキスト形式で送信されることを考えると，メッセージがHTML形式で入力されたとしてもプレインテキストを希望する相手には変換されて送信可能だと思われます．でも何らかのバグにより，メッセージ機能ではまだ正常に機能しないのかも知れませんね．データベースに一度，蓄えるところだろうか？ ともかく根本的原因を追及できるようでしたら，是非，トライして，もし明らかなバグが発見できたらMoodle Trackerへの投稿をお薦めします．
初めて投稿させていただきます。
同様にメッセージ機能で送ったメールが空白になるという現象が発生しこちらの
内容を参考にさせていただきました。
今のところ、暫定対処として以下のよう条件分を無視してfullmessageにはTEXT
化した本文を、fullmessagehtmlにはHTML本文を入れております。
if ($format == FORMAT_HTML) {
//$eventdata->fullmessage = '';
$message_text = preg_replace('@<[\/\!]*?[^<>]*?>@si', '', $message);
$eventdata->fullmessage = $message_text;
$eventdata->fullmessagehtml = $message;
} else {
//$eventdata->fullmessage = $message;
//$eventdata->fullmessagehtml = '';
$message_text = preg_replace('@<[\/\!]*?[^<>]*?>@si', '', $message);
$eventdata->fullmessage = $message_text;
$eventdata->fullmessagehtml = $message;
}
この対処で現象は出なくなったようなので、こちらで運用しております。
このような対処になったのは、空白メールの中身を見た時に、HTML形式のメール
（multipart/alternative）のtext/plainの部分が空になっており、text/htmlに
は本文が入っておりましたので、とにかく本文を入れてみました。
バグのような気がしますが、改善はしてくれないものでしょうか。。
Moodle trackerに投稿していたのですが、解決していただいたようです。
http://tracker.moodle.org/browse/MDL-29814
私もこの方法で直りました。
html_to_text()という関数がすでに実装されていながらも、2.0以降で使われていなかったようです。
