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 に次のように書き加えてみた[1]

<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 というのは行儀が悪いのか[2]、なかなか根絶できない。

そして今日、検索で旧 URL をたどってくる人がなぜか増えている。確認すると、.htaccess の当該部分がすっかり消えている。ファイルの時刻を見ると、絶対に自分で何かをした時刻ではない。WordPress がこれを書き換えることはないと思うし、そうするとこれを置いているレンタルサーバの問題なのだろうか。なんだか気持ちが悪い。

  1. (A or B or C) and D は mod_rewrite の文法でどう書くのだろう。はっきりしないので冗長に書いた。
  2. ログを見るとアクセス頻度もやたらと多い

Organizerプラグイン

画像ファイルを管理するプラグインを探していて、見つけた。 [[http://imthi.com/organizer/|Organizerプラグイン]]は * wp-content/uploadsディレクトリ(または設定しているアップロード用ディレクトリ)とその中のサブディレクトリのファイルを一覧 * アップロード用ディレクトリ内のファイルのコピー・ファイル名変更・削除 * サブディレクトリの作成・名前変更・削除 * ファイルのアップロード * 画像の拡大縮小 * 複数ユーザとパーミッションに対応 * アップロード用ディレクトリでファイル名を変更したら、記事内での参照個所も自動的に変更 * roles に対応。[[http://redalt.com/wiki/Role+Manager|Role Manager]]で管理 というもの。特に最後の3点が嬉しい。そのほかはこの前に導入した[[http://soderlind.no/archives/2006/01/03/imagemanager-20/|ImageManagerプラグイン]]([[http://bd.dotted.jp/archives/85/|日本語版]])でカバーされていたので。 [[//pasero.net/~mako/blog/|ここ]]と、別の管理している某所にいれてみた。その某所ではうまく機能するのに、ここではディレクトリの中のファイルを見つけてくれない(‘No files in this directory’)。ほかのプラグインと干渉しているのか、はたまた別の問題なのか。 その某所とここの大きな違いは、[[http://support.sakura.ad.jp/support/manual/rs/setdom_h.shtml|ドメインのエイリアス設定]]にしていることか。これが何らか影響しているのか。 というわけで、インストールとだいたいの動作は確認できたが、こまかくは見ていない。

wp-dokuwiki手直し

===excerptの生成=== トラックバックの際、特に excerptを書かなかった場合、本文の冒頭から自動的に excerptを生成してくれるが、本文を最初から最後まで[[http://floatingsun.net/blog/code/wp-dokuwiki/|wp-dokuwiki]]で書いた場合、excerpt は空になってしまう。 これを機に、 > 概要\ > ほとんどのトラックバックは概要 ( excerpt ) を記述していないために、トラックバック欄に表示される内容が記事の冒頭部分となってしまっているものばかりです。トラックバックを受信した側は、そういったトラックバックでは記事の概要をつかめません。 >
概要 ( excerpt ) の重要性
ももっともと考え、できるだけ書くようにしようと思った((この記事はまさにexcerptを書くべきであるが、自動生成の試験も兼ねているので敢えて書かない))。 しかし、短い記事やささっと書くものなどわざわざexcerptを書くまでもないものも多いだろうし、それに本文の冒頭は「つかみ」としてexcerpt的に書くことが望ましいとも思う。やはり本文から自動的にexcerptを生成してほしい。 さて、WordPress本体か日本語化の部分に問題があるのかと散々探しまわった挙げ句、やはり wp-dokuwikiの側を直せばいいことがわかった。 wp-dokuwiki.php内のフィルタは、echoで出力し戻り値は空になっている。本文を本文として表示するときにはこれでいいのかもしれないが、今回のように別の個所で利用する際には具合いが悪い。echoで出力されているものを(echoでは出力しないようにして)いったん蓄え、戻り値で返すようにした。これで excerptが生成されるようになった。 === wp-dokuwiki プラグイン 0.3=== [[http://floatingsun.net/blog/code/wp-dokuwiki/|wp-dokuwiki プラグイン]]のバージョンが上がっていたので、入れ替えてみる。 /wp-content/plugins/wp-dokuwiki/lib/tpl/default/design.cssも適用されるようで、いろいろ見た目が違ってくる。すべての記事をすべてwp-dokuwikiで書くのならまあ統一もとれるだろうが、管理している某所のように執筆者や記事ごとに記法が違うと、CSSが適用されたりされなかったりで、見た目がバラバラになってしまう。 code や blockquoteくらいは残してほかは使わないようにして、WordPressのthemeに合わせるようにしたい。 リンクの種類にしたがってアイコンがつくなどいろいろありそうだが、パスが違っているのか、ただ置いただけではうまく働かなかった。詳しくはまだ見ていない。

lightbox2

山頂からの眺め [[http://www.4mj.it/lightbox-js-v20-wordpress/|Lightbox 2 WordPress Plugin]]にした。見た目はかっこよくなるが、ちょっと重そう。 firefoxで確認するとLinux, Windowsとも問題はない。しかし、IE6 では、wp-dokuwikiと干渉して機能しない。wp-dokuwikiのjsを読まないようにすると(ほとんど使っていないと思われるので)、動くようになった。

Pages+プラグイン

複数の人間で(staticな)ページを書いていると、いつ書き換えられたかわかりにくい。管理画面で更新日時順にできればいいのだが、と思ってプラグインを探してみた。そのものではないが Pages+ をほんの少し直せば目的に合いそうだ。slug は要らないので削って、post_author, post_modified をつけ加えた。
@@ -131,7 +134,9 @@
 	$sort_cols = array(
 		'menu_order',
 		'id',
-		'post_title'
+		'post_title',
+		'post_author',
+		'post_modified'
 	);
 	
 	$sort_orders = array(
@@ -142,7 +147,7 @@
 	$orderby = (!array_key_exists('orderby', $_GET) || !in_array(strtolower($_GET['orderby']), $sort_cols)) ? 'menu_order' : $_GET['orderby'];
 	$sortorder = (!array_key_exists('sortorder', $_GET) || !in_array(strtolower($_GET['sortorder']), $sort_orders)) ? 'ASC' : $_GET['sortorder'];
 	
-	$sql = "SELECT ID, menu_order, post_title, post_name, guid FROM $wpdb->posts WHERE post_parent = $parent_id AND post_status = 'static' ORDER BY $orderby $sortorder";
+	$sql = "SELECT ID, menu_order, post_title, post_name, guid, post_author, post_modified FROM $wpdb->posts WHERE post_parent = $parent_id AND post_status = 'static' ORDER BY $orderby $sortorder";
 	$rows = $wpdb->get_results($sql);
 	$num_rows = count($rows);
 	?>
@@ -166,6 +171,18 @@
 		< ?php } else { ?>
 			Title
 		< ?php } ?>
+		&nbsp;|&nbsp;
+		< ?php if($orderby != 'post_author') {?>
+			<a href="<?php echo pp_link_self($parent_id, array('orderby'=>'post_author')); ?>" title="Order by Author">Author</a>
+		< ?php } else { ?>
+			Author
+		< ?php } ?>
+		&nbsp;|&nbsp;
+		< ?php if($orderby != 'post_modified') {?>
+			<a href="<?php echo pp_link_self($parent_id, array('orderby'=>'post_modified')); ?>" title="Order by mod-time">Upd Time</a>
+		< ?php } else { ?>
+			Upd Time
+		< ?php } ?>
 		<br />
 		<strong>Sort order:</strong>
 		< ?php if($sortorder != 'ASC') {?>
@@ -193,7 +210,8 @@
 				
 				<th scope="col">Order</th>
 				<th scope="col">Title</th>
-				<th scope="col">Slug</th>
+				<th scope="col">Owner</th>
+				<th scope="col">Updated</th>
 				<th scope="col"></th>
 				<th scope="col"></th>
 				<th scope="col"></th>
@@ -222,7 +240,8 @@
 				} else {
 					echo "<td>$row->post_title</td>n";
 				}
-				echo "<td>$row->post_name</td>n";
+				echo "<td>" . get_author_name($row->post_author) . "</td>n";
+				echo "<td>$row->post_modified</td>n";
 				if(function_exists(get_guid))
 				{
 					// if available, makes use of the 'Guid Rebuild' plugin (also by me!)

プラグインいくつか

=== Edit Comments === [[http://bd.dotted.jp/archives/67/|BirDesign]]で見て。readme.txtにあるように、 いくつかのphpを修正。 === Search Everything === 同じく[[http://bd.dotted.jp/archives/40/|BirDesign]]で見て。別の記事の[[http://bd.dotted.jp/archives/45/|全角のスペースでAnd検索]]を実現すべく、search_everything.phpの最初の関数 add_comments_search_whereの10行めほどに $q['s'] = str_replace(' ', ' ', $q['s']); を加えた。 === SOMY SpamBlock Japanese === [[http://wp.somy.jp/jump/spam-block-jp|SOMY.jp]]より。”ひらがな”か”カタカナ ”が指定文字数以上、指定回数以上ないとスパムとみなす。 === WP-ShortStat === [[http://bd.dotted.jp/archives/73/|BirDesign]]で見て。「ダッシュボード」にShortStatという見出しができ、そこでアクセス解析の結果が見れる。日本語検索語句の文字 化け対策を施した。 === Link Rel === [[http://bd.dotted.jp/archives/83/|BirDesign]]で見て。ちょっとだけ似たようなも のを直接header.phpに書いていたが、こっちのほうがスマートなので。header.phpに < ?php linkrel(the_ID()); ?> === SearchWord Highlight === http://hiromasa.zone.ne.jp/blog/archives/294/ より。 === LightboxJS === [[http://bd.dotted.jp/archives/42/|BirDesign]]で見て。

PHP Markdownプラグイン

PHP Markdownプラグインを入れてみる。 ひとつだけの記事をこれにすることができず、導入するならすべての記事を、と注意書がある。 が、試したところ、記事ごとに違った記法にしても大丈夫そう。