つい最近気付いたんだけど、サイドバーにある月別アーカイブが使えなくなっていた。
クリックしたらその月の過去記事に飛ぶんじゃなくて、なぜかトップページに飛ばされる。
『.htaccess』辺りが怪しいなーと思ってちょこちょこやっていたんだけど、違った。
悪さをしていたのは『Robots Meta』だった。

このブログの月別アーカイブのURLは『http://www.hosimitu.com/2010/02』なんだけど、
『Robots Meta』を有効化した時は『http://www.hosimitu.com/2010/02/』に書き換わっていた。
スラッシュの有る無しに関わらず意味的には同じだと思うんだけど、なぜか有効化したらトップページへ飛ぶ。
プラグインは現時点の最新版なので無効化する方法を取った。
これで解決したみたい。

WordPressで続きを読むを表示するためのプラグインの一つ『Ajaxified Expand Post NOW』に関して改良した。
このところずっと動かず、なんでだろうなーと思っていたのだけどやっと解決。
結局続きを読む関係のJavascriptがうまく行っていなかった。
素晴らしいプラグインの一つの『Head Cleaner』との相性が悪かったようだ。
『Head Cleaner』が作動する時に、『Ajaxified Expand Post NOW』のJavascriptを削除していたみたい。
なのでJavascriptを別のファイルとして読み込むことにした。

今回の解決策は結構特殊な例なので、試す時はご注意を。

作業の流れ

①『Ajaxified Expand Post NOW』のバックアップを取る。
②Javascript部分を分ける
③分けたJavascriptを修正
④プラグイン本体を修正
⑤アップロードして動作確認

こう言う流れで行こうと思う。
まずは各人バックアップを取るんだ！
面倒くさい人は本家からDLしよう。
失敗した時のためのフォローだから改良して無い人はバックアップもいらないか。

Javascript部分を分ける

ここからはコードの引用が多くなり、わかりづらいと思うので頑張ってね。
『ajaxified-expand-post-now.php』ファイルを改良する。
90行目付近の

echo <<<addJS

から、171行目付近の

AddJS;

までがJavascriptなので、ここを切り取って別のJavascriptファイルにする。
『expand.js』と言うファイルを作ってそこに貼り付ける。
あ、上のAddJSは違うよ。それらの間だけね。

分けたJavascriptを修正

まず『expand.js』の中にある『$aepnPluginLocate』を修正する。

http_request.open('POST', '$aepnPluginLocate', true);

下のように『ajaxified-expand-post-now.php』までの絶対アドレス、http://～～～に書き換える。

http_request.open('POST', 'http://あなたのドメイン/wp-content/plugins/ajaxified-expand-post-now.php', true);

次に、『$aepnLoadingMsg』を修正する。

function fetchLoading() {
	wH(gE('viewBox-'+postID), '$aepnLoadingMsg');
}

この部分は『続きを読む』をクリックした時に表示する、読み込み中という文字の設定だ。

function fetchLoading() {
	wH(gE('viewBox-'+postID), '続きを読み込み中');
}

余談として、プラグイン配布の本家のコメント欄には修正前153行目の

gE('close-'+postID).style.display = 'inline';

の『inline』を『none』にしろとか書いてあったけど、僕は変えてない。
ここを変えたら続きを読み込んだ時にhead部分も表示されてしまった。

プラグイン本体を修正

切り取った『ajaxified-expand-post-now.php』側には代わりに

if (!$more) {
	echo '<script type="text/javascript" src="http://あなたのドメイン/wp-content/plugins/expand.js"></script>';
}

と書く。
『ajaxified-expand-post-now.php』と同じ階層に『expand.js』を置いておく。
それに適するようにアドレスも変えてね。

アップロードして動作確認

ここまでの修正が完了したらアップロードして有効化だ。
phpのエラーが出たらその箇所を修正しよう。

最後に

これで一応解決した。
しかし、lightbox関係のプラグインの『slimbox2』が動かない。
以前に修正方法を探してきたんだけど、Javascriptファイルを分けたことでダメになった。
また修正方法を考えよう。

僕はWordpressのアップグレード時に自動アップグレードを利用している。
自分でアップグレードするのが面倒だからな。
ときどき自動アップグレードで不具合があるんだけど、今回もそれが出てきた。

アップグレード時に途中で止まり、再度アクセスすると『Briefly unavailable for scheduled maintenance. Check back in a minute.』と表示されて操作ができなくなる。
原因は不明なんだけど、解決策を発見。
『WordPressのアップグレード時に「Briefly unavailable for scheduled maintenance. Check back in a minute.」と出ても慌てない』
エラー画面の文章をコピペして検索した結果、上記のページを発見。
リンク先に書いてあるように『.maintenance』と言うファイルを削除した後、再度Wordpressのアップグレードを実行した。
そうすると完全にアップデートが完了した。

