mobile eye+パッチ版　URLGATEについて

パッチ作成者です。

テンプレートの作成で、ページ（投稿とページのページ）のエントリーを表示する場合、日時を非表示にする事は可能でしょうか？

Mobile Eye+ は、単一投稿の表示も、固定ページの表示もどちらも entry.php テンプレートを使います。よって、その中で is_page() テンプレートタグを使って、the_time() を実行するかどうか決めてください。ktai_style_taste テーマはそのような手法を使っているので、参考にしてみてください。

しかし、エントリー内の自サイトURLの画像はURLGATEを通さない形で出力される為、サイズが大きくても直接表示になってしまいます。

画像と外部リンクでは使うサービスが違います。デフォルトでは「通勤ブラウザ」しかチェックがはいっていませんが、これは画像の表示には使われません。
画像を縮小させるには、Mobile Eye+ の設定パネルで画像対応のサービスを選択する必要があります。しかし、リストされているサービスはすべて「広告が出る」仕様なので、あやしい広告が出ていい覚悟が必要です。

画像リサイズは、以前はバナー広告のアダルト広告が出ていましたが、今は Google アドセンスに変更されています。どのような内容になるかは「運次第」のようです。ただし、かなりマイナーなサービスで、サーバー数削減があったなど、将来に渡って使えるかは疑問があります。
ファイルシークとピクトは、あいかわらずポルノ広告・出会い系広告が出ることが確認されています。

画像の縮小なんて、外部サービスを使わなくても、PHP 組み込みの GD を使えば簡単に作れるので、本来はプラグイン自身が実装すべきです。WordPress 自身も GD を使っていますし、拙作の Ktai Style も画像回りは自前で作っています。

Mobile Eye+ が画像の縮小で外部サービスを使っている理由ですが、おそらく、「画像リサイズ」を使わせるためと思われます。このサービスは、Mobile Eye+ の作者が運営に絡んでいる *らしい* のがその理由です。「あやしい広告」さえ出なければ高機能なサービスではあり、便利なんですが、運営元が不明なこと、継続性が微妙なことから、広く一般に配布する WordPress のプラグインが利用するには「ふさわしくない」と考えます。

サーバーで PHP 5 が使えないのは非常に残念なことですが、Mobile Eye+ は上記のように本質的な問題を抱えていることに注意してください。かなり機能は落ちますが、MobilePressNEO の方が、はるかにマトモな作りをしています。

しかし、外部の画像（外部からリンクしている画像）にはURLGATEが適用されるに対して、自サイト内の画像（自サイト内でリンクしている画像）はURLGATEが適用されません。

ひょっとすると、「本文中の画像」設定を「表示する」にされていませんか? これが「表示する」だと、URLGATE 経由になりません。あと、画像にリンクを設定している場合は、画像へのリンクを「そのまま」にするか「削除」するかで挙動が違ってくるので、こちらも確認してみてください。

lid/filter.phpに

// ブログ記事以外はURLGATEに通す
$plugin_dir = defined(‘PLUGINDIR’) ? PLUGINDIR . ‘/’ : ‘wp-content/plugins/’;
return mobile_get_bloginfo(‘siteurl’) . $plugin_dir . basename(dirname(dirname(__FILE__))) . ‘/urlgate.php?url=’ . rawurlencode($url);

があり、これが関係しているのかなぁ･･･とは思っていたんですが･･･関係ないでしょうか？

これは、その前段階で「ブログ内リンクでない」と判断されたときの最後の処理ですね。
で、その前段階は、オリジナルの Mobile Eye+ は結構バグっていて、サイト内リンクなのにそうではないと判断することが多いという問題がありました。このため、パッチ版では確実な方法を利用しています。

よーくコードをチェックしてみましたが、確かに、サイト内の画像だと URLGATE は決して通らないことが判明しました。テスト環境では、「画像をリンクに変換」だと URLGATE を通っていたのですが、微妙に画像の配置場所がブログ外でした。ローカル環境に複数 WordPress があるんですが、他の WordPress にアップロードした画像を参照していました。一見、ローカル環境の URL なので「ブログ内」と思っていて、「うーん。うまく動くのに……」と悩んでいました。

で、結論ですが、現状の Mobile Eye+ パッチ (その2) では「仕様」とさせてください。仕様変更してサイト内の画像でも URLGATE を使えるようにするには、どのような挙動がふさわしいのか検討しなけばならず、ちょこっとコードを変更して修正とはいかないです。

(1) サイト内の画像ならば、実ファイルを探索できるはずなので、画像サイズをチェックして 50KB より大きければ URLGATE を通すとかの自動判定にするとか、(2) 本文中の画像を「表示しない」のときはサイト内の画像でも URLGATE を通すとか、もうちょっと考えてみます。

元の Mobile Eye+ では、今回のような場合 URLGATE を通すのですが、コードを見る限り、それは仕様ではなく「バグによりそういう挙動になっていた」と考えるのが自然です (ブログ内の投稿・ページでも URLGATE を通すこともあったため)。
もし、正しくコードを書いていれば、「サイト内の記事はそのままリンク、画像は URLGATE を使う」という判断を自動で行うのは難しく、かなり悩む必要があったはずです。

結局のところ、「どういう状況のときに URLGATE を通すのがいいか」という問題に突き当たるんですよね。URLGATE の目的は「携帯で見えないサイトや画像・動画・ウェブサイトを見るとき、外部サービスを利用する」ということですが、画像の場合は、VGA サイズぐらいまでなら問題なく携帯で見えてしまいます (外部サイトの画像であっても)。

画像に画像へのリンクが設定されている場合 (img 要素を a タグで囲んでいる場合) は、内側の img 要素はおそらくサムネールと思われるため、URLGATE を通さない方がよいでしょう。外側の a 要素が画像へのリンクであれば、これは元画像と推測されるため URLGATE を通した方がよいかもしれません。

しかし、リンク先が画像である、という判断もけっこう難しいです。拡張子が jpg, png, gif 等で実ファイルが存在することが確認できればいいですが、そうでない場合 (実ファイルのある場所をうまく推測できない) 場合もしばしばあります。

また、現状の URLGATE の設定は、ウェブサイト用の変換サービス／画像用の変換サービス／動画用の変換サービスの区別をしていないため、どれか1つでのチェックが入っていれば「使用する」とみなしているのが問題です。そうなると、画像用の変換サービスをチェックしてないのに、上記のアルゴリズムで URLGATE を使用すると、URLGATE 画面で飛び先がないという事態が発生します。これを回避するには、URLGATE 機能の大幅改変が必要になります。

しかし、パッチ作者は「URLGATE 機能を悪」と考えていますので、そこまで改変するならば、GD による画像縮小機能を実装してしまった方がよいと思います。そうなると、動画をどうするか、というのが悩むのですが……。