Die Jomlasuche "verliert" Inhalte

  • Ich verwende Joomla 3.9 und habe derzeit ca. 3500 Artikel, ich habe den Cache ausgeschaltet. Keine Advanced search aktiviert. Framework Helix 3 ist installiert.

    In der Suche werden vereinzelt Artikel nicht mehr angezeigt obwohl sie vorhanden sind. Ruft man den Artikel im Backend auf und speichert ihn, ist er in der Suche wieder vorhanden. Ich habe an einem Artikel schon mal geschaut, wie das Änderungsdatum ist, das war 2 Monate alt, aber nicht alle Artikel mit dem Alter sind scheinbar betroffen. Hat jemand eine Idee an was das liegen könnte?

  • Liegt es evtl. am Limit (Standard 50) oder werden gar nicht so viele Ergebnisse gefunden?


    Stimmen die Veröffentlichung starten/beenden Daten?


    Sind Nullwerte in der Datenbank, Spalten publish_up/down, zu den nicht aufzufindenen Beiträgen vorhanden?


    Die SQL Abfrage des Content Suchplugins schaut so aus:

    -> where(

    ...

    . 'AND (a.publish_up = ' . $db->quote($nullDate) . ' OR a.publish_up <= ' . $db->quote($now) . ') '

    . 'AND (a.publish_down = ' . $db->quote($nullDate) . ' OR a.publish_down >= ' . $db->quote($now) . ')'

    ...



    EDIT:

    Zitat

    In der Suche werden vereinzelt Artikel nicht mehr angezeigt obwohl sie vorhanden sind. Ruft man den Artikel im Backend auf und speichert ihn, ist er in der Suche wieder vorhanden.

    Vergleiche doch mal den Beitrag direkt in der #__content DB Tabelle (vor/nach dem erneuten Speichern).


    Gruß


    Pascal

  • Also ich weiß jetzt nicht auf was sich die 50 beziehen, es werden teilweise bis zu 114 Ergebnisse angezeigt.
    Beim getesteten Suchbegriff werden nur 3 von mindestens 6 Ergebnissen, angezeigt oder manche gar nicht gefunden.
    Das Datensatz mit vor und nach dem Speichern muss ich mir noch anschauen ist nicht in 2 Min gemacht.
    Es gibt kein publishing Enddatum.

  • So hier ein Datensatz das Einzige was sich verändert hat die Versionsnummer was irgend wie logisch ist. Oder hab ich was übersehen?

    Vor dem Speichern:

    Bearbeiten Bearbeiten Kopieren Kopieren Löschen Löschen 4197 6238 Das Kantatenwerk VOL.1 das-kantatenwerk-vol-1 <h1>Das Kantatenwerk VOL.1</h1>

    <table style="wid... 1 9 2018-07-06 08:35:58 812 2018-07-06 09:34:30 812 0 0000-00-00 00:00:00 2018-07-06 08:35:58 0000-00-00 00:00:00 {"image_intro":"","float_intro":"","image_intro_al... {"urla":false,"urlatext":"","targeta":"","urlb":fa... {"article_layout":"","show_title":"","link_titles"... 5 63 1 145 {"robots":"","author":"","rights":"","xreference":... 0 *


    Nach dem Speichern

    Bearbeiten Bearbeiten Kopieren Kopieren Löschen Löschen 4197 6238 Das Kantatenwerk VOL.1 das-kantatenwerk-vol-1 <h1>Das Kantatenwerk VOL.1</h1>

    <table style="wid... 1 9 2018-07-06 08:35:58 812 2018-12-12 14:24:59 812 0 0000-00-00 00:00:00 2018-07-06 08:35:58 0000-00-00 00:00:00 {"image_intro":"","float_intro":"","image_intro_al... {"urla":false,"urlatext":"","targeta":"","urlb":fa... {"article_layout":"","show_title":"","link_titles"... 6 63 1 145 {"robots":"","author":"","rights":"","xreference":... 0 *

  • Danke hab ich gefunden! Sollte aber bei 8 Artikeln zu einem Thema nicht das Problem sein!
    Hab jetzt noch mehr Artikel entdeckt die in der Suche nicht mehr aufgetaucht sind. Immer nach aufrufen und Speichern im Backend waren sie dann wieder da.

  • hhmm, weiß nicht, ob man das so sagen kann.

    Welche PHP-Version Du jetzt einsetzt, habe ich jetzt nicht entdecken können. Evtl. hat Dein Hoster die PHP-Version geändert ohne die betroffenen Kunden zu informieren.

  • Die aktuelle Konstellation ist also J3.9.1 und PHP 7.2.1. Wie war die Konstellation vorher zu der noch keine Probleme auftraten?

    Kenne Helix nicht, ist es sicher, dass Helix 3 mit J3.9.1 und PHP 7.2.1 kann?

  • Ich hab mir unterdessen sagen lassen, dass ich das Problem den Änderungen in PHP mit der 3.9.1 Version wohl verdanke!

    Da müsstest du die Quelle mal posten, bitte. Wüsste nicht, dass sich in com_search da was geändert hat. Diese Suche wid aber in Joomla 4 ersatzlos gestrichen. Nur als Hinweis. Wäre also der Hinweis von j!-n vielleicht nicht ganz falsch, auf die com_finder-Suche (= Suchindex) umzustellen, auch, wenn die sehr datenbankbelastend arbeitet. Für Popel-Provider-Pakete also vielleicht nicht ganz geegnet.


    Das einzige, was in com_search geändert wurde, ist, dass, wenn ein Suchwort im Titel vorkommt, der Treffer dann höher sortiert wird. Kann nat. sein, dass sich da ein Fehler eingeschlichen hat.


    com_search ist tatsächlich nie besonders trickig gewesen. Nur nebenbei.


    In der Suche hat man ja ein Feld "Anzahl Suchtreffer pro Seite". Bist sicher, dass die Beiträge nicht auf hinteren Seiten stehen?


    Im Menüeintrag kann man die Sortierung einstellen. Weiters einstellen, ob man weitere Filterfelder im Frontend anzeigen lässt. Mit denen würde ich mal rumprobieren, ob die Beiträge tatsächlich gar nicht erscheinen.


    Deaktiviere mal testweise alle anderen search-Plugins, außer das für Beiträge. Noch mal probieren, ob da der Hund begraben liegt.

    Und sortiere sie mal um. Ob das eine Auswirkug hat auf die Reihenfolge der Treffer aus den verschiedenen bereichen.

  • Die Artikel sind alle in der Tabelle sz..._content.
    Bei Schlagworten wo ich die Artikel jetzt neu gespeichert habe also Open und save-Close werden locker 137 und mehr Treffer wieder angezeigt.
    Quelle für die Änderungen Admins der Joomlagruppe auf FB!

  • Ich hab mir unterdessen sagen lassen, dass ich das Problem den Änderungen in PHP mit der 3.9.1 Version wohl verdanke!

    Ich habe einfach Zweifel, dass es hier einen Zusammenhang gibt, der die Probleme verursacht. Kann natürlich sein, dass sich wie Re:Later schrieb, ein Fehler eingeschlichen hat. Das wäre m.M. ein Fehler und keine "Inkompatibilität". Daher die Frage nach den Änderungen bzgl. der Ausgangskonstellation.

  • Hallo deGobbis,
    ich bin nahezu durch jeden Artikel geöffnet und wieder gespeichert.

    Was anderes man kann doch nach dem Notes Feldinhalt suchen, ist auch eine Inverssuche möglich alle Artikel die einen bestimmten Inhalt nicht haben.


  • Ich habe die Seite wohl gefunden. Es handelt sich um eine Suchindex-Suche, die ich da sehe, also nicht com_search, sondern com_finder.


    Damit sind natürlich nur die Einstellungen in dieser Komponente relevant und search-Plugins komplett Bohne.

    Und da die ihre eigene, vollkommen undurschaubare Logik hat, bin ich mal raus hier. Weiß nur, dass man Faktoren vergeben kann, was nun relevanter ist als anderes.