cyber BONMEE

デフォルトでは、記事のタイトルが2行になった時にその2行目が大きく下に離されていて大変なことに。

早速エディタでstyle.cssを開いて中身を確認すると、該当する部分にどうもよく分からない記述があります。


.post_left {
　　width: 410px;
　　height: 67px;
　　float: left;
　　line-height: 55px;
　　margin-left:18px;
}


何がよく分からないって、heightが67pxでline-heightが55pxというところが分からない。

何か裏でもあるのだろうと思って調べてみると確かに裏はありましたが、まぁその辺の話は置いといて、とにかく記事のタイトルが2行になった時に困りますね。ですから、下記のようにline-heightの行をコメントアウトしました。


.post_left {
　　width: 410px;
　　height: 67px;
　　float: left;
　　/*line-height: 55px;*/
　　margin-left:18px;
}


記事タイトルはデフォルトでh3だったのですが、それだと大き過ぎるため変更することに。

index.php、page.php、archive.php、single.phpの4ファイルに記述がありますので、それぞれを開いてh4～h6で試してみます。が、どれもしっくり来ません。

それで、とりあえずタグはh4に決めて、サイズはcssで130%に調整することにしました。上記の4ファイルでタイトル部分の記述が微妙に違っているため、下記のように分けて追加。


#contentleft h4{
　　font-size: 130%;
}
.post_left h4{
　　font-size: 130%;
}


次に、個別記事のページ。ここだけページタイトルが背景の枠を上に突き抜けていましたので、paddingで調整しよう・・・としたところ、左右のラインが切れてしまってまたまた困ったことに。

ちゃんとコードを読んでから手をつければいいのにとりあえず動くのは私の悪いクセなんですが、これは少々困りました。


.single_title {
　　width: 530px;
　　height: 67px;
　　background: url(images/single_title.jpg) no-repeat;
　　margin: 0;
　　/*padding: 0 0 0 15px;*/
　　padding: 1px 0 0 15px;
　　/*line-height: 67px;*/
}


結局、ここにも登場する大きな値のline-heightをコメントアウトし、上にpaddingを1pxだけ取ってラインの切れ目を目立たないようにすることでとりあえず。

後のことは明日以降にでもまたゆっくり考えるかも知れませんし、考えないかも知れません。

フォントサイズがデフォルトで12pxと固定でしたので、それを.85emの相対指定に。


body {
　　background: #332610 url(images/bg.jpg) repeat-x;
　　color: #FFF;
　　/*font-size: 12px;*/
　　font-size: .85em;
　　font-family: "MS P Gothic", "Hiragino Kaku Gothic","VL Gothic",Tahoma, Verdana, Arial;
　　margin: 0px auto 0px;
　　padding: 0px;
}


他の部分は同じくpx値による絶対指定のところを%による相対指定に変更。ブラウザのデフォルトフォントサイズは人それぞれですし、目がいい方ばかりでもありませんからね。

後は例によってJavaScriptの積み替えですが、今はほとんどの関数を外部ファイルに格納してありますので遅滞なく終了。


<script src=./xxx.js>//</script>
<script language=javascript><!--
var loadFlag = 0;
//--></script>
<script language=javascript><!--
checkCookie();
kickAccess();
checkStaySeconds();
//--></script>


これで大丈夫と思ったのですが・・・。

記事を展開する▼ Click here to read More… の行に設定してあるpaddingが地雷でして、そこでまた左右のラインが切れてしまうことに。

これ、cssファイルではなく各記事にstyle指定してあるため、修正しようとするとすべての記事を開いて書き換えなければなりません。面倒がってコピー＆ペーストで対応して来たツケが回って来た格好です。


<div style="margin:24px 0px 24px 0px";><a href=javascript:expand('google')>▼ Click Here to Read More...</a></div>
<div id=google style=display:none;>


しばらく迷っていましたが、もう一度各記事を見直してみるチャンスとも受け取れますので、該当部分のstyleを消してdivにclassを割り振る作業を始めることに。今後の修正も楽になりますしね。

ただ・・・エントリーの数が合計で403あります。全部手作業で書き換えですか？　ああ、やっぱりそうですか。

横着するものじゃないなぁ・・・。

■ スパム対策プラグインのAkismet

WordPressにはスパムを検知して隔離するAkismetというプラグインがあります。

1年ほど前に書いたエントリーと重複しますが、このAkismetも単にスパムを隔離するだけで、実は根本的な解決にはなりません。何故ならば、「隔離する」ことと「ブロックする」ことは別だからです。

