【ITニュース解説】Moving off EventON: its timestamps aren't what they look like

WordPressでイベントを管理する人気のプラグインであるEventONから、別のシステムへイベントデータを移行する、あるいは既存のイベントデータをエクスポートする際に、特に注意すべき点について解説する。この解説は、システムエンジニアを目指す初心者が、データ移行の際にどのような問題が起こりうるのか、そしてそれをどのように解決すべきかを理解できるよう作成されている。

EventONは、WordPressサイト上でイベントカレンダーを構築するための広く使われているツールであり、多くのサイトで利用されている。しかし、このプラグインがイベントデータをWordPressのデータベースに保存する方法には、いくつかの一般的な慣例と異なる点が存在する。これらの違いを理解せずにデータ移行を行うと、イベントの時刻がずれたり、繰り返し設定が失われたり、場所の情報が取得できなかったりといった問題が発生する可能性がある。

まず、EventONがイベントデータをどのように保存しているかから見ていこう。各イベントは、WordPressの「カスタム投稿タイプ」という仕組みを使って、「ajde_events」という種類の投稿として保存される。これは、通常のブログ記事や固定ページとは異なる、イベント専用の投稿形式と考えるとわかりやすい。イベントの開始時刻や終了時刻などの具体的な情報は、「カスタムフィールド」として各イベントの投稿に紐づけられている。例えば、開始時刻は「evcal_srow」、終了時刻は「evcal_erow」というカスタムフィールドに保存されており、これらは一般的に「Unixタイムスタンプ」という形式で記録されている。Unixタイムスタンプとは、1970年1月1日0時0分0秒（UTCという世界標準時）からの経過秒数を表す数値だ。また、イベントが終日開催かどうかは「evcal_allday」、イベントのタイムゾーンは「_evo_tz」といったフィールドに記録されている。

繰り返しイベントの設定も同様にカスタムフィールドに保存される。例えば、繰り返し頻度は「evcal_rep_freq」、繰り返し間隔は「evcal_rep_gap」といったフィールドに格納される。イベントの場所や主催者、イベントの種類は、「タクソノミー」と呼ばれるWordPressの分類機能を使って管理されている。これは、ブログ記事のカテゴリやタグに似た仕組みで、例えばイベントの場所は「event_location」、主催者は「event_organizer」といったタクソノミーが使われる。イベントの色は「evcal_event_color」に、イベントの状態（開催予定、キャンセルなど）は「_status」に保存されている。オンラインイベントの場合のURLは「_vir_url」にある。

しかし、これらのデータ保存方法には、特に注意すべき「罠」がいくつか存在する。最も重要なのが、タイムスタンプの扱われ方だ。

罠1：タイムスタンプが「仮想的」であること

EventONが保存する開始・終了時刻のUnixタイムスタンプは、見た目では通常のUTCタイムスタンプに見えるが、実はそうではない。EventONは、ユーザーがイベントを保存する際に入力した「現地時間（壁時計時間）」を、サイトのタイムゾーンに関わらず、そのまま「UTC時間」として保存してしまう。例えば、日本時間（JST）で午後6時30分のイベントを作成したとしても、EventONはそれを「午後6時30分UTC」としてデータベースに保存するのだ。

この保存方法が問題となるのは、データを読み出す時だ。もしWordPressが提供する標準的な時刻変換関数（例えばwp_date()）を使ってこのタイムスタンプを変換しようとすると、WordPressは保存された値を真のUTCとして扱い、そこからサイトのタイムゾーン設定（例えば日本時間ならUTC+9時間）を適用して時刻を計算してしまう。結果として、実際のイベント時刻からサイトのUTCオフセット分だけ時間がずれて表示されてしまうのだ。

これを避けるためには、保存されたタイムスタンプを「現地時間」として読み出す必要がある。具体的には、PHPで時刻を扱う際には、gmdate()という、UTCとして日付時刻をフォーマットする関数を使用する。これにより、EventONが保存した「午後6時30分UTCとみなされた現地時間」を、そのまま「午後6時30分」として正しく読み取ることができる。データベースから直接SQLでデータを取得する場合も同様に注意が必要だ。SQLのFROM_UNIXTIME()関数は、データベースセッションのタイムゾーン設定を使って時刻を変換するため、事前にセッションのタイムゾーンをUTC（SET time_zone = '+00:00';）に設定してからデータを取得する必要がある。

