WordPressの画像更新はIPTCとEXIFを残すか先に決めて元fileを保管する

WordPressへ画像をuploadするときは、表示用に縮小したfileと、撮影または購入時の元fileを分けて保管します。IPTCやEXIFのmetadataを残すかどうかも、upload前に決めます。画像を表示できることと、著作権、撮影情報、向きに関する記録を扱えることは別です。

WordPress 4.5 Beta 3の公式案内は、画像resize時のstrip_meta()で、IPTC、XMP、EXIF profileをwhitelistし、authorship、copyright、license、image orientationを維持する変更を案内しています。同版は開発中であり、本番siteではなくtest siteで試すよう案内されています。

画像を受け取った時点で、何を正本にするかを決めておくと、差し替えの判断が変わります。WordPressのmedia libraryに入っている一枚だけを元にして、後から別の大きさや切り取りを作ろうとすると、すでに縮小された画像をさらに加工することになります。撮影時のfile、購入元から渡されたfile、公開用に整えたfileは同じものではありません。どの段階のfileかを分かる名前と保存先にしておきます。

metadataも一括して残せばよいわけではありません。撮影日時や撮影場所のように公開を望まない情報が入る場合があります。公開pageで画像の説明として必要なのは、画像の内容を伝える代替textであり、file内部に記録された情報をそのまま見せることではありません。残す情報、外へ出さない情報、別の台帳で管理する情報を分けます。

表示用画像と元fileの役割を分ける

metadataを残せば権利関係がすべて解決するわけではありません。外部から受け取った画像なら、利用範囲、出典、改変の可否を別に確認します。metadataは、その確認を省く理由ではなく、情報を失わないための一つの手掛かりです。

たとえば商品画像を撮影者へ依頼した場合、fileの中に撮影者名があっても、web site、広告、印刷物のどこまで使えるかは別の確認が必要です。画像素材を購入した場合も、購入画面に書かれた利用条件や注文番号を、元fileと離さず残します。WordPressへuploadした日時だけを記録にしていると、どこから受け取った画像かを後で確かめにくくなります。

逆に、自社で撮影した画像でも、加工前のfileを誰が持っているかが分からなければ、更新時に同じ構図を作れません。制作会社や撮影者へ預けきりにせず、利用者側でも保存先と担当を把握します。作業を頼んだ相手が画像を管理することと、画像を利用するための記録を自分で持たないことは別です。

upload前に三つの情報をそろえる

1. 元fileの保存先を決める。
2. 画像をどのpageで、どの大きさで使うかを決める。
3. 出典、利用条件、撮影者など必要な情報を記録する。
4. test siteへuploadし、向きとimage sizeを確認する。
5. 公開後のpageで、切り取りと代替textを確認する。

画像の更新を外部へ頼む場合も、制作側が持つ加工済みfileだけを正本にしません。元file、利用条件、WordPressへ入れた画像を対応させて残します。作業を委託することと、画像の情報を取り戻せない状態にすることは別です。

保存先には、少なくとも元file、公開用file、使用するpage、利用条件を結び付けます。folder名だけで管理するなら、日付、案件名、画像の内容をそろえます。画像を同じ名前で上書きすると、以前のpageで使っていたものと区別できなくなります。既存の画像を差し替えるときは、どのpageのどの位置に出ているかを確認してから、新しいfileを登録します。

WordPressが作る表示サイズと、元fileの大きさも分けて見ます。本文で使う横幅、一覧で使う小さな画像、画面幅によって選ばれる画像は同じ用途ではありません。元fileを大きく保管していても、公開pageで重要な部分が切れていれば、画像の役割を果たしません。商品全体を見せる画像なのか、手元の作業を説明する画像なのかで、切り取りの基準を先に決めます。

向きは管理画面上の見え方だけで済ませません。upload直後に正しく見えても、実際のpage、一覧、mobile幅で表示が変わることがあります。縦長の写真を横長の枠へ収めたとき、人物や商品が途中で切れていないかを確認します。metadataにorientationが残ることと、すべての表示箇所で意図どおりの向きや切り取りになることは別です。

metadataを増やして表示を見落とさない

IPTCやEXIFを扱っていても、記事内の画像が横倒しになったり、重要な部分が切れたりすれば利用者は困ります。metadataの扱いと公開pageの見え方を、同じ確認表へ入れます。

確認表には、画像の内容、元fileの保存先、公開先のpage、利用条件、担当、公開後に見る画面を並べます。画像が十枚を超えると、file名だけで判断する作業はすぐに崩れます。説明用の仮画像、実際の商品画像、購入素材を同じfolderへ混ぜない方が、誤って公開する事故を減らせます。公開できない画像には、理由と使わない範囲を残します。

差し替え後は、旧画像をすぐ消す前に、既存の記事や固定pageで参照が残っていないかを見ます。同じ画像を複数pageで使っている場合、一か所の見た目だけを直しても、ほかのpageの説明と合わなくなることがあります。不要になったfileを整理する判断と、公開中のpageを壊さない確認を一つの手順にします。容量を空けることを急いで、元fileまで失わないようにします。

metadataの扱いが分からない場合は、公開のために必要な判断を先にします。利用条件が確認できない画像は公開用に使わない。撮影者や出典が分からない画像は、後から説明を足せるまで保留する。元fileがない画像は、再加工が必要になる場所へ安易に使わない。この順序なら、技術的な情報を完全に読み解けなくても、公開と管理の責任を曖昧にしません。

最初の一手は、画像を一枚選び、元fileの保存先、利用条件、WordPressで使うpageを一行へ書くことです。その情報がそろってからuploadします。