MM 2.3 und nochmal die Suchfunktion

[Shania]

Zunächst einmal möchte ich sagen, dass die Sache nach den letzten Änderungen deutlich besser aussieht und der Aufbau des Indexes auch auf meiner Seite wieder durch läuft . Das ist schonmal sehr gut!

Es gibt aber noch immer Suchergebnisse, die ich da nicht sehen möchte. Daher zunächst die Frage, ob ich die auch einfach nach dem Aufbau des Suchindexes über die Datenbank löschen könnte, also aus der tl_search. Kann es damit Probleme geben? Ich habs mal getestet und ich kann erst einmal keine Probleme erkennen. Das würde die Suchergebnisse für die Leser meiner Ansicht nach deutlich verbessern.

Konkret ist mir aufgefallen, dass folgende Links aufgenommen werden:

• Links, die im Frontoffice in den Texten gesetzt wurden und MM Filter nutzen. Mir ist klar, dass ich die Links selber ändern und mit dem data-escargot-ignore versehen muss, aber ich finde wohl nicht alle.
• Links der von MM erzeugten Linklisten und Selectfelder und zwar nach wie vor in Kombinationen mit Seiten.
• Links von Checkboxen (Ja/Nein)
• Links von Seiten der MM Listen. Die möchte ich alle nicht in den Suchergebnissen haben. Wenn ich das template aber entsprechend ändere, werden auch die auf den Seiten enthaltenen Einträge nicht mehr in die Suche aufgenommen. Das ist natürlich nichts.

Das Ziel ist für mich, dass nur die erste Seite mit der MM Liste aufgenommen wird (also ohne die Seitenzahl als Angang) und die Detailseiten. So war es ja auch bis zur Änderung des Crawlers. Alles andere ist in meinen Augen überflüssig und bläht den Suchindex nur auf.

Ein Fehler werden doch aber sicher solche Links sein oder? Das ist bei den tags. Oder waren die schon immer so?

https://***/Seitenname/page/8/anfang...prägung4.html

Du kannst es dir auf meiner Seite live ansehen, zonky.

[zonky]

Das Ziel ist für mich, dass nur die erste Seite mit der MM Liste aufgenommen wird (also ohne die Seitenzahl als Angang) und die Detailseiten. So war es ja auch bis zur Änderung des Crawlers. Alles andere ist in meinen Augen überflüssig und bläht den Suchindex nur auf.

... "früher" hat Contao nur das in den Index aufgenommen, was auch in der sitemap.xml steht - der neue Crawler von Contao durchläuft wie ein Google-Bot die FE-Seiten und grast da alles ab....

Ich glaube nicht, dass es da eine allgemeine Lösung gibt, da es durchaus User geben kann, die genau das im Suchindex möchten. Ggf. könnte man eine Option bei den Filterregeln einbauen, die den Parameter "data-escargot-ignore" einfügt - ansonsten eben das/die Template(s) anpassen.

... bin ab Juli wieder im Büro

[Shania]

Ich hatte die Nachrichten so verstanden, dass nun die Templates entsprechend geändert wurden. Und irgendwas hat sich ja auch geändert, sonst wurde es ja nicht jetzt durchlaufen.

Das mit den Seiten verstehe ich auch, dass manch einer das möchte. Alles andere eher nicht, es sei denn man hat nur einen Filter. Schon bei zweien kommt ja Murx raus. Aber mag sein, dass auch das irgendwer so möchte.

Ich bin dabei nun alles überflüssige aus der tl_seach zu löschen. Die templates waren ja alle angepasst. Ich habe sie nochmal erneut geändert wegen der Änderungen von MM, bin aber noch immer weit von meinem Wunschergebnis entfernt und weiß auch gar nicht, wo ich da jetzt noch ansetzen könnte. Aber ok, beim nächsten Update kann ich mich ja mal wieder melden .

Dann dir einen wunderschönen Urlaub .

[zonky]

Ich hatte die Nachrichten so verstanden, dass nun die Templates entsprechend geändert wurden. Und irgendwas hat sich ja auch geändert, sonst wurde es ja nicht jetzt durchlaufen.

