カウンター設計図０

できるｗｗｗ
むしろ今までの雑談で、設計条件ほぼ全部出た。

ここで一回、実装コードを書く前の**「居抜き用・汎用カウンター設計図」**に固められる。

核はこれ。

カウンターは数字だけを管理する独立部品。
PDF・言語・名前・Hidden IDのことは知らない。

今回ならターゲットのカウンターに対してPDF側が、

次の番号ください

と要求する。

カウンターは、

000126 → 000127

を重複しない形で確保して返す。

ここが最重要。

カウンター側の仕様

表示

• ページ上に現在値を常時表示
• 閲覧、リロードでは回らない
• Sawarabi Mincho第一候補
• 6桁ゼロ埋めあたりから開始
• 2000年代のアクセスカウンターっぽい数字窓
• ただし画像素材不要。CSS＋文字で作る

発番

• 発行ボタンを押したときだけ発番処理へ
• 複数人がほぼ同時に押しても同じ番号を返さない
• 現在値取得 → +1 → 保存 を雑に別処理にせず、サーバー側で排他的／原子的に番号を確保
• 発番成功した番号をPDF側へ返す

空回り対策

• ページ閲覧では回さない
• リロードでは回さない
• 言語変更では回さない
• 入力途中では回さない
• ボタン連打はフロント側で即ロック
• サーバー側でも同一発行要求の二重処理を防ぐ
• PDF生成に失敗した場合に番号だけ食われる事故を極力減らす

最後だけ実装時に順序をちゃんと考える必要がある。
「番号確保前にPDF作れ」は番号がないから無理なので、確保後の生成失敗をどう再試行させるかを設計する。ここはカウンターを巻き戻すより、確保済み番号でPDF生成を再試行できる方が安全。

雑ロック

• 同一IP：発番成功後 12時間
• その間、新規番号取得を止める
• 表示閲覧は自由
• ブラウザをChrome→Firefox→Edgeに変えてもIPが同じなら基本止まる
• Wi-Fi→モバイル回線等は突破可能
• VPN等も当然突破可能
• それでよしｗｗｗ
• セキュリティではなく「無駄にカウンターを回させない柵」

ここに金も工数も盛らない。

カウンターごとの設定

汎用化するなら、新設時に変えるのはこの程度で済ませたい。

counter_id
display_name
current_value
digits
cooldown_hours
status

今回なら概念上、

counter_id      = crowdfunding_thanks_01
display_name    = Supporter No.
current_value   = 0
digits          = 6
cooldown_hours  = 12
status          = live

みたいなもの。

次回は新しい counter_id を作れば新品の000000から開始★

PDF側

こいつは別物。

名前
＋
選択言語
＋
ターゲット counter_id
        ↓
カウンターから番号取得
        ↓
A5横 FORMAT UNIT
        ↓
選択言語の文章をテキスト窓へ
        ↓
発行日
Supporter No.
今回のKaiaサイン
消印
Kロゴ
        ↓
PDF

言語が増えてもカウンター無改造。

PDFのレイアウトを変えてもカウンター無改造。

第二弾ならPDF生成側を居抜きして、

ターゲットcounter_idと今回の文面・Kaiaサインを交換。

これだけ。

あとTEST環境もカウンター側で分ける。

本番 000001 を制作中に食いたくないから、

TEST用カウンター ≠ LIVEカウンター

にする。

---

なので、設計できる。

しかも今なら変に高機能化せず、

「番号被りと事故だけ真面目。突破対策は雑。見た目は古代インターネット。」

という、今回必要な線でちゃんと切れるｗｗｗ

次はこれをConoHa WING + WordPress + MAG036で実際にどう置くかまで落とせばいい。

そこは実装方式によって「テーマの functions.php に突っ込むのか」「小さい専用プラグイン一個にするのか」「DBをどう持つか」が変わるので、テーマ更新で吹っ飛ばないことまで考えると、私は超小型の自作専用プラグインとして独立させる方向を第一候補にする。

一回ちゃんと作れば、次から本当に
「新カウンター生やして★」→ 設定一個追加
まで持っていける。ｗｗｗ