罠2：繰り返しイベントの「設定」ではなく「生成されたリスト」を信頼すること

EventONの繰り返しイベントは、イベントがどれくらいの頻度で繰り返されるか（毎日、毎週、毎月など）という「繰り返しルール」の設定と、そのルールに基づいて実際に生成された全ての繰り返しイベントの開始・終了時刻のリスト（「repeat_intervals」というフィールドに保存）の両方を持っている。

データ移行の際、この「繰り返しルール」だけを見て新しいシステムでイベントを再生成しようとすると、問題が生じることがある。特に複雑なカスタム繰り返し設定や、時間単位の繰り返しイベントなどは、ルールから正確に全ての日付を再現するのが難しい場合があるからだ。EventONは、カレンダーに表示する際にこの「repeat_intervals」リストを使っているため、移行の際には、ルール設定ではなく、EventONが実際に生成して保存しているこのリストを「真実」として扱うべきだ。このリストを参考にすることで、全ての繰り返しイベントが正確に移行されることを保証できる。

罠3：場所や主催者の詳細が一般的な場所に保存されていないこと

イベントの場所や主催者の詳細情報、例えば住所、連絡先、地図の座標などは、WordPressのタクソノミーのメタ情報（wp_termmetaテーブル）には直接保存されていない。代わりに、「evo_tax_meta」というWordPressの「オプション」の中に、これらの情報がまとめてシリアライズ（構造化されたデータを文字列として保存する形式）されて保存されている。このオプションの中では、タクソノミーの種類（event_locationなど）と各タームIDをキーとして、関連する詳細情報が格納されている。

移行の際には、この「evo_tax_meta」オプションのデータを確実にエクスポートし、新しいシステムで正しく解析して読み込む必要がある。古いサイトの中には、個別のタームごとにオプションが保存されているケースもあるため、両方をチェックすることが推奨される。このオプションの取得を忘れると、場所の住所や連絡先といった重要な情報が失われてしまう可能性がある。

罠4：イベントタイプが複数セット存在すること

EventONでは、イベントの種類を分類するための「event_type」というタクソノミーだけでなく、追加のイベントタイプセットを作成できる。これらの追加セットは、「event_type_2」「event_type_3」といった形で、それぞれ異なるタクソノミーとして存在し、独自のURL構造を持つ場合がある。

データ移行時には、これらの全てのイベントタイプタクソノミーを把握し、新しいシステムでどのように分類するかを計画する必要がある。また、古いURLから新しいURLへのリダイレクト設定も忘れずに行うことで、ユーザーや検索エンジンが古いイベントリンクにアクセスしても正しく新しいページに誘導されるようにする必要がある。

これらの罠を回避し、EventONからのスムーズなデータ移行を実現するためには、以下の点を事前に確認することが重要だ。 まず、実際に一つのイベントを手動で変換し、gmdate()関数を使ってEventONのフロントエンドで表示される時刻と一致するかを確認する。次に、繰り返しイベントの数を数え、各繰り返しルールの設定と「repeat_intervals」リストを比較し、リストが正確であることを確認する。また、場所や主催者の詳細が格納されている「evo_tax_meta」オプションのデータを、イベント投稿データと一緒に必ずエクスポートする。そして、サイトに存在する全てのイベントタイプタクソノミー（event_type、event_type_2など）と、それらのURLベースをリストアップしておく必要がある。

筆者が開発した「Beacon Events」というWordPressプラグインは、EventONからのインポート機能を持っており、ここで述べたこれら全ての罠に対応している。仮想的なタイムスタンプを正しく読み込み、繰り返しイベントはrepeat_intervalsのリストに基づいて正確に移行し、evo_tax_metaから住所情報を取得し、全てのイベントタイプセットを適切にカテゴリに変換し、古いURLからのリダイレクトも処理する。

EventONからのデータ移行は、一般的なWordPressのデータ構造と異なる部分があるため、細心の注意が必要となる作業だ。この記事で解説したポイントを理解し、準備を怠らないことで、データの正確性を保ちながら、安全でスムーズな移行を実現できるだろう。