Миграция

Как перевести плагин WordPress с платного API геокодирования

Плагины WordPress, которые обращаются к API геокодирования, будь то поиск магазинов, проверка зоны доставки или карта объявлений о недвижимости, обычно строятся вокруг ключа конкретного провайдера, который один раз вводится на странице настроек и используется везде, где плагину нужно определить местоположение. Одно поле в настройках удобно для владельцев сайтов, но оно же означает, что провайдер геокодирования часто встроен в код плагина глубже, чем можно подумать, бегло взглянув на страницу настроек.

Прежде всего нужно понять, переносите ли вы плагин, который поддерживаете сами, или сторонний плагин, который вы только настраиваете. Это действительно разные ситуации:

Если вы поддерживаете плагин сами, миграция сводится к обычному изменению кода: найдите все функции, которые вызывают API геокодирования (поиск по коду плагина имени хоста провайдера или его особого имени параметра ключа обычно быстрее всего находит все места вызова), и обновите эти функции так, чтобы они обращались к новому хосту с новым ключом. Поскольку PHP здесь естественный язык, а совместимые хосты My Geocode воспроизводят точную структуру ответа знакомого провайдера, то если существующий код плагина уже разбирает формат этого провайдера, часто достаточно обновить только хост запроса и аутентификацию, не трогая логику разбора ответа. Аутентификация поддерживает заголовок X-API-Key, Authorization: Bearer, HTTP Basic auth или параметр запроса, так что у любого способа, которым плагин сейчас передаёт ключ, есть прямой аналог.

Если вы только настраиваете сторонний плагин, ваши возможности полностью зависят от того, что доступно на странице настроек плагина. Некоторые плагины позволяют указать собственный эндпоинт API вместе с ключом, и тогда, если для провайдера, под которого изначально создавался плагин, есть подходящий совместимый хост, указание его в этой настройке может сработать вообще без изменений кода, ведь с точки зрения плагина он по-прежнему обращается к API той же структуры. Другие плагины жёстко прописывают имя хоста провайдера, и тогда остаётся связаться с разработчиком плагина, поискать форк или обновление с большей гибкостью или, если зависимость критична, рассмотреть небольшую собственную доработку, если лицензия плагина это разрешает.

Несколько практических замечаний для обоих случаев:

  • Сначала проверяйте любое изменение на тестовой копии сайта и никогда не делайте этого сразу на рабочей установке WordPress, поскольку код плагина, взаимодействующий с рабочей базой данных, несёт больше риска, чем изолированное изменение кода в другом месте
  • Проверьте, не кэширует ли плагин результаты геокодирования в собственной таблице базы данных, поскольку при смене провайдера этот кэш может понадобиться очистить или перепроверить отдельно от самого изменения кода
  • Убедитесь, что обработка ошибок в плагине корректно справляется с неожиданной структурой ответа, ведь сайт на WordPress, показывающий посетителю необработанную ошибку PHP из-за несовпадения ответа API, это худший исход, чем функция геокодирования, которая ненадолго просто не появится

Для сайта небольшого бизнеса, который использует один плагин для поиска магазинов или похожей функции, бесплатной дневной квоты, 2 500 запросов вообще без ключа или 2 500 в день на аккаунт, общих для всех его ключей, часто с запасом хватает на трафик типичного небольшого сайта, и это стоит сверить с реальным числом посетителей и запросов вашего сайта, прежде чем решать, что платный тариф вообще нужен.