WordPress からのほぼすべての通知を XMPP で送信するプラグイン wp_mail to XMPP

先日、WordPress のフォーラムの話題に触発されて、「コメントが来たことをメール以外で知らせる方法」という記事を書きました。

そのあともう少し一般的に考えてみました。WordPress から多くのメールが届きますが、そのほとんどは単なる「通知」で返信を要しないものです。つまりメールである必要はないのです。ということは、コメントがついた時だけでなく、WordPress からのすべてのメールを XMPP にしてもいいのではないか、と思いました。メールと XMPP は形式がとてもよく似ており、そのまま宛先を変えるだけでいいのではないか、と。

探してみたら、同じ目的の XMPP sender というものが既にありました。しかし中を見てみると古くて、メンテナンスもされていないようです。また、完全に wp_mail() を置き換えているので、条件によっては XMPP ではなくメールで送りたいと思っても応用が効きません。

WordPress からの通知は、更新・ユーザー追加・コメントなど発生源は種々あっても最終的には wp-includes/pluggable.php の中の wp_mail() によってメール発信が行われています。[1] wp_mail() を見てみますと、

function wp_mail( $to, $subject, $message, ...) {
	extract( apply_filters( 'wp_mail', compact( 'to', 'subject', 'message', 'headers', 'attachments' ) ) );
		...
		$phpmailer->Send();
}

という構造になっています。冒頭のフック ‘wp_mail’ は、たぶん送信先の追加や、subject(件名)や message(内容)に一律に何か加工するなどを想定されていると思いますが、その中で XMPP 送信を行ってしまえばいいと考えて、次のようなプラグインを作りました。

wp_mail to XMPP
Send almost all notifications via XMPP instead of email

https://github.com/mako09/wp-mail2xmpp にも置いてあります。

前の記事「コメントが来たことをメール以外で知らせる方法」でざざっと書いて示したプラグインは、その機能が今回のプラグインに完全に含まれますので、忘れてください。

なおこのプラグインは、別のプラグイン XMPP Enabled を利用していますので、それを先にインストールしてください。

きっかけとなったフォーラムの話題のように、複数の投稿作成者がいて誰かが投稿したことを他の作成者たちが知りたい、という場合には、投稿を通知するプラグイン(公式ディレクトリで “post notification” で検索すれば、いろいろ見つかります)、たとえば New Post Notification などをインストールしておけばいいでしょう。そのメール通知も今回のプラグインで XMPP に振り替えます。

wp_mail to XMPP の中身

このプラグインは2つのフックを備えています。

abort_xmpp_sender は、XMPP送信処理を中止するためのものです。たとえば「コンタクトフォームからの送信は、JID の有無に関わらず、メールで送信する」としたい場合、件名やヘッダなどで判定するフィルターを追加すれば、実現できます。

email_to_jid は、メールアドレスから JID に変換するフィルターを呼び出します。デフォルトでは、そのサイトに登録されているユーザーかつそのユーザーがJIDを設定している場合のみ、JID を返すフィルターを設定しています。たとえばコメントをつけた人が入力したメールアドレスのように、JID を見つけることができなければ、その人には XMPP 通知を出しません。このフックにさらにフィルターを追加して、たとえば JID があっても XMPP 通知を出さない人を設定する、あるいは逆に、JID が見つからない場合は管理者の JID に XMPP 通知を出す、などを実現できます。

これらの後に、JID があれば XMPP 通知を、JID がなければメール通知を行います。XMPP に送られる通知では、subject(件名)と message(内容)をそのまま用い、headers(ヘッダー)と attachments(添付)は送信せず無視しています。

オプションで、XMPP 通知を行ったユーザーにもメール通知を行うように設定することもできます。

おわりに

はじめてプラグインを公式に公開しようとしたら、実際に動作するコードの部分を書く時間の10倍くらいを、その周辺のことに費やしました。名前を決めること、コメントや readme を英語で書くこと、依存する別のプラグイン XMPP Enabled を国際化・日本語化して作者に連絡して取り込んでもらうこと……。いやはや、いい経験になりました。それでもコード自体にも英語にも自信がありません。おかしなところを見つけて知らせてもらえたらうれしいです。

  1. ただし Jetpack購読(subscription)は、実際には WordPress.com がメールを送信しているため、これに該当しません。

コメントが来たことをメール以外で知らせる方法

WordPress のフォーラムに次のような話題がありました。

