Indexer für Seiten

Beschreibung

Der Seiten Indexer wird verwendet, um normale TYPO3 Seiten zu indexieren.

Alle Inhaltselemente einer Seite werden gruppiert und als ein Indexeintrag in den Index geschrieben. Das bedeutet, dass Sie nur ein Suchergebnis bekommen, auch wenn Ihr gesuchtes Wort in zwei verschiedenen Textelementen auf einer Seite vorkommt.

Der Page Indexer ist in der Lage, folgende Inhaltselemente zu indexieren: Texte, Texte mit Bild, Aufzählungen, Tabellen, reines HTML und Überschriften. Dabei wird das Feld abstract aus dem Indexer automatisch mit dem Teaserfeld (Inhaltsangabe) aus den Seiteneigenschaften befüllt.

Konfiguration

  • Setzen Sie den Typen auf "Seiten".
  • Bestimmen Sie eine Überschrift (wird nur intern verwendet).
  • Weisen Sie dem Indexer nun den Speicherordner zu. Tragen Sie hier bitte Ihren Suchdaten - Ordner ein.
  • Stellen Sie „Startingpoints (recursive)” für die Seiten ein, die Sie rekursiv indexieren wollen.
  • Stellen Sie „Single Pages” für die Seiten ein, die Sie nicht-rekursiv indexieren wollen.
  • Falls Sie bei „Index content elements with restrictions” „Ja” einstellen, werden Inhaltselemente sogar indexiert, wenn Sie im Frontend über bestimmte Berechtigungskonzepte für Nutzergruppen verfügen. Diese Funktion erlaubt es, bestimmte Inhalte bei der Suche zu "Teasen" und dann den Benutzer darüber zu informieren, dass er sich anmelden muss, um auf diese Inhalte zugreifen zu können.
Einstellen der Indexer-Konfiguration

Seitentypen und Inhaltselementtypen

Sie können beim Anlegen einer Indexer-Konfiguration bestimmten, welche Typen von Inhaltselementen (ab Version 2.2.0) oder welche Seitentypen (ab Version 2.3.0) Sie indexieren möchten. Dies ist hilfreich, wenn Sie über die Standard-Seiten- und Inhaltstypen hinaus eigene definiert haben, die Sie nun über die Suche erfassen möchten.

Erfassung von DCE-Elementen mit ke_search

