前記事に書いたプラグイン Featured Image From URL はとても良いと思うけれど、
一長だけでなく一短もある。
これを利用すればテーマが自動作成するサムネール画像を、
（もし他のプラグイン（カルーセルなど）を利用しなければ）ゼロに出来る。
が、このThemeの特徴であるフロントページの複数の大きさのサムネール、
プラグインで一つの元画像から取得するとイメージがリサイズされる。
また width と height も指定できない。
このため、GT Metrix の PageSpeed 評価が一気に10ポイント余り下がってしまった。
それほど気にしなくていいような気もするけれど、10ポイントは結構な数値だ。おまけに高速化という強迫観念に一度憑りつかれると、なかなか達観の境地に至ることができない。
一方、現況メディアライブラリには過去にアップした画像数が220点。これがそれぞれに複数のサムネールを持ち、なかには引っ越しその他の調整で増えてしまったためか、なんと一枚の画像が25個に分裂していたりして、不要なものをゴミ出ししたい、という生理的気分に猛烈に襲われる。
気分の問題だけでなく、不要なものは無いほうが良いに決まっている。と、Force Regenerate Thumbnails を実行してみても、まだ不要なものは残ってしまっているようだ（このプラグインは1年以上更新が無い）。
というようなこともあり、フロントページのサムネール調整と、メディアライブラリの画像数を限りなく減らす策を考えてみた。
とりあえずWPメディアにアップし、WPのアイキャッチを設定
WordPressにアップする画像は以下の2サイズ。なお、functionで取得させるサムネールサイズは80×60のみ。150×150はプラグイン WordPress Related Posts が取得する。
1）640×380
Wp Posts Carousel/Focus用
2）320×240
Wp Posts Carousel/Selections 用
テーマ ウィジェット MH Posts Large、MH Custom Posts 用
これにより画像+サムネール数は以下のように三種類となる。
1）640×380、150×150、80×60
2）320×240、150×150、80×60
テーマウィジェットアイテムの MH Custom Posts 用は150×150をアップすればは計二枚になるのだが、後に述べるようにしばらくすれば削除してしまうので、アップ画像サイズは上記二種類に統一。
同様の理由から、記事トップ用に常に624×370を作成するので、二種類の大きさを用意するのは面倒だし、（サムネールの数は増えてしまうものの）アップ画像サイズは624×370だけでいいのかもしれない（functionで326×245も生成させる必要があるが）。
記事トップのアイキャッチ画像
テーマの content-single.php でアイキャッチ取得用コードをコメントアウトしているため、記事トップにWPメディアからアイキャッチ設定した画像は表示されない。ここには以下の方法で画像を表示させる。
➾ 直接 Flickr に置いた画像をエンベッドで埋め込むか、またはHTMLで挿入
となると、Featured Image From URLはいらないか？
不要画像の整理
サムネールが表示されるのはどのページかというと、まずはフロントページ。ここで、フロントページはそれほど重要なのか、という問いが浮かぶ。サイトの玄関であり、サイトの顔なんだけれど、記事を読みに来る人は検索でダイレクトにある記事にたどり着き、場合によっては関連記事を読み、まれにプロフィールを覗く。いったいどれほどの人がHOMEから入り、あるいはHOMEから出ていくのだろう。
（と久しぶりに ResearchArtisanを見に行って驚いた。5月3日からデータが無いではないか。次々に色々起こるなあ。これはFooterのスクリプトタグをローカルのファイルで上書きしてしまったか？ or タグを何かの折に削除してしまったか私 ？ ➾ 再設定でOK）
NewStatPress で見ると圧倒的にHOMEへのアクセスが多いのだが、これを真に受ける気にはなれない。なぜならこのほとんどはリファーラースパムだと思われるからだ。こいつは実はHOMEにすら実際にアクセスしておらず、単にアクセス解析に足跡をぺたりと貼り付けているだけともいう。
とはいえ、やはりフロントページは大事にしたい。たとえ自己満足であっても。そもそも自己満足がなくて何の趣味サイトであろう。
要は、フロントページのサムネールは、ここに記事タイトルが表示されている間だけあればいいのだ。新しい記事を一つ書いたら古い記事リンクは一つ退場となる。その記事のフロントページ用サムネールはもういらないのだ。いちいち消していくのは面倒ではあるが、もしメディアライブラリにたまる画像数を最低限に保ちたければ、これをするしかない。
フロントページ以外のサムネールは、カテゴリなどのアーカイブページの326×245と、あとは WordPress Related Posts による関連記事の150×150であるが…。
フロントページに非表示になったら不要画像を削除するとして、付随作業は以下の二つのいずれかである。
1）FTPで150×150以外を削除する
これにより画像数はサムネールつき記事数と同数とはなる。なお、カテゴリ―アーカイブのサムネールも150×150が表示される。
2）不要画像をメディアライブラリで「完全に削除」する
カテゴリーアーカイブはサムネール無し、関連記事サムネールはプラグインデフォルトイメージのランダム表示（設定でサムネール無しも可）となる。
アイキャッチのサムネールを表示させたい場合は、投稿記事編集画面の（Featured Image From URL アイキャッチ設定欄）External Feature Image にFlickrの150×150の画像URLを入力する。
あるいは、Flickrに326×245をアップしてこのURLを設定すれば、カテゴリアーカイブのサムネールは規定通り326×245となり、関連記事サムネールは150×150にリサイズされる。
だが、Flickrは自動で150×150を含む複数のサムネールを生成するので、既にアップしてある画像からURLを取得入力するほうが簡単である。（Flickrからひっぱってくるのは自動生成されている他の大きさのサムネールでも、極端な話、アイキャッチ画像と同じURLでもかまわないのだが）。
ということで方針は、不要になったものはどんどん「完全に削除」、で行くことにする。これでWPメディアライブラリには常にフロントページ用の画像だけが残ることになる。当サイト現時点の設定では最高でも25±2点ほどである。何とすっきり。これだと引っ越しもものすごく楽である（もうしないつもりでいるが、人生どうなるかわからない）。
付記 Flickr の画像URLの調べ方
1）エンベッド用コードの取得方法
photostream でも Album からでも該当の写真をクリックし、右下のSharephotoアイコン をクリックし、Embedでサイズを選択、生成されたコードをコピペする。
もし画像上に Flickr の文字や情報を出したくない場合は、コピペしたコードから data-flickr-embed="true" と <script～/script> 部分を削除する。
2）直接サムネールのURLを調べる
同様に該当画像の右下のDownload アイコン をクリックし、ポップアップからVew All Sizes をクリック、Square 150 とか、Small 320 とか好みのサイズをクリック、表示された画像の上で右クリックし、「画像アドレス（URL）をコピー」でコピペする。
と、方針が定まったので、この際過去記事画像も掃除しようと思うのだが、さてうまくいくだろうか…。
付記 05/14
夜、酔い覚ましのソリティアをポチポチやる代わりに画像をポチポチした。結果、、メディアライブラリは18個まで減った。20メガぐらい圧縮できた。
今回の収穫はFlickrで画像編集ができることが分かったこと。スクエアの切り取り範囲を左右にずらすこととか、なかなかいい。
懸案事項
とやっていても、知らぬ間にライブラリに不要な画像が増えている。何なんだろうね、これ。けど、それは気が付いたらどんどん削除することに。
あと、メディアライブラリで削除して安心して、FTPでチェックするとまだ残ってたりするのはなじぇ？ まあこれも遠慮なく削除する。
今日のメイン作業はPDF。しこしこしことロリポップ永久サーバーのprovaiciao/pdf に移し、記事のリンクURLを変更。あとはWebCrowに置いてるやつもロリポップに移すかどうか、くらいまで来たわ。やれやれ。
その後確認したら188メガほど減っていた。wp-Xサーバーの管理画面に反映されるのにタイムラグがあったもよう。PDFも大きかったのだと思う。
それともうひとつの不思議。記事を修正更新すると、なぜかWPのアイキャッチ画像指定が消えてしまう。その都度再度指定しなくちゃいけないのか ？
付記 5/16 DBをどうするか
サムネールが勝手に増えるのが相変わらずで、やはりあまり気持ちは良くない。記事の更新や画像の編集で増えるのならまだしも、今日は何も触っていない古い記事のサムネールがまた生成されていた。プラグイン Auto Post Thumbnail が入っているのなら記事中の画像から生成されるのはわかる。が、このプラグインは停止させるだけでなく削除している。
これ以外のサムネール関連では Force Regenerate Thumbnails がある。不要なサムネールを整理してくれる＝削除してくれると理解していたけれど、挿入されている画像から勝手に生成もしてしまうのだろうか。1年以上更新されていないし、とりあえず停止してみる。
それから気になっているのはデータベースである。投稿記事情報のテーブルが wp_post,、サムネール情報がwp_postmeta ということらしい。 phpMyAdmin でじっくりと眺めてみた。wp_post が800あまり（7.7M）なのに、wp_postmeta が12,000（4.5M）ある。
このうち、meta_key が _thumbnail_id となっているのがサムネール関連らしい。これの meta_value が-1という数値のものがもしかしたら削除したサムネールのことだろうか。ということはこれは削除しても構わないのだろうか。不要レコードは消した、という記事は一件見つけたけれど、どういうレコードが不要なのかということは書いてくれていない。あとはバックアップを取って削除してみるしかないだろうか（不安だけど）。
もっともデータベースで一番でかい顔をしているのは wp_statpress の59.8M（合計84.3Mのうち)である。DB の自動削除現行3か月を1か月くらいにした方がいいだろうか。
ところで、土曜日に外付けHDDにアクセスできなくなった。仕事関連は全てこちらにあって若干焦った。現在FinalDataというソフトで救出➾新HDDに以降作業中であるが、これが時間がかかること！ バックアップの再考必至である。
コメント