100日チャレンジ 23日目: カテゴリOGP画像処理の徹底改善とデータベース設計の最適化

2025年5月22日、100日チャレンジの23日目を迎えました。本日は、開発中のミニブログシステムにおける管理機能、特にカテゴリ編集時のOGP画像処理の強化と、関連するデータベース設計の見直しに注力しました。

本日の作業概要

作業日: 2025年5月22日
チャレンジ: 100日チャレンジ 23日目
作業時間:
- 開始: 16:00
- 終了: 19:20
- 実働: 3時間20分
GitHubリポジトリ: miyakawa2449/100DaysOfCode-016_miniBlog

詳細な作業内容

1. カテゴリ編集機能におけるOGP画像処理の実装とデバッグ (Flask, Python, JavaScript, HTML)

カテゴリごとに設定できるOGP画像のアップロード、トリミング、保存、そして表示までの一連のフローをより堅牢にするため、以下の実装とデバッグを行いました。

設定キーの修正: admin.py内でOGP画像のアップロードフォルダパスを取得する際、app.configのキー名が誤っていた (UPLOAD_FOLDER_CATEGORY_OGP → CATEGORY_OGP_UPLOAD_FOLDER) ためKeyErrorが発生していました。これを正しいキー名に修正し、エラーを解消しました。
JavaScript (Cropper.js) 関連のデバッグ: クライアントサイドでの画像トリミングに使用しているCropper.jsライブラリ周りでいくつかの問題に直面しました。
- CDNから読み込んでいるライブラリのintegrity属性が原因で読み込みに失敗するケースがあり、これを修正しました。
- Cropper is not definedやpreviewImage is not definedといった参照エラーが発生しており、edit_category.html内のJavaScriptコードの実行順序や関数のスコープを見直しました。previewImage関数の定義場所、Cropper.jsの初期化処理、トリミング座標を隠しフィールドに設定するロジックを再確認し、修正しました。
- Cropper.jsのオプションであるzoomOnWheel: falseが期待通りに動作していなかったため、初期化時のオプション設定を修正し、マウスホイールでのズームを無効化しました。
サーバーサイドでの画像トリミング処理の修正 (admin.py): フロントエンドから送信されるトリミング座標 (ogp_crop_x, ogp_crop_y, ogp_crop_width, ogp_crop_height) が文字列型として渡ってきていました。Pillowライブラリで画像トリミングを行う際、これらの座標は整数型である必要がある (isinstance(crop_x, int)) ため、トリミングが実行されないという問題が発生していました。この問題を解決するため、受け取った座標値をint()で明示的に整数型に変換する処理を追加しました。これにより、正確なトリミングが適用されるようになりました。
トリミング後の画像リサイズ処理の追加 (admin.py): OGP画像の推奨サイズ（例: 幅1200px, 高さ630px）に合わせるため、トリミング処理後にPillowのresize()メソッドを用いたリサイズ処理を追加しました。これにより、アップロードされた元画像のサイズやトリミング範囲に関わらず、最終的なOGP画像は常に目標の解像度で保存されるようになります。
古いOGP画像の削除処理の確認: 新しいOGP画像がアップロードされ、正常に保存された際には、既存の古いOGP画像ファイルがサーバーから正しく削除されることを確認しました。これにより、不要なファイルがサーバーに残存するのを防ぎます。
一時ファイルの削除処理の確認: 画像アップロードやトリミング処理中に一時ファイル (例: temp_...) が作成される場合があります。これらの一次ファイルが処理完了後に適切に削除され、ディスクスペースを圧迫しないことを確認しました。

2. データベース設計の見直し (database_spec.md)

OGP画像機能の実装に伴い、データベーススキーマにも変更を加えました。

Categoryテーブルへのogp_imageフィールド追加: 各カテゴリに紐づくOGP画像のファイル名を保存するため、Categoryテーブルにogp_imageカラム (VARCHAR型) を追加する仕様としました。これにより、カテゴリごとにユニークなOGP画像を指定できるようになります。
トリミング座標のデータベース保存方針の検討: 当初、ユーザーが設定したトリミング座標 (ogp_crop_xなど) もデータベースに保存することを検討しました。これにより、後から同じトリミングを再現できるメリットがあります。しかし、運用上のシンプルさや、OGP画像は一度設定したら頻繁に変更・再トリミングするケースは少ないと想定されることを考慮し、トリミング座標はデータベースに保存せず、画像アップロード時にその都度処理する方針としました。これにより、データベーススキーマが複雑になるのを避けられます。この方針に基づき、database_spec.mdのCategoryテーブル定義を更新し、トリミング座標関連のカラムは含めない形としました。

3. フォーム定義の確認 (forms.py)

OGP画像のトリミング座標をフロントエンドからサーバーサイドへ渡すために使用するフォームフィールドについて確認しました。

トリミング座標 (ogp_crop_x, ogp_crop_y, ogp_crop_width, ogp_crop_height) は、ユーザーに直接表示する必要がないため、WTFormsのHiddenFieldまたはIntegerField(widget=HiddenInput())を使用して実装することを確認しました。
前述の通りトリミング座標はデータベースに保存しない方針としたため、これらのフォームフィールドは、サーバーサイドで画像処理を行う際に一時的にデータを受け渡すための中間的な役割を担います。

個人的な所管

画像アップロード機能は、ブログ記事作成ページ、サイト全体の管理設定など、今後開発する多くの機能で共通して利用される基盤的な要素です。そのため、ここで徹底的にテストとデバッグを繰り返し、安定した動作を確保することが非常に重要だと考えています。

今日の作業を通じて、特に画像処理の内部ロジックやデータフローの整合性を高めることができました。エラーハンドリングやファイル管理など、細かな部分まで目を配ることで、より信頼性の高い機能に近づいたと思います。

想定されるユースケースに対する基本的な処理の流れは整いつつあるので、次のステップとしては、ユーザーがより直感的かつ快適に操作できるよう、UI/UXの改善にも取り組んでいきたいと考えています。

今後の展望

カテゴリ編集画面のUI改善 (特にOGP画像アップロード部分)
ブログ記事投稿機能における画像アップロード機能の実装準備
全体的なエラーハンドリングとユーザーへのフィードバック強化

引き続き、ミニブログシステムの完成を目指して開発を進めていきます。