[Veraltet Seit Version 1.5] Suche Funktioniert Nicht Mehr

[toutelle]

Hallo zusammen

 

Gestern hat es auf unserem Server (www.hostpoint.ch) einen Wartungsbedingten Neustart gegeben. Seit der Server wieder oben ist, funktioniert auf unserem Prestashop (1.4.3) die Suche nicht mehr. Ich habe über das Backend den Index wieder neuaufgabaut (komplett), aber trotzdem funktioniert die Suche nicht. --> www.tutel.ch

 

Kann mir jemand bei diesem Problem helfen? Was könnte hier das Problem sein und wie kann ich es beheben?

 

Viele Grüsse und vielen Dank

[guest*]

Die Suche indexierst du neu unter:

 

Voreinstellungen -> Suche -> Link "Index neu aufbauen"

[toutelle]

Hi

Das habe ich gemacht. Es funktioniert trotzdem nicht. Die Indizierung hat etwa eine halbe Stunde gedauert (19'000 Produkte), wurde dann erfolgreich abgeschlossen. Aber eben, die Suche funktioniert immer noch nicht.

[guest*]

Wenn der Index aufgebaut ist und 19.000 von 19.000 anzeigt, dann liegt der Fehler nicht in der Datenbank. Alle Begriffe müssten zur Verfügung stehen. Dahinter verbirgt sich allerdings ein JS, welches offensichtlich bei dir nicht mehr funktioniert. Was hat der Provider, denn für "Wartungsarbeiten" durchgeführt ? Er muss das was er geändert hat entweder rückgängig machen oder seine Skripte downgraden.

[toutelle]

Hi

 

Diese Wartungsarbeiten wurden durchgeführt:

- PHP 5.3 (von 5.3.5 auf 5.3.10)

- ghostscript von 8.71 auf 9.05

- mysql-client von 5.1.54 auf 5.5.20

- postgresql-client von 8.4.6 auf 9.1.2

- Imagemagick Update von 6.7.0.10 auf 6.7.4.4

- Perl von 5.10.1 auf 5.12.4

- pcre von 8.12 auf 8.30

 

Der Hoster wird kaum downgraden für mich.. leider.. also muss ich meinerseits gucken, wie ich da wieder rauskomme.

 

Gibt es vielleicht eine Möglichkeit, dass ich die Suche mit dem JS wieder geradebiegen kann, ohne dass ich die ganze Prestashop Installation upgraden muss? Ich habe einige zusätzliche Felder in den Datenbanktabellen hinzugefügt und ein wenig Respekt davor, das ganze upzugraden.

 

Kann ich das oder die JS-files vielleicht einzeln ersetzen?

 

Viele Grüsse und vielen Dank für die Hilfe.

[guest*]

So erste Zeile gelesen und das reicht. Alle JS sind ab der PHP-Version 5.3.9 nur noch sch... Ich selbst erlebte pausenlos Probleme damit, da ich immer "latest" eingestellt hatte. Ich habe downgegradet auf 5.3.8 wie du aus der Signatur sehen kannst. Hier laufen die JS fast alle ohne Probleme. Besser ist die Version 5.3.6. latest SSL SOAP.

 

Also bitte downgrade und deine Suche funktioniert wieder.

 

Also mein Hoster bietet mir die breite Palette an. Ich kann selbst wählen welche PHP ich fahre und zwar im Admin-Panel. Hast du einen share Host oder einen vHost ?

 

Nein du kannst nichts einzeln ersetzen. Alle Scripte wurde soeben auf den letzten Stand gebracht und das step-by-step. PS bedient sich da von open source Skripte.

[toutelle]

Hi.

Vielen Dank für Deine Antwort. Das hilft mir schon weiter. Ist wirklich ärgerlich. Wenn ich mein Prestashop auf die aktuellste Version upgrade, ist dann das Problem behoben oder funktioniert es generell mit 5.3.10 nicht, egal welche Prestashop Version?

 

Bin leider auf einem Shared Hosting. Wenn Du mir einen guten Hoster (vhost) empfehlen kannst, wäre ich Dir nicht undankbar.

[guest*]

Nein. 1.5 ist ja auch garnicht offiziell freigegeben.

 

Niemals die letzten PHP-Versionen fpr Live-Shops nutzen. Das gilt übrigens auch für andere Software. Auch der letzte Word Press läuft mit Probleme unter 5.3.9. 5.3.10 ist ja überhaupt noch nicht lange erhältlich. So schnell ziehen OS Scripte da auch nicht mit. Immer stabile und mindestens 4-5 Versionen niedrigere PHP-Versionen nutzen, als die letztaktuelle. Das hat sich bewährt und man schliesst viele Probleme damit aus. Wirklich gute Provider werden auch niemals sofort auf eine soeben erschienene PHP-Version Upgraden. Sie lassen den Kunden normalerweise selbst entscheiden, außer natürlich bei shared hosting. Wenn man so einen Host bevorzugt, muss man natürlich sich den Nachteil Abhängigkeit und 0 Flexibilität bewusst sein. Dafür zahlt man ja auch fast garnichts dafür.

[Tontaube]

Ich arbeite beim oben genannten SharedServer-Hosting-Provider, und würde gerne im Sinne der Community zu einer Verbesserung der Situation beitragen

 

Auch wenn unsere Standard-Server auch bezüglich Performance eher zu wenig für einen PrestaShop bieten, für unsere Business-(Shared)-Accounts möchten wir auf jeden Fall eine funktionierende Umgebung für PrestaShops anbieten.

 

Ich möchte den konkreten Fall kurz schildern, damit wir anhand eines konkreten Beispieles Verbesserungen für die Zukunft finden können:

 

* Wir haben Ende Feb mit dem Software-Stand von Mitte Feb begonnen, ein Update für unsere Umgebung vorzubereiten

 

* Im Laufe von März und April haben wir Tests mit verschiedensten Accounts, zuletzt mit mehreren tausend Kundenaccounts gefahren.

 

* ab 25. April haben wir das Rollout gemacht, da wir bis dahin keine Showstopper gefunden hatten.

 

Damit haben wir Ende April die PHP-Version von Anfangs Feb 2012 rollouted, welche unter anderem ein Sicherheitsloch geflickt hat;

PHP würde uns gar bitten, immer asap auf die neueste PHP-Version zu updaten (also innerhalb der Linie, z.B. von 5.3.10 auf 5.3.12).

Endanwender des Prestashops wissen meist nicht, was jetzt das für Ihren Shop bedeutet, und Entwickler bleiben am liebsten bei 5.3.5 bis sie in 2 Jahren auf PHP 5.4 wechseln (überspitzt ausgedrückt; ich bin auch Entwickler und kenn die Hintergründe dieser nach aussen meist sehr konservativ wirkenden Einstellung).

 

Ich fand leider beim Durchforsten der PrestaShop-Webseiten nur die Anforderung "PHP 5.2+" und ein paar wichtige Abhängigkeiten wie z.B. gd. Ob jedoch weitere, unter anderem die in der Liste von toutelle aufgeführte Software, eingesetzt wird ist für mich nicht klar ersichtlich. Für uns als Webhoster ist es - vermutlich für euch nachvollziehbar - erst recht schwierig, dies auch noch für alle möglichen Module abzuklären (oder nur schon herauszufinden, welche

Module weit verbreitet sind).

 

Wäre allenfalls jemand bereit, bei der nächsten Testrunde (wir updaten ca. halbjährlich) die Tests mit PrestaShop durchzuführen?

 

Ich gehe von einer Win-Win-Situation aus:

 

* wir können unseren Kunden eine bessere (SharedHosting- und ManagedServer) Umgebung bieten

 

* Die PrestaShop-Community entdeckt früher Probleme mit kommendenSoftware-Versionen und kann sie gezielt an Entwickler weitergeben

 

* Insgesamt ist der PrestaShop sicherer, wenn er zügig mit Sicherheits-Updates der verwendeten Software mithalten kann

 

Vielleicht gibt es aber andere Vorschläge, was Ihr einem SharedHoster empfehlen würdet? Wie seht ihr den Sicherheits-Aspekt?

Soll man einfach auf uralten PHP-Versionen bleiben / wie lange soll man warten mit dem Einführen einer neuen Version? (dies hat Einfluss auf die Sicherheit der Shops)

[guest*]

Ich nehme hierzu mal kurz Stellung:

• Dass ein shared hosting nicht die optimale Lösung für Prestashop ist, ist ja jedem bekannt. Dass allerdings 99,99% der Shared-Hoster auch keine eigene Anpassung an PHP-Versionen zulassen, das ist das größte Manko und das hat auch wenig mit einer bestimmten Anwender-Software zu tun. Weil sich Prestashop auch von sehr vielen externen OS-Skripten (JS) bedient, die nicht so schnell angepasst werden wie Prestashop selbst, ist es auch nicht möglich da mit allen Skripten aktualisiert mitzuhalten. Genau aus diesem Grund sollte man als User niemals php latest fahren. Im Testbetrieb so wie ich das mache schon, aber niemals im Live-Betrieb. Genau aus diesem Grund ist ein shared-hosting nicht die optimale Lösung.
  

• Die letzten PHP-Versionen, weil sie auch sehr knapp hintereinander herausgegeben wurden, zeigen auch eindeutig wo das Problem liegt. Eine gute PHP-Version wird nicht so schnell released. Interessant ist hier anzumerken, dass mein Provider mit gestern die Version 5.3.9 nur explizit für Testzwecke zurückgezogen freigegeben hat. 5.3.10, sprich noch höher steht garnicht zur Verfügung. Das hat sicher auch einen sehr triftigen Grund... Waren doch die letzten Versionen keine Glanzleistung, wie ich selbst an meinen Shops erfahren musste ???
  

• Wenn Bugs bekannt werden, werden diese auch im bug-tracker sofort gemeldet. Allerdings macht keiner, der wirklich jahrelang Erfahrungen als Anwender hat, sofort Updates von grundlegender Software wie PHP usw. Bugs werden relativ zügig ausgebessert, wenn sie verifiziert sind. Gibt es nur eine Meldung dazu, dann wird das eben nicht so schnell behandelt. Ich arbeite mit 3 Shops (aber keine Prestashop, sondern anderes System !) wo PHP 5.3 überhaupt nicht läuft. Aus diesem Grund werde ich ich auch diese Version nicht forcieren und habe die Datenbank für diese 3 Projekte eben nach wie vor auf 5.2. laufen. Warum sollte ich als Anwender auch eine Software austauschen, nur weil Provider nicht flexibel genug ist ? Da hole ich mir doch lieber ein etwas teureres Paket, wo ich auch flexible bin. Da müssen die Provider umdenken, wollen sie Kunden behalten und nicht Kunden dazu zwingen sich aufzuhängen, weil man seinen Server "Sicher" macht. Sicher ist schon mal rein garnichts, wenn man nicht anders Vorkehrungen trifft. Das wissen Sie als Entwickler genauso wie ich als langjähriger Anwender mit einem bereits gehackten Server, wo nur noch der Tausch der Festplatte möglich war.
  

• Prestashop ist sicher genug und das hat auch nichts mit den PHP-Versionen zu tun die der Provider verwendet. Meine Shops laufen unter 5.3.6 und 5.3.8 und sind weder gehackt, noch unsicher. Sicherheitssoftware sollte immer auch speziell eingesetzt werden. Dazu ist sie auch da. Sprechen Sie das PHP-Problem PHP-CGI an, so ist Prestashop davon garnicht betroffen. Um sicher zu gehen gibt es auch einen Post hier, der erklärt was man machen kann, aber nicht MUSS, wenn man dagegen noch zusätzlich etwas tun möchte.
  

• Woher sie entnehmen dass empfohlen wird, dass man Prestashop mit 5.2.+ fahren soll, das entzieht sich meiner Kenntnis. Es wird empfohlen AB 5.2 ausgenommen die Versionen die angegeben werden, weil sie fehlerhaft sind. Es gibt allerdings ein Post von mir, weil ich ja auch auf Entwicklerebene arbeite, wo beschrieben wird, was Mindestanforderung ist, um die aktuellen Versionen von Prestashop zu fahren.
  

• Wer im Forum auch mitliest, wird feststellen, dass eben die letzten PHP-Versionen nicht empfohlen werden. Somit muss man als Anwender auch leider flexibel bleiben, oder den Hoster sagen, dass fix eingestellt bleiben muss Version xxxx für Datenbank xxxx. Experimentieren kann man auf Testebene, so wie Sie als Entwickler das tun und ich auch, aber Kunden sind keine Versuchskaninchen.
  

[Tontaube]

Vielen Dank für die Stellungnahme. Da wir auch ManagedServer anbieten, nehme ich die Argumente gegen SahredHosting mal unkommentiert zur Kenntnis - es geht mir darum, zusätzliche Lösungen zu finden und nicht, für oder gegen bestimmte Art von Produkte zu sprechen. Deshalb als einiziges Statement dazu: Ein Shop-Betreiber der einen wesentlichen Teil seines Umsatzes mit dem Shop macht, sollte unbedingt ein Angebot mit SLA einsetzen, um auch gegen Ausfälle seitens des Anbieters abgesichert zu sein.

 

Das aktuelle Beispiel zeigt, dass PHP bereits darauf verzichtet, überhaupt noch Updates für Versionen ausserhalb von 5.3.x und 5.4.x anzubieten. Von Seiten PHP (beachten Sie dies bitte) ist also der Einsatz von PHP 5.2 auf Produktiv-Systemen nicht mehr zu verantworten. Gleichzeitig pflichte ich Ihnen bezüglich Release-Zyklus und "guten PHP-Versionen" absolut bei; eine stabile PHP-Version sollte länger gepflegt werden (auch/vor allem von Seiten PHP).

 

Wir als Provider stehen da etwas zwischen Stuhl und Bank: PHP sagt, auf keinen Fall mehr PHP 5.2 einsetzen, Sie sagen, wir sollen unseren Kunden freie Wahl lassen. Wie weit müssen wir unsere Verantwortung wahrnehmen, und veraltete Software aus dem Angebot streichen, wenn wir gleichzeitig bei leider doch immer wieder vorkommenden Hacks unsere Kunden unterstützen können wollen?

 

Ich kann Ihnen weiter nur zustimmen, dass wir als Provider so flexibel als möglich sein sollen. Genau deshalb will ich dazu hier auch noch mehr in Erfahrung bringen, insbesondere wie Sie an unserer Stelle handeln würden, da Sie die entsprechende Erfahrung bezüglich des PrestaShops besitzen. Ich pflichte Ihnen bei, die Sicherheit der Software hängt nicht alleine von der PHP-Version ab; umgekehrt können wir kaum je abschätzen, was ein konkretes PHP-Problem in irgendeinem Modul der Kunden für Konsequenzen hat. Weil wir dies nicht können, ist es fahrlässig wenn wir PHP nicht auf dem laufenden halten. Selbstverständlich bieten wir z.B. PHP 5.2 noch an, solange es noch Sicherheitsupdates gibt. Da es jetzt keine mehr gibt, müssen wir um nicht fahrlässig zu handeln, PHP 5.2 aus dem Verkehr ziehen. Wir werden bald PHP 5.4 anbieten, auf welche Kunden je nach Wunsch testweise umschalten können. Wir werden PHP 5.3 auch noch anbieten, wenn wir längst PHP 5.4+ als Default haben - solange PHP Sicherheitsupdates dafür herausgibt. Entspricht dies dem, was Sie unter Flexibilität verstehen? Oder wünschten Sie sich, dass jeder Kunde die Sicherheit selber beurteilt und man auch die PHP 5.2 Linie noch jahrelang weiter anbietet? Wo würden Sie als Shop-Mitentwickler da die Grenze ziehen? (interessiert Sie überhaupt, was PHP offiziell sagt?)

 

Eine Information von Ihnen, welche uns und unseren Kunden in Zukunft noch weiterhelfen könnte: Zum konkreten Problem / zu den Problemen unter PHP 5.3.10; hat man als externe irgendwo Zugriff auf den Bugtracker, damit man einsehen kann, was genau die Probleme sind und man allenfalls Workarounds oder Hilfe zu den Problemen anbieten kann? Damit wir in Zukunft vielleicht auch noch ein Update hinauszögern können, falls es ein bekanntes Problem gibt und wir aber noch keine Kenntnis davon haben? Im konkreten Fall wo wir erst ca. 60 Tage nach dem Release von PHP updated haben, hätten wir gerne Kenntnis davon gehabt dass mit dem PrestaShop Probleme auftreten, um den Kunden entsprechende Lösungen anbieten zu können (z.B. mit dem Update zuwarten oder auf bestehende Probleme hinweisen).

[guest*]

Selbstverständlich haben Sie Zugriff auf den bug-Tracker. Allerdings um mitzudiskutieren, auf Prestashop-Ebene, also auch als User von Prestashop muss man sie zunächst einmal einloggen.

 

Die Shops die ich mit 5.2. betreibe sind eine noch nicht sooo alte Software (6 Jahre am Buckel), die auch sehr gut läuft. Es gibt dazu ein gutes Sprichwort, welches mir immer wieder und erst vor kurzem auch wieder bestätigt hat: Never change a running system.

 

Ich hatte meinen großen Prestshop 1.4.4.1 auf 1.4.6.2 upgedated. Hatte da auch noch PHP latest eingestellt gehabt. Es war eine reine Katastrophe. Es ging kein einziges JS mehr. Kein Log-in mehr ins BO, die Suche ist ausgefallen, sämtliche JS haben zum Spinnen angefangen. Ich habe zunächst auf eine stabile 5.3.6 heruntergeschraubt. Habe dann graduiert bis auf 5.3.9 versucht. Diese lief so halbwegs, aber auch noch mit JS Ausfälle. Bin dann wieder auf 5.3.8 gegangen. Hier funktioniert alles sehr sauber, auch Word Press wieder ohne Probleme. Wobei WP halte ich penibel immer auf dem letzten Stand.

 

Auf ein Upgrade von externe Skripte zu warten ist der falsche Weg. Das liegt auch garnicht im Ermessen von Prestashop. Manche Skripte werden erst in einem Jahr verbessert. Prestashop wiegt hier dann den Faktor Kosten/Nutzen ab. User sollten niemals, wenn sie nur Produktiv damit arbeiten experimentieren. Das geht zu 100% irgendwann völlig daneben.

 

Grundsätzlich gilt es auch, egal ob shared, vHost oder dedi, ein User ist selbst verantwortlich für die Absicherung seines Webspaces. Es ist nicht die Aufgabe eines Hosters dies zu tun. Das Einzige was ein Hoster machen muss, sind zusäztliche Sicherungskopien bereitzustellen, wenn mal was schief geht. Bei meinem Provider gibt es nur 1X Jahr ein kostenloses Back-up und falls der Server eingeht. Sonst bin ich selbst dafür verantwortlich. Das ist ein Kompromiss den ich verkraften kann.

 

Auch ist es nicht nötig tausende von Euros für die Absicherung seines Webspaces gegen Spammer, Hacker und andere Schadbots auszugeben. Dazu gibt es ebenfalls sehr gute kostenloses Skripte die schon mal 99,99% dieser Malware abwehren. (project honeypot, bot-trap). Wenn man nicht in bestimmte Länder verkauft, sollte man auch das Geotargeting nutzen, was bei Prestashop mit an Bord ist. Wobei hier zu beachten ist, dass USA (Google, Yahoo, Alexa und andere große Suchmaschinen) niemals gesperrt werden soll. Schurkenstaaten wie Argentinien, Brasilien, Südafrika, Russland, Kolumbien, China, sollte man, wenn man dorthin nichts verkauft einfach mit Geotargeting sperren. So wehrt man auch schon einen großen Teil seiner Feinde ab.

Einen Hacker der es auf einen absieht wird auch eine teure Firewall oder Software knacken. Davor sind wir alle nicht geschützt.

 

Ob ein Provider eine beratende Tätigkeit übernimmt in Punkto Sicherheit, das muss jedem selbst überlassen werden. Das ist eine Dienstleistung die fast niemand anbietet und wenn, dann extra zu zahlen. So sollte es auch bleiben, denke ich. Weil das muss auch mit der eingesetzten Software abgestimmt werden. Ich z.B. fahre nicht nur einen Prestashop, es sind Projekte die mit anderer Software kommunizieren und untereinander Daten austauschen. Da aus einer Hand eine beratende Dienstleistung anzubieten ist vermutlich nicht sehr leicht. Es kennt kein Provider alle Programme im Kern. Die meisten stellen lediglich den Webspace zur Verfügung und das war es dann auch. Herumschlagen muss sich der User dann mit Fachchinesisch. Ich habe vor, jetzt sind es schon 8 Jahre, auch nicht anders angefangen. Musste auch lernen und habe viele Fehler gemacht. Das Know-How wenn erfragt wird hier im Forum weitergegeben.

 

Hier im Forum gab es schon einige Postings bezüglich Absicherung des Webspaces. Wir helfen und beraten gerne, denn wir kennen auch die Software am Besten und dazu ist ja ein Forum für eine bestimmte Software da.

[Tontaube]

Ob ein Provider eine beratende Tätigkeit übernimmt in Punkto Sicherheit, das muss jedem selbst überlassen werden. Das ist eine Dienstleistung die fast niemand anbietet und wenn, dann extra zu zahlen.

Wir versuchen, ein gutes Fundament zu sichern indem wir nur sichere Software zur Verfügung stellen. Dies bedingt aber natürlich ein regelmässiges Update sämtlicher CMS durch unsere Kunden - welche damit meist aber auch sicherer werden. Dies kostet uns einiges an Zeit - so haben aber insgesamt die sauberere Umgebung und können dadurch mit angemessenen Kosten den besseren Kundensupport anbieten und trotzdem den schweizer Ansprüchen an Verfügbarkeit genügen.

 

Vielen Dank für deinen investierte Zeit im allgemeinen zum Thema - für mich war es sehr interessant, deine Sicht noch näher kennenzulernen. Nun aber zurück zum eigentlichen Thema des Threads:

 

Wir konnten nun eine Ursache der kaputten Suche finden: Das Problem ist, dass das verwende Such-Modul die Funktionen von Drupal übernommen hatte, wo ein bekannter Bug mit pcre 8.30 auftritt. Wie man den Fehler beheben kann, liest man am besten beim entsprechenden Bug im Drupal Bugtracker nach: http://drupal.org/node/1446372

 

Kannst du mir per Zufall noch erklären, wie ich die Ausgabe von Fehlermeldungen _aktivieren_ könnte? Wenn nämlich der auftretende Fehler irgendwo sichtbar ist, kann ich das nächste mal den Zusammenhang anhand der Fehlermeldung auf Anhieb feststellen.

[guest*]

Wir versuchen, ein gutes Fundament zu sichern indem wir nur sichere Software zur Verfügung stellen. Dies bedingt aber natürlich ein regelmässiges Update sämtlicher CMS durch unsere Kunden - welche damit meist aber auch sicherer werden. Dies kostet uns einiges an Zeit - so haben aber insgesamt die sauberere Umgebung und können dadurch mit angemessenen Kosten den besseren Kundensupport anbieten und trotzdem den schweizer Ansprüchen an Verfügbarkeit genügen.

Das ist ein sehr unrealistischer Ansatz, zumindest beim shared hosting. Am Beispiel Drupal sieht man ja, dass so etwas umzusetzen nicht möglich ist. Jeder User sollte zugeschnitten auf seine Anwendungen die Beste Möglichkeit einsetzen. Ein Server wird so etwas niemals als Gesamtpaket erfüllen können.

Weiters, welche Software ist auch 100% sicher ? Pauschal gesagt: keine, sowie auch keine Software fehlerfrei ist.

 

Bezüglich der Fehlermeldungen Aktivierung: a) Fehler müssen serverseitig auch aktiviert sein, sonst wird nichts angezeigt. b ) in der /config/config.inc.php den DEBUG-Modus aktivieren. Dies sollte aber niemals im produktiven Einsatz geschehen, weil die Fehler auch fronted ausgegeben werden, was eine Möglichkeit zu Hack-Attacken zur Folge haben kann.

