未分類 Archive

以前書いた、Disable Revisions and Autosave pluginsというエントリーで困っていた、WordPressのパーマリンクを連番にする方法の解決策が分かった。一般的には%postname%、すなわち投稿スラッグを使う解決策が知られているみたいですが、ここではあくまでも%post_id%にこだわって解決しています。

関連リンク（%postname%を使った解決策を紹介しているサイト）

WordPressで公開順に投稿IDを振っていく方法 – Liner Note

WordPressのURIを公開順で連番にする方法 – (DxD)∞

WordPress › フォーラム » page_idの数字が書き込んだ順に振り分けられない

WordPress %post_id%が連番にならない件 | ejtunes.com blog

制限事項

%post_id%にこだわった代償として制限事項（リスク）があります。お試しになる場合は、予めご承知おきの上で試してください。

1. 既に割り振られた%post_id%を連番に修正する過程が入りますので、新たにWordPressを立ち上げた人など、エントリー数がまだ少ない方以外にはお薦めできません。エントリー数の少ない人は連番にこだわらないような気もしますので、要するにあまり需要の無さそうな解決策だということになりますが…。orz

2. 投稿リビジョン機能とメディアライブラリ機能が使用できなくなります。但し、画像のUploadに関しては代替策を用意しています。他のメディアファイルのUploadに代替策があるかどうかは、必要に迫られてないので分かりません。これについては、何か代替策をご存知の方は情報提供をお願いします。

解決策

%post_id%が肥大化する原因は以下のとおり２つあります。この2つの機能を無効（使わない）にしないと、%post_id%の肥大化は止められません。

1. 投稿リビジョン機能
2. メディアアップロード機能

手順１：投稿リビジョン機能の停止

投稿リビジョン機能を無効化するPluginであるDisable Revisions and Autosave pluginsを導入しました。この対策で投稿リビジョン機能による%post_id%の肥大化は止めることが可能です。但し、もうひとつメディアアップロードによる%post_id%の肥大化が残っています。

手順２：IImage-browser 日本語版の導入（メディアアップロード機能は使用停止）

メディアアップロード機能を使ってメディアファイルをUploadすると、Uploadした各ファイルに%post_id%が割り振られるため、記事数とは無関係に%post_id%が肥大化します。そこで、IImage-browser 日本語版 というPluginを導入しました。この IImage-browser 日本語版 を使用すると、WordPress標準のメディアアップロード機能を使わずに画像ファイルをUploadすることができるようになるので、結果的に%post_id%の肥大化が止められるようになります。但し、アップロードした画像ファイルには%post_id%が割り振られなくなるので、副作用としてメディアライブラリ機能も使用できなくなります。メディアライブラリ機能を使用したい方は、潔く諦めて%postname%を使った解決策を利用してください。

手順３：既存%post_id%の修正

手順２までの解決策は、今後の%post_id%の肥大化を止めるものです。既に発生してしまった欠番は、手順２までの解決策では無くなりませんから、こちらは手作業による修正が必要となります。修正作業は、PhpMyAdminを使って行います。

1. まず、wp_postsテーブルから、投稿リビジョン及びメディアップロードによるレコードを削除します。

2. レコード削除によってpost_idフィールドの値が虫食い状になっていますから、それを詰めるようにひとつひとつ修正していきます。

3. post_idの値はwp_postmetaテーブルにもありますので、こちらもwp_postsの修正に合わせて修正が必要です。

なお、PhpMyAdmin上での修正作業は結構面倒だったので、私はwp_postsテーブルとwp_postmetaテーブルをエクスポートし、テキストエディタにてpost_idフィールドの値を手動修正後、書き戻す方法で修正しました。

手順４：auto_increment のリセット

手順３まで実行すると、過去エントリーの%post_id%が連番になり、今後の投稿も連番になって万々歳…、と思ったら、もうひとつ問題が残っていました。修正後最初の新規投稿に割り振られる%post_id%が最も小さい空番号にならないのです。

この問題の解決がなかなか出来ずに悩んでいたのですが、MySQLのauto_incrementをリセットすることで解決することができました。解決策が判明したのはテック☆クラウド » auto_increment のリセットという記事のお陰でした。その記事はWordPressの記事ではなかった（Nucleusに関する記事だった）のですが、たまたまヒットした記事を読み、「きっとこれだ！」と直感してPhpMyAdminから試してみたところ、ビンゴ！だったのです。