「コメントが来たことを知らせる方法をメール以外でなにかほしい」

現在、ワードプレスを数人で管理し、記事を書いています。

私たちの環境では、ディスカッション設定の自分宛のメール通知のところにある「コメントが投稿された時」にチェックを入れています。

(中略)

メールに気づく派も気づかない派も、各ユーザーがメールの通知以外でコメントに気づくことが出来るようにしたいと思っています。

そこで私は、以前に書いた「Jabber と WordPress」を示しながら、ただし XMPP サーバーを確保できないと難しいので一般的ではないと回答しました。

さて質問文をよく読むと、

  • 投稿にコメントがついたことの通知を受け取るのは、その投稿の作者のみでよい

で済みそうです。一度の通知の送り先は1人でよい、ということであれば、先に示したややこしい仕組みは必要ありません。

やはりインスタントメッセンジャー(IM) の XMPP を利用した通知を行うことにします。

管理者の作業

公式プラグインのサイトから XMPP Enabled というプラグインをインストールします。

さらに次のプラグインをインストールします。これは XMPP Enabled と同じ作者による、投稿のあった際に XMPP で通知する Juick Crossposter というプラグインを、コメントの場合に置き換えて作り直してみたものです。

また管理者は次の節の脚注の作業も必要に応じて行ってください。

【追記】 これを元に、一般化して、プラグインを公開しました。「WordPress からのほぼすべての通知を XMPP で送信するプラグイン wp_mail to XMPP」を参照してください。

各投稿者の作業

先の質問では複数の投稿作成者がいるようです。そこでそれぞれが通知を受け取るためには、各人の PC やスマートフォンなどに XMPP クライアントを用意してもらいます。また、各人に XMPP のアカウント(JID)を取得してもらいます。WordPress.comのアカウントを取得すれば自動的に (アカウント)@im.wordpress.com が JID になるのでそれを利用できます。

さて投稿しているブログサイトで、各人は自分のプロフィールのページにある「Jabber/Google Talk」の欄に取得した JID を入力しておきます [1][2]

これで設定は完了です。コメントがつくと、そのコメントがつけられた元の投稿の作者に XMPP で通知が行きます。

  1. 「Google Talk」とありますが、2013年末現在、Google Talk はサービスがなくなり(Google+ ハングアウトに吸収され)、他の XMPP ネットワークと連絡できなくなりました。そのため Gmail アカウントはここでは利用できません。
  2. なお、つい最近の WordPress を新たにインストールして始めた場合には、この「Jabber/Google Talk」欄がないかもしれません。管理者は、たとえばこのページなどを参考に(そこでは悲しいことにJabber項目の削除として紹介されていますが、ちょうどその逆の操作です)、jabber というフィールド名の項目を追加してください。

wp-login.php への攻撃に対処する

サーバーにログインして作業しようとしたら非常に反応が悪く、どうしたことかと見てみると(普段と違って、コマンドを入力してから応答があるまで数十秒も待たされるのでヒヤヒヤしましたが)、大量の apache プロセスが走っていて、ログには wp-login.php への大量のアクセスが記録されていました。最近よく耳にする wp-login.php へのブルートフォースアタックです。

1つの IP アドレスから5,6回のアクセスがあり、すぐに(あるいは同時に)別の IP アドレスからのアクセスがあります。結局、2時間ほどのあいだに数千回のアクセスがあり、その後沈静化しました。

特に対策らしい対策をしていなかったので、パスワードの強度のみで耐えたことになりますが、実際目の当たりにすると気持ちのいいものではありません。それにどちらかというとサーバーに対する高負荷のほうが心配です。

そこでいまさらではありますが、少し手を打つことにしました。

強いパスワードにする

今回行った対策ではありませんが、そこそこ強いパスワードにしていたので、攻撃に気づくまでの30分間ほどはこのことだけで侵入を防ぎました。

.htaccess で制限する

攻撃に気づいてすぐ、 .htaccess に次のように書いて wp-login.php へのアクセスを制限しました。これは効果てきめんで、すぐにサーバーの負荷は通常の範囲まで下がりました。

<Files wp-login.php>
Order deny,allow
Deny from all
Allow from xxx.xxx.xxx.xxx
</Files>

前述のように攻撃側の IP アドレスは絞り切れないので、Deny に列挙することができません。

さて当面はこれでしのいだとしても、正当に管理画面にアクセスするのが複数の人間で、それぞれの接続元の IP アドレスが固定していなかったりすると、Allow に列挙するのもやっかいです。

