microCMS の仕様変更により画像ファイルアップロードの挙動が以下のようになりました。
- 画像ファイルを明示的に(再度アップロードで)上書きできる。
- 同名ファイルをアップロードしても上書きしなければ個別の項目として扱われる。
※ ただし、上書きした場合は画像の URL は変更される(GET API レスポンス内の URL は自動的に変更される)。
これは一見すると「GET API(リッチエディタ等) を経由して画像を扱っていれば、 画像ファイルを上書きしても従来通りで問題はない」ということになりそうですが、状況によっては注意が必要です。
以下は「GET API レスポンスに含まれる画像 URL が自動的に変更される ＝ 静的にビルドされているサイト内の画像 URL が自動的に変更される」ということではない という例です。
静的ビルドされているブログに、以下のような赤い背景の画像を含む記事があるとします。
この画像を青い背景に入れ替える必要がでてきました。まずは上書きで画像を再アップロードします。リッチエディタでは青い背景の画像が表示されているので順調に見えます。
しかし、ここで元の記事をリロードすると画像が消えてしまっています。これは「再アップロードしたときに画像のURLが変更された ＝ 元の画像ファイルが消えている」ためです(ブラウザ等のキャッシュが残っている場合はあります)。
今回はわかりやすくするためにリッチエディタで編集しているときにリロードしていますが、単純に再アップロードしただけでも記事が更新(ビルド)されるまでは画像が消えた状態になります。
従来の仕様でも上書きしたら(キャッシュが更新された時点で)画像が入れ替わってしまうので、あまりやらない操作だとは思いますが、「記事を再公開する前でも更新された画像が表示されるならよし」としていたのならば注意が必要です。また、画像を再アップロードしただけでは Webhook でのビルドは起動されない ので、そのまま放置してしまうと画像のリンクが切れたままになります。よって、再アップロードは慎重に行う方が良いということになります。
記事内の画像を更新する場合は、新しい仕様でも「同名ファイルを複数同時にアップロードできる」機能を利用する方が都合がよいようです。
上書きしないでアップロードした場合は、青い背景の画像も(ファイル名を変更しなくとも)メディア上に同時に存在できます。
この場合、「リッチエディタでは青い背景の画像を選択しなおして編集を行う」「ブログ上の記事では赤い背景の画像を表示」を両立させることもできます。
上書きするときに表示されるアラートでも「更新前のメディアファイルは削除されます」と出ているので、当然といえば当然な挙動ではあるのですが、従来の感覚で「再アップロードしてあとはキャッシュが更新されるのを待つだけ」という操作をしていると画像のリンクが切れたままの状態になることもあるのかなという感じです。
一方で、こちらの「消極的な対応」でも少し書きましたが、「同名ファイルを複数アップロードできる」機能を利用する方が安全(リンク切れが発生しにくい)に画像ファイルを扱えるので、画像ファイルの更新はこちらを活用する方が良いのかもしれません。
License: CC0 1.0 http://creativecommons.org/publicdomain/zero/1.0/deed.ja