WordPressのサイト内検索が「重大なエラー」に。原因はEvent Organiserだった

WordPressのイベント管理プラグイン「Event Organiser」を使っているサイトで、サイト内検索をすると「このサイトで重大なエラーが発生しました」と表示されるようになりました。

調べてみると、PHP 8.3以降で起きるプラグイン側の問題で、数行の修正で直せました。

Event Organiser、ちょこちょこ不具合でてくるんで自分のメモとあわせて、同じ症状で困っている方の参考になればと思い書き留めときます。

WordPressサイトで検索するとエラーが発生

PHP 8.3 からPHP 8.5 への更新を行なった直後の動作確認でエラーが発生。

確認した環境

• PHP 8.5.12

• WordPress 7.1.4

• Event Organiser 3.12.11

• テーマ：Cocoon 2.9.6

【症状】サイト内検索が「重大なエラー」になる

• サイト内検索の結果ページが重大なエラーで表示されない

• Event Organiserを無効化すると検索は正常に動く

ちなみに私の場合、通常の記事とイベントの両方を通常フィードに出す設定にしたときも、同じエラーになりました。

フィードを通常投稿と同じRSSに出力したい場合は、フィードをまとめる方法の記事も書いているので参考にしてみてください。
ただし、
絶対この記事の内容が解決してからにしてね！
（またはEvent Organiserを最新にアップデート）

【エラーの内容】debug.logの「DateMalformedStringException」

wp-content/debug.log には、次のように記録されていました。

PHP Fatal error: Uncaught DateMalformedStringException:
Failed to parse time string ( ) at position 0 ( ): Empty string
in .../plugins/event-organiser/includes/event-organiser-archives.php:632

ログの出し方は、wp-config.php に次を書くだけです。
(調査が終わったら WP_DEBUG は false に戻してください)

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

【原因】PHP 8.3以降の仕様変更とEvent Organiserの日付処理

エラーが出ているのは _eventorganiser_update_event_dates_cache() という関数です。
この関数は取得した記事ごとに、イベントの開始日・終了日から日時のオブジェクトを作ってキャッシュします。

ところが、検索結果やFeedのように、通常の投稿とイベントが混ざったクエリでも、この関数が動きます。
日時のデータを持たない通常の投稿に対しても日時を作ろうとして、実質的に空白だけの文字列を渡してしまいます。

PHP 8.2までは、この空の文字列を黙って受け入れていました。
PHP 8.3以降は例外が投げられるようになり、致命的エラーになった、というのが私の見解です。

同じエラーは、WordPress公式のサポートフォーラムにも、複数の方が報告しています。

• Fatal error: Uncaught DateMalformedStringException

• Event Organizer breaking search

【解決方法】event-organiser-archives.phpを数行修正する

event-organiser-archives.php の _eventorganiser_update_event_dates_cache() の中、
foreach の直後に日時データを持たない投稿を飛ばす処理を足します。

修正前 event-organiser-archives.php

	foreach ( $events as $event ) {

		$id = $event->ID;
		$cached_event = (array) wp_cache_get( 'eventorganiser_occurrences_'.$id );

修正後 event-organiser-archives.php

	foreach ( $events as $event ) {

		// イベントの日時データを持たない投稿(検索結果の通常記事など)はスキップ
		if ( empty( $event->StartDate ) || empty( $event->StartTime )
			|| empty( $event->EndDate ) || empty( $event->FinishTime )
			|| ! isset( $event->occurrence_id ) ) {
			continue;
		}

		$id = $event->ID;
		$cached_event = (array) wp_cache_get( 'eventorganiser_occurrences_'.$id );

足したのは if のブロックだけです。
日時のデータを持つ本物のイベントは今までどおり処理され、持たない投稿だけが飛ばされます。

この修正で検索が正常に動き、イベントも検索結果に出ることを確認しました。

注意点1. プラグイン更新で元に戻る

プラグイン本体のファイルを修正しているので、プラグインがアップデートを行なった際に更新すると、この修正は消えます。

更新後に同じエラーが出たら入れ直しが必要です。
修正したファイルを、日付をつけて保管しておくと安心です。

また、プラグインの本体を書き換える方法なので自己責任です。
作業前に必ずファイルのバックアップを取ってください。

正直、Event Organiserの更新は遅めなんで今回はもう直接やっちゃれーって感じで弄りました。
自動更新はOFFにしておいてください。

注意点2. 原因を特定する際のプラグイン無効化について

原因の切り分けには、まず Event Organiser を無効化して検索が直るかを確認する方法が早いです。

ただし、テーマの functions.php に Event Organiser の関数を呼ぶコードがあると、プラグインを無効化したときにサイト全体がエラーで止まることがあります。
そのときは、function_exists( '関数名' ) で守っておくと安全です。

また、管理画面に入れなくなった場合は、FTPでプラグインのフォルダ名を変えれば無効化できます。

【別の解決方法】プラグイン本体を触りたくない場合

サイト内検索からイベントを外す（簡易）

プラグインのファイルを触りたくない場合は、サイト内検索の対象からイベントを外す方法もあります。
検索結果にイベントが含まれなければ問題の処理が呼ばれず、エラーを避けられます。

テーマの functions.php（子テーマ推奨）の末尾に、次を追加します。

// サイト内検索から、イベント(event)だけを除外する
add_action( 'pre_get_posts', function ( $query ) {
    if ( ! is_admin() && $query->is_main_query() && $query->is_search() ) {
        $types = get_post_types( array( 'exclude_from_search' => false ) );
        unset( $types['event'] );
        $query->set( 'post_type', array_values( $types ) );
    }
} );

注意点としてはイベントが検索結果に出なくなるので、イベントの扱いによっては利用しにくいと思います。
自分はライブスケジュールに使っていたので、そもそもサイト検索できないとなると不便なのでこの案は却下しました。

ただ、プラグインを更新しても消えないので本体の修正より管理は楽です。

PHPを8.2に下げて回避する（あまりおすすめではない）

コードを触りたくない場合は、サーバーのPHPを8.2に下げると、同じ問題を避けられる可能性があります。

私の環境では、PHP 8.3.36 のときは検索が動いていて、PHP 8.5.12 と Event Organiser 3.12.11 に更新した後にエラーになりました。
どちらの更新が引き金か、切り分けはできていません。
このエラーはPHP 8.3で導入された例外によるものですが、8.3で必ず起きるとは限らないようです。

ただし、PHP 8.2はサポート期限が近く2026年12月末までなので、同じサーバー上の他のサイトにも影響することがあります。
長く使う前提なら、前述のコード修正のほうがおすすめです。

あとがき

Event Organiserは、フォーラムでも「保守されているのか」という声が出ているプラグインなので、ちょっと今後は考えものなんですよね。
ただフォーラムの報告から11日後(10月30日)に修正版が出たので一応動いてはいるみたいですね。
今回の修正で当面は動きますが、長く使うなら他の方法への移行も検討しておいたほうがよさそうです。