WordPress のロックダウン

IP アドレスでふるい分けられないとすれば、wp-login.php のところで何らかの制限をかける方法が考えられます。たとえば Force Email Login は、中心となる機能は「ログインをユーザー名ではなくメールアドレスで」という点なのですが、そのほかに

  • ログインに失敗すると、ログイン処理に対して10秒間 wp_die() を発火させて膨大な量のブルートフォースアタックによるサーバー負荷を軽減します。

ということも行います。

こちらの問題のサイトでは「ログインをユーザー名ではなくメールアドレスで」という機能は必要ないので(というか、ようやく「ユーザー名」が何かを理解するくらいの人たちにもう一度ログイン方法を周知徹底するのが面倒すぎるので)、その部分を削ぎ落とすことにしました。

ただ、これだと誰か(攻撃者)がログインに失敗するとその後10秒間は誰も(正当なユーザーも)ログインできません。たとえば5秒に1回、1週間にわたってログインを失敗し続けるという、もはや「ブルートフォース」とは呼べないようなぬるい攻撃(?)で、そのあいだ正当なユーザーのログインを妨害することができるという欠点があります。

やはり「IP アドレスごとに」という機能をつけざるを得ないのかもしれません。そこで、Limit Login Attempts in WordPress … のようなものにすることにしました。これだと、同一 IP アドレスから1秒間にn回のログインの失敗があったらその後m秒間、その IP アドレスからのアクセスを禁止します[1]。ユーザー名/パスワードを試みる回数は、IP アドレスをチェックしないものよりは増えますが、何も対策しないよりはずいぶん減らせるでしょう。

さて、たとえば1秒間に2か所からそれぞれ2回、3回の攻撃があった場合の対応は、この対策を行わない場合、

  • wp-login.php にアクセス → データベースでユーザー名とパスワードを調べる → 失敗
  • wp-login.php にアクセス → データベースでユーザー名とパスワードを調べる → 失敗
  • wp-login.php にアクセス → データベースでユーザー名とパスワードを調べる → 失敗
  • wp-login.php にアクセス → データベースでユーザー名とパスワードを調べる → 失敗
  • wp-login.php にアクセス → データベースでユーザー名とパスワードを調べる → 失敗

となっていたわけですが、これが

  • wp-login.php にアクセス → データベースで IP アドレスごとの失敗回数を調べる → データベースでユーザー名とパスワードを調べる → 失敗
  • wp-login.php にアクセス → データベースで IP アドレスごとの失敗回数を調べる → 失敗(403)
  • wp-login.php にアクセス → データベースで IP アドレスごとの失敗回数を調べる → データベースでユーザー名とパスワードを調べる → 失敗
  • wp-login.php にアクセス → データベースで IP アドレスごとの失敗回数を調べる → 失敗(403)
  • wp-login.php にアクセス → データベースで IP アドレスごとの失敗回数を調べる → 失敗(403)

となります。いずれにせよデータベースにはアクセスするわけで、1回の試行の負荷はどれほど違い、全体での負荷はどれほど違ってくるのでしょうか。そこまでは調べていません。

apache のモジュールで制限する

データベースへのアクセス前に制限できれば負荷を小さくできるのは明らかなので、前述の .htaccess によるものに代わる、apache のモジュールはないか探してみました。

mod_bw は回数制限ではない、mod_dosdetector は特定ページ(wp-login.php)のみに限定できない、mod_dosblock は IP アドレスごとではない……と、どれも一長一短のようです。ModSecurity だと要求にかなっていそうですが、これだけのためには機能が豊富すぎてルールが難しく、まだ理解できていません。

mod_evasive というのは、IP アドレスごとのアクセス回数を制限できますが特定ページの指定はできないようで、 mod_dosdetector と同じです。しばらくのあいだ、これを試してみることにしました。


管理するいくつかのサイトで、実情に合わせて上述の対策のいずれかをとることにしました。

  1. 実際は、1回の失敗ですぐ制限をかけるようにするため、このページのコードを少し修正しました。

Weaver II テーマ で Youtube を埋め込む

少し前の記事

Jetpack by WordPress.com プラグインで Youtube の画を埋め込んでいるのだけれど、説明どおりにやっても小さくできない。縦は縮むのに横幅はそのまま。別の環境で見るとまたちがうのだろうか。

と書いたけれど、原因がわかった。

