Implementierung von Google GSS in Joomla

Anfang des Jahres wurden wir mit dem Hinzufügen von erweiterten Suchfunktionen zu mehreren Joomla-Websites beauftragt. Die Projektanforderungen schlossen die Verwendung der Standard-Joomla-Suche aus. Nach der Überprüfung verschiedener Lösungen haben wir uns dafür entschieden, mit Google GSS zu arbeiten. In diesem Beitrag können Sie nachlesen, wie wir Google GSS in Joomla implementiert haben – und warum wir uns dafür entschieden haben.

  • Überlegen Sie, Ihre Website auf J!4 bzw. J!5 zu aktualisieren oder zu einem anderen CMS zu migrieren? Wir helfen Ihnen bei der Entscheidung!

    Wie die meisten CMS-Sucherweiterungen indiziert Joomla Search Inhalte aus dem CMS heraus.

    Grob gesagt funktioniert das wie folgt:

    • Wir sagen der Sucherweiterung, welche Arten von Inhalten wir verwenden und wo/wie diese in der Joomla-Datenbank gespeichert sind.
    • Die Suche generiert dann entweder einen eigenen Index auf Basis dieser Informationen oder durchsucht die relevanten Datenbanktabellen/Felder in Echtzeit.

    Für einfache Suchszenarien hat Joomla Search mehrere Vorteile: Es ist einfach einzurichten, und wenn wir nur in Artikeln und anderen nativen Joomla-Inhalten suchen müssen, kommt es quasi gebrauchsfertig.

    Voraussetzungen für dieses Projekt

    Suchindex

    Der Suchindex sollte das gesamte Frontend bzw. die Website umfassen, unabhängig von der Quelle des Inhalts (z.B. Artikel, Module, verschiedene Komponenten, SPPB-Seiten). Es sollte auch alle selbst gehosteten PDF/DOC-Dateien indizieren, die mit einer beliebigen Stelle auf der Website verlinkt sind.

    Benutzeroberfläche

    Die Suche erforderte nur eine einfache Benutzeroberfläche, sollte aber leicht zu warten und stark skalierbar sein. Sie sollte dem Benutzer auch erlauben, mehrere Webseiten von einer Oberfläche aus zu durchsuchen, die nicht alle mit Joomla erstellt wurden.

    Suchfunktion

    Die Suche sollte eine einfache Filterung der Ergebnisse nach Inhaltssprache und Quellwebsite ermöglichen. Das Layout der Ergebnisseite sollte leicht zu handhaben sein, und die einzelnen Ergebnisse sollten kontextuelle Ausschnitte enthalten.

    Warum nicht Joomla Search verwenden?

    Unterschiedliche Inhaltstypen

    Mit Joomla Search wird es mit jeder weiteren Art von Inhalt komplizierter.

    Für eine Website mit einer Vielzahl von Komponenten, Modulen und Methoden, zur Generierung und zum Rendern von Inhalten, ist es sehr aufwendig, Joomla Search einzurichten, um alle diese Inhalte zu berücksichtigen. Außerdem gibt es keine Möglichkeit, Inhalte in z.B. PDF- und DOC-Dateien zu indizieren.

    Erweiterung der Joomla-Suche?

    Es wäre möglich gewesen, unsere eigene, umfangreichere Joomla-Sucherweiterung zu entwickeln, aber dies hätte eine direkte Suche und Filterung der Datenbank erforderlich gemacht, ein Ansatz, der die Datenbank/Server wahrscheinlich stark belastet und somit die Performance beeinträchtigt hätte.

    Außerdem gibt es keine Möglichkeit, dem Benutzer zu erlauben, mehrere Websites von einer Suchinstanz aus zu durchsuchen. Wenn alle betroffenen Seiten Joomla-basiert wären, wäre es vielleicht eine Möglichkeit, eine benutzerdefinierte API innerhalb jeder Seite zu implementieren, um Ergebnisse für diese Seite zurückzuführen, jedoch wäre die Umsetzung ein umfangreiches Unterfangen – und selbst dann würde die Lösung nur für Seiten funktionieren, die mit Joomla erstellt wurden.

    Bewertung von Google GSS als Lösung

    Obwohl Google GSS die natürliche erste Wahl für dieses Projekt war, haben wir auch verschiedene andere Optionen wie Apache Solr und Elastic Search geprüft und in Betracht gezogen: jede auf ihre Weise eine großartige Lösung, die aber nicht so gut wie GSS zu unseren Anforderungen passt.

    Für diejenigen, die noch nicht auf GSS gestoßen sind: Die Google Site Search bietet die Möglichkeit, Standard-Google-Suchergebnisse in Ihrer persönlichen Suchmaschine anzuzeigen. Die Suchergebnisse werden aus einer vordefinierten Teilmenge des tatsächlichen Suchindex von Google gezogen.

    Google GSS hat viele Vorteile:

    • Es indiziert alles, was für den Benutzer sichtbar ist, einschließlich der Dateien. Es verwendet auch Schlüsselwörter, Metadaten, den Standort des Benutzers bei der Indizierung und Anzeige der Ergebnisse.
    • Die von der API zurückgegebenen Ergebnisse sind die gleichen wie bei der normalen Google-Suche und enthalten Snippets, Titel, Beschreibungen, URLs etc.
    • GSS ist viel schneller und leistungsfähiger als jede Standard-CMS-Sucherweiterung und verbraucht keine lokalen DB/Server-Ressourcen.
    • Die Google Search API ist sehr leistungsfähig und bietet viele Funktionen (z.B. Filterung), die einfach implementiert werden können.
    • Schließlich ist GSS gut dokumentiert, kann mit jeder Plattform oder Technologie (Python, PHP….) verwendet werden und ist insgesamt einfach zu implementieren und zu warten.

    Es gibt aber auch einige Nachteile:

    • Da GSS auf den bestehenden Google-Suchindex zurückgreift, gehören die zugrunde liegenden Daten zu Google und können nicht manuell manipuliert werden, um den Bedürfnissen des Kunden gerecht zu werden.
    • Neue Inhalte werden nach dem Google-eigenen Ermessen indexiert – es ist möglich, einen Re-Index anzufordern, aber es gibt keine Garantie dafür, wie schnell das geschehen wird.
    • Ergebnisse können nach Sprache gefiltert werden, jedoch immer nur nach einer Sprache auf einmal. Google unterstützt keine Filterung der Suchergebnisse nach mehreren Sprachen (z.B. Englisch und Deutsch).

    Implementierung von Google GSS in Joomla

    Benutzerdefinierte Search API

    Google GSS arbeitet auf Basis der benutzerdefinierte Search API. Wir erstellen und übermitteln Suchanfragen als Anfragen an die API, und GSS sendet die Ergebnisse entweder im XML- oder JSON-Format zurück.

    Da relativ wenig Code notwendig ist, um GSS in eine Website zu integrieren, und da wir geplant hatten, GSS auf mehreren Websites zu implementieren, haben wir uns entschieden, keine eigene Joomla-Erweiterung zu entwickeln, sondern unsere Integration ausschließlich auf PHP zu basieren, indem wir nur zwei PHP-Dateien und einen Joomla Artikel Layout Override verwenden, um GSS innerhalb der Website zu rendern.

    Suchformular & Seitenlayout

    Unsere erste PHP-Datei setzt das Formular und das Layout um und enthält eine HTML-basierte Suchschnittstelle zur Erfassung der Suchanfrage/-optionen sowie das Layout, das für die Anzeige der Ergebnisse im Frontend erforderlich ist.

    Das Formular enthält ein Eingabefeld für die Suchanfrage, ein Auswahlfeld für den Domain-/Site-Filter und zwei Ankreuzfelder für den Sprachfilter.

    Dieses Skript wurde im Rahmen eines Artikel-Layout-Overrides implementiert, mit einem Dateipfad wie /templates/mytemplate/html/com_content/article/search.php. Um die Suche innerhalb der Website zu rendern, haben wir dann einfach einen Artikel erstellt und dieses Layout zugewiesen. Der Artikel selbst musste keinen Inhalt enthalten, es sei denn, die Seite sollte z.B. statischen Text in die Suchseite aufnehmen. Wir richten dann einen einzelnen Artikel-Menüpunkt ein, um den URL-Alias (z.B. /search) zu setzen und so den Startpunkt für die Suche auf unserer Seite zu schaffen.

    Datenverarbeitung & API-Anfragen

    Die zweite PHP-Datei ist das eigentliche Gehirn hinter der Operation. Diese Datei wird beim Absenden des Formulars via Ajax von unserer ersten Datei aufgerufen und hat die folgenden Eigenschaften bzw. Funktionen:

    • Sie enthält die Suchlogik und verwaltet alle unsere Daten und Parameter.
    • Sie sendet die API-Anfrage beim Absenden des Formulars.
    • Sie manipuliert die von der API zurückgegebenen $_POST-Daten.
    • Sie enthält eine hartkodierte Liste der Domains, die der Benutzer durchsuchen/filtern kann, um die Filter-Dropdown-Liste in der Suchmaske anzuzeigen.

    Die benutzerdefinierte Search-API erfordert die folgenden Parameter für jede API-Anforderung:

    • Google API URL
    • Unsere API Client ID
    • Anzahl der Suchergebnisse pro Anfrage (bzw. Standard)
    • Offset, das uns hilft, die Seitenzahlen zu verarbeiten.

    Dieses Skript verwaltet die übermittelten POST-Daten und baut die Abfrage daraus wie folgt auf:

    $gss_url= // API call 
