WordPress メール投稿プラグイン Ktai Entry 0.8.5 リリース
WordPress 用メール投稿プラグイン「Ktai Entry」のバージョン 0.8.5 をリリースいたします。変更点は以下の通りです。
- 外部メールボックスを読み出すトリガーを、スタイルシートの呼出しに変更しました。これにより、JavaScript オフの設定がされたブラウザーによる閲覧でもメール読み込みが行なわれます。
- 同じ時刻の投稿があれば重複としてエラーにする確認を、DATE コマンドで添付画像の撮影日時を投稿日時に指定した場合でも行うようにしました。
- 同じ内容の投稿がある場合、重複とみなしてエラーとするようにしました。
- デフォルトの投稿スラッグが、時分秒を繋いだ6ケタの数字にならず、固定の文字列「003328」になってしまうバグを修正しました。(Ktai Entry 0.8.4 のみ存在するバグ)
- Windows サーバーで運営していて、かつ、プラグインのフォルダー名を ktai_entry 以外に変更しているとき、正常に動作しない不具合を修正しました。
- GD が組み込まれていない PHP で稼動させたとき異常終了していましたが、添付画像ファイルを無視して投稿処理がされるようにしました。
- WordPress MU で使用した場合、管理パネルの「メール投稿」でメールサーバーの設定をできるようにしました。通常の WordPress の場合は従来通り、「投稿設定」→「メールでの投稿」にて設定してください。ただし、添付画像の投稿にはうまく対応していないかもしれません。(Ktai Entry 0.8.4 で作り込んだつもりでしたが動作していなかった)
今回は投稿スラッグが固定の文字列になってしまうバグの修正および、重複投稿チェックの強化、外部メールボックスの読み出しトリガーの変更を行なっています。最後のものはちょっとチャレンジングな変更かもしれません。JavaScript オフの環境でも動作する反面、スタイルシートの呼び出しをきっかけとしているため、ブラウザーのキャッシュに入りやすい (==何回も実行されない可能性がある) という欠点があります。手元では問題なく動作していますが、環境によってはうまくメール取り込みが行なわれないかもしれません。
機能自体の強化ではありませんが、附属ドキュメントに「メール投稿されたら管理者にメールが届くようにしたい」というカスタマイズを掲載しました。作者としてはそういう機能の必然性を感じないため本体に取り込む予定はありませんが、必要な方はカスタマイズを行なってみてください。
今回は変更点やカスタマイズについて慎重にテストを行なっているので、たぶん問題なく動作するはずです。
WPMU1.5 ケータイエントリー
WPMU1.5でうまく動かなかったケータイエントリー。
バージョン0.8.5 で動作するようになりました！
これでDBに直接アカウントを入力するような事はしなくても良いわけです。
yurikoさ…
携帯メール記事投稿系をＶｅｒ0.85へバージョンアップ！
このブログの携帯メール記事投稿系の制御を行っているプラグイン
Ktai Entry @ Yuriko.net
バージョンを0.84 -> 0.85に
上げましたです
メールからの記事を本体に取り込むタイミングを，スタ…
すみません
Ktai Entryの設定の記載で、
.qmail/.forward/.procmailrc から WordPress のプラグインディレクトリーにある投稿スクリプト (ktai_entry/inject.php) が呼び出せることが必須です。メールサーバーとウェブサーバーが同一であれば大丈夫でしょう。違う場合は相当困難です。
とあり、現在メールサーバとウェブサーバが違うため、自分のスキルではKtai Entryが使用できない状態です。
ウェブサーバのほうにもローカルのみのメールサーバをつくり、メールサーバを２つで、転送したりしても場合でも、Ktai Entoryは動作するものなのでしょうか？動作する可能性はあるのでしょうか？
なにぶん不束ものでございますが、どうかヒントをお教え頂ければと思います。
という記述は、「メール着信により投稿スクリプトを起動させる方式」の場合のみ該当するものです。外部のメールボックスを随時読み込む方式であれば、ほぼ確実に利用可能です。
動作する可能性はありますが、ローカルのみとしてもメールサーバーを動かしてしまうのは管理の手間がかかりすぎると思います。むしろ、メールサーバーの方で、メール着信するたびに retrieve.php にアクセスさせるようにした方がよいと思います。
ゆりこさん、返信ありがとうございます。
乏しい知識ゆえに、的違いでしたら大変恐縮ですが・・・
| /usr/bin/php /(WordPress へのパス)/wp-content/plugins/ktai_entry/inject.php
を
| /usr/bin/php http://ローカルIP/(WordPress へのパス)/wp-content/plugins/ktai_entry/inject.php
ということだけでは解決しないですよね？
これは明らかにダメです。CLI の php コマンドがどういうものか調べてみれば、動かない理由が分かるかと思います。
これについては試したことがないのでよく分かりません。inject.php は「標準入力からメールメッセージを受け取る」前提で作られているので、動かない可能性が大です。やるとすれば inject.php 側の大改造が必要でしょうが、セキュリティーが心配なので、やめといた方が無難だと思います。
返事した内容は、あくまで、「WordPress をインストールしたサーバーから、ローカルのメールサーバーに POP3 アクセスする」という仕組みです。そのトリガーとして、メール着信したらウェブサーバー側の retrieve.php を実行させる (wget なり curl なり lynx なり) 方法を提案しています。
返信ありがとうございます。
router⇒(A)reverseproxy-server&mail-server⇒(B)web-server
以上のような構成です。
流れとしては、携帯から投稿してメールサーバが受信し、以下のコマンドが実行されて、WEBサーバ上でinject.phpが起動し、wordpressに書き込まれるイメージでよろしいのでしょうか？
| /usr/bin/php /wget http://ローカルIP/(WordPress へのパス)/wp-content/plugins/ktai_entry/inject.php
最後に定期的にゴミ削除。
または、
lynxインストールして文字コード設定して
| /usr/bin/lynx -source http://ローカルIP/(WordPress へのパス)/wp-content/plugins/ktai_entry/inject.php
ゴリ3さん:
わたしの回答を再度よく読んで欲しいのですが、別サーバーの inject.php を起動させることは、ほぼ不可能なのであきらめてください。ssh でトンネルを作ってコマンドを実行させるとか、そういう手段を使わない限り無理でしょう。
ゴリ3さんの環境で容易に実現可能と思われるのは、WordPress の動いているウェブサーバーから、メールサーバーへの定期的な POP3 アクセスによるメール取り込みです。本来ならば、附属ドキュメントに書いてある通り、Gmail や Yahoo! メールを使う場合などの設定と同様に行うだけで十分で、メールサーバー側からウェブサーバーの retrieve.php を起動させる必要はありません。
しかし、できるだけ迅速なメール取り込みを行わせるために、メール着信時に retrieve.php にアクセスするような追加設定を提案しています。その意図がよく分からなければ、この追加設定はなくても構いません (ただし、メール送信から投稿処理までは多少タイムラグが発生してしまいます)。
wget はコマンドであって php スクリプトじゃないので、php コマンドの引数にしても多分動きません。また、wget コマンドはふつうルートディレクトリーにはインストールされていないので、File Not Found になると思われます。コマンドラインの使い方をもうちょっとよく調べてみてください。
これも、遠隔で inject.php を起動しようとしているならば、動作しません。inject.php じゃなくて retrieve.php にアクセスしようとする目的ならば使えますが、source オプションはあまり意味がありません (retrieve.php の出力はそもそもテキストなので)。
ゆりこ様
はじめまして。
ワードプレスを利用した携帯サイトへの投稿をKtai Entry0.8.5にておこなっております。
投稿用メールアドレスに携帯から画像と本文（記事）を送り、最新情報として表示するような仕組みにて運用しておりますがうまく更新されず参っております。
専用サーバーにてあれこれ設定を変更できる環境にて動作を試しておりますがなにぶん素人で、原因の特定も出来ず、書き込みさせていただきました。
こちらで考えた仕組みとしては、携帯から記事投稿時、.qmail-secretの方法でinject.phpにメールを渡すパターンなのですが、キャッシュの関係なのか、ブラウザ更新を行わなければ記事が読み込まれず、正しく動作しているのかもわからずといった状況です。
仕様であれば仕方ないのですが、思い描いていたのは、
１更新用メールアドレスに記事を送信
２ページを確認すると記事が反映されている
というイメージです。
なにか思いつくミスなどあればご教授いただければ幸いです。
ユウさん:
本当はメール送信だけで投稿されているものの、ウェブブラウザーのキャッシュ、ないし (設定していれば) WordPress 側のキャッシュが効いている可能性がありますね。これを確認するには、投稿後の内容確認には、ブラウザーのキャッシュをクリアしておくか、別のウェブブラウザーで閲覧するなどの方法があります。
WP-Cache などの WordPress 側のキャッシュについては、新規投稿があれば関連するキャッシュがクリアされるようになっているはずですが、それがうまく動いていない可能性があります。キャッシュプラグインを使っているならば、停止して確認してみてください。
あと、携帯電話からのメール送信は比較的遅延があるので、メール送信から記事反映まで数十秒ほどかかることもあります (特に au は遅い)。
ご返信ありがとうございます！夜分遅くにも関わらずお心遣い感謝いたします。
コチラの環境としてはキャッシュプラグイン等は使用しておらず、（2.5.1の初期状態）
30分以上たった後も更新されない事もあったのでどこか私の設定ミスがあるのかもしれません。
こちらで行った検証としては、
１PCにて管理画面をモニターし、携帯から記事投稿。
２ブラウザ更新せず、何度も該当ページを観覧している携帯端末にて表示確認（更新されていない）
３ブラウザ更新をおこない記事投稿反映（何度かブラウザを更新すると反映されるケースもあった）
読み込みのタイミングが、場合によって執拗にブラウザを更新しなければ反映されない状況で、
私が想定した結果としては同じ端末で何度も見ている中でも、常に最新記事を表示させる事ができれば満足なのですが…。
インクルードされるheader.phpにキャッシュ関係のmetaを記述してもダメで。
もう少し色々と細かく洗ってみます。
ユウさん:
携帯電話での閲覧の場合、機種によってキャシュが残る場合があります (特に au 端末)。Ktai Style を利用されている場合、フロントページ (トップページ) はキャッシュに残らないように処理していますが、それ以外のページはキャッシュ制御していないので、古いページがそのまま見えてしまうことがあり得ます。
あと、実際にメール着信が遅い可能性もありそうですね。これはメールサーバーのログをリアルタイムで確認してみるとよいでしょう。
携帯電話の場合、HTML の meta タグはきちんと見てくれない場合が多いです。HTTP ヘッダのキャッシュ制御をきちんと行う必要があります。Ktai Style の場合は、ktai_style.php の 471 行目付近にある
if (ks_is_front()) {ブロックをとっぱらって、nocache_headers();を常に実行されるようにしてしまえば、常にキャッシュされなくなります。他の携帯プラグインの場合も、出力を行う直前でnocache_headers();を入れればよいです。自分の的外れな理解にも返信して頂き、本当にありがとうございました。
頑張ります！！
外部メールボックスに随時アクセスの場合の方法しか、現状は難しいということですね！！
そのためPOP3 読み込み間隔の推奨間隔５分のタイムラグは、しょうがないってことですね！！
頑張ってやってみます！！
度々のご返信ありがとうございます。
当方携帯表示用プラグインは使用せず、PC用テーマを改変して携帯用としております。
といっても、必要最低限の機能まで絞って
古い携帯にも対応できるようコードを改変しているだけなので（それがダメなのかもしれませんね）
ワードプレス自体をキャッシュされないようにしなければいけないのかも知れませんね。
ただメール投稿は執拗にブラウザ更新をおこなえば反映されるので設定は間違っていないように思うのですが…。
ちなみにサイト構成としては通常のHTMLファイルにて携帯サイトを構築し、
サブコンテンツとしてワードプレスを設置しております。
なにか考えられる要因をお示し頂けたら幸いです。
度々質問して申し訳ありません。
それですと、携帯電話側のキャッシュが効いてしまっている可能性が大ですね。au 電話は特にキャッシュを見せる傾向にあります。こればっかりは端末側の仕様なので仕方ありません。端末側で随時再読み込みさせてください。
これも有効な解決策です (具体的には、テーマの functions.php で
nocache_headers();をむりやり実行してしまう)。ただし、サーバーの負荷がかかるという欠点もあります。Ktai Style のやっているように、フロントページだけキャッシュしないという手法がいいと思います。au、ウィルコムの場合、スタイルシートを解釈するのでメール取り込みは行なわれるはずです。ドコモの場合は無理です。ソフトバンク、イー・モバイルの場合はよく分かりません (要調査)。ドコモ端末の場合は、いくら携帯電話で閲覧しても投稿メールの取り込みは行なれません。
なお、それなりにアクセス数の多いサイトの場合、他の人の閲覧が投稿メール取り込みのトリガーになっている可能性もありますが、お話から言うと、おそらく投稿処理は行なわれているのではないかと思います。
ご返答ありがとうございます。
ゆりこさんが書かれた以下の記述を試したいのですがfunctions.phpのどこにかけばいいのでしょうか？
これも有効な解決策です (具体的には、テーマの functions.php でnocache_headers(); をむりやり実行してしまう)。ただし、サーバーの負荷がかかるという欠点もあります。Ktai Style のやっているように、フロントページだけキャッシュしないという手法がいいと思います。
サーバーに関しては自己管理できているしそれ程アクセスが多いわけでもないので
ある程度の負荷で更新がスムーズに行われるなら問題ありません。
単純に、テーマの functions.php に
nocache_header();と書くだけです。これは WordPress コアが持つ命令で、HTTP ヘッダでキャッシュを防止するような出力を行うものです。もし functions.php が存在しなければ、新規作成して、<php と ?> で囲んでやる必要があります。携帯向けテーマということですから、おそらく functions.php は存在すると思いますが。
functions.php に
nocache_header();
を記述すると真っ白画面になってしまいました。
これは…。
あれ?
nocache_headers();です。コメント16,17番は正しく書いていますが18番は誤記ですね。失礼いたしました。引き続きnocache_headers();を用いてテストしております。
上記処理を施しても更新のタイミングがつかめずやきもきしております。
当方auの端末にて観覧テストしておりますが、
執拗なブラウザ更新でも反映されず（携帯メールの遅延なのかも）
ブラウザ更新でのトリガーが効いているのかいないのか判別がつかず。
メールボックスをcronにて定期的にチェックする方法で試してみるか考えております。
お手数お掛けして大変申し訳ありません。
もう少し色々と探ってみます。
au 端末はスタイルシートに対応しているので、メール取り込みは行われるはずです。ただし、設定パネルで決めた時間間隔を経過しない限り、読み込み処理はされません。最短の5分間隔とした場合、投稿テストは5分以上間を空けて行なってください。あと、au 端末は夜間は比較的遅延があります (といっても数分もすれば着信しますが)。
リアルタイム性を重視するならば cron を使う方が確実ですね。
メールボックスをcronにて定期的にチェックする方法を試してみたいのですが、
マニュアル等を見渡しても特に記述がないようですが、
どこを参考にするとよいでしょうか？
何度もコメントしてしまい申し訳ありません。
Q_and_A.html の方には、crontab の記述サンプルを載せてあります。しかし、crontab の使い方自体は載せていません。これはお使いのサーバー屋さんが提供するヘルプを調べてみてください。シェルログインできるならば
man crontabしてマニュアルを見てみてください。Yuriko様、何度も申し訳ありません。
cronの設定まで行い、au端末からの投稿をretrieve.phpから読み込む所までいったのですが、
docomo端末からの投稿で以下のようなエラーメッセージが返ってきてしまい、
投稿が反映されていないのです。
以下のメッセージから原因を突き止める事は可能でしょうか？
何度もお手数をおかけし大変申し訳ありません。
ユウさん:
同じ内容の投稿のため、重複エラーが発生しています。しかし、Ktai Entry 0.8.5 では、重複エラー検出時の処理が不正で、PHP エラーが出てしまうため、報告して頂いた状況になります。最新版の Ktai Entry 0.8.7 では改善されていますので、同じ本文を使っても PHP エラーは出なくなります。ただし、本文重複のため投稿できないことには違いありません。テスト投稿の際には、必ず本文に違う内容の文章を使ってください。単純に「テスト1」「テスト2」と数字を増やしていくので構いません。
本文は同一内容ではないのですが、
件名は未入力のまま投稿テストしております。
ワードプレス管理画面には(タイトルなし)と表示されています。
もしかしてこれが原因でしょうか？
はい、タイトルなしの場合は公開状態になりません。タイトルは必須となっています。
ご返信ありがとうございます。
Yuriko様のおかげで全て解決致しました！
一連のご回答誠にありがとうございました！！