youtube を埋め込むには、

  1. Weaver II テーマは独自にショートコード weaver-youtube を持っているので、これを使う。横幅は percent というパラメータで指定する。
  2. 上記を使わず、Jetpack by WordPress.com プラグインのショートコード youtube を使う。ただし Weaver II テーマで設定されているスタイルと干渉する。

のどちらかによる。はじめ (a)に気づいていなかったので (b)の方法にしていた。気づいたいま、どうするか。記事を書く際にテーマやプラグインに依存した記述をすると、そのテーマまたはプラグインを外したときに変なことになる可能性がある。将来 Weaver II テーマを使わなくなる可能性と Jetpack by WordPress.com プラグインを使わなくなる可能性を比べると、後者のほうが断然低そうなので、やはり (b)の記述のままにすることにした。

さてそうすると、どちらの方法でも youtube を埋め込む iframe には class="youtube-player" が指定されているのだが、 Weaver II テーマではそれに対するスタイルが

.youtube-player {
    width: 100%;
}

と設定されていたのであった。(a)の方法では、その上で画像の横幅を制御しているのであろう。そのまま (b)の方法を使うと、前に書いたように、w=320 のような横幅指定を付けてもそれが適用されない。

ここでは、記事の記述は(b)の方法にしたので、このスタイル指定をやめるため、Weaver II テーマの設定画面の advanced Options → <HEAD> Section の Custom CSS Rules に

.youtube-player {
    width: auto;
}

と書くことにした。これでうまくいくようになった。

Weaver II テーマ に変えてみた。それにプラグインも追加 (その2)

このサイトの見かけを変更するためにテーマを Weaver II に変えた、というのが前回のお話。ついでに、プラグインもいろいろ入れ替えたり追加したりした。

多機能プラグイン

いつからか Jetpack by WordPress.comWP Total Hacks のように、ひとつで多くの機能を持つプラグインを使うようになった。そのために不要になったプラグインを削除した。たとえば、サイト情報の統計情報のためのスマイリー[1]を隠すとか、SNS の共有ボタンの設置やそれらへの自動投稿とか、favicon の設定とか、リビジョンコントロールの制御とか……。

追加したプラグイン

Yet Another Related Posts Plugin

以前は別の何かのプラグインで表示させていたのだがいつの間にか外していたので、このプラグインでふたたび「関連するかもしれない記事」を表示させることにした。

Picasa Express x2

数か月前から写真を Google+ 経由で Picasa に置いてみている。それをこんなふうにこちらから参照するためのプラグイン。

WP-Footnotes

ずっと前から使っているのだが、その頃にはプラグインの公式ディレクトリはなかったのか、作者のサイトから直接もらってきたか何かで、更新の通知がないためにずっとバージョン 0.9.1 のままだった[2]。この機会に探してみたらうんとバージョンが上がっていた。

CSS を管理画面で設定できるようになって便利になっていた。しかし何かの拍子にこれも含め WP-Footnotes の設定全部が消えてしまうようだ[3]。そこで備忘録としてここに書いておく。

  • マークは [ ] で囲い、算用数字。上付
  • 脚注の最後の戻りマークは、カッコをつけず、&#8617;

そして脚注の CSS は次のとおり。

ol.footnotes { 
    clear: both;
    border-top: solid 1px #444;
    font-size: 0.8em;
    line-height: 1.6em;
    padding: 0 2em;
}

AdSense Now!

これまでは不向きだと思って考えてもいなかったのだが、今後書いていきたい内容からすると、広告を載せてもいいかという気になってきた。サイドバーの広告はウィジェットの「テキスト」にそのまま書くことにして、個々の記事に付ける広告にはこのプラグインを使うことにした。

Amazon Widgets Shortcodes

これも広告。文中に画像や、文字へのリンクを簡単に埋め込めそうだったので、このプラグインを入れてみた。下書きで試した程度でまだ本格的には使っていないが、便利そうだ。ビジュアルエディターでしか使えないのがちょっと残念。

【2015年12月21日追記】このプラグインはその後 WordPress 本体がバージョンアップして以来、編集画面でうまく使えなくなっていた。手でショートコードを書き込めば使えていたのだが、2015年末、このブログ全体を SSL 化するに際して、とうとう対応できなくなってしまった。長らくメンテナンスされていないこのプラグインをあきらめ、AmazonJS に乗り換えることにした。

  1. 何もしないと画面の一番下あたりに表示される smily のこと。
  2. あまりに古いのでリンクにはしないが http://www.elvery.net/drzax/2006/02/10/footnotes-0-9-plugin-for-wordpress-2-0-x/ となっているのでその頃のものだったようだ。
  3. いまのところ明らかに、 Weaver-II テーマの設定を変更して保存するとこちらの設定が消えてしまう。