ほとんどのスパマーは同じコメントをスクリプトで大量に送信しますので、書き込めたかどうかを人が目で見て確認することはありません。あくまでサーバーが返すステータスコードだけを見ており、そこで301や302、あるいは403や404が返れば「失敗」、200が返れば「成功」となります。

Akismetはブロックではなく隔離ですから、サーバーはステータスコード200を返しています。

彼らにとっては通ったコメントが表示されていようがいるまいが関係ないので、これはスパム送信成功を意味し、その該当記事は「今後も送り続ける」対象のリストに残ってしまいます。根本的な解決にならないというのはこの部分です。

じゃあ、どうすればいいか。

■ 根本的な解決策を探る

スパマーは各記事に配置されているコメントフォームから送信しているのではなく、コメントフォームに書き込んだ時と同じクエリをwp-comments-post.phpに直接送って来ます。ですから「それを止めてしまえ」というのもひとつの考え方ですね。

一口に「止める」と言っても、考えられる方法はいくつかあります。

とりあえず効果がありそうに思えるのは「HTTP_REFERERにブログ本体のドメインを含む場合にポストを許可する」ようphpコードを書き換えること。スパマーが自動送信して来るコメントは大抵referrerを持ちませんから、この方法はかなり有効かと思われます。

ただ、これには大きな問題点がひとつあります。それは「非常に面倒くさい」ことです。

phpコードを書き換える訳ですから、いくつものファイルに分かれているプログラムのすべてに目を通し、矛盾が生じないよう書き換えなければなりません。これだけ考えても余裕で眠くなります。

加えて、WordPressのアップデートを行うたびにその作業が待っています。

自分が書いたプログラムならば全体のブロックダイアグラムはおおむね把握していますが、それでもかなりの面倒な作業になるでしょう。ましてWordPressは他人様が書いたプログラムです。改造したものを売る気ならともかく、ただの日記趣味にそこまでの労力は費やせません。

■ 古典的な手法

昔からある古典的な方法としては「wp-comments-post.phpをリネームする」というものがありますね。スパマーはそこへ直接actionしてクエリを送って来るのですから、確かにこれも有効だと思われます。

ただ、この方法にも大きな問題点があります。それは「人の目でソースコードを見られたら一瞬でバレてしまう」ことです。

昔、Perlで書いたCGIにスパムがよく来ていた頃、投稿フォーム部分のコードを外部の.jsファイルに格納してdocument.writeで書き出していたことがあります。

action先をソースコードから消せるため当初は効果がありましたが、そのうち誰かが外部の.jsファイルを見たんでしょうね。一度バレたら後はもうザル状態になり、私はまたコードを書き換えてと、結局は無限ループのいたちごっこになってしまいました。

当然、この方法にも限界はあるということです。

■ 一番マシな方法はどれ？

ただ、action先をリネームする方法は、一度ざっと全体のコードを見通せばいいだけ（読む必要はない）ですから比較的簡単ですね。現時点でのデフォルトのアクション先はwp-comments-post.phpですから、そのファイル名が登場する部分がどことどこにあって、という情報だけを掴んでおけば簡単に対処出来そうです。

どのファイルにwp-comments-post.phpという記述があるかを調べるには、コンソールから$ perlを実行して下記のプログラムを打ち込みます。


$ cd wordpress/wp-content/themes/bible-scholar
$ perl
@_ = `ls | grep php`;
foreach $_(@_){
　$cat = `cat $_ `;
　if($cat =~ /wp-comments-post/){
　　print;
　}
}
C^d


テーマディレクトリにあるファイル名からphpが付くものだけを抽出して配列に格納し、foreachで回しながら`cat`でファイルの中身を吐き出させて$catに格納、wp-comments-postにヒットしたファイル名だけを出力させます。簡単ですね。

これを実行すると、なんとcomments.phpだけがヒットします。あれ？

そういうことなら、この方法が一番お手軽ですね。これにしましょう。かなりベタなやり方ではありますが。

■ 必要なファイルの書き換えとリネーム

wp-comments-post.phpをリネームするだけでは、action先がnot foundになってコメントポストが出来ません。ですから、まずはそこを書き換えます。

Dashboardから[Appearance]→[Editor]→[Comments.php]で開き、下にスクロールして真ん中付近にありますね。そこのwp-comments.post.phpを、何か適当なファイル名に変更します。hana-mogera.phpでもqawsedrftgyhujiko.phpでも何でも構いません。