[Tontaube]

Am Beispiel Drupal sieht man ja

... dass wir durch Tests die Probleme erkannt hatten und erst nachdem die aktualisierten Drupal-Versionen verfügbar/absehbar waren unsere Updates durchgeführt haben. Im Idealfall können wir unsere Kunden in Zukunft auch noch gezielt und genug früh informieren, so dass Sie vor einem grösseren Update von unserer Seite Ihre Applikation aktualisieren können. Möglich ist es wenn man will.

 

Bezüglich 100%iger Sicherheit: full ack

 

Danke für die Infos bezüglich Fehlermeldungen. Im Falle, dass ein unvorhergesehenes Problem bei einem LiveShop auftritt, würde ich kurz einen Passwort-Schutz aktivieren welcher darauf hinweist, dass kurz Wartungsarbeiten durchgeführt werden und für diesen Moment das Debugging aktivieren. So ist der Unterbruch 5min und man hat nachher verwertbare Daten. Ihre Empfehlung, den Debug-Modus aus Sicherheitsgründen nicht im Live-Betrieb zu aktivieren, kann ich nur unterstützen.

[guest*]

Das brauchst du nicht. Prestashop hat so eine Funktion eingebaut. Einfach unter Voreinstellungen -> Shop aktivieren auf NEIN und dann im Feld darunter die IP eintragen die man gerade verwendet. Der Shop wird bis auf die dort eingetragenen IP's mit einer Seite versehen: Wartungsarbeiten, bitte besuchen Sie uns später noch einmal.

 