Die Templates, die als Link(-Liste) daher kommen macht das aus unserer Sicht natürlich Sinn, die zu übergehen und dort ist das entsprechend eingebaut... beim Rest müsste man sich das genauer angucken ob es da nur den einen "use-case" gibt...

[Shania]

Na ja, bei den tags ist es ja an sich das gleiche, wie bei den Linklisten oder seht ihr das anders?

Das löschen in der tl_seach hat wohl den Nachteil, dass die Links alle wieder kein kommen, sobald jemand entsprechend sucht . Oder Google hat sie schon indexiert und crawlt sie nochmal ab. Jedenfalls ist das ein Kampf gegen Windmühlen.

Was auch komisch war, ich hatte jetzt haufenweise doppelte Links drin, einmal https://domain.de/index.php/... und einmal ohne index.php . habe ich auch gelöscht, aber ich befürchte, die kommen auch wieder. Und sowas hatte meines Wissens nie irgendwo mal online oder gepostet oder sowas.

[zonky]

können wir uns sicher im Juli nochmal zusammen ansehen

[Shania]

Ich habe jetzt ewig nicht nach dem Suchindex geschaut, muss ich zugeben und wollte nun mal wieder updaten, da ich in MM das Problem habe, keine Bilder mehr ergänzen zu können. Ich hatte hier auch irgendwann mal gelesen, dass das behoben sein soll, finde es nur nicht mehr. Daher wollte ich es nun einfach mal ausprobieren.

Aber beim kopieren der Datenbank ist nun eine ziemliche Katastrophe aufgefallen. Die Datenbank ist aufgrund des Suchindexes nun über 20 GB groß. Und das kommt fast alles durch die tl_search (ca. 5 GB) und die tl_search_index (ca. 15 GB).

Das liegt sicher daran, dass jede Seite, die im Frontend aufgerufen wird, in den Index aufgenommen wird und so landet alles, was durch Nutzung der MMs an Kombinationen möglich ist, doch noch im Suchindex. Kann man das irgendwie abstellen oder gibt es sonst eine Idee für eine Lösung?

[mlweb]

Wenn es nur um Probleme beim kopieren der DB geht - die drei Tabellen, die die Suche betreffen musst Du ja nicht zwingend mit kopieren.

[Shania]

Das weiß ich, darum allein geht es nicht. Wenn da die ganzen URLs aufgenommen werden, die man mit den Merkmalen und in Kombination mit den Seiten durch MM erzeugen kann, brauchen Suchanzeigen ewig bis sie überhaupt ein Ergebnis zeigen. Und ob das Ergebnis dann gut ist, ist fraglich. Die benutzt dann einfach auch niemand mehr. Dazu verbraucht es ja auch völlig sinnlos Speicherplatz. Die gezippte Sicherung ohne die zwei Tabellen hat keine 3 MB. Nur mal zum Vergleich.

[zonky]

Du kannst doch die MM-Seiten von der Contao-Suche/Indexierung ausschließen - MM hat ja eine eigene Suche... wenn Du mit Levenshtein arbeitest, sogar mit eigenem (einstellbaren) Index und optionaler Autovervollständigung.

[Shania]

Ok, das kann ich mal versuchen, glaube aber nicht das es hilft. Denn ist es nicht so, dass noch immer auch jede neu besuchte/geklickte Seite in den Index aufgenommen wird? Denn ansonsten ist diese Masse an Einträgen gar nicht zu erklären. Das ist nach dem Aufbau des Suchindexes ja nicht so gewesen, sonst wäre der Aufbau ja wieder nicht durchgelaufen.

Die Suche von MM kann ich dann aber nur auf der Seite, wo die daten stehen suchen oder? Das ist in unserem Fall nicht so optimal, denn die Leute wissen ja vorher eventuell gar nicht, dass es das MM mit den Infos gibt. Das müssten sie über die Suche ja erstmal finden können. Und wenn die Seite nicht in der Suche ist, dann ja auch nicht in der Sitemap. Und auch das fände ich in unserem Fall nicht gut. Es mag andere Anwendungsfälle geben, wo das anders ist, aber uns würden die Anwender Beides suchen - die Liste im Ganzen und auch einzelne Einträge, je nach dem eben.

