Eine Zapier- oder Make-Automatisierung auf einen neuen Geokodierungs-Host migrieren
No-Code-Automatisierungen mit einem Geokodierungsschritt brauchen einen anderen Migrationsansatz als eigener Code. So gehen Sie bei diesem Wechsel vor.
WordPress-Plugins, die eine Geokodierungs-API aufrufen, etwa eine Filialsuche, eine Prüfung von Liefergebieten oder eine Karte mit Immobilienangeboten, sind meist so gebaut, dass der Schlüssel eines bestimmten Anbieters einmal auf einer Einstellungsseite eingetragen und überall dort verwendet wird, wo das Plugin eine Standortabfrage braucht. Dieses eine Einstellungsfeld ist für Websitebetreiber bequem, bedeutet aber auch, dass der Geokodierungsanbieter oft tiefer im Code des Plugins verankert ist, als ein kurzer Blick auf die Einstellungsseite vermuten lässt.
Zuerst sollten Sie klären, ob Sie ein Plugin migrieren, das Sie selbst pflegen, oder ein Plugin eines Drittanbieters, das Sie nur konfigurieren. Das sind wirklich unterschiedliche Situationen:
Wenn Sie das Plugin selbst pflegen, ist die Migration eine normale Codeänderung: Finden Sie jede Funktion, die die Geokodierungs-API aufruft (die Codebasis des Plugins nach dem Hostnamen des Anbieters oder dem Namen seines Schlüsselparameters zu durchsuchen, ist meist der schnellste Weg, jede Aufrufstelle zu finden), und passen Sie diese Funktionen so an, dass sie den neuen Host mit einem neuen Schlüssel aufrufen. Da PHP hier die naheliegende Sprache ist und die Kompatibilitäts-Hosts von My Geocode die exakte Antwortstruktur eines vertrauten Anbieters nachbilden, genügt es oft, nur den Host und die Authentifizierung der Anfrage zu ändern statt der Logik zum Parsen der Antwort, sofern der vorhandene Code des Plugins bereits das spezifische Format dieses Anbieters parst. Die Authentifizierung unterstützt einen X-API-Key-Header, Authorization: Bearer, HTTP-Basic-Authentifizierung oder einen Query-Parameter, sodass es für jede Art, wie das Plugin seinen Schlüssel derzeit sendet, eine direkte Entsprechung gibt.
Wenn Sie ein Plugin eines Drittanbieters nur konfigurieren, hängen Ihre Möglichkeiten ganz davon ab, was die Einstellungsseite des Plugins anbietet. Manche Plugins erlauben, neben dem Schlüssel einen eigenen API-Endpunkt zu konfigurieren. Dann kann es ganz ohne Codeänderungen funktionieren, diese Einstellung auf einen passenden Kompatibilitäts-Host zu richten, falls es einen für den Anbieter gibt, für den das Plugin ursprünglich gebaut wurde, denn aus Sicht des Plugins spricht es weiterhin mit einer API derselben Struktur. Andere Plugins haben den Hostnamen des Anbieters fest im Code verankert. Dann bleiben Ihnen nur diese Möglichkeiten: den Entwickler des Plugins zu kontaktieren, nach einem Fork oder einem Update mit mehr Flexibilität zu suchen oder, bei einer kritischen Abhängigkeit, eine kleine eigene Anpassung in Betracht zu ziehen, sofern die Lizenz des Plugins das erlaubt.
Einige praktische Hinweise für beide Fälle:
Für die Website eines kleinen Unternehmens, die sich für eine Filialsuche oder eine ähnliche Funktion auf ein einziges Plugin verlässt, deckt das kostenlose Tageskontingent, 2.500 Anfragen ganz ohne Schlüssel oder 2.500 pro Konto und Tag, die sich alle seine Schlüssel teilen, den Traffic einer typischen kleinen Website oft bequem ab. Es lohnt sich, das mit dem tatsächlichen Besucher- und Abfragevolumen Ihrer Website abzugleichen, bevor Sie annehmen, dass überhaupt ein kostenpflichtiger Tarif nötig ist.