ImageCacheモジュール

アップロードした画像のリサイズ処理などにImageCacheモジュールを使用しています。
このモジュールを導入すると、アップロードしたオリジナル画像とは別に、ImageCache専用のフォルダへ処理後の画像が保存されます。
その画像がブログ記事の本文などで使用されます。

当サイトでImageCacheが使用されるのは、ブログ記事の本文に貼り付けた画像のみにしてあります。
なのでWYSIWYG ImageCacheを使用した場合にImageCacheの影響を受けます。
アップロードした画像をブログ本文に貼り付ける(Insert)とHTMLコードが生成されますが、そのコードは以下のようになります。
※Insertモジュールを少し変更しています。
※記事保存前の状態です。
 

<a class="thickbox" title="" href="/media/mfront_2011062501.png"><img class="imagecache-body_middle" title="mfront_2011062501" alt="mfront_2011062501" src="http://phoenixknight.jp/media/imagecache/body_middle/mfront_2011062501.png" /></a>

 


記事を保存すると以下のように書き換わります。
※ImageCacheの箇所はimagesが付与される場合とそうでない場合があるようです。

 

 

 

<a class="thickbox" title="" href="/media/images/mfront2011062501.png"><img class="imagecache-body_middle" title="mfront_2011062501" alt="mfront_2011062501" src="http://phoenixknight.jp/media/imagecache/body_middle/images/mfront2011062501.png" /></a>

 


コードが変わるのはFileField Pathモジュールで画像のパスを変更しているためです。
※InternetExplorerとFireFoxとで結果がことなり、InternetExplorerの場合はFileField Pathモジュールの画像パスやURLエイリアスの句読点変換が反映されず、FireFoxの場合は反映されます。
※また、InternetExplorerの場合は画像挿入を1つの記事で複数枚挿入しようとするとInsertボタンをクリックした時点でHTMLソースコード表示になってしまいます。このとき、FileFieldにはアップロードした画像ファイルは格納されますが、HTMLコードは生成されません。

記事の作成時に使用したブラウザーの影響を受けてしまうようです。

本文に挿入した時点では、アップロードした画像ファイル自体はコードに表示されたパスに存在し、記事を保存するとファイル自体を移動しコードも書き換わるようです。
しかし、ImageCacheで処理した画像は移動ではなくコピー(複製)になっているようなので2箇所にファイルが存在します。
毎回そうなるわけでもありません。
また、ImageCacheの処理が正常に終わらなければファイルは作成されませんが、コードは生成されますのでリンク切れの状態になります。

さらに、ImageCacheの既存プリセットを編集し保存すると、既存のファイル(ImageCache/プリセット名以下)がすべて消去(Flush)されてしまうようです。
そのため、既存プリセットを編集した場合もリンク切れが発生してしまいます。

ImageCacheの消去(Flush)による再構築方法

再構築はcron実行時に行われるのではないだろうか?と思うのですがよくわかりません。
cronで実行してくれない場合を想定して、その場合の対処方法としては、再構築を手動でしてやることです。
その再構築には、トリガーとアクションを使用します。

具体的には以下のようなトリガーとアクションを登録します。
トリガー:「記事を更新時」※サイトに影響のない物を選択
アクション:「ImageCache: Generate ALL presets for this node's filefield images」

実際にトリガー条件を満たすように記事の更新します。
すでに稼動しているサイトでは数百以上の記事があると思いますので、これらを1つずつ更新していくのは時間のムダでしかありません。
そこで一斉に記事の更新をするために、今回はContent Mmanagment Filterの機能を利用しました。
※コンテンツ一覧の表示でも可ですが、1ページに表示する数を変更できページ数を減らせるのでCMFを使いました。一度に多くを選択するとエラーが発生するかもしれません。
実際、250ノードを対象にした場合はエラー(アクセス権違反)になりましたが100ノードの場合はうまくいきました。

CMFのフィルターで該当ノードだけのリストを表示し、すべてを選択したのち、「フロントページから撤去する」または「フロントページへ掲載する」を実行します。
※当サイトはフロントページへの掲載や撤去を切り替えても影響はありません。
※フィルターの一覧にあるページ単位で作業するので割りと楽に記事の更新ができます。

この更新によりトリガー条件が満たされアクションが実行されます。
アクションは「ImageCache: Generate ALL presets for this node's filefield images」の通り、ノードに含まれるfilefieldの画像に対してすべてのImageCacheプリセットを処理して作成します。そのため、実際に使用していないプリセットも処理され結果としてプリセットの種類だけ画像が重複して存在してしまいます。(※無駄なディスク容量を消費します)
また、FileFieldを使用せずにアップロードした画像が対象外になります。IMCEでアップロードした場合がそれに該当しますので、すべてのリンク切れの修正ができていない可能性があります。

※この再構築で生成されるImageCacheの画像の場所と記事の本文中のIMGタグ内のURLとが不一致だと何の意味もありませんので注意してください。
※FielField Pathで画像のパスを変更している場合は、本文中に使われているURLがアップロード時点の場合と記事保存後の場合があるので特に注意が必要です。

このImageCacheの再構築をもっと確実に効率よく行うには、やっぱりPHPコードを自作してそれをアクションに登録するのがベストだと思います。
IMGタグを使用している記事を検索するのはデータベースの「node_revisions」テーブルをエクスポートすればよさそうですし、FileFieldを使っている場合は、「files」テーブルをエクスポートすればよさそうです。
まずは、パスの統一をして、それからImageCacheの再構築用のPHPコードを書こうかなぁと思っています。
そのPHPコードについては今後の課題にしておきます。

リンク切れを発見する方法
何らかの理由でリンク切れが発生した場合は、通常、そのコンテンツに誰かがアクセスした際に400番台のエラーが Drupalのレポートに記録され、管理者がそれをみて発見となります。
しかし、それでは事後対応をしているにすぎませんので、事前に把握する方法を調査しました。

ブラウザのアドオンを使用するもの
link Evaluator(FireFox用)

Drupalモジュールを使用するもの
Link Checker

リンク切れチェックサイトを使用するもの
リンクチェッカー
W3C Link Checker
Another HTML-lint

※自サイトのTOPアドレスを入力すればサイトすべてをチェックしてくれるようですが、「すべて」の定義はチェックサイトによって変わってくると思います。
※チェックサイトからアクセスがあるのでDrupalのログでも確認できます。
※すべてを入念にチェックしてくれるサイトは非常に時間がかかります。

ロボットやクローラの巡回結果を使用するもの
Googleウェブマスターツール(アカウント登録が必要)

リンク切れはSCO対策の観点でも放置するべきでないとされていますので、SCO対策のノウハウやツールを扱っているサイトでいろいろ見つかると思います。
※前に導入した「Golobal Redirect」や「Path Redirect」モジュールは、Druaplで運用していると発生するリンク切れが起こらないようにするモジュールになります。

運用の基本的な考えは「早期発見」「迅速な対応」「再発防止」になりますので、それぞれで工夫が必要になります。
日々の変化に対応するためにも、PDCAサイクルを回すこと、そしてその仕組み作りが重要とされています。

「早期発見」を考えた場合にどの方法がベストなのか・・・
試しで②番のLink Checkerモジュールを使ってみようと思います。
これについては別の記事にします。

 

 

 

Drupalバージョン

Drupal 6.x

モジュール

ImageCache