プラグインやテーマの国際化を少し楽に

すっかり忘れていたのですが

と思い出させてもらったので、ここに書いておきましょう。

これは世界で人気のプラグインやテーマの開発者向けの情報です。もとより私はプラグインもテーマも書かないし、したがって世界中から言語ファイルを送られて「大変だー」なんて思いをしたことはないのですが、たまたまその声を聞いて Makefile を miya さん に贈り、それがここで使われています。

WordPress の国際化

おさらいです。WordPress では gettext ライブラリおよびツールを使用して国際化します

プラグインやテーマの開発者は、その中の翻訳されるべきメッセージに __()_e() などのマークを付けておきます。こうしたプラグインやテーマから、マークされた文字列を抽出して POT ファイルと呼ばれる、翻訳者にとって原本となるものを作成します。この作業は WordPress の本家で配布されているスクリプト wordpress-i18n tools を入手して、これで行います。

翻訳者はこの POT ファイルを元に、メッセージをそれぞれの言語に翻訳した PO ファイルと呼ばれるものを作り、これを開発者に送ります。

開発者は PO ファイルを、実行時にすばやく読み込まれるようにバイナリ化された MO ファイルと呼ばれるものに変換して、これをプラグインやテーマに同梱して配布することになります。

少し楽に

完全に出来上がっていてメッセージが不変で、たまに「新しい言語に翻訳したよ」と送られてくるものを追加するだけなら、手作業でもさほどでもないのでしょう。しかし現時点で既に各言語の翻訳ファイルがあるところに、元のプラグインやテーマに手を加えてメッセージが変わってしまい POT が変更になって、これをいちいち各言語の PO に反映して、MO を作りなおすのがメンドクサー、という工程を自動化するのがこの Makefile です。

プラグインやテーマの開発者にとって詳しい説明は不要でしょうから、あとは簡単に紹介します。

POT の生成には上述の wordpress-i18n tools が必要です。

make pot
で POT を生成します。あとは外部ファイル LINGUAS に作成したい言語の locale を書いておき、適宜
make

で、必要な MO までが生成されます。


POT 生成の部分は本家のスクリプトですし、後半の部分も gettext 関連のところでよく見かけるものから拝借して、前半に WordPress 特有の設定を加えたものです。私ができるのはこの程度です。あとは誰かすばらしいプラグインやテーマを作ってくださいね。

WordPress で Google マップを使う (再挑戦)

以前に「Google マップを使う」を書きましたが、その後 WordPress も Google マップもずいぶん進化して、時代遅れになってしまいました。

意図してる使い方は次のようなものです。

  • 固定ページに位置情報を持たせる。その固定ページにマップが表示される
  • それらのインデックスとなるような、上記の各ページにリンクされたマークが表示された全体図が、別の固定ページがある

たとえば、会社案内のサイトで各支店ごとに固定ページを作り、それぞれに案内地図を掲載し、「支店一覧」の全体図が別にもうひとつある、というイメージです。Lightweight Google Maps はほぼ条件を満たしていますが、その便利な機能がこちらの思惑には合いませんでした。

ざっと探してみましたが、「固定ページに位置情報」というものはなかなかありません。そこで、固定ページではなく投稿に、というプラグイン RomeLuv Google Maps for WordPress を見つけたので、それを改変することにしました。

RomeLuv Google Maps for WordPress を改変

--- romeluv-maps.php.orig
+++ romeluv-maps.php
@@ -51,6 +51,12 @@
         'romeluv_maps_inner_custom_box',
         'post' 
     );
+    add_meta_box( 
+        'romeluv_maps_sectionid',
+        __( 'Maps', 'romeluv_maps_textdomain' ),
+        'romeluv_maps_inner_custom_box',
+        'page' 
+    );
   
 }
 
@@ -361,6 +367,7 @@
 }
 
 add_action('save_post', 'romeluv_maps_handle_savepost');
+add_action('save_page', 'romeluv_maps_handle_savepost');
 
 
 
@@ -385,7 +392,7 @@
         if ($romeluv_single_map_done) return $post_content_html; else $romeluv_single_map_done=TRUE;
     
     