次に、ローカルでwp-comments-post.phpを同じ名前にリネームしてからftpで送ります。これでコメントポストを試したところ、問題なく投稿出来ました。

ただ、これで終了という訳ではありません。上に書いた通り、場合によってはスパマーとの「いたちごっこ」が起こり得るからです。

あと、これは私が使用しているBible Scolarというテーマの場合に限った話かも知れません。他のテーマの場合は分かりませんので、上記のperlスクリプトなり他の方法なりで事前に丁寧に調べておく必要はあるでしょう。

■ all_in_one_seo_pack.phpを修正

ダッシュボードからプラグインエディタでall_in_one_seo_pack.phpを開きます。

Ctrl+fで”title”という文字を検索しながら下に飛ばして行き、

add_option(”aiosp_tag_title_format”, ‘%tag% | %blog_title%’, ‘All in One SEO Plugin Tag Title Format’, ‘yes’);

という部分を探します。

ここで、’%tag% | %blog_title%’ とある部分が曲者。アポストロフィ ( ‘ ) と日本語の2バイト文字の1バイト目をくっつけてデコードしてしまうようで、ここを離してやれば何とかなるのではと閃きました。

それで、%tag%の前に半角スペースをひとつ挿入。以下のように変更します。

add_option(”aiosp_tag_title_format”, ‘ %tag% | %blog_title%’, ‘All in One SEO Plugin Tag Title Format’, ‘yes’);

これがビンゴ。たったこれだけのことでタイトルの文字化けを回避。アホみたいな話です。

その下にある$search%という変数も文字化けを起こすため、同じようにスペースをひとつ挿入。

私はカテゴリーに日本語を使用していないため無関係ですが、日本語のカテゴリー名を使用しておられる方は%category_title%の前も空けておいた方がいいかも知れません。

このAll In One Seo Packは更新頻度が恐ろしく高いので、アップデートする度にここを書き換える覚悟が必要です。どうせ作者は2バイト文字が化けることなんか気にかけちゃいないでしょうから、どれだけバージョンが上がってもこの点はそのままでしょう。Donateしませんよ（笑）。

それはさておき。

ほんとにね。面倒がらずにコードくらい読んでおく必要はありますね。プラグインやテーマなどはサードパーティが製作するものですから、テーマの作者がドキュメントルートへのパスを勘違いしていたりとか（それでLinkの編集が出来なかったり）しますので、時間を見つけてでもコードは一通り読んでおくべきだと思いました。はい。

それでも多分、私はしないと思いますが。本気で困ってから動くという姿勢は、おそらく死ぬまで直らないものだと思っています。

おかしいな？と思って再度同じ操作を行うと、今度はFTPソフトが反応しません。固まったかな？と思ってFTPソフトを再起動しようとしたら、今度は起動しません。変ですね。

それで、デスクトップ上のアプリケーションをすべて終了し、一度ログアウトしてみました。

再度ログインしようとすると、Xサーバーは起動しますがKDEが起動しなくなりました。普段は使用しないGNOMEを試しましたが、こちらも起動しません。あれ？

勘のいい方は、ここまでの記述で私が何を失敗したかお気付きですね？

そうです。リモートにあるファイルのパーミッションを0606に変更しようとして、誤ってローカルの、それもホームディレクトリのパーミッションを0606に変更してしまったのです。

＄HOMEを0606にしてしまったら、そりゃあ起動しませんよね。実行権限がない訳ですから。

慌ててしまって何かトンチンカンなことをしてしまったらしく、パネルの設定などが全部消えてしまいました。.kdeを一旦バックアップして削除したつもりが、リストアする際に失敗していたようですね。もう本当に何をやっているのかと。

これ、私的には、原因を突き詰めれば「FTPソフトを使った」ことに行き着きます。リモート側のつもりでローカル側のパーミッション変更ボタンをクリックしてしまったからおかしくなったのであって、普段のようにコンソールからログインしてFTPコマンドでchmodしていたら「絶対に」間違える訳がないからです。

FTPコマンドはディレクトリをリカーシブに追いかけてくれませんから、階層が深いとFTPソフトは便利なんですけどね。パーミッション変更くらいはchmodすればいいのですから、横着しないで普段通りにすべきでした。

別にコマンド手打ちがソフトより優れているとか、そういう話をしているのではありません。コンピューティングにおける作業の手法はもちろん人それぞれです。

が、要は「自分が慣れていて」「安心出来る」方法を崩さないことが、失敗の可能性を排除する最良の方法であると言えます。