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;
}

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

Firefox での印刷時の背景色

Firefox (Iceweasel) で、背景色を白以外(薄い灰色)に指定して使用している。プリンタへの印刷の際には「背景色を印刷しない」設定ができる。そのはずなのだが、しばらく前からこれが印刷されるようになってしまっていた。

検索してみて、もじら組フォーラムから Bug 652914 という情報にたどり着いた。いまだ解決されていないようだ。背景色を白以外に設定していて、かつ、プリンタに印刷することのある人というのはかなり少数なのだろうか。

自分の userContent.css に

@media print {
        * {background-color: white;}
}

と書いたら、とりあえず背景色は印刷されなくなった。この程度で回避できるくらいなら、すぐにも修正されそうな気もするのだが。

どうしよう日本語入力システム (その1)

Debian sid (i386) で、libgtk2.0-0 を 2.24.5-4 にアップデートしたら日本語入力システム ATOK X3 が使えなくなってしまった。2.24.4-3 に戻せば使える。そのあいだのバージョンではどうだかわからないが、いずれにせよ、ほかのアプリケーションとの兼ね合いで libgtk をそのままにしておくわけにもいかないだろうから、ごまかしておけるのも時間の問題だ。

そもそも、それまでずっと使っていた日本語入力システム Wnn7 が、やはりライブラリ (や、日本語文字コード) の問題でうまく動かせなくなり、その代わりにしかたなく ATOK X3 を使い始めたのだった。今度もまた本質的ではないと思われるライブラリの問題で使えなくなるとは非常に残念である。このへんが頻繁にバージョンアップのあるオープンソースと、どうしても対応が緩慢 (この場合、緩慢どころかもう停止してるのだろう) になる商用ソフトの相性の悪いところだ。

選択肢がない

日本語を使う者にとって日本語入力システムは必要不可欠だ。ハードウェアがどうとか OS が何であるかよりもっと人間よりのところにあると言ってもいい。キーボードのHappy Hacking Keyboard のページに、

アメリカ西部のカウボーイたちは、馬が死ぬと馬はそこに残していくが、どんなに砂漠を歩こうとも、鞍は自分で担いで往く。馬は消耗品であり、鞍は自分の体に馴染んだインタフェースだからだ。

いまやパソコンは消耗品であり、キーボードは大切な、生涯使えるインタフェースであることを忘れてはいけない。

[東京大学 和田英一 名誉教授の談話]

という言葉が掲げられているが、この「キーボード」を「日本語入力システム」に置き換えても何ら違和感はない。

それにもかかわらず、Windows 環境下ですら現在では選択の幅がほとんどない。その原因は Windows にバンドルされている MS-IME の寡占につきると思う。しばらく前の Web ブラウザ Internet Explorer 寡占問題と同じだ。このときヨーロッパは 「WindowsとIEの抱き合わせは競争法違反」と異議声明を出した。日本でも MS-IME に対して異議を申し立てるべきだったのだ。それまで多くの日本語入力システムがあって切磋琢磨していたものが、ほとんど姿を消してしまった。

OS のシェアから考えて、Linux 版のみの商用日本語入力システムが開発されるわけもなく、Windows 市場で稼げなければ Linux 版は存在し得ない(もちろん MS-IME の Linux 版が出るわけもないし)。こうして Wnn も Linux 版の ATOK も消えていきつつあるのが現状だ。


長くなってきたので、この項つづく

WordPress 3.2.1 日本語版への更新

WordPress 3.2.1 日本語版がリリースされました。この案内にもきちんと書かれていますが、読みようによっては誤解したり不安を感じたりする方もあるようですので、ここにやや詳しく書いてみます。

WordPress 日本語版パッケージ

配布されているWordPress 日本語版パッケージに含まれているものは

日本語リソース
本体のメッセージを日本語に置き換えて表示するためのもの
WordPress 本体
日本語リソースでカバーできない変更のため、いくつかのファイルを差し替えている

のほかに、オマケとして

