Jump to content

schibulski

Members
  • Posts

    174
  • Joined

  • Last visited

Everything posted by schibulski

  1. Hallo Manica und willkommen im Forum! Das Modul heißt vor der Installation unübersetzt "advancedeucompliance". Erst nach Installation ändert sich der Name in "Europäische Rechtssicherheit". Das gilt im Übrigen für alle Module: Vor Installation haben Sie alle den englischen Originalnamen, sofern eine Übersetzung vorhanden ist sieht man diese erst nach der Installation. Das war glaube ich mal anders und ist in der Tat etwas verwirrend, aber nach ner Zeit kommt man rein :-) Edit: Mist, ne Sekunde zu spät Kulli. Du "Ninja Forist"! :-D
  2. Ich würde sicherheitshalber auch mal gucken ob das Modul "Verkäufe und Bestellungen" auch unter "Modulpositionen" im Hook "displayAdminStatsModules" vorhanden ist.
  3. nö, eindeutig an der Moduleinstellung. Lies nochmal richtig. Hier hat ja keiner was von einem Fehler gesagt. Lediglich die Ursache wurde gesucht. Und die wurde im Modul gefunden, unabhängig davon ob man das ein- und ausschalten kann ;-)
  4. Hello rocky! Where can I download it? Prestashop Addons still shows 2.7.0 by the way: just installed the update to 2.7.0 and found a bug: The Option "Show All Dropdowns" does´t work anymore. Means that the Categories don´t reload. Can just use the first dropdown. All others are deactivated. Switched back to 2.6 Version and everything is fine. Presta 1.6.1.1
  5. Hallo RetoFurter und willkommen im Forum! Ich tippe in deinem Fall mal darauf dass du einen Filter bei der Facettennavigation gesetzt hast. Wenn ich mich recht erinnere werden dann alle Artikel aus den jeweiligen Unterkategorien angezeigt. Versuche mal das Modul "Facettennavigation" zu deaktivieren und guck dir dann nochmal dein Frostend an.
  6. Komisch. Bei mir hat es auf Anhieb geklappt (Siehe Screenshot weiter oben). Hast du mal alle Coaches geleert und in dem Einstellungen/Leistung Menu "Kompilieren erzwingen" ausprobiert?
  7. sehr gerne Hast du unter "Voreinstellungen->Bestellung" ganz oben im ersten Punkt unter "Allgemein" auch den OPC aktiviert oder nur innerhalb vom advancedeu.. modul? ich hab es auf Anhieb auch nicht gefunden mit dem Übersetzungstool im Backoffice. Du kannst die Datei aber manuell abändern. Zu finden unter: /modules/dateofdelivery/translations/de.php Diese Datei einfach mit einem Texteditor bearbeiten (Der gesuchte String ist in Zeile 62, und am besten auch in Zeile 64 abändern) und wieder per ftp hochladen, oder direkt auf dem Server bearbeiten, je nachdem wie du das machst. Die Schriftgröße für den Part ist nicht in einer css Datei hinterlegt sondern direkt in einer .tpl Datei. Zu finden im oben genannten Modulordner direkt auf erster Ebene: beforeCarrier.tpl in Zeile 89 direkt den Part "<span style="font-size:10px;margin:0;padding:0;"><sup>*</sup>....." bearbeiten und dort bei font-size die gewünschte Größe eingeben.
  8. Hilft die dabei nicht das kostenlose, bereits in Prestashop enthaltene aber deaktiviert Modul "Lieferzeit" nicht weiter? Es zeigt auf Basis des gewählten Versanddienstleisters und deiner eigenen, frei definierbaren Vorlaufzeit (Vorbereitung an Samstagen und Sonntagen etc.) das voraussichtliche Lieferdatum im Warenkorb des OPC an. Sorry für den schlechten Screenshot, hab die css für den Bestelvorgang noch nicht angepasst.
  9. Hallo, ich weiß nicht ob ich mich blöd anstelle, oder ob hier wieder ein Bug im Modul advancedeucompliance ist: Szenario: Sowohl Verbraucher als auch Händlerkunden sollen im gleichen Shop einkaufen können. Die Verbraucher sehen den Preis inkl. MwSt. Die Händler sollen ihren rabattierten Preis zzgl. MwSt sehen. Maßnahmen: Neue Kundengruppe "Händler" angelegt mit der Option "Preise anzeigen -> zzgl. MwSt" Artikelpreise mit hinterlegtem Sonderpreis für Gruppe "Händler" Ergebnis: Händler sehen zwar den korrekten Sonderpreis ohne MwSt. im FrontOffice, allerdings mit dem Zusatz "inkl. MwSt." was ja falsch ist. Hier sollte jetzt wie in den Kundengruppen festgelegt "zzgl. MwSt." stehen. Der korrekte Zusatz erscheint nur wenn ich in den Steueregeln im gesamten Shop die MwSt. Anzeige deaktiviere. Kurios: Wenn ich in den Einstellungen von advancedeucompliance die Option "MwSt. anzeigen" deaktiviere zeigt das FO dennoch die Zusätze "zzgl. bzw. inkl. MwSt. an. Diesmal sogar korrekt, allerdings unformatiert, in der gleichen Schriftgröße wie der Preis. bootstrap-default mit angepasstem Farbschema PS 1.6.1.1 Kann das jemand nachvollziehen oder stelle ich mich hier einfach blöd an und muss bestimmte Optionen miteinander kombinieren?
  10. Hast du "zuzüglich Versandkosten" manuell übersetzt oder war das out of the box nach Modulinstallation? Bei mir steht dort englisch "Shipping excluded" und ich bekomme es einfach nicht übersetzt. stelle mich gerade irgendwie doof an. Im Backoffice kann ich es nicht übersetzten weil mein Server wohl nur 1000 Anfragen zulässt und für die Modulübersetzungen brauche ich mindestens 2200 :-( jetzt habe ich manuell in den de.php Dateien gesucht und finde es einfach nicht :-O In der Moduldatei ist die Übersetzung korrekt, in der Hauptsprachdatei meines Themes finde ich den String nicht. Hab auch nochmal die Übersetzung aus dem aktuellen Bootstrap Theme 1.6.1.1 in mein Theme kopiert.
  11. Und ich dachte schon in meinem Shop stimmt was nicht :-O Nicht nur dass die Übersetzung fehlt, sondern selbst das PopUp geht nicht auf. Ich bekomme dann lediglich eine Fehlermeldung (Wortlaut hab ich gerade nicht im Kopf). Ich finde es ja auch super dass sich Presta in die richtige Richtung bewegt, aber dass solch eine Funktion in einem freigegeben Release nicht funktioniert ist Wahnsinn :-O Aber egal: Gibt es eine Möglichkeit die fehlerhafte Übersetzung Manuel einzupflegen? Ich habe mal die Übersetzungen im Modul als auch global durchsucht und werde dort auch fündig was die korrekte Übersetzung anbelangt. Allerdings ist diese wohl falsch hinterlegt? Woher kommen diese Zahlenkombinationen vor jeder Übersetzung?
  12. Also dass man Artikelpreise im BO jetzt immer ohne Steuer eingeben muss finde ich als extrem lästig. Das ist doch nicht praktikabel, oder? Ich meine wenn es um einen ganzen Schwung Artikel geht wird das eh per cvs-upload gemacht. Aber wenn man mal eben einen einzelnen Artikel anlegen oder bearbeiten möchte... Was soll denn sowas? :-O
  13. Do you use some kind of "multiple features module" ?
  14. For me it was the Module "Cron tasks manager" by prestashop. It was hooked in "Display:AdminHeader" It caused very strange loading times, removing it from the hook made saving products very fast without any other modifications. The module activated automatic during the update to 1.6.0.11, and even in a fresh installation. I think this module is specially made for the cloud version of prestashop and causes this strange problems on self hosted shops. Try to deinstall the module! In my shop it made all loading times in the backend from about 6-12 seconds to under 0.5 seconds! The Save buttons in the Product Page are now accsessible in about 5 seconds (before it was up to a minute!)
  15. Auch wenn ich das Problem persönlich durch oben genannte Lösung abstellen konnte, poste ich hier nochmal einen äußerst interesanten Artikel der sich im Speziellen mit endlos lang rotierenden Save Buttons in presta 1.6.0.11 beschäftigt: http://nemops.com/spinning-save-button-prestashop-1-6/#.VNiRWXbomcY Hier wird nochmals deutlich beschrieben dass die Buttons erst dann klickbar werden wenn alle Tabs der Artikelseite geladen sind und wie man mögliche Fehlerquellen identifiziert und beseitigt. Ich hoffe der ein oder andere kann das gebrauchen, mir hat es jedenfalls sehr geholfen.
  16. Ich könnte mir aufgrund meiner Fehlermeldung auch vorstellen dass die Cron Dienste nur für die Cloudversion von Prestashop gemacht sind. Bei der selbst gehosteten Variante definiert man seine Cron Jobs doch eher über den Server selbst. Das würde auch erklären warum das Modul plötzlich in 1.6.0.11 von Haus aus aktiv ist... Nachtrag: Ich habe das Modul gerade auch mal bei einem frisch installierten Shop bei einem völlig anderen Hoster (sehr langsam) deaktiviert. Mit dem Modul: ca. 5-6 Sek. Ladezeit auf jeder Seite im BO, mit deinstalliertem Modul: signifikante Verbesserung auf Ladezeiten knapp unter 1 Sekunde! Das Modul "Cron Tasks Manager" sorgt definitv für extreme Leistungseinbrüche im BO
  17. Hast du denn jobs im Cron Manager hinterlegt? Ich hatte dort nämlich keinen einzigen Job drin, und als ich mal in die Einstellungen des Moduls gegangen bin stand dort in rot "Keine Verbindung zum Prestashop Cron Dienst möglich" (oder so ähnlich) Eventuell hat das bei mir zu diesen ewigen Ladezeiten geführt. Hab meine Lösung jedenfalls auch im englischen Forum publiziert.
  18. For me it was the module "Cron Tasks Manager" by Prestashop. It caused huuuuge loadtimes over 12 Seconds in the BO, and specially in the product editing page. It was also in the hook "DisplayBackOfficeHeader". After removing from the Hook the Loadtimes in Backoffice increased to 0.2 Seconds. The Module Page was still very slow. After completly deinstalling the module, even this page was screaming fast again!
  19. Update: Der Fehler ist gefunden und behoben. Nachdem ich mal den Network Monitor und den Debug Modus von Presta eingeschaltet habe stellte sich heraus dass das Problem im Hook "displayBackOfficeHeader" zu finden war. Bei den Modulpositionen mal nachgeschaut was sich da eingenistet hat: Das Modul "CronTasks Manager" von Prestashop und der ThemeConfigurator waren darin zu finden. Als erstes Mal den Cron Manager vom Hook entfernt: Problem gelöst! Einzig und alleine die Modulseite hat noch genausolange geladen. Hab den Cron Manager dann komplett deinstalliert und seitdem läuft auch die Modulseite im BO wieder flüssig. Halleluja! Das BO hat jetzt durchweg Ladezeiten von 0.100 bis 0.300 Sekunden. :) Da stellen sich mir 2 Fragen: 1. Wieso zur Hölle war das Modul überhaupt installiert, kann mich nicht erinnern dass installiert zu haben ?! und 2. Warum wird es bei der Installation in den o.g. Hook geschrieben? P.S.: Den Theme Configurator habe ich auch aus dem Hook entfernt. Oder gehört der da wirklich rein?
  20. Am Server liegt es definitiv nicht. Der gleiche Shop hat mit 1.5.6.2 im Backoffice Ladezeiten von Durchschnittlich 0.3s. Alles was Geschwindigkeit bringt ist aktiviert (nginx führt den php code aus, APC cached das Frontend, CGI und FastCGI sind aktiviert, alle CCC Funktionen sind unterstützt und aktiviert und so weiter und sofort. Das Frontend ist auch weiterhin rasend schnell (Hab dort auch Ladezeiten deutlich unter 0,5 Sekunden. Die Probleme wurden auch von Leuten berichtet die dedizierte Server haben. Ich habe auch schon mit allen oben genannten Funktionen gespielt und jede Kombination ausprobiert. Nix zu machen. Fast jede Seite im BO hat Ladezeiten von durchschnittlich 12 Sekunden! In der Produktbearbeitung ist es besonders schlimm. Hab eben mal die Zeit gestoppt: 12 Sekunden Ladezeit, und nochmal 36 Sekunden drauf bis die Speicherbuttons aufhören zu rotieren und "klickbar" werden. Bei einer frischen Installation mit null Produkten, Kategorien und Zusatzmodulen sinken die Ladezeiten auf durchschnittlich die Hälfte der oben angegeben Werten. Das Backoffice des 1.5.6.2 dagen fühlt sich fast wie eine Desktopanwendung an. 1.6 war zwar schon immer etwas langsamer als die 1.5, was aber aufgrund der Neugestaltung auch okay war, diese massiven Probleme treten erst ab 1.6.0.11 auf. Und das wie gesagt massenhaft. Man durchsuche nur mal die englischen Foren hier oder googelt nach "Prestashop 1.6.0.11 very slow backoffice" Wie gesagt: Es ist zwar ein shared Hosting, aber in nem ziemlich fetten Paket bei SSD-Webhosting. Daran liegt es mit Sicherheit nicht, schon garnicht wenn man das mit dem exakt gleichen Shop auf 1.5.6.2 vergleicht.
  21. Speziell das Bearbeiten eines Artikels ist eine Qual in 1.6.0.11. Die Speichernbuttons rotieren eine gefühlte Ewigkeit im Kreis. Habe den Effekt sowohl bei einem von 1.5 "geupdateten" Shop, als auch bei einer ganz frischen 1.6.0.11 Neuinstallation. Im englischen Forum ist dieser Umstand auch in vielen Threads nachzulesen. Das Problem scheint hier zu sein dass die Buttons erst dann klickbar werden wenn alle Tabs vollständig geladen sind. Bei dem Updateshop kann das teilweise Minuten dauern, da der Kategoriebaum sehr groß ist (4500 Kategorien) und es circa ebensoviele Artikeleigenschaften gibt. Der Kategorientab braucht im Gegensatz zur 1.5 Version des Shops auch unglaublich viel mehr "php_memory limit" Dass die Buttons aber auch einem frisch installierten System so lange "rotieren" ist ja eher nicht normal. Hab das ganze mit verschiedenen Hostinganbietern getestet, überall das Selbe Kurzum: Das Bearbeiten von Artikeln ist in einer Produktivumgebung nicht möglich. Mich wundert dass hier im deutschen Forum noch nichts dazu aufgetaucht ist. Jemand ähnliche Erfahrungen gemacht? Ein Hoch auf AJAX!
  22. Naja, er hat den Wert für truncate ja auch auf 100.000 erhöht :-)
  23. in dem Fall kann ich das Modul "Ajax Dropdown Categories" wirklich wärmstens empfehlen. Die Dropdowns funktionieren in dem Fall über die Kategoriestruktur. Ich habe das Ding im Einsatz für Motorradersatzteile (Hersteller wählen -> Hubraum -> Modell -> Baujahr. Das klappt wirklich super, ist per css vollständig individualisierbar und lässt sich an beliebigem Hook einbinden. ABER wie gesagt, nicht mit Merkmalen und Eigenschaften, sondern über die Kategorien. Sollte aber für deinen Einsatzzweck auch super sein. Hier der Link zu den ps Addons: http://addons.prestashop.com/de/front-office-features-prestashop-module/11592-ajax-dropdown-categories.html
×
×
  • Create New...

Important Information

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