Fehlermeldungen fronted sind immer ein gefundenes Fressen sich einen Code zu stricken, der in die Schwachstelle eindringt. Aus diesem Grund und auch weil es nicht sehr professionell ist einen Shop den Kunden mit Fehler freizugeben, sollte man das vermeiden.

[netsolution]

Hallo

 

Wir sind auch bei Hostpoint und haben das Problem mit der Suche - gibt es inzwischen eine praktikable Lösung?

 

Besten Dank!

[guest*]

Post durchgelesen ? Suche neu indexieren, wie unter #2 angegeben. Das Problem bei diesen Hoster war eine andere Software die interferierte. Hat nichts mit Prestashop zu tun, sondern mit der Serverkonfiguration. Bringt #2 keine Lösung Provider kontaktieren und dort um Lösung verlangen.

[Tontaube]

Hallo

 

Ja, zumindest bei einem Kunden konnten wir den Fehler auf das Update der pcre-Software zurückverfolgen. Geholfen hat das Vorgehen, welches auch bei Drupal beschrieben wird:

Das Problem ist, dass das verwende Such-Modul die Funktionen von Drupal übernommen hatte, wo ein bekannter Bug mit pcre 8.30 auftritt. Wie man den Fehler beheben kann, liest man am besten beim entsprechenden Bug im Drupal Bugtracker nach: http://drupal.org/node/1446372