前置きが長くなりましたが、auto_incrementをリセットするにはPhpMyAdminから次のようなSQL文を実行します。

ALTER TABLE table_name AUTO_INCREMENT = 1

今回の場合は、table_nameはリセットしたいのはwp_postsテーブルですから、実際には次のように実行しました。

ALTER TABLE wp_posts AUTO_INCREMENT = 1

これで、無事%postname%を使わず、%post_id%のまま連番のパーマリンクを使用することが出来るようになりました。

関連リンク（auto_incrementのリセット方法ついてピックアップ）

テック☆クラウド » auto_increment のリセット

MySQLでauto_incrementの値を初期化する方法 – while(life)tech_onoue++;

アイテムやコメントの削除した後、欠番を作らない方法 – 株式会社M&Aバンク

以上。

西丹沢（世附川）

6月に行った日原が意外に遠くて活動時間が充分に取れなかったので、もう少し近くて良い場所は無いものかと考え、国道246号線一本でアクセスできる西丹沢へ初めて訪れてみた。

まず最初に丹沢湖から西へ延びる世附川へ。比較的長い谷に沿って林道が延びているので、車で奥まで入りながら、要所要所で停まって歩いてみようという計画でした。ところが、林道入口のゲートが閉まっていて車では入れない。仕方なく歩いてみましたが、予定していた奥の方の谷に辿り着くには相当な時間を要するため、途中で断念して引き返しました。

西丹沢の世附川まで行って、まともに撮れているのはヤマトシジミだけ、と惨憺たる有様。

西丹沢（中川川）

世附川沿いの探索を断念したあとで、残った時間を使って中川川へ転進しました。西丹沢自然教室までバスが通っている中川川は、世附川と違って奥の方まで車で遡ることが出来ます。但し、天候が悪いのは変わらなかったので、車で入れる最奥地のキャンプ場付近の様子を偵察するだけでさほど時間をかけずに帰ることにしました。

寺家ふるさと村（横浜市青葉区）

西丹沢からの帰還途中、都心方面へ近づくにつれて天候が少し良くなってきたので、寺家ふるさと村に寄ってから帰ることにしました。結局、虫影はここが一番多かった。天候の悪い日は、無理に遠出しない方が良いですね。

7月3日朝

昨年から継続観察しているエノキで、7月3日に今年第2化のアカボシゴマダラが羽化した。

↑ 羽化直後に葉上で休息中のところ発見。葉裏に蛹の抜け殻が確認できる。この個体は再びのアカボシゴマダラ（幼虫→蛹化）で蛹化を報告した個体。

↑ 上の写真を1枚撮った直後、うっかり枝に触れて驚かせて飛び立たせてしまった。「まだ1枚しか撮ってないのに！」と思ったが、運良く数十センチほど場所を移動しただけで、しかも翅を開いてくれた。

↑ 移動先の閂の上はつるつる滑って安定しなかったらしく、風が吹いたところで再び舞い上がって、今度は5mほど離れた街路樹の梢に移動した。この日は風が強く、しばらく枝にしがみついていたが間もなく飛び去った。ゆっくり休ませてあげなくてゴメンね。

7月3日午後

↑ ベニシジミ

↑ ベニシジミ（上のと同じ個体）

↑ チャバネセセリだと思う

↑ チャバネセセリの吸蜜

CASIO EXILIM EX-FC100で撮ったモンシロチョウとツマグロヒョウモン♀の写真をUp。

モンシロチョウ

街かどのヒメジョオンの花で吸蜜中のモンシロチョウが飛び立った瞬間をパスト連写にて撮影。

ツマグロヒョウモン♀

ツマグロヒョウモン♀

吸蜜中のツマグロヒョウモン♀が飛び立った瞬間をパスト連写にて撮影。上のモンシロチョウの同じようなシチュエーション。

P_BLOGからWordPressへのエントリー移転後、サイト内リンクや画像ファイルのリンクを貼り替えたりしているうちに、妙なことに気がついた。