[zonky]

A: Ok, das kann ich mal versuchen, glaube aber nicht das es hilft. Denn ist es nicht so, dass noch immer auch jede neu besuchte/geklickte Seite in den Index aufgenommen wird? Denn ansonsten ist diese Masse an Einträgen gar nicht zu erklären. Das ist nach dem Aufbau des Suchindexes ja nicht so gewesen, sonst wäre der Aufbau ja wieder nicht durchgelaufen.

B: Die Suche von MM kann ich dann aber nur auf der Seite, wo die Daten stehen suchen oder? Das ist in unserem Fall nicht so optimal, denn die Leute wissen ja vorher eventuell gar nicht, dass es das MM mit den Infos gibt. Das müssten sie über die Suche ja erstmal finden können. Und wenn die Seite nicht in der Suche ist, dann ja auch nicht in der Sitemap. Und auch das fände ich in unserem Fall nicht gut. Es mag andere Anwendungsfälle geben, wo das anders ist, aber uns würden die Anwender Beides suchen - die Liste im Ganzen und auch einzelne Einträge, je nach dem eben.

Zu A: nicht unbedingt - wenn Du in den Seiteneigenschften die Seite von der Suche/Indexierung ausschließt, steht das im Quelltext unten in dem JSON-LD-Bereich.

Zu B: die "Suche", d. h. der MM-Filter muss nicht nur auf der Listenseite sein - den kann man "irgendwo" hinsetzen und auf die Listenseite verweisen; auf der Listenseite muss aber auch der Filter hin, da der aus den POST- die Slug(GET)-Parameter macht. Bis MM 2.2 musste der Filter dann als Modul angelegt werden, damit beide Forms die selbe ID haben - in MM 2.3 kann man die ID selbst vergeben und zwei CEs anlegen.

[Shania]

Ach je, jetzt hatte ich eigentlich schon eine Antwort fast fertig, musste dann aber weg und hatte den Rechner aus gemacht. Das Forum speichert das wohl nicht zwischen. Sehr ärgerlich.

A: Ich probiere es nochmal aus, denke aber nicht, dass das etwas nützt.

Im Suchindex hätte ich nach wie vor gerne
1. die Seiten mit den Listen und dann ausschließlich
2. alle Detailseiten, mehr nicht.

So wie es bis zur Änderung des Suchbots in Contao eben auch möglich war. Aber, wenn heute jemand Seite 3 der Liste anschaut, mit diversen anderen Filtern, dann wird eben diese URL mit den Filtern ja auch in die Suche aufgenommen. Nur deshalb ist die Tabelle so riesig geworden.

Wäre schön, wenn das irgendwann wieder ginge.


B: Die nutze ich auch, aber direkt über den Listen, weil man dann eben nur diese durchsucht. So ein Formular woanders hin zu stellen macht für mich keinen Sinn, denn wer nicht weiß, was alles auf der Seite zu finden ist, der soll natürlich über die allgemeine Suche auch alle Unterseiten finden können, denn sonst findet er sie womöglich gar nicht. Und ich habe auch so einige MMs, da wüsste ich jetzt gar nicht, wo ich außerhalb der Listseiten noch die Suchformulare einbauen sollte.

[zonky]

Aber, wenn heute jemand Seite 3 der Liste anschaut, mit diversen anderen Filtern, dann wird eben diese URL mit den Filtern ja auch in die Suche aufgenommen.

Der Eintrag in der JSON-LD sollte dynamsich zur "Laufzeit" anpassbar sein, d. h. Du kannst die Indexierung ausschließen, wenn ein Filterwert gesetzt ist. Alle Filterwerte sind in einem eigenen Array - mach mal ein dump($this); in deiner Liste...

[Shania]

Kannst du mir etwas genauer erklären wo ich das eintragen soll oder kann ich das irgendwo nachlesen, wie ich das mache?

Das dump($this); im Listentemplate unten anzuhängen hat zumindest nichts gebracht.

[zonky]