-       if (!is_single()) return $post_content_html;
+       if (!is_single() && !is_page()) return $post_content_html;
         //return "".$post_content_html;
        global $wpdb,$post,$mapheight;
        $savepost=$post;
@@ -552,13 +559,25 @@
     
     global $wpdb,$post;
     $savepost=$post;
+
     
+    extract( shortcode_atts( array(
+          'cat' => '', // category ID
+       ), $atts ) );
+       if (esc_attr($cat) == '') {
+         if (isset($_GET[cat])) $get_cat = $_GET[cat];
+       } else {
+         $get_cat = esc_attr($cat);
+       };
+
+
+
     ////query all the posts to display on the global map
      $querystr = "
        SELECT wposts.* 
        FROM $wpdb->posts wposts 
        WHERE  wposts.post_status = 'publish' 
-       AND wposts.post_type = 'post' ". $whereadditional ."
+       AND (wposts.post_type = 'post' OR wposts.post_type = 'page') ". $whereadditional ."
        ORDER BY wposts.post_date DESC
     ";
     //echo $querystr; //useful for debugging your custom query
@@ -571,9 +590,7 @@
     
     if ($result_posts):
     
-    if (isset($_GET[cat]))  echo '<h3 id="map-category-heading">'.get_cat_name($_GET[cat]).'</h3>';
-    
-    
+    if (isset($get_cat))  echo '<h3 id="map-category-heading">'.get_cat_name($get_cat).'</h3>';
     
     $mapwidth=get_option('global_romeluv_mapwidth');
     $mapheight=get_option('global_romeluv_mapheight');
@@ -614,7 +631,7 @@
                            
                              $count++;  
                            
-                           if (isset($_GET[cat])) if (!in_category($_GET[cat],$post->ID)) continue; //this allows category filtering adding the $_GET parameter ?cat=xx
+                           if (isset($get_cat)) if (!in_category($get_cat,$post->ID)) continue; //this allows category filtering adding the $_GET parameter ?cat=xx
                            
                            if (is_category()) { if (!in_category($cat_ID,$post->ID)) continue;  }   //skip posts if viewing a category page, if those do not match the current category
                            

改変の内容は、

  • 固定ページの作成画面にも「Maps」の入力欄を表示する
  • 全体図の出力の際に固定ページも対象にする
  • 全体図を出力するショートコード [GLOBALMAP] に、オプションcat を追加する

です。この最後の項目は次のような事情です。

このプラグインのオリジナル版では、全体図を表示させるには、固定ページでショートコード [GLOBALMAP] を用います。特定のカテゴリーに属する投稿だけを全体図に表示するという絞り込みができます。その方法は、カテゴリーの ID をパラメータで付加して、http://www.example.com/map?cat=6 のような形で、全体図のページを呼ぶようにします。

しかし、WordPress 標準のメニュー機能でこのような形式のリンクを作る方法が思い浮かびません。そこで、むしろ複数の全体図のページを用意することにして(たとえば http://www.example.com/map1 と http://www.example.com/map6)、それぞれのページでのショートコードにオプションでカテゴリー ID を付けるようにしました(たとえば [GLOBALMAP cat="1"][GLOBALMAP cat="6"])

さて、ここでは固定ページに位置情報を付加して、全体図を作ることを想定しています。すると固定ページにもカテゴリーが設定されていないと、上記の絞り込みができません。テーマの functions.php か何かで

function add_category_to_page() {
    register_taxonomy_for_object_type('category', 'page'); 
}
add_action('init', 'add_category_to_page');

とやって、固定ページにもカテゴリーを設定できるようにしておく必要があります。

twentyeleven で Google マップが壊れる

実際に使用してみると、表示される地図が微妙に壊れていました。タイルの継ぎ目が合わずに道や川がずれているような感じになります。はじめ、自分が使っているブラウザか何かの環境のせいかと思って、いろいろ調べましたがわかりません。ようやく、テーマ twentyeleven にすると壊れて、twentyten にすると正常に表示されることに気がつきました。それから今度は twentyeleven のスタイルシートのどの記述が影響しているのか順に見ていき、ついに imgmax-width が付いているとこの現象が起こることがわかりました。これだけで随分と時間を費やしました。

このプラグインの影響下の img のみ max-width を解除するため、

div#romeluv-global-map img,
div#single-post-map img {
        max-width: none;
}

をスタイルシートに書いて、解決しました。