このBlogでは、各エントリーのパーマリンクを”/archives/123″となるように設定している。そして移転エントリーの記事番号は63まで。つまり、移転後の新規エントリーの記事番号は64～になるはずなのだが、何故か211だの227だの、3桁の記事番号に跳ね上がっているのだ。

その謎は、phpMyAdminでwp_postsのレコード数と各レコードの内容を確認して納得した。どうやら、WordPressでは自動保存や下書き保存した記事がリビジョンとして保存され、それぞれに記事番号が与えられているらしい。うーん、これは嫌な仕様だな～。

で、ググってみたらすぐに解決策が見つかった。このWordPressの投稿リビジョン機能を無効にしてみた – Hinemosuという記事を投稿した方も、WordPressのバージョン2.6以降で取り入れられたこの機能に閉口したらしい。この方は、Disable Revisions and Autosave pluginsというPluginを居導入して解決したらしいので、私も同じプラグインを導入することにした。WordPressの自動保存機能とリビジョン機能を同時にOFFにするPluginだそうな。うまく動作すれば、記事番号がちゃんと連番になるはずだ。

なお、既にDatabaseに保存されてしまっていた不要なリビジョンはphpMyAdminからすべて削除し、大きな記事番号を与えられていた4記事に64～67の記事番号を付け治したので、今回導入したPluginが上手く動作していれば、記事番号は68になるはずだ。では、保存するよ？えい、ポチッ。

追記

6月30日追記

なんで記事番号が329になるんだ。orz
もう一度、原因をよく探らないと。

7月1日追記

wp_postsだけでなく、wp_postmetaの編集も必要らしい、と判断した。ついでに、categoryとtagもおかしなことになっていたので、wp_terms、wp_term_relationships、wp_term_taxonomyも修正。今度こそ、大丈夫だと思う。

7月7日追記

実は、上記のwp_pastmetaの編集をしても解決してなかったのだが、ようやく解決した。詳細は別エントリで解説する。

CASIO EXILIM EX-FC100を使って、カラスアゲハの飛翔写真の撮影に成功した。やっぱ良いね！EX-FC100！

ちなみに、撮影場所はいつものアカボシゴマダラ観察場所と道路を隔てた反対側の空地。空地なんだけど、小屋があって、地面に毛布みたいのが敷いてあり、この毛布が水を吸ってジトッと湿っているようで、そこに吸水に来たところを撮影した。

吸水中のカラスアゲハ／6月26日／川崎市高津区久本／EX-FC100／パスト連写

吸水中のカラスアゲハ／6月26日／川崎市高津区久本／EX-FC100／パスト連写

カラスアゲハの飛翔写真／6月26日／川崎市高津区久本／EX-FC100／パスト連写／トリミング

カラスアゲハの飛翔写真／6月26日／川崎市高津区久本／EX-FC100／パスト連写／トリミング

早くも第2化幼虫の蛹化を確認しました。

6月16日：終齢幼虫（脱皮直後）

上の幼虫があっという間に大きくなりました。

6月23日：上の写真と同じ個体です。1週間で見事な巨体に成長。

気がついたら蛹化してた…。色合いから言って、蛹化後すでに1日以上経過しています。

6月26日：上の個体が蛹化。越冬幼虫たちと違って、低い枝に移動しないでそのまま蛹化。

そういえば、5月8日のエントリーで雨のせいか羽化しない、と書いた越冬幼虫の蛹、結局羽化出来ませんでした。

6月26日：結局羽化できなかった越冬幼虫の蛹。昨年いくつか見つけた黒ずんだ蛹は、実は羽化できずに死亡した蛹たちであったことがよく分かる。

設置後、わずか2日でComment Spamの第1号が来ていたので、P_BLOG、Loggixで有効だった「日本語を含まないコメント・トラックバックを弾く」手段がないかとググった結果、SOMY SpamBlock JapaneseというPluginを導入することにしました。

2005年3月以降バージョンアップされていないようですが、とりあえず正常に動いているようです。

また、バックドアが実装されている指摘もありましたが、同等機能のある代替Pluginが見つからないし、wp2.1以上であればどうやら問題ないようなので、気にしないことにしました。

WordPressでBlogを立ち上げるにあたり、Themeとしてwp.Vicuna Ext. Customを選択しました。

理由その1

XHTML 1.0 Strict Validであること。P_BLOGやLoggixを選択したときと同じ理由です。

