MENU
暮らしを少し便利にするアプリとサービスを作っています
  1. ホーム
  2. Wordress
  3. 有料プラグイン「The Events Calendar Shortcode & Block Pro」を、自作ショートコードに置き換えた記録

有料プラグイン「The Events Calendar Shortcode & Block Pro」を、自作ショートコードに置き換えた記録

Wordress

前回の記事 でカルーセル用の Slider Revolution を自作プラグインに置き換えた話を書いた。同じサイトで使っていた有料プラグインがもう1つあったので、続けてそれも置き換えた。The Events Calendar Shortcode & Block Pro という、The Events Calendar 本体の有料拡張プラグインだ。

目次

置き換え対象は2箇所だけ

このプラグインに払っていたサブスクリプションは、実際にはサイト内の2箇所でしか使っていなかった。

  1. トップページに表示している「直近のコンサート12件のグリッド一覧」（アイキャッチ・タイトル・開催日・会場）
  2. 月別の固定ページ群（2026-6, 2026-7 … といったスラッグで月ごとに1ページずつ作成）

この2箇所を、tribe_get_events() などの The Events Calendar 本体の関数だけを使った自作ショートコードに置き換える。本体プラグインは残し、拡張側だけ自作に差し替える、という方針。

設計のヒントは公式のテンプレートにあった

実装にあたって、置き換え対象プラグインに同梱されている table.php（design=”table” 用のテンプレート）が大きなヒントになった。これを読むと、リンク・会場・日付の取得に何の関数を使っているかが全部分かる。

<a href="<?php echo tribe_get_event_link(); ?>" rel="bookmark">
...
<?php echo tribe_get_start_date( null, false, tribe_get_date_format() ); ?>
...
<?php echo tribe_get_venue(); ?>

自作側でもこれらの関数をそのまま使えば、データの出方を完全に揃えられる。推測ではなく現物を見て同じ関数を使う、というのが今回の安全策だった。

①トップ一覧：[roon_events]

過去イベントを自動除外する一覧表示。tribe_get_events() に start_date を今日に指定すると、これから開催のものだけを開催日順に取得できる。生の WP_Query で日付計算するより、繰り返しイベントの扱いまで含めて確実。

$events = tribe_get_events( array(
    'posts_per_page' => 12,
    'start_date'     => current_time( 'Y-m-d 00:00:00' ),
    'eventDisplay'   => 'list',
    'orderby'        => 'event_date',
    'order'          => 'ASC',
) );

日付表示は「5月 20日(水)」形式。曜日だけ日本語に差し替える。

$jp_week = array( '日', '月', '火', '水', '木', '金', '土' );
$start_ts = intval( tribe_get_start_date( $event_id, false, 'U' ) );
$date_label = sprintf( '%d月 %d日(%s)',
    intval( wp_date( 'n', $start_ts ) ),
    intval( wp_date( 'j', $start_ts ) ),
    $jp_week[ intval( wp_date( 'w', $start_ts ) ) ]
);

②月別ページ：固定ページを「1枚」に統合する

ここが今回の本当の改善点。元の運用では、月別ページが 2026-6, 2026-7, 2026-8 … と月ごとに固定ページとして存在していた。毎年12枚を手動で作って、それぞれにショートコードを書き込む。これが面倒なうえに、入れる月を間違えるミスも起きやすかった。

そこで月別ページを 1枚に統合することにした。固定ページは「コンサート月別」1枚だけ。月の指定はURLパラメータ ?ym=YYYY-M で行う。

if ( isset( $_GET['ym'] ) && preg_match( '/^(\d{4})-(\d{1,2})$/', wp_unslash( $_GET['ym'] ), $m ) ) {
    $year  = intval( $m[1] );
    $month = intval( $m[2] );
}
$first_day = sprintf( '%04d-%02d-01 00:00:00', $year, $month );
$last_day  = wp_date( 'Y-m-d H:i:s', mktime( 23, 59, 59, $month + 1, 0, $year ) );

$events = tribe_get_events( array(
    'posts_per_page' => 50,
    'start_date'     => $first_day,
    'end_date'       => $last_day,
    'eventDisplay'   => 'custom',
    'orderby'        => 'event_date',
    'order'          => 'ASC',
) );

月切り替えバー（元から自作で持っていた）のリンク href を、固定ページのスラッグ（2026-6）から ?ym=2026-6 形式に変更するだけで連携できる。変更箇所はJavaScript1行だけ。

これで、月ごとの固定ページを毎年作る作業がゼロになった。来年も再来年も、固定ページは1枚のまま使い続けられる。古いページが溜まる問題も消える。

結果

  • 払っていたサブスクリプションを解約できる見込みになった
  • 月別固定ページを毎年手動で作る運用が消滅した（これが個人的には一番大きい）
  • 入れる月を間違えるという人為的ミスが、構造的に起こりえなくなった
  • 過去ページの定期削除という宿題も消えた（そもそも作らないので溜まらない）
  • The Events Calendar 本体は維持。データの入れ物は本体に任せ、表示だけ自作する、という分担に整理できた

教訓

置き換え対象プラグインのテンプレートファイルを読むと、何の関数を使っているかが全部分かる。これが分かれば、推測ではなく現物に合わせて自作できる。今回 table.php を読んだことで、データの出方が元と完全に同じになった。

そして、定型的な手作業を肩代わりさせる方向で考える前に、その作業自体をなくせないかを考えると、もっと根本の解決ができることがある。月別ページの自動生成ではなく、月別ページという概念そのものを1枚に統合する。サブスクの解約以上に、この運用上の負担が消えたことが嬉しかった。

リポジトリは Private にしているので公開はしていないが、同じように The Events Calendar 関連の有料拡張を自作で置き換えたい人がいれば、考え方の参考になれば。

Wordress
目次