自動アップグレードにあたってデータベースをバックアップするように勧められる。
致命的なエラーが出てしまった時、復元できるようにだろう。
そんな中、自動でデータベースをバックアップするプラグインなんて言うのもある。
『WordPress Database Backup』
アップロード＆有効化した後、定期バックアップを有効にしている。
週に1度、自分のメール宛にSQLファイルが送られている。

自動化した事によって簡単にアップグレード出来るのは楽で良いね。

ブログの記事が多くなってくると、カテゴリーやタグで記事のグループ分けをすると思う。
そして訪問者が記事に来た時、そのカテゴリーやタグを参考に情報収集をするだろう。
そんな時に役立つのがパンくずリストによる誘導だ。
詳しくはググってもらうとして、今回はその導入と、タグをパンくずリストに組み込む方法を紹介する。

プラグインの導入

今回はyoastさんが作ったプラグインを利用する。
『Yoast Breadcrumbs』
導入方法はダウンロード＆アップロード。
そして有効化だ。
その後、single.phpなどに

<?php if ( function_exists('yoast_breadcrumb') ) { 	yoast_breadcrumb('<p id="breadcrumbs">','</p>'); } ?>

を書き加える。
これだけ。
プラグインの設定なんかはデフォルトのままでも良いし、自分でいじっても良い。

パンくずリストでカテゴリーの代わりにタグを使う

ここからが今回の本題。
カテゴリーの記事数が多すぎるので、代わりにタグにしようと思っていじってみた。
僕は個別記事にしかパンくずリストを表示しないので、それ以外は意識していません。
なのでカテゴリーなどにも表示しようとする人はこの方法ではダメかも。

まず、プラグインの管理画面で『Show category in post breadcrumbs?:』にチェックを入れる。
それからプラグイン本体を改造しよう。
『yoast-breadcrumbs.php』を改造する事になる。

if (is_single() && $opt['singlecatprefix']) {
	$cats = get_the_category();
	$cat = $cats[0];
	if ( is_object($cat) ) {
		if ($cat->parent != 0) {
			$output .= get_category_parents($cat->term_id, true, " ".$opt['sep']." ");
		} else {
			$output .= '<a href="'.get_category_link($cat->term_id).'">'.$cat->name.'</a> '.$opt['sep'].' ';
		}
	}
}

この部分を編集するので、この部分を削除するかコメントアウトする。
そして以下のように書き換えよう。Let’s コピペ。

if (is_single() && $opt['singlecatprefix']) {
	$tags = get_the_tags();
	if ($tags) {
		$i = 0;
		foreach($tags as $tag) {
			if($i > 0){
				$output .= ", ";
			}
			$output .= '<a href="'.get_tag_link($tag->term_id).'">'.$tag->name.'</a> ';
			$i++;
		}
		$output .= $opt['sep'].' ';
	}
}

書き換えたらアップロードして動いているか確認しよう。
複数のタグが割り振られていてもキチンと動くはず。

今日も今日とて唐突に繋がらなくなるこのブログ。
何が原因かは分からないが、解決の方法を色々試行錯誤中。
今回はメモ程度に繋がらないときの対策を残しておく。

どうやらwordpressで使っているMySQLに接続ができていなかったようだ。
xreaはphpMyadminって言うソフトでデータベースを管理している。
いざログインしようとすると『max_user_connections』とか表示されて出来ない。

どこぞから謎の接続があると仮定して、そのためにマックスなんだと考えた。
そうしたらとりあえず全員接続できなくすれば『max_user_connections』も解消するのだろうと考えた。
『こんなでいいのか？という復帰方法』を参考に『.htaccess』に追記。

order allow,deny
deny from all
allow from 自分のIP

こう設定すれば自分だけ接続できるはずなんだけど、実際は出来なかった（笑）
数分時間をおいてから.htaccessを元に戻してデータベースにログインする。
で、データベースを最適化する。
『オーバーヘッドってなんですか？』
データベースに何度もデータを書いたり消したりしていると、
オーバーヘッド化するらしい。
それを最適化するんだけど、パソコンで言うデフラグみたいなものかな？

オーバーヘッドに表示があると、それをクリックすれば個別のページに飛ぶ。
そして最適化を実行する。

これで終了。無事wordpressに接続が出来るようになった。

【2009.9.3 追記】
しょっちゅうオーバーヘッド化していたwp_optionsテーブルを修復してみた。
Aksmetのスパム削除時にテーブルが壊れる事があるらしい。
修復した後は結構快適なブログ生活に戻ったので、これが原因だったのかも。
チェックボックスにチェックを入れて、テーブルを修復するでOK。

【2010.4.19 追記】
関連記事を書きました。
『wp_optionsを自動で最適化するプラグイン』