DCE-Element sind individuell konfigurierte Inhaltselemente (mehr dazu unter https://docs.typo3.org/typo3cms/extensions/dce/)

Sie können DCE-Elemente indexieren, indem Sie die Typenbezeichnung ihres DCE-Elements in der Indexer-Konfiguration im Feld "Inhaltselement-Typen, die indexiert werden sollen" hinterlegen. 

Voraussetzung: Ihr DCE-Element nutzt die Standard TYPO3-Datenbankfelder aus der tt_content-Tabelle (title, bodytext).

Wenn Ihr DCE-Element die Bezeichnung "dce_dceuid1" trägt, muss also der Wert 

text,textmedia,textpic,bullets,table,html,header,uploads,dce_dceuid1

eingetragen sein. 

Auch eigene Felder können indexiert werden: Sie können Ihre eigenen Felder im DCE auf die Spalte tx_dce_index mappen, damit werden diese dann auch erfasst.

Das ist der Hook, der dafür verantwortlich ist, tx_dce_index zu berücksichtigen:

forge.typo3.org/projects/extension-dce/wiki/Updating-DCE-to-12

bitbucket.org/ArminVieweg/dce/src/72e9dcc3d2c1da0067ff47c844bdc0c02bcef598/Classes/Hooks/KeSearchHook.php

Registriert wird dieser so:

  if (\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::isLoaded('ke_search')) {

        $GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['ke_search']['modifyContentFromContentElement'][] =

            'EXT:' . $extensionKey . '/Classes/Hooks/KeSearchHook.php:ArminVieweg\\Dce\\Hooks\\KeSearchHook';

    }

Zugriffsberechtigungen

Nach folgenden Regeln wird der Indexer indexieren, wenn für eine bestimmte Seite Berechtigungskonzepte gelten:

  • Versteckte (und natürlich auch gelöschte) Seiten werden nicht indexiert.
  • Zeitliche Beschränkungen (start / stop field), werden aus den Seiteneigenschaften in den Indexer kopiert.
  • Frontend Berechtigungskonzepte für Nutzergruppen, werden ebenfalls aus den Seiteneigenschaften in den Index kopiert.

Das bedeutet für "Seiten", dass ihre zeitlichen Beschränkungen und ihre Frontend Berechtigungskonzepte für Nutzergruppen komplett übernommen werden und funktionieren.

Zugriffsberechtigungen bei Inhaltselementen

Weil mehrere Inhaltselemente in einen Index-Eintrag gespeichert werden, ist hier die Handhabung ein wenig anders. Falls sie die volle Unterstützung für Berechtigungskonzepte von Inhaltselementen benötigen, verwenden Sie bitte den Inhaltselement-Indexer.

Der Seiten-Indexer indexiert Ihnhaltselemente folgendermaßen:

  • Versteckte (und natürlich auch gelöschte) Inhaltselemente werden nicht indexiert.
  • Inhaltselemente mit zeitlichen Beschränkungen (start / stop field) werden nicht indexiert, wenn die zeitlichen Beschränkungen greifen (d. h. das Inhaltselement sollte nicht sichtbart sein). Es kann passieren, dass Inhaltselemente in der Suche angezeigt werden, obwohl sie zu dem Zeitpunkt nicht sichtbar sein sollten. Beispiel: Wenn Sie eine Seite an einem Montag indexieren und diese Seite Inhalte enthält, die am Dienstag nicht sichtbar sein sollten, so erscheinen diese Elemente am Dienstag trotzdem in der Suche, wenn keine erneute Indexierung vorgenommen wird. Das liegt daran, dass ein alter Index verwendet wird. Diesem Problem können Sie entgegenwirken, indem Sie in kürzeren Zeitabständen eine Re-Indexierung vornehmen.
  • Inhaltselemente mit Frontend Berechtigungskonzepte für Nutzergruppen werden nur dann indexiert, wenn die Indexerkonfiguration auf "Index content elements witch restrictions". Andernfalls werden sie nicht indexiert. Das bedeutet, dass Sie "Appetitanreger" in Ihrer Suche verwenden können: Wenn ein Nutzer auf einen solchen Eintrag auf der Ergebnisseite klicken sollte, wird er auf die entsprechende Seite geleitet, kann aber keine Inhalte sehen, da er nicht eingeloggt ist. Stattdessen bekommt er zum Beispiel die Benachrichtigung "Bitte loggen Sie sich ein, um den Inhalt zu sehen.

Das bedeutet, dass die Zeitbeschränkungen und Frontend Berechtigungskonzepte für Nutzergruppen von Inhaltselementen nur teilweise übernommen werden. 

Sie müssen für Ihre Installation entscheiden, ob Sie:

  1. Berechtigungskonzepte für Seiten statt für Inhaltselemente verwenden wollen, oder
  2. den Inhaltselement-Indexer (siehe unten) verwenden wollen anstelle des Seiten-Indexer, oder
  3. die Berechtigungskonzepte für Inhaltselemente verwenden wollen, um einen "Teaser"-Effekt in der Ergebnisliste zu erreichen (wie oben beschrieben).

Wichtige Anmerkung: Die Seiteneigenschaft "Auf Unterseiten ausdehnen" wird ab Version 1.3 übernommen, d. h. Seitenberechtigungen werden auch in der Suche vererbt, wenn diese Eigenschaft gesetzt ist.

Bei Version 1.2 und niedriger bedeutet das, dass eine Unterseite nicht die Berechtigungskonzepte ihrer Elternseite erbt, wenn bei dieser "Auf Unterseiten ausdehnen" eingestellt ist.

Andi (Archiv)
Ist es tatsächlich gewollt, dass Seiten, auf denen lediglich Plugins sind, überhaupt nicht indiziert werden? Auch nicht der Titel?
Beispielsweise habe ich eine Seite "Kontakt", auf der lediglich ein Kontaktformular liegt. Der Suchbegriff "Kontakt" liefert keine Treffer.
Mir ist klar, dass Inhalte von Plugins nicht durchsucht werden, hätte aber zumindest gerne den Titel der Seiten im Suchindex.
Ein Workaround ist, den Namen der Seite nicht in den Header des Plugins sondern als Textelement (überschrift) einzugeben. Das ist aber nicht schön, da dann die Plugins im BE keinen Namen haben.
Wie kriege ich das am besten hin?
Danke
Andi
Christian (Archiv)
Ja, das Verhalten ist so bei ke_search.

Hier handelt es sich natürlich um einen Sonderfall, Dein vorgeschlagener Workaround sollte funktionieren, wenn er auch die von Dir beschriebenen Nachteile mitbringt.
Andi (Archiv)
ja, der workaround funktionert.
Und auch du siehst keine alternative Lösung zum Thema?
Christian (Archiv)
Für eine Änderung des Verhaltens müsste die Programmierung des Seiten-Indexers angepasst werden. Denkbar wäre, dass man dies dann konfigurieren könnten "Indiziere leere Seiten (nur Seitentitel): ja / nein". Aber das ist derzeit nicht auf unserer Todo-Liste. Du könntest ein Feature-Request auf http://forge.typo3.org/projects/extension-ke_search/issues erstellen. Vielleicht findet sich ja auch jemand, der das Feature sponsort.
Daniel (Archiv)
It's not clear for me with the access restricted pages. If the "Index . . ." is set to Yes the pages will be indexed and a teaser will be shown. But if I set it to No are they not indexed or will the results only be shown to FE users who are loged in? Only that will be for me "will fully be taken into account".
Christian (Archiv)
Hi Daniel, I try to explain. If the otpion "Index content elements with restrictions" is set to "yes", every content element will be indexed, no matter if it has restrictions. Therefore, thesee elements appear in the result list. If this option is set to "no", content elements with access restrictions will not be indexed and do not appear in the results list.

The restrictions for pages are handled differently: They are taken fully into account. That means, access restricted will only appear in the result ist, if the user is logged in and has the right groups assigned to him.

If you need access restriction support on a per content element basis, please have a look at the content element indexer.
Gabi (Archiv)
Hallo, ich habe in den Seiteneigenschaften bei den Meta-Tags Schlagworte hinterlegt. Kann ich diese auch mit indizieren lassen?
Christian (Archiv)
Hallo Gabi, das ist derzeit nur über einen Hook möglich, d. h. über zusätzliche PHP-Programmierung.
Gabi (Archiv)
Hallo Christian,

vielen Dank für die Info. Das habe ich mir schon fast gedacht. Mein Problem ist nur, dass ich php nicht wirklich kann.

Vom Prinzip her muss ich doch eigentlich nur die entsprechende Tabelle in der Datenbank, in der die Schlagworte gespeichert sind auslesen und bei den ke_search-Tags hinterlegen, oder?

Noch eine Frage, abseits vom Thema: Wenn ich hier im Kommentar-Formular meine E-Mail-Adresse eingebe, ist diese dann auch bei den Kommentaren, wie der Name, für alle sichtbar?
Christian (Archiv)
Hallo Gabi. Im Prinzip ja. Es gibt eine Erweiterung ke_search_hooks im TER, die erste Schritte zu Erweiterung von ke_search zeigt. Zu Deiner anderen Frage: Es wird nur der Name angezeigt, nicht die E-Mail-Adresse.
Dan (Archiv)
Hallo Christian,

ich verwende ke_search und habe unterschiedlichste FE-User-Gruppen. Ist es möglich, dass der FU-User nur die Seiten in seinem Suchergebnis erhält, die er sehen darf? Es ist nicht schön, wenn man ein Suchergebnis anklickt und die Meldung erhält, dass man keinen Zugriff darauf hat.
Gruß Dan
Christian (Archiv)
Hi Dan. Das ist eigentlich das Standardverhalten von ke_search: Das Suchergebnis erhält die gleichen Berechtigungen wie die Seite. Wenn Du also den Seiten-Indexer verwendest, siehst Du nur Ergebnisse, auf die Du auch Zugriff hast. Beim Seitenelement-Indexer (der jedes Element einzeln indexiert) ist das ebenfalls so. Nur wenn Du beim Seitenindexer bestimmst, dass auch geschützte Inhaltselemente indexiert werden, kann es zu dem von Dir beschriebenen Fall kommen, dass Du auf eine Seite kommst, wo sich Inhalte befinden, die noch geschützt sind.
Thomas (Archiv)
Hallo Christian,
ich verwende ke_search und habe ebenfalls unterschiedliche FE-User-Gruppen. Einen bestimmten Seitenast darf nur eine bestimmte Gruppe sehen. Die Root-Seite des Astes ist unter "Zugriff" dieser Gruppe zugeordnet und "auf Unterseiten ausdehnen" ist aktiviert.
Ich verwende den Seiten-Indexer, keinen Content-Indexer. "Indiziere Content-Elemente mit eingeschränkter Zugänglichkeit?" ist auf "nein" gestellt.
Im Suchergebnis werden die zugangsgeschützten Seiten leider allen FE-Usern angezeigt. Ein Aufruf des angezeigten Ergebnis-Links führt zur - frei zugänglichen - übergeordneten Seite.
Nach den o.a. Kommentaren dürften die geschützten Seiten doch nur Usern der entsprechenden Gruppe angezeigt werden.
Woran kann das liegen?
Gruß Thomas
Christian (Archiv)
Hallo Thomas, ja, genau, die Seiten sollten nicht in der Suche auftauchen. Dieses Feature existiert aber auch erst seit Version 1.3, welche Version setzt Du ein? Wenn Du möchtest, schau ich mir das mal an, Du müsstest mir dann mal direkt eine E-Mail schreiben.
Stefan (Archiv)
Hallo Christian, der Support ist ja auch sagenhaft schnell bei Euch - super! Ich habe dasselbe Problem wie Thomas - ein Intranet mit unterschiedlichen Zugangsberechtigungen auf einzelne Seiten. Im Suchergebnis werden aber alle Seiten angezeigt und geteasert, auch wenn der Link dann zur übergeordneten, frei zugänglichen Seite führt. Gibt es schon neue Erkenntnisse, wie dieses Verhalten behoben werden kann?

Lg, Stefan
Christian (Archiv)
Hallo Stefan, grundsätzlich werden Seiten- und Inhaltselementberechtigungen bei ke_search berücksichtigt. Ich bräuchte Zugriff auf die Installation, um so etwas am "lebenden Objekt" nachvollziehen zu können.
marc (Archiv)
hy,

kurze tech-frage: wo kann der fehler liegen, wenn man 2 indexer für seiten (1x global für alle seiten im baum und 1x nur für eine bestimmte seite mit unterseiten - indexer jeweils in eigenen ordnern im seitenbaum angelegt) einsetzt, für beide der indexer bei händischem start 2 unterschiedliche ergebnisse liefert, aber beide suchformulare immer auf den "großen" indexer der alles indiziert hat, laufen?
Christian (Archiv)
Hallo Marc, es ist immer schwierig, Fragen zur Konfiguration ohne Einblick in das System zu beantworten. Hier sieht es so aus, dass die Einstellung für den "Ausgangspunkt" bei beiden Suchplugins auf die Seite mit dem "großen" Index zeigt.
Patrick (Archiv)
Servus Christian,

ist es (im Standard oder per Erweiterung) möglich, CEs vom Typ "Datensatz einfügen" zu indexieren?

Danke und Grüße Patrick
Christian (Archiv)
Hallo Patrick, derzeit ist diese Funktion nicht implementiert, müsste also programmiert werden. Gruß, Christian
Lutz, 06-07-16 16:22
Anscheinend baut ke_search (1.10.0) den Pfad ohne Berücksichtigung der Einstellungen zu RealURL auf, so dass Seiten, die aus dem Pfad ausgenommen sein sollen, in den Pfaden der Suchergebnisse erscheinen.
Beispiel:
Wir haben zwei verschiedene Hauptmenüs auf der Seite, an verschiedenen Stellen. Im Baum haben wir also einen Ast "/Grosses Menü/..." und einen Ast "/Kleines Menü/...", die ersten Ebenen sind aber für die Pfad-Generierung durch RealURL ausgeklammert, erscheinen also in unseren Pfaden nicht. Bei den Suchergebnissen werden sie aber eingebaut, ebenso wie andere Hilfsebenen ("unsichtbare" Zwischenseiten für Tab-Menüs, etc.), obwohl wir die interne Struktur gerne vor unseren Besuchern verbergen würden.
Außerdem erscheint im Pfad immer der Seitentitel, auch wenn man RealURL angewiesen hat, den Pfad in der Reihenfolge "Untertitel > Alternativer Navigationstitel > Seitentitel" aufzubauen, wovon wir exzessiv Gebrauch machen.
Im Changelog steht diesbezüglich nichts, so dass ein Update bisher keine hohe Priorität hat.

Eine kleine Anmerkung zu dem ersten Post (Andi):
Dieses Problem stellt sich bei allen Content-Elementen, die keine Überschrift brauchen (z.B. Banner) aber von anderen Seiten referenziert werden sollen. Ich habe unsere Redakteure dahin geschult, diesen Elementen trotzdem eine aussagekräftige Überschrift zu geben und dann den Typ auf "verborgen" zu setzen. Ein wenig mehr Arbeit bei der Erstellung, aber eine wesentliche Erleichterung beim weiteren arbeiten. Mehr Freiheit bei der Positionierung der Überschriften hat man damit auch.

Grüße
Lutz
Wiebke, 02-03-17 17:17
Hallo,

habe ein TYPO3 6.2 und ke_search 2.2.1 über composer installiert. Leider kann ich keine Indexer Konfiguration im Backend anlegen. Nach Speichern werden die Felder wieder geleert. Ausschließlich der ke_search Version 1.10.0 funktioniert zuverlässig. Wollte aber gern Fluid Templates nutzen.

Hattet ihr schon mal dieses Problem?

Liebe Grüße
Wiebke
Urs Bräm, 11-03-17 10:00
Hallo Christian

ich habe dieselbe Ausgangslage wie bei DCE oben – aber in Bezug auf ext:mask. Ich könnte ja den page indexer erweitern – aber gibt es vielleicht schon eine eingebaute Lösung? Bräuchte Mask dazu auch einen Hook?

Liebe Grüsse
Urs
Urs Bräm, 11-03-17 10:12
Hallo Christian nochmal
... ich hab mittlerweile herausgefunden, dass das (= mask Elemente indizieren) dank "Content element types which should be indexed " out-of-the-box geht. Wahnsinn!

Wenn ich aber tt_content mit mask um zusätzliche Spalten erweitert habe – dann muss ich den Indexer für diese händisch erweitern, richtig?

Lg
Urs
Christian, 13-03-17 09:39
Hallo Urs, vielen Dank für Deine Rückmeldung. Ja, falls Du andere Felder als die Standard-Contentfelder indexieren möchtest, müsstest Du das über einen eigenen Indexer machen oder den Seitenindexer erweitern. Ggf. wäre es für die Zukunft mal ein interessantes Feature, die zu indexierenden Datenbankfelder ebenfalls konfigurierbar zu machen.
Oliver, 16-06-17 14:02
Hallo,

ich habe zurzeit ein Problem mit der Indexer Konfiguration. Ich richte, wie oben beschrieben den Seiten- Indexer ein und erhalte bei der Indizierung den Fehler "Incorrect integer value '' for @orig_pid".

Die Extension betreibe ich lokal in einer Apache2 Umgebung mit PHP 7.1.15. Meine Typo3 CMS hat die aktuellste 7er Version (7.6.18).

Der Backtrace für nur zu der Typo3 eigenen Funktion sql_query. Woran könnte dies möglicherweise liegen oder könnte möglicherweise die Kombi Typo3 7.6.18 und PHP 7.1.15 dafür verantwortlich sein, da die Extension auf der aktuellen 8.7er Version von Typo3 funktioniert?
Oliver, 18-06-17 23:15
Hallo zusammen,

das Problem habe ich soeben gelöst. Zu der aktuellen LAMP Umgebung gehört zurzeit MYSQL der Version 5.7, hiermit scheint ke_search nicht zu funktionieren.

Nach einem Downgrade auf die Version 5.6.16 scheint jetzt alles bestens zu laufen.

Beste Grüße und ich hoffe, dass ich einigen von euch geholfen habe.
Christoph, 17-10-17 14:28
Hallo zusammen, es wäre vielleicht eine gute Funktion beim Seiten Indexer ein Feld zu haben "Pagefield-Typen" wo man einzelne Felder aus den Seiteneigenschaften in den Indexer mit aufnehmen kann, ohne großartige Programmierung. Außerdem wird bei den Suchergebnissen, innerhalb der Schlagwörter, in Verwendung der Syscat die ID angezeigt anstatt der title #syscat117.

Grüße Christoph
Eric, 16-11-17 19:31
Hallo zusammen,

leider kann ich den Indexer für Seiten nicht dazu überreden DCEs zu indizieren. (TYPO3 7.6.21, ke_search 2.6.1, DCE 1.4.11)

Aus der Beschreibung oben: "Wenn Ihr DCE-Element die Bezeichnung "dce_dceuid1" trägt, muss also der Wert"...
Woher bekommt man denn die Bezeichnung des DCE-Elements? Ist das der Wert, der im Feld "Titel" im DCE eingetragen wird?

Freue mich über sachdienliche Hinweise.

Danke, Eric
Ulrich Diehl, 29-11-17 10:24
Hallo, ich habe eigene Inhaltstypen definiert, das Indexieren klappt grundsätzlich auch, aber nur für Standard tt_content Felder. Ich habe tt_content aber um eigene Felder erweitert, diese werden nicht indexiert, muss ich da einen eigenen indexer schreiben? Beim tt_content Indexer ist aber doch eigentlich schon eingetragen, dass er alle Felder der Tabelle indexieren soll, oder?

Danke im Voraus, Uli
Tobias, 09-01-18 12:17
Bei mir werden die Bild-Metadaten bzw- Datei-Metadaten bei den Inhaltselementen nicht indexiert.
Diese werden ja nicht inder Tabelle tt_content abgespeichert sondern in der Tabelle sys_file_reference.
Diese wird scheinbar nicht mit berücksichtigt.
Muss ich dafür einen eigenen Indexer programmieren der die Tabelle sys_file_references mit indexiert?
Oder gibt es dafür eine andere (einfachere) Lösung?
(Typo3 8.7, ke_search 2.6.2)
Mario Wilhelm, 15-06-18 08:10
Wir nutzen den suchindexer für Seiten inkl. PDFs. Funktioniert soweit so gut.
Aber wir habe einige Seiten mit PDFs vom Suchindex ausgeschlossen (Seiteneigenschaften -> Verhalten -> Indexsuche). Diese werden nun in der Suche nun nicht mehr gefunden, jedoch werden die Dateien, welche auf diesen Seiten verlinkt sind weiterhin gefunden.

Diese dürfen auch nicht im Suchindex erscheinen. Wie deaktiviere ich das indexen der Dateien auf diesen Seiten? Geht das?

Kommentar hinzufügen

* - Pflichtfeld

Ihr Ansprechpartner für ke_search

Das Absenden ist erst dann möglich, wenn alle Pflichtfelder ausgefüllt sind und der Haken „Ich akzeptiere“ gesetzt ist. * Pflichtfelder

Hinweis zum Kontaktformular: Wir benötigen Ihren Namen um Sie ansprechen zu können und Ihre E-Mail-Adresse um Ihnen antworten zu können.
Datenschutzhinweise: Ihre Anfrage wird verschlüsselt übertragen. Sie erklären Sich damit einverstanden, dass wir Die Angaben zur Beantwortung Ihrer Anfrage verwenden dürfen. Weitere Informationen zum Datenschutz und Widerrufhinweise finden Sie auf unserer "Datenschutzerklärung".

zurück zum Kontakt
 

TYPO3 Agentur aus Leidenschaft. Wir erbringen alle Dienstleistungen rund um TYPO3. Von einfachen Webseiten bis hin zu TYPO3 Portal-Webseiten oder hoch komplexen TYPO3-Extensions. Wir engagieren uns im TYPO3 Security Board und in der Community. Unsere TYPO3 Agentur "lebt" TYPO3.