スロット攻略 プロジェクトドキュメント

Appearance

機種（kishu）表示用文言マッピング（Issue #1203） ​

概要 ​

みんレポ由来の機種名と本サイトの表記を統一するため、表示用文言マッピング（データ文字列 → 表示用文字列）を導入している。

  • データ文字列: みんレポ・CSV 等のデータソースに含まれる機種名
  • 表示用文字列: 保存時に DB に格納する機種名（公開画面ではこの値をそのまま表示する）

マッピングは保存時のみ使用する。表示時の変換は行わない。 インポート・一括更新時にマッピングを参照し、保存済みの値はそのまま表示に使う。

マッピングの定義 ​

  • 定義場所: DB テーブル db_kishu_display_mapping（接頭辞付きでは例: wp_db_kishu_display_mapping）
  • カラム: data_kishu（データ文字列）, display_kishu（表示用文字列）
  • 管理画面での編集（Issue #1206）: WordPress 管理画面の「設定」→「機種表示マッピング」から、一覧・追加・編集・削除が可能。
  • テーブル作成手順: kishu-display-mapping-table-production.md。DDL 正本は KishuDisplayMappingInstaller.php を参照。

初期データ投入（Issue #1211） ​

初回テーブル作成後、既存の日別データ（db2023）に存在する機種名を初期データとして一括投入します。 初期状態では data_kishu = display_kishu（同一文字列）とし、差異が生じた時点で差分エントリを追加・編集します。

sql
-- 初期データ投入: db2023 の DISTINCT kishu をマッピングテーブルに投入する（Issue #1211）
-- display_kishu は data_kishu と同一文字列で初期化。既存行は IGNORE で重複スキップ（冪等）。
-- created_at は db2023 における各機種の最古の DAY（最初に出現した日）を設定する。
-- 接頭辞が wp_ でない場合は wp_ を環境の接頭辞に置換すること。
INSERT IGNORE INTO `wp_db_kishu_display_mapping` (data_kishu, display_kishu, created_at)
SELECT
    kishu,
    kishu,
    STR_TO_DATE(MIN(DAY), '%Y/%c/%e')
FROM `wp_db2023`
WHERE kishu IS NOT NULL AND kishu <> ''
GROUP BY kishu
ORDER BY kishu;

登録時の変換 ​

CSV インポート時、保存直前に KishuDisplayMappingService::to_display() が適用され、DB には表示用文字列が保存される。表示時は DB の値をそのまま使い、変換は行わない。

既存データの一括更新 ​

マッピングに基づき、次の4テーブルの kishu を「データ文字列 → 表示用文字列」へ一括更新する機能を用意している。

テーブル役割
db2023（日別×台別 raw）台別データ・ヒートマップ等の正本
db_daily_article_kishu_single_day_summary機種別ランキングの集計・機種名表示
db_daily_article_kishu_count_delta機種別台数の前日比（kishu キーで紐づく）
db_birthday_kishu誕生日ピックアップの関連機種名

注意: summary のみ古い機種名のままだと、ランキング表の機種名と台別詳細の突合がずれ、詳細ボタン（「表示」）が出なくなる。誕生日関連機種のみ古いままだと、誕生日ピックアップと日別記事の突合がずれる。反映処理では上記4テーブルを同一トランザクションで更新する。

WP-CLI での実行 ​

bash
# ドライラン（更新せず、更新対象件数のみ表示）
wp slot-kouryaku kishu migrate-to-display --dry-run

# 実行
wp slot-kouryaku kishu migrate-to-display
  • マッピングが空の場合は「更新対象はありません」と表示される
  • 各エントリごとの更新件数と合計が表示される
  • 永続キャッシュ（Redis 等）利用環境でも、WP-CLI 実行時はマッピング取得でキャッシュをバイパスするため、テーブル更新直後にコマンドを実行すれば常に最新のマッピングが参照される

将来の名前変更時 ​

表示用名を別名に変更したい場合は、次の手順でよい。

  1. db_kishu_display_mapping テーブルを編集する
    • 既存の表示用名を新しい表示用名に変えるエントリを追加する（または既存行の display_kishu を UPDATE する）
  2. 上記の一括更新コマンドを再実行する（--dry-run で確認してから本実行）

同じ一括更新機能を再利用できる。

管理画面での反映実行（バックグラウンド化） ​

「設定 → 機種表示マッピング」の「登録データに反映」は、管理画面から次の条件を指定して実行できる。

  • ドライラン（更新せず件数のみ確認）
  • 全件反映 / 選択分のみ反映
  • 選択分のみの場合は data_kishu ごとにチェックボックスで対象を指定

実行ボタン押下後は、処理本体はバックグラウンド（WP-Cron）で実行される。
画面にはジョブ状態（実行中 / 完了 / 失敗）が表示され、実行中は状態をポーリングして更新する。

実行中は「X / Y 件のマッピングを処理済み」を AJAX ポーリングで表示する。進捗は wp_options（kishu_display_migration_job_state）に永続化し、マッピング更新と 別リクエスト から読み取る。

トランザクションと進捗の可視性: マッピング更新は on_progress コールバック指定時のみ、各マッピング処理後に COMMIT してから進捗を書き込む（小トランザクション方式）。同一 wpdb 接続の未コミット更新は別リクエストのポーリングから見えないため。on_progress なし（WP-CLI 等）では従来どおり 1 トランザクションで全件更新する。途中失敗時はコミット済み分のみ反映される点に留意する。

進捗の wp_options 書き込みは件数・時間で間引く（10 件ごと / 2 秒間隔 / 先頭・末尾は必ず）。フロントのポーリング間隔（3 秒）より短い間隔で永続化し、更新の取りこぼしを抑える。

注意点 ​

  • WP-Cron が実行されない環境では完了まで時間がかかる場合がある。
  • 反映ジョブが長時間 running のまま残った場合は、次回実行時に stale 判定で自動リセットされる。

staging で admin-ajax.php が 400 の場合 ​

「登録データに反映する」押下時に 登録データへの反映開始に失敗しました。 が出る場合は、次の順で確認する。

  1. 管理画面で DevTools の Network を開き、admin-ajax.php リクエストを選択する。
  2. Request Payload に次が含まれているか確認する。
    • action=kishu_display_migration_start
    • nonce=<非空文字列>
    • kishu_display_migration_scope=all|selected
  3. Response を確認し、JSON で success:false + message が返っているか、非JSON（HTML/0）かを判別する。
  4. Console で window.kishuDisplayMappingAdmin を評価し、ajaxUrl, startAction, nonce が存在するか確認する。

補足:

  • admin-ajax.php の 400 は action 欠落時に発生しやすい。
  • staging のみ発生する場合、JSアセットの不整合やキャッシュで古いスクリプトが配信されている可能性が高い。