Jump to content

comfuse

Members
  • Posts

    28
  • Joined

  • Last visited

Everything posted by comfuse

  1. Hi, I just checked and noticed that I left out a vital part of info: Once we simply choose a product as you did, it also works at our end, but it does not work once we apply a filter. For Examlpe we only want to delete combinations of the´product in size M and filter the combination list. If we then want to mark all of thos it does not work the way you describe. Cheers Carsten
  2. Hi, you write in your description in "Combination Delete": "You can select a range of checkboxes when you keep the shiftkey pressed during the second click. The position of the first click will determine whether the range will be set or not." I have tried every interpretation of these instructions, but I could not check more than one checkbox at a time. We have a vast amount of combinations, that we have to delete in batches, so this function would be vital. OR one checkbox to "select all". Please help! Carsten
  3. Hi, I guess I should upload the suite again in this case and make sure the file count is identical I will check it again. Good to know that it's no limitation of the free version. Which plugin or plugin package should we choose if we mainly wanted to manage / update our huge catalogue of combinations? Cheers.
  4. Hi, thank you for fixing the function1.php so quickly. Now the suite works a treat, except for quite a few pages that still show "You cannot call the program this way by addressing the root. Address one of the files!" when I choose the page from the navigation, i.e. "Imgaes Edit", "Feature List", "Category revenue" et cetera. Is this because of Prestools running in the free version? In addition to that I think I might have forgotten a thing or two about your license model: Is the editing and "mass" updating of combinations included in the free version or do I have to buy a plugin for that? I only found "Copy / Delete combinations" as a plugin, so is the combination editing included in the free version? Cheers.
  5. Hi, I just uploaded Prestools to a shop where I had not used it before, changed settings1.php, opened product-edit.php and logged in, then I got this error I have not seen before: Parse error: syntax error, unexpected ')' in /var/www/.../.../admin*********/prestools/functions1.php on line 253 Since this display, no page of Prestools can be accessed and no login screen appears. What can I do? Already deleted htaccess with no effect. Cheers.
  6. 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.
  7. 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.
  8. 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 :)
  9. 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
  10. 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
  11. 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
  12. Ja, das werde ich jetzt machen (in der Hoffnung, dass die alte Datenbank noch da ist).
  13. 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
  14. 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?
  15. 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
  16. 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?
  17. Wie heißt das bei Facebook im Besziehungsstatus? "Es ist kompliziert" Ich danke trotzdem im Voraus und wünsche ein schönes Wochenende!
  18. 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
  19. 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
  20. 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
  21. Hm, inzwischen bekommen wir vereinzelt Rückmeldungen, dass die Leute bereits beim Einloggen mit Fehler 500 geschmissen werden, sich dann ein neues Passwort machen müssen und dann ihre Bestellungen platzieren können. Bekannter Fehler? Backend-Fehler lass ich mir ja noch gefallen, aber jetzt geht das auch im Frontend los. Gibt es Erfahrungswerte, was dem PS gar nicht schmeckt hinsichtlich Serverconfig? Da wir den nicht verwalten, tappen wir im Dunkeln. Kann das ein Cache Problem sein? Einfach mal alle Cache Module ausschalten? Als wir das das letzte mal probiert haben, ist der Server-Cache komplett vollgelaufen und es ging gar nichts mehr Irgendeine Idee? Carsten
  22. Hi, we have a similar issue on a case to case basis. Some customers try to login, they get a persistent "Error 500" message. Only when they create a new password, they can login once, place their order, but the next time it's the same shambles... It's version 1.7.5.0, Classic theme, no addons for authentication (such as Captcha etc.) As I said: It does not happen with every customer, only some.
  23. Am Ende sind Deine Antworten gleich mehrfach freigeschaltet worden Danke, den Tipp mit dem Kopieren kannte ich noch nicht! Leider geht es unter anderem um native Module... Aber ich habe inzwischen noch etwas merkwürdiges gesehen. Die URL, wenn ich die Übersetzungen aufrufe, sieht so aus: /index.php/improve/international/translations/modify?form[modify_translations][translation_type]=modules&form[modify_translations][module]=41&form[modify_translations][language]=de Was sollen denn diese Klammerausdrücke in der Adresse? Wird da was nicht richtig aufgelöst? In einer Standard-Installation der gleichen PS-Version sieht das so aus: /index.php/improve/international/translations/?lang=de&type=modules&locale=de-DE&selected=ps_wirepayment&_token=s68Y8ukK6CldtVc2vji6RO562rMCv6GaKaaYyS9usNk Nicht enden wollendes Mysterium...
  24. Wie macht man denn dann in der 1.7 manuell Übersetzungen, wenn noch zudem die Übersetzungsdateien im Modulordner (z.b. translations/de.php) selbst leer sind. Gar nicht?
  25. Hallo, ich werde beim Aufruf der Übersetzungen "Installierte Module" - egal bei welcher Modulauswahl - mit einem Fehler 500 geschmissen. Wenn ich debugge, heißt es: Symfony\Component\Debug\Exception\ FatalThrowableError in src/Adapter/Translations/TranslationRouteFinder.php (line 208) */ private function isModuleUsingNewTranslationSystem($moduleName) { $module = $this->moduleRepository->getInstanceByName($moduleName); return $module->isUsingNewTranslationSystem(); } } Aber: Wenn ich irgendeinen anderen Bereich der Übersetzungen aufrufe, geht alles. NUR bei "Installierte Module" ist der Ofen aus. Schon mal gehabt? Das nervt... Carsten
×
×
  • Create New...

Important Information

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