テーマ Twenty Eleven
日本語版ではこのテーマのメッセージを日本語に置き換える日本語リソースを同梱している
テーマ Twenty Ten
日本語版ではこのテーマのメッセージを日本語に置き換える日本語リソースを同梱している
プラグイン Hello Dolly
日本語版では、「プラグイン」の一覧で表示される説明文を翻訳している
プラグイン Akismet
日本語版では、「プラグイン」の一覧で表示される説明文を翻訳している
プラグイン WP Multibyte Patch
マルチバイト文字の取り扱いに関する不具合の累積的修正と強化を行うもので、日本語版で独自に同梱しているもの

です。

はじめてのインストールは問題ない

これまで WordPress を使用していなかったところに、はじめて導入する場合は、何も考えることはありません。最新版をダウンロードしてインストールしてください。

自動更新

WordPress 日本語版の新しいバージョンがリリースされると、WordPress の管理画面(ダッシュボード)で、その旨の通知があります。案内に従って手順をすすめれば、新しいバージョンに更新されます。従来(3.2まで)は、この手順でパッケージに含まれるすべて、つまり上述の本体とオマケのすべてがパッケージ内のものに更新されていました。

オマケは更新されなくなった

3.2.1 以降、自動更新では、本体のみが更新され、オマケの部分は自動更新されないことになりました。たとえばテーマ Twenty Eleven のバージョンは、WordPress 3.2 日本語版では 1.1 で、WordPress 3.2.1 日本語版では 1.2 です。もし 3.2 日本語版で運用しているところで、本体の自動更新を行っても Twenty Eleven は 1.1 のままです。

もし、これらのオマケをまったく利用していなければ、以下の話は読み飛ばしてもかまいません。

テーマやプラグインは別途に

オマケのテーマやプラグインに、もし新しいバージョンがリリースされた場合、本体の更新とは別に、個別に「更新」の通知があります。後から独自に導入したテーマやプラグインとまったく同等の扱いになるということです。

オマケのテーマやプラグインであっても、本体のリリースとは無関係に新しいバージョンがリリースされることがあります。

日本語リソースはさらに別途に

テーマやプラグインは、本体とまったく別途に更新できます。しかし、ここで注意することがあります。従来のように本体のオマケとして配布されていたときには、それらの日本語リソースや説明文を翻訳していたものを配布できていました。しかし今後、個別に更新される際には、それらの含まれないオリジナル(英語版)になってしまうのです。

テーマ Twenty Eleven を例にとります。「更新」の通知があったら、まずこの Twenty Eleven を更新します。その状態では日本語リソースは存在しません (1.1 のときに存在していても 1.2 に更新したら消えてしまいます)。そこで、日本語リソースを別途入手して、適切に配置します。現時点での最新の日本語リソースは http://i18n.svn.wordpress.org/ja/branches/3.2/messages/twentyeleven/ja.mo です (この記事をずっと後にご覧になる方はバージョンやテーマ名にご注意ください)。これをダウンロードして、wp-content/themes/twentyeleven/languages/ の下に置き、サーバーが読める状態にしておきます。

同様に、テーマ Twenty Ten の日本語リソースはhttp://i18n.svn.wordpress.org/ja/branches/3.2/messages/twentyten/ja.mo にあります。

