Google マップを使う
WordPress でGoogle マップを使ってみる。
Plug ‘n’ Play Google Map
新しい版はPlug ‘n’ Play Google Map。旧版の日本語の解説がある。
マップ型の目次といった使い方になるのか。このサイトのマップ。
記事だけでなく、(静的)ページのマークも地図に載るように改造した (((静的)ページにも緯度経度情報を入力できるようにGeo プラグインもちょっと改造した。))。
ついでに、ページのマークは「アルファベット付」マークになるようにした。Tutorialのソースを参考に切り貼り。印刷時にもアルファベット付マークになるように printImage や mozPrintImage も設定するようにした。印刷用のマーク(例: “A”)は
http://www.google.com/mapfiles/markerAie.gif http://www.google.com/mapfiles/markerAff.gif
とか言う名前であった。
Inline Google Maps Plugin
“目次”マップではなく、個々の記事にマップを貼りたい。wp-dokuwikiプラグインに付属しているはずなのだが、うまく動かない。
Inline Google Maps Plugin というのがあった。これは簡単そう。
[gmap name='20061007' lat='38.27501322074987' lng='140.83431959152222' zoom='12' desc='プラグインのテスト'] [gmark lat='38.27501322074987' lng='140.83431959152222' desc='プラグインのテスト'] [/gmap]
ひとつのマップにひとつのマークしか置くことができない。
コメントにあるように、当分はこのままらしい。
NICとkernel 2.6.18
Intel PRO/1000GT
オンボードのLANチップがどうにも調子が悪く、新たにIntel PRO/1000GTを差した。で、使わないオンボードLANとieee1394をBIOSで殺しても、新しいNICは eth0 にはならず eth2 としてしか認識してくれない。
dmesg を見ると、
... e1000: 0000:00:0d.0: e1000_probe: (PCI:33MHz:32-bit) 00:0e:0c:xx:xx:xx e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection ...
なのに、/etc/network/interfacesには eth0やeth1と書いてもだめで、
auto eth2 iface eth2 inet static ...
としないと設定できない。どうしてだろう。
kernel 2.6.18
さて上記に伴って、まずvmplayerでネットが使えなくなってしまい、vmware-config.pl もカーネルとヘッダの情報が云々…でできないという状態だったので、思いきって sid の linux-image-2.6.18-1 に入れ換えてからやることにした。
vmplayerもすっかり入れ換えて、これは動くようになった。
別に入れているモジュールも入れ直し。nvidia-kernel-sourceは特に問題なし。shfs-sourceはコンパイルできず。バグ情報を見つけて、shfs-0.35-6-2.6.18.diffのパッチを当ててようやくできた。
e1000モジュールはカーネル同梱のもので動いているのでそのまま。というか新しいものを持ってきてコンパイルしようとしたが、まずバージョン情報を取得できず、これは2.6.18では UTS_RELEASE が include/linux/version.h と別になって include/linux/utsrelease.h になっているからのようだ。で、Makefileを書き換えてみたのだが、今度は
error: 'struct skb_shared_info' has no member named 'tso_size'
のエラーが出て失敗。e1000_main.cの’tso_size’を’gso_size’に書き換えればいいというのを見つけて、これでコンパイルできた。
fontconfig 2.4.1
設定ファイル
設定ファイルの配置が変更になったようで、/etc/fonts/conf.avail/ から/etc/fonts/conf.d/ にリンクが張られていると有効となるようだ。で、この中に 51-local.conf というのがあって、それで /etc/fonts/local.conf を読み込むようになっているので、ローカルの設定は結局 /etc/fonts/local.conf に書けばよさそう。 ところで debian 的には、/etc/fonts/conf.avail/ 以下の内容を書き換えたい(上書きしたい場合)はどうするのがよいのだろう。例えば 90-synthetic.conf は「疑似斜体」と「疑似ボールド」を実現するのだが、このうち斜体は生かしたくてボールドは抑制したい。local.conf で embolden を false にしても読み込みの順番によって true にされてしまう。90-synthetic.conf を直接書き直すのだろうか。 ここでは、リンクを /etc/fonts/conf.avail/51-local.conf から/etc/fonts/conf.d/91-local.conf に張りかえて、local.conf が最後になるようにした。IPAフォントを総称名で
「sans」「sans-serif」で指定したときに、IPAフォント ((GRASS国際化版やオープンプリンティングプロジェクトで入手できる。))を用いるようにしたい。Xft フォントシステムの設定を参考にして、/etc/fonts/local.conf に
<alias>
<family>serif</family>
<prefer>
<family>Bitstream Vera Serif</family>
<family>IPAMincho</family>
</prefer>
</alias>
<alias>
<family>sans-serif</family>
<prefer>
<family>Bitstream Vera Sans</family>
<family>IPAGothic</family>
</prefer>
</alias>
<alias>
<family>monospace</family>
<prefer>
<family>Bitstream Vera Sans Mono</family>
<family>IPAGothic</family>
</prefer>
</alias>
のように書く。
ボールドはEPSONフォントを
EPSON プリンタに付属の CD-ROM に太明朝や太ゴシックなどのフォントが入っている ((もしCD-ROMを紛失したならEPSONダウンロードサービスから入手可能。))ので、ボールドは疑似を使わず、これらを用いるようにする。 /etc/fonts/local.conf では、まず疑似ボールドを抑制し ((そして前述のようにこの指定が最後に来て有効になるようにして。抑制しておかないと太字にデザインされたフォントをさらにボールド化しようとして醜くなる。))、
<match target="font">
<edit name="embolden" mode="assign">
<bool>false</bool>
</edit>
</match>
明朝 (IPAMincho) のボールドに EpsonFutoMincho, ゴシック (IPAGothic) に EpsonFutoKakugo をそれぞれ対応させる。
<match target="pattern" > <test name="family" > <string>IPAMincho</string> </test> <test compare="more" name="weight" > <const>medium</const> </test> <edit mode="assign" name="family" > <string>EPSON 太明朝体B</string> </edit> </match> <match target="pattern" > <test name="family" > <string>IPAGothic</string> </test> <test compare="more" name="weight" > <const>medium</const> </test> <edit mode="assign" name="family" > <string>EPSON 太角ゴシック体B</string> </edit> </match>ここでフォント名はフォントそのものに埋め込まれている名前 (fc-listで表示される)を書く。UTF-8 なら local.conf も UTF-8 にする。
ビットマップを抑制
武藤さんの日記にあるとおりなので、/etc/fonts/local.conf に
<match target="font" >
<edit mode="assign" name="embeddedbitmap">
<bool>false</bool>
</edit>
</match>
を書く。
「〜」(波ダッシュ、U+301C)
IPAフォントでは「〜」(波ダッシュ、U+301C)が表示されない。これについてはいろいろ意見があるだろうが、現実問題として、Firefoxであちこちのサイトを見る場合などかなり鬱陶しい。 根本的解決でなくても、表示する際に fontconfig あたりで置換することはできないのだろうかと思って検索してみると、やはり既にパッチがあった。 上記のもののうち必要な部分だけを取り出し、最新の fontconfig (2.4.1)に行番号を合わせたものを置いておく。 まず apt-get source fontconfig でソースを持ってくる。ディレクトリ debian/ の下にpatches/ というディレクトリを作り、その下に上記のパッチを置く。その際ファイル名の拡張子は .patch とか .diff にする。 あとは dpkg-buildpackage -rfakeroot で、自動的にパッチを当てながらパッケージができる。 パッケージをインストールした後、fc-cacheを忘れずに。MediaWiki
またもや随分間があいてしまった。
さて今度は訳あって某所に Wikiを導入。多言語を扱いたいという要望により MediaWiki にした。特に問題なくインストール完了。
一般公開するものではなく、閲覧もメンバに限りたいということで、LocalSettings.php に
$wgWhitelistRead = array( "Main Page", "Special:Userlogin"); $wgGroupPermissions['*']['read'] = false;この2行めが必要ということに気づくまで時間がかかってしまった ((1行めは、もし日本語でインストール場合は
$wgWhitelistRead = array ("メインページ", "特別:ユーザログイン");
として utf-8で保存する。))。
書込みももちろんメンバ限定なので
$wgGroupPermissions['*']['createaccount'] = false; $wgGroupPermissions['*']['edit'] = false;
Organizerプラグイン
mod_rewrite
しばらく間が空いてしまった。WordPress自体があまり手がかからないようで、ひととおり設定してしまえば特に問題もなく、書くこともない。
今回の件は WordPress カテゴリに含めるのも何だという気もするが、その関連ということで。
WordPress導入時、.htaccessに自動的に
# BEGIN WordPress
<ifmodule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</ifmodule>
# END WordPress
と書き込まれる。実在するファイル名・ディレクトリ名でない場合、/index.php が呼ばれるようになる。
さて、WordPress 導入以前に同じサイトで某日記システムを使っていたのだが、その URL は
http://www.example.com/?date=20050325
のようになるものであった。現在この URL で指示されるものはないのだが、上記により、404 エラーにはならず、トップページが表示される。
検索エンジンに旧い形式の URL が残っていて、しかもいま WordPress で作られたトップページがその旧い形式の URL の内容として着々と更新され続ける。WordPress で書いた最新の記事の内容が、http://www.example.com/?date=20050325 のものとして検索されてしまうのだ。
放っておいてもその連鎖は断ち切れないので、ロボット対策を参考に、.htaccess に次のように書き加えてみた (( (A or B or C) and D は mod_rewrite の文法でどう書くのだろう。はっきりしないので冗長に書いた。))。
<ifmodule mod_rewrite.c>
RewriteCond %{HTTP_USER_AGENT} archiver [NC]
RewriteCond %{QUERY_STRING} .*date=200.*
RewriteRule ^.*$ - [G,L]
RewriteCond %{HTTP_USER_AGENT} crawler [NC]
RewriteCond %{QUERY_STRING} .*date=200.*
RewriteRule ^.*$ - [G,L]
RewriteCond %{HTTP_USER_AGENT} robot [NC]
RewriteCond %{QUERY_STRING} .*date=200.*
RewriteRule ^.*$ - [G,L]
RewriteCond %{HTTP_USER_AGENT} slurp [NC]
RewriteCond %{QUERY_STRING} .*date=200.*
RewriteRule ^.*$ - [G,L]
RewriteCond %{HTTP_USER_AGENT} spider [NC]
RewriteCond %{QUERY_STRING} .*date=200.*
RewriteRule ^.*$ - [G,L]
RewriteCond %{HTTP_USER_AGENT} googlebot [NC]
RewriteCond %{QUERY_STRING} .*date=200.*
RewriteRule ^.*$ - [G,L]
RewriteCond %{HTTP_USER_AGENT} msnbot [NC]
RewriteCond %{QUERY_STRING} .*date=200.*
RewriteRule ^.*$ - [G,L]
RewriteCond %{HTTP_USER_AGENT} findlinks [NC]
RewriteCond %{QUERY_STRING} .*date=200.*
RewriteRule ^.*$ - [G,L]
</ifmodule>
旧URLへのアクセスは、(1)せっかく検索して見つけて来てくれる人には今のトップページをみていただく (2)検索ロボットなら 410 エラーを返す、とした。こうしておけばそのうち検索エンジンから消えるだろうし、昔の記事に直接リンクしている人はほぼいないだろうから、旧URLへのアクセスは絶滅するだろうと考えた。
—-
という対策をとったのが実は1ヶ月前。だいたい思ったとおりに絶滅に向かっていったのだが、Yahoo の Slurp というのは行儀が悪いのか ((ログを見るとアクセス頻度もやたらと多い))、なかなか根絶できない。
そして今日、検索で旧 URL をたどってくる人がなぜか増えている。確認すると、.htaccess の当該部分がすっかり消えている。ファイルの時刻を見ると、絶対に自分で何かをした時刻ではない。WordPress がこれを書き換えることはないと思うし、そうするとこれを置いているレンタルサーバの問題なのだろうか。なんだか気持ちが悪い。