$gss_base_url.'& // Google API URL 
cx='.$gss_client_id.'& // API client ID 
num='.$gss_num.'& // Number of results 
start='.$gss_start.'& // Result offset 
hl='.$gss_lang.'& // UI display language 
lr=lang_'.$gss_lang.'& // Result language filter 
q='.urlencode($gss_q); // Search query + site filter*

    *Der q-Parameter enthält die Abfrage aus dem Such-Eingabefeld sowie einen zusätzlichen (optionalen) Parameter, der von Google verwendet wird, um festzulegen, welche Sites/Domains durchsucht werden sollen.

    Das Skript erstellt die Abfrage mit Curl, führt sie aus und holt die Ergebnisse von Google ab. Curl ist sehr leistungsstark, aber in unserem Fall müssen wir nur Curl initialisieren, die URL mit der Abfrage setzen und angeben, dass die API-Anfrage ein RETURNTRANSFER ist, was Google wissen lässt, dass wir eine Antwort auf die Abfrage erwarten.

    Hier ist der Code:

    $curl = curl_init(); 
curl_setopt_array($curl, array( 
CURLOPT_RETURNTRANSFER => 1, 
CURLOPT_URL => $gss_url, 
)); 
$resp = curl_exec($curl); 
curl_close($curl);

    Die endgültige API-Anfrage sieht etwa so aus:

    &cx=our_id&num=10&start=0&hl=en&lr=lang_en&q=search term here

    Die Antwort mit den Suchergebnissen wird von Google erstellt. Da dies im XML-Format geschieht, verwenden wir die eingebaute PHP-Klasse SimpleXMLElement, die beim Erstellen ein einfaches XML-Dokument darstellt. Danach ist alles, was wir noch tun müssen, diese Antwort zu analysieren und als HTML zu rendern.

    War das Projekt ein Erfolg?

    Die Umsetzung der oben beschriebenen Lösung dauerte etwa ein bis zwei Wochen, zusätzlich wurden 1-2 Tage zur Vorbereitung mit Forschung und Planung verbracht.

    Das Endergebnis sieht großartig aus und entspricht (wenig überraschend) Google selbst was die Leistung angeht.

    Erwarten Sie das Unerwartete

    Das Projekt war ein Erfolg…. für etwa einen Monat: Im März 2017 kündigte Google an, den GSS-Dienst im April 2018 vollständig einzustellen.

    Weitere Insights