siehe https://metamodels.readthedocs.io/de...ebug-templates - am besten ganz oben ins Template

wie man die JSON-LD dynamsich anpassen kann, kann ich Dir aktuell nicht genau sagen - erweitern geht so https://metamodels.readthedocs.io/de...ng-mit-json-ld

[Shania]

Ok, danke dir! Das schaue ich mir mal an und melde mich, wenn ich nicht klar komme .

[Shania]

Also, ich habe das jetzt im Template drin und der Debugmodus zeigt mir auch die enthaltenen Filter .

Ich habe mir das jetzt mal angesehen und verstehe ich das richtig, dass man erst einmal das gesamte template so anpasst, dass Google es als "strukturierte Daten" erkennt? Dann müsste ich wohl erst das Beispiel von Jobposting auf Itemlist ändern, richtig?

https://schema.org/ItemList

Denn meine Einträge sind ja keine Jobs und dafür gibt es auch keinen anderen Standard.

Ich nehme also das Beispiel aus der Doku:

<?php

use Contao\CoreBundle\Routing\ResponseContext\JsonLd\J sonLdManager;
use Contao\System;
use Spatie\SchemaOrg\JobPosting;
use Spatie\SchemaOrg\Organization;
use Spatie\SchemaOrg\Place;
use Spatie\SchemaOrg\PostalAddress;
use Spatie\SchemaOrg\PropertyValue;

$jsonLdGraph = null;
$responseContext = System::getContainer()->get('contao.routing.response_context_accessor')->getResponseContext();
if ($responseContext && $responseContext->has(JsonLdManager::class))
{
/** @var JsonLdManager $jsonLdManager */
$jsonLdManager = $responseContext->get(JsonLdManager::class);
$jsonLdGraph = $jsonLdManager->getGraphForSchema(JsonLdManager::SCHEMA_ORG);
}
?>
<?php if (count($this->data)): ?>
<div class="layout_full">
<?php foreach ($this->data as $arrItem): ?>
<?php
// Build Schema.org data.
$schemaData = (new JobPosting())
->identifier((new PropertyValue())->propertyID('jobId')->value($arrItem['raw']['id']))
->hiringOrganization((new Organization())->name($arrItem['text']['corporation_name']))
->title($arrItem['text']['name'])
->datePosted(date('Y-m-d', $arrItem['raw']['created_date']))
->jobLocation((new Place())->address((new PostalAddress())->addressCountry($arrItem['text']['country'])))
->description($arrItem['text']['description']);
?>
<div class="item <?= $arrItem['class'] ?>">
<h2 itemprop="title"><?= $arrItem['text']['title'] ?></h2>
<div>
<p><strong>Location:</strong><?= $arrItem['text']['city'] ?> <?= $arrItem['text']['region'] ?>
</p>
</div>
...
<div class="actions">
<?php if (null !== ($href = $arrItem['actions']['jumpTo']['href'] ?? null)) {
$schemaData->url($href);
} ?>
<?php foreach ($arrItem['actions'] as $action): ?>
<?php $this->insert('mm_actionbutton', ['action' => $action]); ?>
<?php endforeach; ?>
</div>
</div>
<?php /* Add Schema.org data. */ $jsonLdGraph?->add($schemaData, 'job-' . $arrItem['raw']['id']); ?>
<?php endforeach; ?>
</div>
<?php else : ?>
<?php $this->block('noItem'); ?>
<p class="info"><?= $this->noItemsMsg ?></p>
<?php $this->endblock(); ?>
<?php endif; ?>

Das was rot ist muss ich mit der Googledoku neu bauen und das was grün ist, da kommt mein bisheriger Templateinhalt für die Felder rein, ist das richtig?

Was ich noch nicht verstehe ist, wie ich damit dann URLs für die Aufnahme in die Suchfunktion ausschließen kann. Aber ganz grundsätzlich auch ohne das Suchfunktionsproblem ist es sicher sinnvoll die Templates so umzubauen.

[zonky]

Das was rot ist muss ich mit der Googledoku neu bauen und das was grün ist, da kommt mein bisheriger Templateinhalt für die Felder rein, ist das richtig?