プラグイン Akismet や Hello Dolly をもし更新した場合は、「プラグイン」一覧に表示される説明文が日本語ではなく英語になってしまいますが、動作には何ら影響はありません (この説明文はそれぞれの php の冒頭にコメントの形で書かれているものです)。どうしても気になる場合は、やはり日本語版の配布元 (http://i18n.svn.wordpress.org/ja/branches/3.2/dist/wp-content/plugins/ あたりにあります) から、その部分を差し替えたものを入手して、適切に配置してください

WP Multibyte Patch

WP Multibyte Patch は新しいバージョン 1.5 で、この自動更新の振る舞いの変更に対応されました。

WP Multibyte Patch 1.5 をリリースしました。
今回は重要な変更があります。設定ファイル (wpmp-config.php) の設置場所が /wp-content の下に変わりました。設定ファイルをサイトでご利用中の方は、以下配置で再設定を行ってください。

/wp-content/wpmp-config.php

この作業は設定ファイルをご利用中のサイトにおいて 1.5 より古いバージョンから 1.5 以降のバージョンにはじめてアップデートした場合に1度だけ必要となります。設定ファイルをご利用でない場合は作業の必要はありません。

ということですから、注意してください。

公開 Jabber/XMPP サーバー

半年ほど前から、Jabber/XMPP サーバー STEP.imを公開しています。

Jabber/XMPP については、しばらく前に記事にしました。Jabber/XMPP をはじめるには、アカウント (JID) が必要です (ちょうどメールを使う際にメールアドレスが必要なように)。もし GMail のアカウントや WordPress.com のアカウントをお持ちであれば、それらを JID として使うことができます。これらのアカウントを持っていない、または使いたくない場合はこの STEP.im でアカウントを作ることができます。

また、グループチャット(Multi-user chat, MUC) の談話室をこの STEP.im に開設することができます (STEP.im のアカウントを持っていなくても開設・参加できます)。IRC によく似ていますが、後発なだけに、IRC の欠点を補って使い勝手のいいものです。

数年前から、自分のごく近傍で Jabber/XMPP を利用してきました。なかなか優れていると思うのですが、あまり話題になることがありません (Google トークや Facebook チャットなど、ユーザーに意識させないところで浸透しているようですが)。クライアント Gajimの日本語訳、サーバー ejabberd の日本語訳のお手伝いなども行ってきました。そしてとうとう公開サーバーを運用することにしたのです。

どうぞよろしくお願いいたします。

GNOME でのシャットダウンの禁止—最近の流儀

検索で古い記事「gdm でのシャットダウンの禁止」にだどりつく方があるようなので、最近のやり方を書いておきます。

その記事にあるように、私にとってそもそもなぜこの設定をしたいのかというと、うっかりミスの防止です。ログイン後のメインメニューで、「ログアウト」と隣り合って「シャットダウン」の項目があり、単にログアウトするつもりがシャットダウンしてしまうことがあるのです。

最近の流儀では policykit で設定で行うようです。その方法はdebian-user メーリングリストにあるとおりです。要点を簡単に記すと、

  • /usr/share/polkit-1/actions/org.freedesktop.consolekit.policy を書き換えるという回答もあるが、このファイルはそもそも設定ファイルではないし、バージョンアップによって書き換えられる(元に戻ってしまう)ので、よろしくない。
  • /etc/polkit-1/localauthority/50-local.d/ に適当な名前(ただし末尾を .pkla にする)のファイルを作り、その中に次のように書く。
    [consolekit]
    Identity=unix-user:*
    Action=org.freedesktop.consolekit.system.*
    ResultAny=no
    ResultInactive=no
    ResultActive=no
    [upower]
    Identity=unix-user:*
    Action=org.freedesktop.upower.*
    ResultAny=no
    ResultInactive=no
    ResultActive=no
    
これで GNOME のメニューから「シャットダウン」の項目が消えます。

異体字同一視検索

PostgreSQL をバックエンドに、フロントエンドを PHP でどうにか書いて、自前のデータベースを仕事に使っています。そこでたまに異体字を同一視してほしい(たとえば「斎藤」さんだったか「齊藤」さんだったかうろ覚え)ときがあるのですが、それほど頻度も高くないし、人間が注意して対処(「読み」も登録しているので「さいとう」で検索)すれば乗り切れるので、つい後回しにしていました。

そろそろ何とかしなければ、と web を検索したところ、「異体字同一視検索」を見つけました。そう、以前に調べたときにこの方と同じく「漢字データベースの異体字データベース」を見つけてはいたものの、そこからどうしようと思いながらそのままにしていたのでした。

さっそくそのページの説明のとおりに自分のスクリプトに組み込みました。こちらでは日本語のいわゆる旧字体があれば十分で、簡体字は必要ではないのですが、そのままで快適に機能しています。このように情報を公開していただいていることに大変感謝しています。