ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
WordPressプラグインを有料のジオコーディングAPIから移行する
ジオコーディングAPIを呼び出すWordPressプラグイン(店舗検索、配達エリアのチェッカー、物件一覧の地図など)は、通常、特定のプロバイダーのキーを設定ページで一度入力し、プラグインが位置の検索を必要とするあらゆる場所でそれを使うように作られています。この1つの設定欄はサイト運営者にとって便利ですが、同時に、ジオコーディングのプロバイダーが、設定ページをざっと見て想像するよりもプラグインのコードに深く組み込まれていることが多いということでもあります。
最初に確認すべきなのは、自分で保守しているプラグインを移行するのか、設定するだけのサードパーティ製プラグインを移行するのかです。この2つは本当に異なる状況です。
プラグインを自分で保守している場合、移行は通常のコード変更です。ジオコーディングAPIを呼び出しているすべての関数を見つけ(プラグインのコードベースでプロバイダーのホスト名や固有のキーパラメーター名を検索するのが、すべての呼び出し箇所を見つける最も速い方法であることが多いです)、それらの関数を新しいキーで新しいホストを呼び出すように更新します。ここではPHPが自然な言語であり、My Geocodeの互換ホストはなじみのあるプロバイダーのレスポンス形式を正確に再現するため、プラグインの既存のコードがすでにそのプロバイダー固有の形式を解析しているなら、レスポンスの解析ロジックではなく、リクエストのホストと認証だけを更新すれば十分なことがよくあります。認証はX-API-Keyヘッダー、Authorization: Bearer、HTTP Basic認証、クエリパラメーターに対応しているため、プラグインが現在どの方式でキーを送っていても、直接対応する方式があります。
サードパーティ製プラグインを設定するだけの場合、選択肢はプラグインの設定ページで何を変更できるかに完全に左右されます。キーと一緒にカスタムのAPIエンドポイントを設定できるプラグインもあります。その場合、プラグインが元々対象としていたプロバイダーに対応する互換ホストがあれば、その設定を互換ホストに向けるだけで、コードを一切変更せずに動作する可能性があります。プラグインから見れば、同じ形式のAPIと通信していることに変わりはないからです。プロバイダーのホスト名を完全にハードコードしているプラグインもあります。その場合の選択肢は、プラグインの開発者に連絡する、柔軟性を加えたフォークや更新がないか確認する、あるいは重要な依存関係であれば、プラグインのライセンスが許す範囲で小さな独自の修正を検討する、といったものに限られます。
どちらの場合にも役立つ実践的な注意点をいくつか挙げます。
- 変更は、稼働中のWordPressに直接ではなく、必ず先にサイトのステージング環境のコピーでテストしてください。稼働中のデータベースとやり取りするプラグインのコードは、他の場所での独立したコード変更よりもリスクが大きいからです
- プラグインがジオコーディングの結果を独自のデータベーステーブルにキャッシュしていないか確認してください。プロバイダーを切り替えると、コードの変更とは別に、そのキャッシュを消去したり再検証したりする必要がある場合があります
- 予期しないレスポンス形式をプラグインのエラー処理が適切に扱えることを確認してください。APIのレスポンスが合わないせいでWordPressサイトが訪問者にPHPのエラーをそのまま表示するのは、ジオコーディング機能が一時的に表示されないことよりも悪い結果だからです
店舗検索などの機能を1つのプラグインに頼っている小規模ビジネスのサイトであれば、1日の無料枠(キーなしで2,500リクエスト、またはアカウントごとに1日あたり2,500リクエストをアカウントのすべてのキーで共有)で、一般的な小規模サイトが生み出すトラフィックに余裕で対応できることがよくあります。有料プランが本当に必要だと決めつける前に、サイトの実際の訪問者数と検索量と照らし合わせて確認する価値があります。