Was ich noch nicht verstehe ist, wie ich damit dann URLs für die Aufnahme in die Suchfunktion ausschließen kann. Aber ganz grundsätzlich auch ohne das Suchfunktionsproblem ist es sicher sinnvoll die Templates so umzubauen.

das sind zwei verschiedene paar Schuhe! Mit dem Beispiel kannst Du eigene strukturierte Daten ausgeben z. B. als https://schema.org/Product

Wie Du die bestehende Auszeichnung von Contao abändern kannst, ist was anderes!

[Shania]

Sorry, dann ist mir das zu hoch. Ich verstehe, dass das strukturierte Daten sind, aber genau das hattest du mir ja verlinkt. Na ja, ich denke, das wird meine Fähigkeiten ohnehin einfach übersteigen, wenn du schreibst

wie man die JSON-LD dynamsich anpassen kann, kann ich Dir aktuell nicht genau sagen

Das werde ich wohl nicht selber heraus bekommen. Ich nutze MM ja, weil ich etwas bauen möchte ohne Entwickler zu sein. Templates bauen zähle ich mal jetzt nicht direkt dazu. php anpassen klappt so gerade noch, aber dann hört es auch auf.

Ich werde es dann einfach so lassen und den Suchindex immer mal wieder löschen und neu aufbauen. Vielleicht kann man das ja auch per Cron in der Nacht machen. Dann wäre das Ergebnis nah am gewünschten Zustand.

[lucina]

Die Felder im MetaModels zu nutzen ist da doch eine sinnvolle Lösung.

[zonky]

Das werde ich wohl nicht selber heraus bekommen. Ich nutze MM ja, weil ich etwas bauen möchte ohne Entwickler zu sein. Templates bauen zähle ich mal jetzt nicht direkt dazu. php anpassen klappt so gerade noch, aber dann hört es auch auf.

Die Werte können über die Seiteneigenschaften gesteuert werden - z. B.

<?php 
global $objPage;

$objPage->description = 'HUHU!!';
$objPage->noSearch    = true;
?>

Du kannst das "noSearch" abhängig von der gesetzten Filterung setzen.

[Shania]

Also, du meinst, dass das in das MM template der MM Liste soll oder?

Ich habe jetzt mal im Debugmodus geschaut, was da zu den Filtern mit kommt, kann aber keinen Unterschied erkennen, wenn ein Filter gesetzt ist und wenn nicht. Hier ist keiner gesetzt, aber es sieht genauso aus, wenn einer gesetzt ist.

Bild_2023-11-22_201041491.png

Oder ist das die falsche Stelle?

Wenn ich irgendwo abfragen kann, ob ein Filter gesetzt ist, dann könnte man per if Abfrage die Indizierung verhindern. Habe ich das richtig verstanden?

[zonky]

dort bist Du schon richtig ... guck mal in arrData ... da könnte es filter oder filterParams geben - d.h. dann

dump($this->filterParams); 

Wenn ich irgendwo abfragen kann, ob ein Filter gesetzt ist, dann könnte man per if Abfrage die Indizierung verhindern. Habe ich das richtig verstanden?

jess!

[Shania]

Das sieht so aus:

Bild_2023-11-23_145120405.png

Ist das dann so gemeint? Meine Kenntnisse reichen leider nicht aus, um zu verstehen wie beides zusammen hängt.

<?php
global $objPage;
<?php if ($arrItem['jumpTo']['filterSettings']['futtermittelart']!=''): ?>
    $objPage->noSearch    = true;
<?php endif; ?>
?>

Und das dann eben für alle Filter entsprechend erweitern?

[zonky]

eher sowas

<?php if (!empty($this->filterParams)): ?>
    global $objPage;
    $objPage->noSearch = true;
<?php endif; ?>

[Shania]

Das klappt so nicht. Die Seite wird dennoch in den Suchindex aufgenommen, wenn man sie anklickt. Ich hatte jetzt den Suchindex komplett gelöscht, um das auszuprobieren.

Der Code sieht auch irgendwie nicht so aus als würde er funktionieren oder?

Ich hatte es auch so probiert:

<?php global $objPage;
if (!empty($this->filterParams)): ?>
        $objPage->noSearch = true;
<?php endif; ?>
?>

Die Zeile
$objPage->noSearch = true;
steht in beiden Fällen sichtbar auf der Seite.

[zonky]

ach... so ist das, wenn man Quelltext kopiert und anpasst...

muss so aussehen:

<?php 
if (!empty($this->filterParams)) {
    global $objPage;
    $objPage->noSearch = true;
}
?>

und dann sollte im Quelltext bei den JSON-LD stehen

...
"noSearch": true,
... 

[Shania]

Ahhhh, mega! Das klappt *juhu*! Du bist der Held, zonky!

Was jetzt noch aufgenommen wird, sind die Seiten, wenn die Liste mehrere Seiten hat, aber ich denke, das ist zu verschmerzen.

Tausend Dank! Vielleicht magst du das auch ins Handbuch aufnehmen. Dann hat das Volllaufen des Suchindexes endlich ein Ende .

[zonky]

Tausend Dank! Vielleicht magst du das auch ins Handbuch aufnehmen. Dann hat das Volllaufen des Suchindexes endlich ein Ende .

Am Handbuch kann jede/r mitschreiben - siehe Link Github oben rechts auf jeder HB-Seite... ich bin da mit meinen Zeiten recht ordentlich im Vorlauf, so dass ich den Kelch gern weiter reiche

[Shania]

Ok, das schaue ich mir mal an. Aber ich wollte mich nicht mit fremden Federn schmücken .

[Shania]

Ich weiß leider nicht, wie man dort neue Seiten anlegen kann, aber der Textvorschlag für eine Seite unter "Kochbuch" wäre dieser.

Ausschluss von Filter-ULRs aus dem Suchindex

Wenn man auf seiner Contao-Listenseite mehrere Filter verwendet, indiziert die Suchfunktion standardmäßig alle durch die Filter erzeugten Seiten (URLs) in Kombination mit eventuellen Seiten.

Nehmen wir als Beispiel eine Liste von Mitarbeitern mit jeweils einer Detailseite für jedes Profil (Skills, Erfahrungen usw.). Die Liste erstreckt sich über 5 Seiten. Die Mitarbeiter sind verschiedenen Aufgabenbereichen (Aufgaben) und Projekten (Projekte) zugeordnet. Die Liste ist nach diesen Kriterien filterbar.

Die URL der Liste lautet:

https://www.meinedomain.de/mitarbeiterliste.html
https://www.meinedomain.de/mitarbeiterliste/page/1.html

Wenn der Filter "Projekte" mit der Ausprägung "metamodel-3.0" ausgewählt wird, lautet die URL:

https://www.meinedomain.de/mitarbeiterliste.html
https://www.meinedomain.de/mitarbeit...model-3.0.html

Bei mehreren Seiten ergibt sich beispielsweise:

https://www.meinedomain.de/mitarbeit...0./page/2.html

Wenn auch der Filter "Aufgabenbereich" mit der Ausprägung "Entwickler" gewählt wird, lautet die URL:

https://www.meinedomain.de/mitarbeit...er/page/2.html

Die durch die Filter erstellten Seiten (URLs) werden zunächst nicht automatisch in den Suchindex aufgenommen. Dies geschieht erst, wenn sie von einem Benutzer oder Suchmaschinen genutzt werden. Bei wenigen Filtern ist dies unproblematisch.

Wenn jedoch viele Filter und Einträge vorhanden sind, kann dies zu einem stetig wachsenden Suchindex und wenig hilfreichen Suchergebnissen führen. Um dies zu vermeiden, kann der folgende Code am Anfang des Templates für die Listenseite eingefügt werden. Dadurch werden nur noch die Listenseite selbst mit den verschiedenen Seitenzahlen und alle Detailseiten (zum Beispiel die Mitarbeiterprofile) in den Suchindex aufgenommen.

Code von zonky:

<?php 
if (!empty($this->filterParams)) {
    global $objPage;
    $objPage->noSearch = true;
}    
?>

[zonky]

https://metamodels.readthedocs.io/de...rch-index.html