理由その2

Simpleかつデザインの美しいSkinが標準で何種類か用意されていること。写真が映えるよう黒っぽい背景にしたかったので、今回はとりあえずstyle-galaxyを選択しました。

理由その3

標準タイプのwp.VICUNAではなく、拡張版のwp.Vicuna Ext.を選択したのは、簡単なカスタマイズを手軽に実現するVicuna Configが使えるからです。

いや、実際このThemeは秀逸な出来だと思います。強いて言うなら、Global Navigationをカスタマイズしたいところですが、それは後で時間があるときにゆっくり検討することにします。

散策：日原再訪（6月4日）−速報版−で簡単な報告をしましたが、当日はいろいろ酷い目にあったので、今回はその話を。

予想通り、天候は悪かった。

6月1日や6月3日のエントリーで、天気予報に一喜一憂しながら、天候はあまりよろしくなさそうだということを半ば覚悟した上で日程を決め、行ってきたわけですが、予想通り天候は良くなかった。

雨こそ降らなかったものの、一日中空はどんよりと曇っており、見上げた先の山頂付近がガスに覆われている時間帯も多かった。そして思っていたより肌寒い。
覚悟していたこととはいえ、とても蝶が飛び回る天候ではなく、事実、目撃できた蝶は数えるほどだったのにはがっくり来た。 :-!

ところで、今日は凄く良い天気ですね。今さらですが、今日行くんだったなあ…。日程を決めたのは6月2日（火）ですが、当時の週間天気予報では晴れるのは明日（8日）で、今日は4日と同様の曇りの予定だったのに。

準備不足でヒッチハイクをするハメに。

奥多摩駅に11:06に到着してみると鍾乳洞行きのバスが12:40まで無かった。

え？なんで？前回はバス有ったよ？

でも、よく考えてみれば前回（5月9日）は土曜日だったが、今回（6月4日）は木曜日。列車もバスも平日と休日でダイヤが違うことは当たり前だ。にも関わらず全く失念していたのだ。他方面行きのバスも11:40まで無い。タクシー乗り場にもタクシーの姿はない。思わず途方に暮れたが、辛抱強く待っていたら11:30近くなってタクシーがお客を乗せて戻ってきた。喜んで乗ろうとしたのだが…。

「すみません。この後、予約が入ってますのでご利用いただけません。次に戻ってこれるのは1時間後くらいになりますが…」

思わず、目の前真っ暗。

2〜3分ほど考えがまとまらなかったが、一大決心して日原街道を歩くことにした。そして、車が通りがかったら、事情を話して乗せてもらおう！

平日なのでなかなか車が通りがからなかったが、バス停3つ分（15分程度）歩いたところで、運良く通りがかったカップルの車に乗せていただくことが出来た。ヒッチハイクなんて、生まれて初めてだ。お陰で、12:10頃には日原鍾乳洞に到着することができた。感謝。

いずれにせよ、列車・バスの乗り継ぎくらい、事前にちゃんと確認しておくべきだったと反省。休日と平日の違いくらい気付けよ！と。

帰りのバスに乗り遅れそうになって山道を10分間走るハメに。

まだあんのかよ！というツッコミが聞こえてきそうですが。

帰りのバスの予定は、日原鍾乳洞16:20発にしていました。

当日は小川谷林道と日原林道の両方を往復したのですが、最初小川谷林道を往復してバス停のある小川谷橋へ戻ってきたのが14:50でしたから、日原林道の往復にかけられる残り時間は1時間半ありました。

往復の予定ですから、1時間半を半分に分けると45分です。ですが、念のために復路に10分ほど余分に時間配分（往路40分／復路50分）することにして、15:30までに行けるところまで行ってUターンして戻ることにしました。

ところが、歩いているうちに何故か勘違いしてしまい、Uターンしたのが15:40。（自分では予定通りだと思っていた）そして八丁橋まで戻ってきたところで、残り時間が足りないことに気がついた。往路で小川谷橋〜八丁橋を23分かけて歩いたのに、復路で八丁橋を通過したのが16:10、残りたったの10分しかない。大慌てで残りの行程を走り、バス停にギリギリセーフで辿り着きました。あー、疲れた。Trailしに行ったわけじゃないのに。