Konkret muss man im Suchplugin 2-3 dieser Codes rauslöschen.

 

Falls das zu wenig genau ist: Den Debug-Modus aktivieren und die Fehlermeldungen anschauen (vorher wird empfohlen den Wartungsmodus zu aktivieren, so dass nur eue IP die Fehlermeldungen zu Gesicht bekommt; das Vorgehen ist weiter oben beschrieben); mit den konkreten Fehlermeldungen könnt ihr euch gerne auch an den Hostpoint Support wenden (dort am besten mit Vermerk "zuhanden von Tontaube" ;-) ).

[netsolution]

Konkret musste ich

 

\x{d800}-

 

rauslöschen (Zeile 56 in classes/Search.php)

 

Nachher hats wieder funktioniert (Suche neu indexieren nicht notwendig, resp. bringt nichts)

 

Falls noch jemand danach sucht...

[guest*]

Ich hab's mal in den bug-tracker aufgenommen http://forge.prestas...owse/PSCFI-5684

 

Danke für die Rückmeldung.

[JrDeline]

Danke für den Tip. Hatte seit kurzem das selbe Problem und dank der Lösung funktioniert es wieder

[toybox]

Hallo Zusammen,

 

ich hatte diesen post mal eröffnet und habe nun ein grundsätzliches Problem mit der Suchfunktion.

