WordPress のイベント日付が 1970 年になるときの記録確認

誤った日付を記録し来場者の案内を保つ

日付の出所と修正を記録するシートをダウンロード（Markdown、英語）

対象イベント名、WordPress 編集 URL、公開 URL、表示された日付、タイムゾーン、最後に正しく見えた画面を記録します。編集画面でも 1970 年なのか、ログアウトした公開ページだけなのかを確認し、同じサイトの正常なイベントと比べます。誤った日付が公開中なら、責任者から確定日程を受け取り、調査中の来場者向け訂正または問い合わせ経路を用意します。

英語のワークシートで、確定日付、元の行、保存済みフィールド、公開結果を分けて記録します。ポスター、前回開催分、端末の時計から正しい日付を推測しないでください。発生時刻と記録の担当者も残します。

確定日程と保存済み記録を照合する

すぐに保存せず、編集画面の開始日・終了日を確認します。手入力、複製、インポートのどれで作成されたイベントでしょうか。CSV なら元の行と開始・終了日時の列の対応を照合します。提供元は CSV の日付に `YYYY-MM-DD` を推奨しています。異なる形式や未対応の列は、使用中のインポーターの最新手順で確認します。[1][2]

再読み込み後も編集画面の日付が確定日程と一致するか調べます。インポートした一括データに影響があるなら、変更前に数件を標本確認します。提供元によれば、再インポートで一致する既存イベントが更新される場合があります。一括再投入を単なる診断として行わず、元ファイルとイベント ID を管理者用に保存します。[2]

検証環境でインポート・編集原因を切り分ける

復元点のある検証環境で代表的な一件を試します。元の行が誤っていれば行または列対応を修正し、そこで一件のインポート経路を試します。複製時に日付が失われたなら、新規の手入力下書きと比べます。編集画面が正しく公開表示だけ誤る場合、何度も上書きせず表示処理を管理者に調べてもらいます。

元データと保存記録を確認してから、テーマやプラグインの競合を検証環境で切り分けます。一つずつ変えて同じイベントの前後を比較します。提供元は検証環境を推奨しています。本番でテーマ変更やプラグイン停止をすると登録やナビゲーションに影響する場合があります。[3]

一件の修正を反映しサポートへの記録を準備する

責任者に正しい日付と最小の検証済み修正を承認してもらいます。反映後、ログアウトしたパソコンと電話でイベントの直接ページとカレンダーを開き、確定した開始・終了日時とタイムゾーンを確認します。チケット・登録リンクがあれば現在の行き先をたどり、正常だった別のイベントも再確認します。

1970 年が再発したら、検証済みの元の状態に戻し、イベント ID と URL、作成方法、編集フィールドの前後、無関係なデータを含まない例示行、プラグイン版、検証結果を管理者に渡します。公開ページが正確になるまで、主催者が指定した経路で確定日程を案内し続けます。[1]