Suchergebnisse sortieren noch Position des Suchbegriffs

Eine fertige Lösung dazu habe ich noch nicht gesehen (was natürlich nichts heißt).
Stichworte wären vermutlich - drupal view sort relevance.
Ich wüßte nur Folgendes:
Mit dem Modul Views PHP ( https://www.drupal.org/project/views_php ) kannst Du ein Feld vom Typ global php anlegen.
In diesem Feld kannst Du mit PHP die Position des Suchbegriffs im String ermitteln und daraus eine Zahl generieren.
Und auf dieses Feld (das Du in der Ansicht auf unsichtbar stellst) kannst Du unten in der Sortierung zugreifen.
Hier in Antwort 3 sind die Schritte erklärt (natürlich für einen anderen Anwendungsfall).
Die Filterung auf den Begriff machst Du ganz normal mit exposed Filter.

Es ist ohnehin nicht ratsam vor allem nicht bei Websites mit vielen besuchen und/oder viel Inhalt Volltextsuchen auf der MySQL-DB laufen zu lassen. Mit Search API kann Views auf viel flexiblere Such Indizes effizient zugreifen. Dort kann man die Text-Felder dann gewichten. Ob das mit "steht am Anfang des Titels" klappt weiß ich gerade nicht. Aber vor allem mit Apache Solr geht dann richtig die Post ab bezüglich Geschwindigkeit.

Hallo montviso, das hört sich nach einem pragmatischen Ansatz an. Ich werde das mal testen. Problem könnte sein, dass ich hier ca. 150.000 nodes habe, die durchsucht werden. Die live-Berechnung mittels views-php wird wahrscheinlich ziemlich an die Performance gehen???
Vielen Dank auf jeden Fall schon einmal für den Tipp!

Hallo Carsten,
vielen Dank für die Rückmeldung! Wie bekomme ich denn den Apache Solr dazu mit einem Views exposed filter zu arbeiten? Oder macht man das ganz anders? Bevor ich hier zu stark rumexperemtiere (ich erinnere mich, dass solr ein recht komplexes Thema ist....) müsste ich prüfen, ob ich damit meinen Ansatz geregelt bekomme. Gibt es hier ein gutes Tutorial?

Das Entscheidende ist, den View neu zu erstellen und dabei nicht direkt in Nodes sondern in einem SearchAPI Index suchen zu lassen, den man dafür anlegen muss. Das Nutzen von dessen Feldern auch in Exposed Filtern mit Volltext-Suche ist dann kein Problem.
Bei der Menge an Nodes würde ich dringend dazu raten zusätzlich ApacheSolr zu nutzen und auch sämtliche Views, die in diesem riesigen Datenbestand suchen, mit SeacrhAPI Solr zu betreiben.

Oha. Ja, die Performance könnte dann schon ein ziemlicher Knackpunkt sein.
Überleg mal wirklich, ob Du nicht prinzipiell (wie schon von Carsten vorgeschlagen) [do:search_api SearchAPI] und Apache Solr als Backend einsetzen möchtest.
Die Berechnung ist dann allerdings noch ein anderes Problem. Anstelle von [do:views_php Views PHP] ist es besser, Dir einen eigenen Sort Handler zu bauen, in dem dann die Berechnung passiert. So wirklich schön ist das vom Prinzip her dann allerdings nicht, da Du hier kaum Chancen hast, die Werte der Berechnung zwischenzuspeichern, also bei jedem Aufruf die Werte neu ermitteln musst :/
Aber der Sort Handler ist schonmal ein sauberer Ansatz als custom PHP direkt im View ;)

Ja, wenn es so viele Datensätze sind, dann ist die pragmatische Lösung nicht optimal.