Kein Begriff oder Artikelnummer wird gefunden.

 

Index neu erstellt. Auch die in diesem post am Ende angegebenen Drupal-Änderungen in classes/search.php wurden getestet, ohne Erfolg.

 

Ich habe presta 1.4.6.2. und PHP 5.3.21 auf dem Server.

 

Wo kann ich da noch ansetzten?

 

Vielen Dank!

[guest*]

Bricht dein Server vorher ab, wenn du die Artikel alle neu indexierst ? Schau einmal ob sich die Tabellen in der Datenbank überhaupt gefüllt haben.

 

ps_search_egine

ps_search_index

ps_search_word

 

Wenn die Tabellen mit 0kb stehen, dann wird nicht indexiert. Steht allerdings dort ein Wert, dann hast du ein Skript Problem. Eigenes Theme ?

[kontakt.plus]

Prestashop Suche funktioniert nicht mehr

 

Funktioniert in Ihrem Prestashop OnlineShop die Suche plötzlich nicht mehr, ohne das es Änderungen gab?

Prestashop Versionen 1.4 ?

 

Hier nochmals die genau beschriebene Lösung zur Fehlerbeseitigung/Bug-Fix:
 

1. Loggen Sie sich mit FTP ein und gehen in die Search.php im Ordner Classes.

 

2. Zeile/Line 56 “x{d800}” einfach ersetzen mit “x{e000}”, anschließend speichern und hochladen.

 

 

 

3. Danach die Suche im Backend von Prestashop neu indexieren lassen unter Voreinstellung > Suche