Jump to content

Scully

Members
  • Posts

    2,677
  • Joined

  • Last visited

  • Days Won

    22

Everything posted by Scully

  1. Bald ein Jahr her seit dieser Thread gestartet wurde. Und es hat sich leider bei Prestashop kaum Relevantes zum Besseren gewandelt. Quo vadis Prestashop?
  2. Du hast natürlich recht, ich habe die Formatierung gelöst, nicht die Rundung.
  3. SSL hat erstmal meines Wissens keinen Einfluss auf den Versand der Mails. Die P.S.-Version hast Du nicht erwähnt - darum: Lesen in der Glaskugel
  4. Und natürlich muss man die Währung entsprechend umkonfigurieren. Da das vmtl. nicht direkt über das Shop Backend geht, weil dieses noch nichts von diesem Fomat 5 für Franken-Rundung weiss, ändert man es am einfachsten direkt in der Datenbank. Die Tabelle heisst ps_currency und das Feld heisst Format. Dort muss dann auch eine '5' rein.
  5. Gaaaanz ausnahmsweise schreibe ich hier nochmal eine Hilfe, weils ein Schweizer Problem ist ;-) Die Rundungsfunktion finden in classes/Tools.php statt und dort in public static function displayPrice. Der Case 5 ist derjenige von mir hinzugefügte für CHF. Das sind drei Zeilen zusätzlich. switch ($c_format) { /* X 0,000.00 */ case 1: $ret = $c_char.$blank.number_format($price, $c_decimals, '.', ','); break; /* 0 000,00 X*/ case 2: $ret = number_format($price, $c_decimals, ',', ' ').$blank.$c_char; break; /* X 0.000,00 */ case 3: $ret = $c_char.$blank.number_format($price, $c_decimals, ',', '.'); break; /* 0,000.00 X */ case 4: $ret = number_format($price, $c_decimals, '.', ',').$blank.$c_char; break; /* X 0'000.00 Added for the switzerland currency */ case 5: $ret = $c_char.$blank.number_format($price, $c_decimals, '.', "'"); break; }
  6. P.S. Das www als Präfix gemahnt mich an die Urzeiten des Internets. Braucht doch heute kein Mensch mehr. Das würde ich in der Konfiugration somit auch weglassen. Wenn man cachen möchte, habe ich mit Express Cache akzeptable Erfahrungen gemacht. Der Performancegewinn ist in der Regel gut spürbar, mitunter hat es bei Updates des Modules gewisse Holprigkeiten gegeben.
  7. Deine Startseite wird insgesamt dreimal hintereinander geladen. Das kann nicht schnell sein. Gibt man einfach wirdrucken.at als URL ein, dann wir folgendes geladen: http://wirdrucken.at => Weiterleitung an http://www.wirdrucken.at => Weiterleitung an https://www.wirdrucken.at Schlechter kann man es kaum konfigurieren.
  8. Du hast zwar nicht geschrieben, welche PS-Version Du einsetzt. Aber ich denke, die Antwort ist allgemeingültig: man kann das nur lösen, indem mal selbst den Programmteil der Warenkorbregeln neu schreibt. Allenfalls gibt es auch ein Kaufmodul dazu. Jedenfalls ist es mit Bordmitteln nach meinem Wissen nicht umsetzbar.
  9. I don't follow this subject anymore and mostly stopped supporting the forum. That is the reason why you don't find the patch anymore.
  10. Würde ich eine solche Lösung einfach umsetzen, dann wäre es mithilfe einer Auswertung, bei welcher der tatsächliche Zahlungseingang mit der Bestellung abgeglichen wird. Es gibt nämlich nicht nur ein Status (dessen Wert "flüchtig" ist), sondern auch eine Tabele mit Payments. Da kann ich sogar sehen, wenn jemand nur eine Teilzahlung geleistet hätte. Wenn also Total(Payment_Amount) < Order_Amount, dann muss ich da nachfassen, Rechnung oder Mahnung senden.
  11. eleazar, Du hast in vielen Punkten natürlich Recht. Und es ist ja deshalb auch nicht verboten, seine eigenen Schlüsse zu ziehen. Im realen Leben geht man dem einen oder anderen undankbaren Mitmenschen aus dem Weg. Und im Forum kann man das indirekt auch machen. Wenn dann halt von den Usern, welche regelmässig mit Hilfestellungen zur Hand waren ein Teil wegbricht, dann markt man es irgendwann.
  12. Wir haben als Dienstleister im Bereich PrestaShop nie eine Migration auf eine PS 1.7. gemacht. D.h. die von uns betreuten Shops laufen oder liefen alle unter PS 1.6.1.1x. Zur Kernfrage: Ich hatte für PS 1.6. ein Modul für Ferienabwesenheiten geschrieben, welches im Header, im Bestellablauf und (wahlweise) in den Mails auf Ferien-/Abwesenheiten hingewiesen hat. Den Bestellablauf selbst hat das Modul nicht beeinflusst. Stattdessen konnte man von der Hinweismeldung im Header direkt auf eine CMS - Seite verweisen, wo man ausführlich erläutern konnte, was wie wo wenn. Gut möglich, dass es sowas auch zu kaufen gab irgendwo.
  13. Und P.S. machmal oder zu oft auch wenig Wertschätzung von Forums-Mitgliedern gegenüber den Kollegen hier. Das Forum sollte halt auch keine Einbahnstrass sein. Ich hatte letztes Jahr zB einen Patch geschrieben, damit die Suchfunktion auch bei zwei oder mehr Suchworten korrekte Ergebnisse liefert. War damals ein beständig und heiss diskutiertes Thema bzw. Problem. Ich habe den Patch auf Anfrage auch sicher 50x mal per Mail versendet. Hmm... wie oft kam nach dem Versenden noch eine Rückmeldung oder einfach ein Danke? Zwei mal, drei mal?
  14. Ich habe im August diesen Jahres einen Post geschrieben, weshalb ich mich aus dem Forum weitgehen zurückgezogen habe. PrestaShop hat halt vieles falsch gemacht in den letzten Jahren. Der Update der Forums-Software war ein voller Misserfolg, Forum auf mobilen Geräten geht so gut wie gar nicht, Forum oftmals voll von Spam (eher im englischsprachigen Bereich) und wenig Wertschätzung von PrestaShop gegenüber verdienten Community-Members, um nur ein paar Stichworte zu geben. Irgendwann schlägt sich das halt auch nieder in einem Forum.
  15. Diese Meldungen beziehen sich aber nicht auf die Version 1.6.1.22 sondern auf den Inhalt Deines THEME-Ordners. Da sind im Theme Dateien nicht vorhanden, welche das AEUC-Modul wohl braucht. So zumindest meine Interpretation. Ich nutze das Modul selbst nicht.
  16. Korrektur zu obigem Post: Das sind NOTICE Meldungen. Keine Fehler. Das ist unschön, aber es passiert dabei nichts schlimmes. Und wenn die rosaroten Fenster aufpoppen, dann deutet das darauf hin, dass in der Config Datei defines.inc.php der Wert _PS_MODE_DEV_ auf true gesetzt ist. Dieser Wert sollte aber im normalen Betrief auf false sein. Sonst loggt PrestaShop eine Menge an Daten, die man eigentlich im Normalbetrieb nicht will und nicht braucht.
  17. Ich habe ein paar 1.6.1.17 bis 1.6.1.19 Shops laufen auf PHP 7.2. Das funktioniert, hat aber für jeden Shop einen halben Tag Anpassungsaufwand gemacht. Vorgehensweise: Nach Umstellung auf PHP 7.2. alle relevanten Shop Funktionen testen, während man den Debug / Debug-Profiling Modus aktiviert hat. Und dann den Code dort anpassen, wo es Fehlermeldungen gibt. Im genannten Zeitaufwand ist das aber nur für sehr erfahrene PHP-Entwickler so machbar.
  18. Es gibt Module und z.B. auch das PrestaShop Dashboard, welche Verbindungen zu PrestaShop Servern herstellen. Haben diese Server ein Problem, hat oftmals auch die lokale Installation ein Problem, weil der Standard-Timeout oftmals bei 30 Sekunden liegt. Generell: Nur die Module auch wirklich installiert lassen, die man braucht und nutzt. Alles andere: deinstallieren (löschen muss man die Module deswegen ja nicht).
  19. Bei solchen Antwortzeiten ist es sehr wahrscheinlich, dass im Server-Logfile Fehler abgelegt werden. Daher einmal das Error_Logfile von Apache / NGnix anschauen. Und in Prestashop Debug Profiling anschalten. Da sieht man dann auch gut, wo die Zeit verbraten wird.
  20. Du solltest vielleicht schreiben, dass die Search Console eventuell die Google Search Console ist? Ich vermute nur. Hellsehen können die wengisten. Wenn dem so ist: dann schau dort, woher der Content Verlinkt wird. Das kann man nämlich bei einem Klick auf den fehlerhaften Link sich anzeigen lassen.
  21. Du kannst diese Felder unter Lokalisierung / Länder im jeweiligen Land bearbeiten. Telefonnummer kann man wohl weglassen, ist dann aber auch in der Erfassung weg. Das Land kann man ohne Eingriff im Core Programm nicht wegmachen.
  22. It is a known bug (at least known to me). It is caused by the wrong handling of url string parameter escaping in the search function. I fixed that some two years ago but haven't the fix ready to dispatch.
  23. Wenn man sich die Mühe machte und die Logfiles analysiert, dann stellt man fest, dass in 99% der Spam das Kontaktformular gar nie im "Lesemodus" aufgerufen wird. Es gibt im Logfile in der Zeitspanne in der Regel nur einen POST Request, Einen GET davor jedoch nicht. Daraus kann man folgern, dass die Spam-Roboter direkt per POST an eine bereits vorher bekannte URL den Request absetzen. Damit kann man nun auch eine Abwehr einbauen. Wir öffnen ContactController.php: Schauen dort in public function initContent() und setzen bei der Anzeige des Formulars (GET) ein Session - Cookie mit Timestamp. session_start(); if ($_SERVER['REQUEST_METHOD'] == 'GET') { $_SESSION['testcookie'] = time(); } Trick: Wir setzen das Session Cookie nur, wenn es sich um einen GET Request handelt. Der GET entspricht dem "Anschauen" des Formulars durch einen Besucher. ... um dann bei Erhalt eines Formularinhaltes mittels POST zu schauen, ob auch ein Cookie vorhanden und in einem akzeptablen Zeitabstand gesetzt wurde... Das kommt dann in die Funktion public function postProcess() if (time() - $_SESSION['testcookie'] > 180) { $_SESSION['testcookie'] = 0; $this->errors[] = Tools::displayError('Invalid request'); } Im Beispiel wird eine Fehlermeldung generiert, wenn das Cookie älter als 3 Minuten ist. Weiters könnte mann dann auch noch so verschärfen: if (!Validate::isCleanHtml($message) OR stripos($message,'http://') !== false OR stripos($message,'https://') !== false ) { $this->errors[] = Tools::displayError('Invalid message'); } ... indem wir keinen Inhalt mit http oder https in der Nachricht selbst zulassen. Spam beinhaltet ja in der Regel einen Link. Ggf. könnte man '<a href' auch noch in die Liste aufnehmen. So läuft es bei uns seit Jahren und ohne Spam.
  24. @Claudiocool Mit Dir war es jedenfalls immer kurzweilig, das gilt durchaus auch für eine Handvoll anderer Leute hier aus der Community. Nur reicht das nicht aus für eine längere und engagierte Arbeit hier im Forum. Bei mir war die Motivation da, die Community von PrestaShop zu unterstützen, zur Verbreitung des Systems beizutragen (damit dessen Weiterbestand zu sichern) und natürlich selbst dazu zu lernen. Ich habe viel aus Problemen anderer User und deren Analyse auf unseren eigenen Systemen gelernt. Das funktionierte immer dann gut, wenn zu einer Problemstellung dann auch mal die Lösung veröffentlicht wurde oder zumindest die Fragestellung präzise und mit gewissen Grundinformationen versehen war. Genau in Bezug darauf fand ich zu viele Fragesteller aber zu häufig als unzureichend. Indem man: aa) als Themenstarter / Fragesteller das Resultat der Hilfestellungen irgendwann nicht weiter kommentierte. Es sind mir sowohl im englisch- als auch deutschsprachigen Forum doch eine grössere Anzahl User bekannt, die es jeweils schafften, immer neue Threads zu oft unterschiedlichsten Fragestellungen aufzutun ohne jemals einen einzigen davon sauber abzuschliessen. Oder Threads zur gleichen Fragestellung doppelt einzustellen. Ich habe in vielen Threads auch dazu angemahnt, diese nicht unbeantwortet zu verlassen. Leider zu häufig ohne Erfolg. bb) Die immer gleichen Grundinformationen vermissen liess. Welche Version, welche Module, welche Fehlermeldung. Oder, nachdem man sich genau danach erkundigte, wochenlang Funkstille war. Eine Community funktioniert längerfristig nur dann, wenn die Mehrheit der Teilnehmer gewisse Grundregeln berücksichtigt. Das hat auch mit Respekt und Umgangsformen zu tun. Im PrestaShop Forum hatte ich zunehmend den Eindruck, dass es eine Masse von Fragestellern gab, die einfach nur innert kürzest möglicher Zeit eine Lösung wollten. Selbst nachdenken lieber nicht und der Community etwas zurückgeben auch nicht. Es gibt aber zahlreiche Foren, die beweisen, dass es besser funktionieren kann. Dazu muss man halt auch schauen, dass man sich um Forum und Community entsprechend bemüht. PrestaShop kümmert sich weder ausreichend um das Forum noch um die Community. Wie es hier schon geschrieben wurde: das Forum ist eher lästig aber weil es ganz ohne nicht geht, betreibt man es halbherzig. Dass war übrigens keine Kritik an den Moderatoren.
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More