Jump to content

comfuse

Members
  • Posts

    28
  • Joined

  • Last visited

Profile Information

  • Location
    Osnabrück, Germany
  • Activity
    Web development agency

Recent Profile Visitors

1,830,682 profile views

comfuse's Achievements

Newbie

Newbie (1/14)

  • First Post Rare
  • Collaborator Rare
  • Week One Done Rare
  • One Month Later Rare
  • One Year In Rare

Recent Badges

1

Reputation

  1. Hallo, wir haben ein Problem, mit dem wir schlicht nicht alleine sein können, wir finden aber nirgends eine Lösung. Wir nutzen ein Suchmodul (Totl Search Pro), das sowohl eine Ajax Suche ausführt und in einem Overlay getrennt nach Produkten, Kategorien und CMS Inhalten Ergebnisse als auch eine Suchergebnisseite ausschmeißt. Auf letzterer wollen wir Filter zur weiteren Verfeinerung des Suchergebnisses anbieten. Als Filter nutzen wir Advanced Search 4 und hier leigt das Problem. Wie bekommen wir es hin, dass die Filtersuche sich an dem Suchkontext der Ergebnisse orientiert? Momentan werden einfach alle Filter des gesamten Katalogs angezeigt, ohne Orientierung an dem Suchergebnis. Das heißt, dass man als Suchergebnis für "Hose" korrekt alle Hosen angezeigt bekommt, sobald man aber das Suchergebnis nach alles schwarzen Hosen filtern will, auch alle schwarzen Socken ausgegeben werden. Nicht das, was was wir wollen, von daher wäre die kurze Frage: Wie realisieren wir eine korrekte After Search Filternavigation? Module habe ich keine gefunden, aber vielleicht feht mir auch einfach der richtige Suchbegriff. Würde mich sehr über Tipps freuen. Danke für Eure Aufmerksamkeit.
  2. Guten Tag, wir haben eine Frage zum Vorgehen des Prestashop, wenn sich URLs im System ändern. Beispiel: Eine Seite ändert den Pfad, weil der Kunde seinen Content diversifiziert. Aus www.meinepage.de/socken wird www.meinpage/kleidung/socken. Oder www.meinepage.de/sportsocken. Im Rewriting kein Problem, aber wo wird die Weiterleitung von der alten auf die neue URL im PS gespeichert? Weiß das jemand? Danke im Voraus.
  3. Hallo, das mag alles stimmen, aber der Kunde ist nun mal seit Jahren so unterwegs und möchte seine Anforderungen nicht ändern. Da hängen Warenwirtschaft, SEO-Kram und europaweiter Konzern-Schnickschnack dran, den wir als technischer Dienstleister nicht wegdiskutieren können. Und wahrscheinlich gibt es wasserdichte Beispiele für die Notwendigkeit einer solchen Differenzierung, die der Kudne selbst besser erklären könnte. Hier geht's aber leider, und ich wiederhole mich ungern, um das wie und nicht das warum. Trotzdem Danke für Deinen Einsatz. Scheinbar ist die Multishop-Funktionalität des PS grundsätzlich eine selten besuchte Baustelle :)
  4. Hallo, erstmal Danke für die Antwort. Es geht in meiner Anfrage nicht um das "Warum" oder wie es besser bzw. logischer gehen würde, sondern um die schlichte Anforderung des Kunden. Identische Gutscheincodes, aber nur unique für die jeweilige Shopinstanz. Anderes Beispiel: In den Niederlanden gilt der Gutschein für orange Warnwesten, in der Schweiz für gelbe, Rabattaktion ist aber die gleiche. Bezieht sich in diesem Fall auf den Bereich Berufsbekleidung und da differieren die jeweiligen regiónalen Aktionen nun mal voneinander, während sie im Marketing gleich behandelt werden. Und da ist dann noch ein wichtiger Punkt: Wenn die Differenzierung im Multishop nicht möglich ist, muss der Kunde seine gesamten Marketing-Prozesse anpassen, darum ist er natürlich scharf darauf, es so umgesetzt zu bekommen, dass er das nicht machen muss
  5. Hallo, wir haben ein Projekt mit einem Multishop, in dem unser Kunde mehrere Marken(shops) in mehreren Ländern anbietet. - Innerhalb einer Marke fährt der Kunde Gutscheinaktionen (über Warenkorbregeln), die mit dem gleichen Code länderübergreifend gelten sollen. Soweit so gut. Aber: - Der Gutschein "winter20", der 20% auf den Bestellwert gibt, soll von Land zu Land unterschiedliche Bedingungen haben, z.B. einen unterschiedlichen Mindestbestellwert oder unterschiedliche Festrabatte (5 Euro in DE, 8 Euro in AT, 3 Euro in NL) usw. - Das bekommt man im Standard nicht getrennt, weil zwar Gutscheine für unterschiedliche Shops angelegt werden können, diese aber nicht einen identischen Code haben dürfen. Gibt es Addons, die so ein Problem abbilden können? Oder eine Möglichkeit, die Gutscheinlogik so zu beenflussen, dass ein Guscheincode nur pro Shop unique ist und nicht im gesamten Multishop? Würde mich brennend interessieren, im Sinne von: Ich freue mich schon auf die Handarbeit Gruß Carsten
  6. Hallo, der Support für das Migrationsmodul hat die Sache gefixt. Das problem entstand wohl durch Kunden, deren Konto im alten Shop erzeugt wurde, die aber dann in der Version 1.7 einer Validierung unterzogen werden, bei der es dann im classes /customer.php knallt. Hier musste dann die Validierung von Vorname, Name und E-Mail-Adresse auskommentiert werden, damit diese Felder nicht mehr als Namen bzw. E-Mail, sondern lediglich als Zeichenektten getestet werden. Sieht dann so aus: public static $definition = array( 'table' => 'customer', 'primary' => 'id_customer', 'fields' => array( 'secure_key' => array('type' => self::TYPE_STRING, 'validate' => 'isMd5', 'copy_post' => false), 'lastname' => array('type' => self::TYPE_STRING), // 'lastname' => array('type' => self::TYPE_STRING, 'validate' => 'isName', 'required' => true, 'size' => 255), 'firstname' => array('type' => self::TYPE_STRING), // 'firstname' => array('type' => self::TYPE_STRING, 'validate' => 'isName', 'required' => true, 'size' => 255), 'email' => array('type' => self::TYPE_STRING), // 'email' => array('type' => self::TYPE_STRING, 'validate' => 'isEmail', 'required' => true, 'size' => 255), 'passwd' => array('type' => self::TYPE_STRING, 'validate' => 'isPasswd', 'required' => true, 'size' => 255), 'last_passwd_gen' => array('type' => self::TYPE_STRING, 'copy_post' => false), ... Was das zukünftig für Auswirkungen hat, werden wir sehen... Ich hoffe, dass zukünftig niemand statt E-Mail-Adresse "Kartoffel" als Login benutzen kann... Markiere trotzdem mal als [Gelöst] Danke allen für die Mithilfe. Carsten
  7. Ja, das werde ich jetzt machen (in der Hoffnung, dass die alte Datenbank noch da ist).
  8. Das ist ja gerade der Witz, wir können den Fehler nicht reproduzieren, bei uns klappt der Login immer. Und was den "development" Part betrifft, ist unser Programmierer natürlich gerade im Urlaub
  9. 1590 Kunden, urghs... Das ist nicht das, was man direkt nach seinem Urlaub lesen möchte, aber erstmal Danke, sowas hatte ich schon befürchtet. Das Error-Log faselt etwas von PHP7 Fatal Errors in der SortOrder.php, das wird was anderes sein - was es aber nicht besser macht... Das Log ist allerdings mal eben alleine 120 MB schwer (!), was mich nicht so zuversichtlich stimmt. Kann es am Ende an der PHP-Version liegen?
  10. Hallo, wir haben einen PS 1.6 nach PS 1.7 migriert (mit dem Addon von Migration Pro, https://addons.prestashop.com/de/datenmigration-backup/8934-migrationpro-prestashop-upgrade-und-migrationstool.html). Die migrierten Kunden haben mit der Ausnahme EINER Kundengruppe keine Probleme beim Anmelden - nur eine im alten Shop zusätzlich erzeugte Gruppe wird beim Login regelmäßig mit einem Fehler 500 geschmissen. Kurios: Der Kunde kann dann sein Passwort neu vergeben, der Login klappt damit ein Mal, und beim nächsten Mal geht es wieder nicht mehr. Kennt das jemand so oder ähnlich? 500er Fehler sind immer doofes Fischen im Trüben. Diesen kann ich zudem nicht mal reproduzieren, weil es bei mir mit Testkunden in dieser Kundengruppe immer funktioniert... Wäre für jeden Ansatz dankbar. Carsten Shopdaten: PHP-Version 7.2.19-0ubuntu0.18.04.1 MySQL-Version 5.7.27-0ubuntu0.18.04.1 PrestaShop-Version 1.7.5.0
  11. Ach so, das wird direkt von Crowdin als Übersetzungspaket geladen? Ich dachte, das müsse man immer proaktiv machen, also die xlf runterladen, in DE umbenennen und dieser ganze Zipp und Zapp. War das nicht mal so?
  12. Wie heißt das bei Facebook im Besziehungsstatus? "Es ist kompliziert" Ich danke trotzdem im Voraus und wünsche ein schönes Wochenende!
  13. Nein, die Übersetzungen von Crowdin nutze ich schon einige Zeit nicht mehr. Die max_input_vars hatten wir vorsorglich (und weil der Attribute Wizard in dieser Hinsicht ja königliche Anforderungen hat) auf einen absurd hohen Wert gestellt (10.000?), damit da nichts anbrennt. Das ist aber auch nicht gerade die feine Art, hat der Webhoster gesagt. Ich wüsste nicht warum, aber kann das die Installation unsicher machen? Den APC würdest Du also wieder deinstallieren? Wir haben den Smarty-Cache ausgeschaltet, aber CCC aktiv. Carsten
  14. Mir ist gerade noch was eingefallen: Wir haben im Laufe des Aufbaus erst den APC Cache aktiviert, später dann aber auf MEMCache umgeschwenkt. In der PHP.ini sehe ich gerade, dass beide Module noch aktiv sind. Wir nutzen MEMCache, bekommen im Bakcend aber zudem eine eher seltsame Liste verfügbarer Cache-Arten angezeigt (Screenshot, 2x MEMCached ???). Sollte man das vielleicht mal "entschlacken"? Und welcher Cache ist überhaupt empfehlenswert? Carsten
  15. Guten Morgen, die Befürchtung steht im Raum, ja. Blöderweise ist das nicht unser Server, er wird von einem zweiten Dienstleister bereitgestellt. Das hier kann ich im Backend sehen: Serverdaten: Linux #58-Ubuntu SMP Mon Jun 24 10:55:24 UTC 2019 x86_64 Version der Server-Software: Apache/2.4.29 (Ubuntu) PHP-Version: 7.2.19-0ubuntu0.18.04.1 Speichergrenze: 2048M max_execution_time: 300 Upload (max. Dateigröße): 64M Datenbank: MySQL-Version 5.7.26-0ubuntu0.18.04.1 PrestaShop-Version: 1.7.5.0 Müsste man für eine Einschätzung noch andere Daten haben? Die müsste ich anfragen. Was Serverkonfiguration angeht, haben wir uns bislang immer auf die Hoster verlassen und solange im Backend grüne Haken waren, war alles okay Der Shop an sich rennt jetzt nicht unbedingt, aber es ist erträglich. Die Übersetzungspakete haben wir shcon ein paar Mal von Crowdin runtergeladen und selber auch ein paar Eingaben dort gemacht. Aber die Übersetzungen gelten ja nur für den Core, richtig? Dieser Mischmasch aus verschiedenen Systemen nervt... Danke für Deine Hilfe. Carsten
×
×
  • Create New...