Suche über Seiten statt SysOrdner

Moin Leute,

leider musste ich vor kurzem feststellen, dass einige Redakteure in unserem Shopsystem ca. 3000 Artikel nicht
in einen SysOrdner, sondern als Datensatz in die jeweiligen
Unterseiten hinterlegt haben.

Ist es irgendwie möglich die tt_products - Suche über die Seiten laufen zu lassen? Leider ist es mir bisweilen nicht
gelungen (Suche ohne Ergebnis).

Wäre wirklich toll, wenn mir jemand mit Rat zur Seite steht.

Ciao,
Michael

Hallo MZ995 et al,

ich habe das selbe Problem. Gibt es hierzu schon Neuigkeiten?
Da die Suche ja wohl über die tt_products-Tabelle läuft, sollte es ja eigentlich egal sein, ob die Produkte in einem SysFolder oder in normalen Seiten liegen. Oder sehe ich da was falsch?

Mein Szenario: Die Produkte sind verschiedenen Unterbäumen unterhalb der Shop-Root abgelegt. Als Startpunkt für die Suche habe ich die Shop-Root angegeben (rekursiv, unendlich). Auf der Suchergebnisseite ist das Shop-Plugin mit den Modes SEARCH und LIST angegeben. Ergebnis der Suche ist immer "Diese Suche war erfolglos.".

TYPO3 4.0.2 / tt_products 2.5.1.2

Grüße
Jochen

Ich habe eine Lösung gefunden 🙂

Das Problem liegt darin, dass dem SQL-WHERE-Statement eine Bedingung vorangestellt wird, die die Suche auf Records in einer bestimmten Seite beschränkt. Dies ist aber nur für den LIST-Modus wichtig, nicht aber für den SEARCH-Modus.

Die WHERE-Bedingung, die tt_products bildet, sieht in etwa so aus:
products.pid IN (123) AND 1=1 AND (products.title LIKE '%suchbegriff%' OR products.subtitle LIKE '%suchbegriff%' OR ...

Das heisst, das products.pid IN (123) AND muss bei der Suche weg:
In der Datei 'tt_products/view/class.tx_ttproducts_list_view.php', ca. Zeile 410 fügt man folgenden Code ein (eingeschlossen in "// edit jf...")

$queryParts = $itemTable->table->getQueryConf($this->pibase->cObj,$tablename, $selectConf, TRUE);
// edit jf begin
if($theCode=='SEARCH'){
  $queryParts['WHERE'] = substr($queryParts['WHERE'], strpos($queryParts['WHERE'],' AND ')+5);
}
// edit jf end
$res = $TYPO3_DB->exec_SELECT_queryArray($queryParts);

Grüße
Jochen

Dieser Fehler sollte in 2.5.1 vom 05.10.2006 bereits korrigiert sein.