Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 10/24/2018 in all areas

  1. 2 points
    Hola cómo estáis!, Bueno veo que el tema esta calentito por el foro y que lo que ha pasado con web empresa ha denotado que PrestaShop no está haciendo las cosas como tocan. He creado un video en mi canal comentando mi opinión, y relajando un poco el tema: www.youtube.com/watch?v=pox8rSxXExc Mi opinión personal, para dejarla por aquí también escrita, es que el error principal ha venido dado por las prisas que se provocaron para sacar una versión 1.7. Que nadie se confunda, no tuvo nada que ver con posicionamiento de mercado, Magento en ese momento estaba con grandes problemas y Shopify no había pegado tan fuerte, Woo estaba en pañales todavía. El problema clave aquí es que la directiva necesitaba y apretaba al equipo para sacar la versión antes de fin de año para marcarse un punto con los inversores. Si habéis estado al caso, han cambiado el CEO de PrestaShop y no ha sido por casualidad. Hoy justamente he tenido la oportunidad de hablar con el equipo de PrestaShop sobre mi posición como Partner, agencia etc y como están tratándolas. Esperemos que para mejorar la relación y lo que aportan. (eso es otro tema, no quiero liarme). Recordáis el tema de las Release Candidates??, donde se ha visto que aparezcan 3 RC con errores de inestabilidad, eso fue grave pero se podía gestionar gracias a que era cosas de GitHub. Claramente se sacó algo mucho antes de que se debiese sacar. Sobre el paso a usar Symfony, me parece que es una de las mejores decisiones que se tomaron, puesto que esto hace que el framework se mantenga por otra comunidad y de más tiempo al equipo de PrestaShop de mantener y crear nuevas funcionalidades. El cambio de theme ha sido la leche, y realmente aporta mucha funcionalidad, el Child Theme está haciendo las delicias de mis compañeros, poder extender el tema es lo mejor... Sobre los errores o bugs, creo que esta versión debe servir para cambiar la mentalidad, debe poder actualizarse siempre que se necesite, no puede ser esto de dejar a los usuarios atrapados en versiones porque se trapichea (permitidme la expresión) el código. Relacionado con esto y directamente con el problema de salir antes, está relacionado que la versión 1.7 saliese por ejemplo con la opción de multitienda, lo habéis probado... es la muerte.... hasta la 1.7.4 no se corrigen los errores de Contexto relacionados con el Back Office, no hubiese sido mejor dejar esa opción deshabilitada hasta por ejemplo la 1.7.5, y enviar un newsletter informando con un "Pásate ahora a la 1.7 tu mutitienda esta lista y esperándote"... Realmente lo que se lleva a cabo se prueba, el checkout, es un buen ejemplo, test unity para comprobarlo, ejecutar pruebas de desarrollo etc, pero no está todo en test unity y los módulos de addons están fuera de esa comprobación. No obstante, creo que los avances están dándose, si se hubiese sacada a finales de 2017 parecería que se avanza un montón, pero trayendo lo arrastrado de casi un año parece un siglo.... Sobre Webempresa, como empresa ellos verán, pero como comento en mi vídeo lo mismo esa subida de nivel en el desarrollo les implica hacer un gran esfuerzo en llevar a cabo la formación del equipo para que sea capaz de gestionar dudas sobre Symfony... Bueno no me extiendo mucho más, tengo esperanzas en la 1.7.5 que va a traer novedades y por lo que veo en GITHUB parece que se están centrando en temas de estabilidad y funcionalidad propia de PrestaShop, por tanto iré rescatando información del equipo de Francia e iré actualizándola en el canal. Un abrazo a todos!!
  2. 1 point
    Salve e buongiorno a tutti . Dopo aver sviluppato e messo a disposizione della community questo modulo per la versione 1.6 (disponibile a questo post) il nostro reparto tecnico ha trovato un ritaglio di tempo per poterne sviluppare una versione adatta al nuovo PrestaShop, la 1.7 per l'appunto Abbiamo deciso di creare un nuovo post perché questo modulo è totalmente (o quasi) diverso da quello per la 1.6, che di fatto non funzionerebbe. Quindi riscritto appositamente per la 1.7, e compatibile con il nuovo template 'classic' (ovviamente ) Il modulo è stato creato sulla versione 1.7.0.4 di PrestaShop. Testato fino alla 1.7.7.0. Il modulo oltre ad aggiungere uno stato d'ordine specifico per il metodo di pagamento scelto aggiunge anche i template delle email con le specifiche informazioni della PostePay da dover ricaricare, quindi il titolare, il numero di PostePay e il codice fiscale del titolare. Potete personalizzare i testi delle email nel seguente percorso (dopo aver installato il modulo) prestashop/mails/it/tanzopostepay.html Accettiamo qualsiasi suggerimento per delle eventuali migliorie o modifiche da applicare. Il modulo è risk-free, ma consigliamo sempre di provarlo prima in un ambiente di test, mi raccomando. Buon download, e se vi è stato utile un like è sempre gradito v1.0.6-ps_tanzopostepay-ps17.zip Changelog Older version DISCLAIMER THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF THE USE OR INABILITY TO USE THE SOFTWARE OR FROM OTHER DEALINGS IN THE SOFTWARE. DOWNLOADING AND INSTALLING THIS PRODUCT YOU ACCEPT THE TANZO ANALYSIS PROGRAM.
  3. 1 point
    [Το ίδιο post έγινε και στο Αγγλικό τμήμα του forum] Επειδή χρειαζόμουν ένα πρόσθετο για αντικαταβολή με χρέωση, αποφάσισα να φτιάξω ένα δικό μου, βάζοντας όσα περισσότερα χαρακτηριστικά μπορούσα να σκεφτώ: Συμβατό με πολλαπλά νομίσματα και καταστήματα. Μπορείτε να βάλετε τη χρέωση στη χρέωση του μεταφορέα, ή να προσθέσετε ένα ψευτοπροϊόν στο καλάθι με τη χρέωση, ορίζοντας μάλιστα και το φόρο που θα έχει. Για να εφαρμόσετε τη χρέωση, μπορείτε να ορίσετε διάφορες παραμέτρους (σύνολο καλαθιού, χώρα ή ζώνη παράδοσης, μεταφορέα, γκρουπ πελάτη, κατηγορία προϊόντων, κατασκευαστή και προμηθευτή). Η χρέωση υπολογίζεται είτε σαν σταθερή, είτε σαν ποσοστό στο σύνολο του καλαθιού ή σαν συνδυασμός αυτών των δύο, λαμβάνοντας υπόψη μια ελάχιστη ή μέγιστη τιμή. Ορίζετε συνθήκες με τις παραπάνω παραμέτρους και μπορείτε να εφαρμόσετε την πρώτη που θα περάσει τον έλεγχο ή να προσθέσετε τις χρεώσεις από αυτές που πέρασαν. Μπορείτε να δοκιμάσετε σενάρια αγορών και να δείτε αν η χρέωση είναι αυτή που περιμένατε. Μπορείτε να αποθηκεύσετε όλες τις συναλλαγές με αυτό το τρόπο πληρωμής και να δείτε σε κάθε μια πως ακριβώς υπολογίστηκε η τελική χρέωση. Δυνατότητα για έλεγχο ενημέρωσης (και αυτόματα). Πλήρως μεταφρασμένο στα Ελληνικά. Για όποιον θέλει να διορθώσει κάτι ή να προσθέσει κάτι, υπάρχει στο github (sakgiok/codwfeeplus). Παρακαλώ ενημερώστε με αν υπάρχει κάτι που δεν είναι σωστό ή αν νομίζετε ότι κάποιο άλλο χαρακτηριστικό θα ήταν χρήσιμο. Edit: Στην έκδοση 1.0.9 και για το Prestashop 1.7 η προεπισκόπηση του καλαθιού περιλαμβάνει και τη χρέωση αντικαταβολής όταν επιλεγεί αυτή η μέθοδος. Edit: Νέα έκδοση 1.0.10 που διορθώνει ένα θέμα με τους μεταφορείς, όταν έχουν εισαχθεί από ένα πρόσθετο. Edit: Νέα έκδοση 1.1.0 που μπορείς πλέον να έχεις μια ή παραπάνω συνθήκες για να ελέγχεις αν θα απενεργοποιείς τον τρόπο πληρωμής. Edit: Νέα έκδοση 1.1.1 με διόρθωση έτσι ώστε να εμφανίζονται σωστά οι φόροι. Edit: Νέα έκδοση 1.1.2 με εισαγωγή κατάστασης παραγγελίας και κάποιες διορθώσεις και παραπάνω ελέγχους. Edit: Νέα έκδοση που διορθώνει ένα πολύ σημαντικό bug. Edit: Νέα έκδοση 1.1.4 που διορθώνει κάποια σημαντικα bugs. Edit: Νέα έκδοση 1.1.5 που διορθώνει τη συμβατότητα με τις εκδόσεις 1.6.0.6 και 1.6.1.24. Edit: Νέα έκδοση 1.1.6 που διορθώνει προβλήματα με κάποιες εκδόσεις μικρότερες από τη 1.6.1.0 και υποστήριξη για τη μελλοντική έκδοση 1.7.6.0 Edit: Νέα έκδοση 1.1.7 που εισάγει το πεδίο "Νομοί" στις συνθήκες. Edit: Νέα έκδοση 1.1.8 που διορθώνει ένα σφάλμα, όπου δεν δούλευε το module όταν γινόταν εγκατάσταση από την αρχή. Download: codwfeeplus_1.1.8.zip Demo: https://ps17demo.sakgiok.gr/admin107ak3oho Username: demo@ps17demo.sakgiok.gr Password: demodemo
  4. 1 point
    Hi I have submitted that bug here https://github.com/PrestaShop/PrestaShop/issues/9802 and looks like there is not yet solved even there is solution proposed. https://github.com/PrestaShop/PrestaShop/pull/10392/files Just replace line in red with two new once in green. That should fix it.
  5. 1 point
    Bonjour, Bonne nouvelle ! Effectivement, il faut veiller à une certaine cohérence entre la version PHP du coté de l'hébergeur, de la version prestashop installée afin de faire les tests en local dans les mêmes conditions ! En effet, depuis la version de prestashop 1.6.1.4 les versions permettent de fonctionner avec PHP 7.0. http://build.prestashop.com/news/prestashop-1614-maintenance-release/?_ga=2.16478390.1039534432.1540278618-43009363.1540278617 Merci de noter l'en-tête du titre comme résolu. Amicalement
  6. 1 point
    Le mec n'est pas ton larbin non plus faut pas déconner. La première chose à faire sur un forum c'est : - Se présenter Ensuite on utilise la fonction recherche. Mais toi tu préfères sortir des injures... Donc pour les assistés comme toi, ca se passe ici entre autres: https://www.prestashop.com/forums/topic/907780-prestashop-1617-bo-et-fo-trop-lent-very-vey-slow/#comment-2979281
  7. 1 point
    Merci à tous ceux qui ont pris le temps de me répondre. Je vais tenter de lancer le développement sur les 2 versions en parallèle dans un premier temps, lorsque cela deviendra trop chronophage, je trancherai.
  8. 1 point
  9. 1 point
    The new version of the module is available at www.presta-addons.com. All upgrades are FREE for life. CHANGELOG v2.4.1 (2018-10-24) - Fixed list filtering in the module administration - Fixed missing translated strings, formatted numbers and other Smarty function outputs (PrestaShop 1.7.4 only) v2.4.0 (2018-10-04) - Added the ability to select records to create a bulk PDF in the module administration - Fixed Debug template output (PrestaShop 1.7) - Fixed Features data (catalog, only Multistore)
  10. 1 point
    Bonjour, Vous pourriez déjà donner des informations comme l'url du site, les liens concernés (barre de menu, produits, ...) et la version PrestaShop utilisée.
  11. 1 point
    WOW! increible recomendar algo que como desarrollador en lo particular no recomendaria jamas ! . . . empezando por los dolores de cabeza de el modelo de datos de Woocommerce
  12. 1 point
    Witzig, aber nicht böse gemeint Was du da beschrieben hast ist so ziemlich die aller höhste Kunst,. Es ist das Online äquivalent zu einem Kaufhaus das du betrittst und umgehend sagst: Hier bin ich zuhause, ich Verkaufe das Haus. Was du beschrieben hast ist also nichts weniger als das was Amazon und co. solange anstreben und versuchen zu erreichen wie die Giganten existieren. Schaffen werden Sie es wohl nie. Ich habe viele Klienten / Kunden / User erlebt die anfangen einen Shop zu betreiben. Einige planen sehr gut und einige gar nicht. Was aber viele völlig vergessen ist meiner Meinung nach das wichtigste: Du musst zwingend Prioritäten setzen und wissen was du möchtest. Es ist doof geschrieben, weil eigentlich müsste es auch heißen, dass du zwingend wissen musst was du möchtest und dann Prioritäten setzen. Das eine geht nicht ohne das andere und beides müsste gleichbedeutend behandelt werden. Das fängt bei der Auswahl der verkauften Artikel an, geht über die Marktsituation, Konkurrenz, Vor und Nachteile, wieso der Kunde bei Dir kaufen sollte, das der Kunde sich auf deiner Webseite in den ersten 2 Sekunden zurechtfindet und wohl fühlt, das der Kunde sich auch sicher fühlt (ohne scheiß: Werbung geht gar nicht!) geht dann über zum gebuchten Webhosting Paket etc. Warum ich das erwähne: Ich und auch die anderen hier, die anderen hier und ich wollen das zukünftige Nutzer und Shopbetreiber aus den Erfahrungen der anderen lernen. Leider passiert das viel zu selten mangels der Zeit und dem Willen sich die Zeit dafür zu nehmen sich mit die vielen Themen auseinander zu setzen. Du solltest ganz unbedingt immer Fragen, wenn du etwas nicht verstanden hast denn nur so wirst du dauerhaft Lernen und Vorschritte machen. LG ps: Das fett gedruckte kleine i (i) sieht ja aus wie ein großes I oder kleines l....war das schon immer so?
  13. 1 point
    This is a recurrent issue with Prestashop indeed. You can apply this quick and dirty fix . Find out more at https://github.com/PrestaShop/PrestaShop/compare/1.7.4.x...jocel1:disable-api-addons-calls
  14. 1 point
    You will most likely run into more problems after solving this, Billd11. That was also my first. Let me show you my problems/solutions upgrading PrestaShop from 1.6.1.6 to 1.7.4.3 recently. The reason to upgrade was simple. I am urged to do so by my hosting provider because PHP 5.6 is at its end of the lifecycle. That said, every customer of One.com will experience a switch to PHP 7.2 by the end of the year. Since I was sure PrestaShop 1.6 would probably not survive the switch, I tried to move early, in case something goes wrong. Also, well you guessed it, something went wrong. I made a full backup of files and database, as recommended, but I couldn't even upgrade via 1-Click-Upgrade on my live server. My workaround solution was to set up a local environment with XAMPP running on PHP 5.6 instead. It was pretty straightforward. Changing the database connection in '/config/settings.inc.php' and edit a few store URLs in the database. 'PS_SHOP_DOMAIN' and 'PS_SHOP_DOMAIN_SLL' in table 'ps_configuration', as well as 'domain' and 'domain_ssl' in table 'ps_shop_url'. Moreover, if you previously ran on SSL / SSL everywhere, you should probably search these fields in the config table, too, and set them to 0 in the meantime. After getting back into the admin section on the local server, I was able to perform the 1-Click-Update to PS 1.7.4.3, apparently successfully. Well, I faced several issues from there. No. 1: Admin permission issues I wasn't able to view customers nor orders, 'permission denied.' I solved it by replacing the 'ps_access' table in the database entirely, with a clean one from another clean install of 1.7.4.3 I had to perform to grab it. No. 2: Module updating issues Fatal errors occurred while trying to update 36-37 outdated modules. First I thought a class was missing, because of the error message, but PrestaShop told me all files were there. Reset all modules one by one did the trick. No. 3: 500 server error with debug mode off When I finally decided to turn the debug mode off, I was surprised that the shop wouldn't work as expected. I couldn't access certain areas at all anymore. I solved this by deleting the 'var/cache' folder entirely. No. 4: Products changes not saved This one has a backstory since I increased the meta description length in PrestaShop 1.6 to 320 possible characters. To my surprise, the 'meta_description' field in the database in table 'ps_product_lang' remained at 'varchar(320)'. I had to because 50-300 characters are recommended. The fix was in 'classes/Product.php,' where I looked for the '$meta_description' validation lines, as well as in 'src/PrestaShopBundle/Form/Admin/Product/ProductSeo.php' for the counter in the form field. I increased the value limits to 320 each, which let me save my products again without having to shorten anything. After turning off maintenance, another error occurred. No. 5: Product images are not showing Thumbnails were available in the back office product catalog, so I knew the product images were there, but in product edit mode, the images were missing as well. I thought It'd clear with rebuilding images/thumbnails, but it didn't. In the end, the fix was simple, but you need to know where to look. Disabling SEO friendly URLs, and re-enabling it, did the trick. Don't forget to clear browser cache after, or you might run into server errors which are caused by the changes and .htaccess caching. After that, some expected cosmetic changes were necessary, because the product description was in such a narrow column in 1.7 'classic' theme, that I had to make the column wider again. That was quickly done, however, as templating is much more comfortable in PS 1.7. Previously created slides needed new uploads of their respective background images in a new, full-width format. The three sample slides were removed, as well as the '20% off on clothes' default block on the home page before the footer. There seems to be a general design flaw with the option "only available online," as it floats anywhere, even beyond blocks, looking like it's glitching and not well taken care of/neglected by the designers. I removed the check mark from every product, so I don't have to deal with it for now. Double-checking prices and tax settings is necessary, as well as quickly revisiting email templates and payment module options and settings. After that, everything went like a charm, like it's supposed to. By transferring everything back and switching to a new database, previously set up with the backup from my local environment, and making changes back to the live shop URLs and SSL settings, I now run my store on the newest version. I switched to PHP 7.2, and there are no errors to be afraid of anymore. If you want to swap files into your root on the live server, I recommend transferring everything except the index.php and .htaccess file first and make a static copy as PHP file of your current shop maintenance page beforehand. Don't forget to set the status code to 503 via PHP to signal the crawlers in a proper way that they should come back later. That way no errors will show during transfer, and you retain 503 at all times. When you are ready with all files and database changes, you can then transfer the 'index.php' and '.htaccess' to your root directory to go live (or real maintenance mode again, if you chose so.) Cheers
  15. 1 point
  16. 1 point
    my version is 1.7.4.2 too You can't find it cause it was deleted I think. here is my solution. you can see on the pictures where you have to go. On the last picture you see there have to be the AttachementProductController.php If not, you have to insert the AttachementProductController.php in the attachment down below. Hope it works. AttachementProductController.php
  17. 1 point
    Interesting, we a fixing Prestashop.... I was a bit afraid to make changes to not break it, but since I just test it now ... So after I applied the fix you said I got 2 more errors: FatalErrorException in AdminLoginController.php line 400: Compile Error: Declaration of AdminLoginControllerCore::viewAccess() must be compatible with AdminControllerCore::viewAccess($disable = false) Then I edited line 164 (in AdminLoginController.php) : public function viewAccess() to: public function viewAccess($disable = false) And got the next error: FatalErrorException in AdminLoginController.php line 400: Compile Error: Declaration of AdminLoginControllerCore::setMedia() must be compatible with AdminControllerCore::setMedia($isNewTheme = false) Then edited line 47: public function setMedia() to: public function setMedia($isNewTheme = false) And got acces to BO, at last. But... I have a warning in BO: Warning line 569 file C:\\Apache24\\htdocs\\classes\\controller\\AdminController.php[2] count(): Parameter must be an array or an object that implements Countable Then a lot of more errors inside BO. Someone from Presta team have to definitely check this tread. I do have PHP 7.2(64bit) installed, on Apache 2.4.29(64bit) Windows 7(64bit), VC2017(64bit), MySql 5.6(64bit) PrestaShop 1.7.2.4
  18. 1 point
    In fact just change add $isNewTheme = false in setMedia declaration and set $isNewTheme in parent::setMedia call. AdminDashboardController.php (# 43) public function setMedia($isNewTheme = false) { parent::setMedia($isNewTheme); $this->addJqueryUI('ui.datepicker'); $this->addJS(array( _PS_JS_DIR_.'vendor/d3.v3.min.js', __PS_BASE_URI__.$this->admin_webpath.'/themes/'.$this->bo_theme.'/js/vendor/nv.d3.min.js', _PS_JS_DIR_.'/admin/dashboard.js', )); $this->addCSS(__PS_BASE_URI__.$this->admin_webpath.'/themes/'.$this->bo_theme.'/css/vendor/nv.d3.css'); } I submited this correction on GitHub (https://github.com/PrestaShop/PrestaShop/pull/8588)
  19. 1 point
    Ich lesen in den verschiedenen Forums-Bereichen immer mal wieder über Probleme mit der Performance von PrestaShop. Dazu einige Erfahrungen, wie man PrestaShop performant betreiben kann. Ladezeiten von unter 2 Sekunden sind oft auch ohne Hexerei möglich. Server / Hosting Wer den Shop auf einem shared Hostingpaket laufen lässt, wird fast immer an Grenzen stossen. Der Hosting - Provider wird nach Möglichkeit soviele Webseiten auf einem Server laufen lassen, wie möglich. Deshalb die Empfehlung für einen dedicated Server. Da hat man als Shopbetreiber nicht nur die Ressourcen für sich sondern meist auch mehr Konfigurationsmöglichkeiten. PrestaShop Cache Settings Diese findet man in Backoffice - Erweiterte Einstellungen - Performance. Wir haben gute Erfahrungen mit folgenden Einstellungen gemacht: Smarty Cache Generell empfehlen wir, Smarty Cache einzuschalten. In Verbindung mit dem Modul Advanced EU Compliance kann es jedoch zu fehlerhaften Anzeigen führen. Hier berichten Users, dass das Abschalten des Smarty-Cache hilft. Template-Kompilierung Templates nach Datei-Änderungen neu kompilieren. Wenn man keine Tests mehr macht, kann man auch auf "Nie kompilieren" setzen. Dabei nicht vergessen, dass man den Smarty Cache dann bei Änderungen manuell leeren muss. Optionale Funktionen Varianten und Eigenschaften deaktivieren, wenn man diese Funktionalität nicht nutzt. Ebenso Kunden-Gruppen, wenn man keine unterschiedlichen Preisregeln für Kunden-Gruppen nutzen möchte. CCC Smarty Cache für Stylesheets: EIN Smarty Cache für CSS: EIN Reduzierung des HTML-Inhaltes: AUS (entgegen vielfachen Hinweisen stellen wir eine verschlechterung der Performance fest, wenn aktiviert) Javascript ans Ende verschieben: EIN Media Server Es kann sinnvoll sein, Ressourcen wie Bilder, Javascript oder CSS über einen oder mehrere Media-Server auszuliefern. Allerdings nur dann, wenn der Media-Server mindestens gleich performant ist wie der Shop selbst. Über die Browser Developer Tools kann man das recht gut überprüfen. Cache (letzte Option) DEAKTIVIERT, ausser man weiss genau, was man tut. Insbeondere der Filesystem Cache führt häufig zu einer deutlichen Verlangsamung des Systems. Installation von Modulen Es gilt der Grundsatz: je mehr Module installiert werden, desto langsamer wird das System. Jedes Modul beansprucht Verarbeitungszeit. Und nicht alle Module sind in Bezug auf Performance optimal entwickelt. Daher der Tipp: Vor der Installation eines neuen Moduls überlegen, ob es für den Shopbetrieb essentiell ist. Nicht (mehr) benutzte Module deinstallieren und nicht nur deaktivieren. Themes Verschiedentlich liest man auch Berichte über Themes, welche zu Performanceeinbussen führen. Vor einer allenfalls aufwändigen Adaption eines neuen Themes kann es sich lohnen, Demoseiten des Themes zu besuchen oder zu recherchieren, wo das Theme im produktiven Einsatz steht und die jeweiligen Nutzer zu deren Erfahrungen zu befragen. Oft zeigt auch schon ein Besuch einer Demoseite, ob das Theme performant arbeitet. Multi Language Mehrere Sprachen führen zu zu einer exponentiellen Vergrösserung der Datenbank. Zahlreiche Tabellen führen die Sprach-ID als Wert - nicht nur für Produkte. Einhergehend ist damit in der Regel eine spürbare Einbusse der Performance. Auch werden Redirects von der Hauptdomain zur passenden Sprache gemacht, z.B. von beispiel.com auf beispiel.com/de/. Diese Redirects benötigen ebenfalls Zeit und führen im Prinzip zu einer Verdoppelung der Ladezeit für den Text-Content. Grösse der Startseite (Speicherumfang) Als sinnvolle Faustregel kann man sagen: 1 bis 2 MB auf der Startseite nicht überschreiten. Das bekommt man hin, wenn man nicht ewig grosse Bilddateien verwendet (siehe auch nachfolgend: Image Slider) und extrem viele Zusatzmodule am Laufen hat. Die Grösse der Startseite hat verschiedene Aspekte, welche die Ladezeiten direkt und indirekt betreffen: a ) Bandbreite: Je langsamer eine Verbindung, desto länger dauert die Übertragung. b ) Anzahl zu ladende Objekte: Meist gilt: Je umfangreicher die Seite, desto mehr einzelne Objekte (Bilder, CSS, Javascript) werden geladen. Jeder Zugriff beansprucht alleine für den Verbindungsaufbau schnell 20 bis 50 ms. Bei 100 zu ladenden Objekten sind schnell 2 bis 5 Sekunden Ladezeit vergangen. c ) Javascript und CSS sind häufige "Bremser". Javascript wird für die Ausführung von Programmelementen auf dem Client (Browser) genutzt. CSS ist zuständig für die Art der Darstellung (Design, Farben, Schriften). Bei beidem gilt im Grundsatz folgendes: Bis nicht die letzte Anweisung aus diesen Dateien geladen ist, beginnt der Browser nicht mit dem Rendering-Prozess (=Anzeige / Formatierung der Ausgabe). Je grösser diese Dateien, desto länger wird potentiell das Rendering verzögert. Gleiches wie für die Startseite gilt im Prinzip auch für Unterseiten. Trotzdem ist die Startseite als "Eingangstor" zum Shop sicher die wichtigste Visitenkarte. Image Slider Image Slider erfreuen sich allgemein höchster Beliebtheit. Meines Erachtens nicht immer zu Recht. Man muss sich im Klaren sein, dass i.d.R. alle Slider-Bilder erst geladen werden, bevor sich in der Anzeige etwas tut. Optimiert man diese Bilder nicht in Bezug auf Grösse und Kompression, so hat man schnell 1 bis 1.5 MB an zusätzlichem Datenvolumen. Auch mit geeigneter Kompression (was PrestaShop nicht wirklich kann), hat man schnell 500 KB oder mehr an Daten beisammen. Zudem sind viele Slider in der Grösse so skaliert, dass diese auch auf grossen Bildschirmen ohne Scrollen 90 bis 100% des sichtbaren Seiteninhaltes in Anspruch nehmen. Wichtige andere Seiteninhalte werden dadurch unnötig in den Hintergrund verbannt. Wenn Silder: dann sollte dieser nicht mehr als etwa 50% der verfügbaren Höhe nutzen. PayPal Wir haben beim Standard-Paypal Module regelmässig beobachtet, dass sich die Performance zum Schlechten verändert. Man würde ja annehmen, dass dieses Modul erst im Warenkorb bzw. bei der Bezahlung Auswirkungen hat. Dem ist nicht so! PayPal sendet bei jedem Seitenaufruf Logging-Daten an PayPal - selbst wenn noch gar nichts im Warenkorb ist. Diese zusätzlichen Post-Requests benötigen jenachdem gerne mal 2 oder 3 Sekunden Zeit. Behelfen kann man sich, indem man Hooks des PayPal-Modules überall dort entfernt, wo es nicht um die eigentliche Zahlungsabwicklung geht. Tracking Services Aus unserer Beobachtung sehe ich, dass viele Shopbetreiber Tracking-Services nutzen, teilweise auch mehrere unterschiedliche Systeme. Google-Analytics, Goodle-Adwords, Facebook seien als prominente Beispiele erwähnt. Ja, auch hinter einem vermeintlich simplen Facebook-Button steht in der Regel in Tracking Service. Allen diesen Diensten sind mehrere Dinge gemeinsam: - Sie übermitteln beständig Daten an die jeweiligen Zielserver. - Sie verzögern den Seitenaufbau, wenn entsprechende Hooks im Header genutzt werden. - Sie sind in der Regel nur dann sinnvoll, wenn man die Auswertungs-Tools kennt und zu nutzen weiss und auch wirklich einsetzt. - Sie nützen oft dem Anbieter des Tracking-Service sehr viel mehr als dem Shopbetreiber. Bezüglich der Impacts verweise ich auf einen Ausfall bei Facebook vor ca. 6 Monaten. Viele Webseiten waren seinerzeit nicht mehr aufrufbar, weil sie sich mit Facebook verbanden, dieser Dienst jedoch gestört war. Per Default wartet ein Browser meist 30 Sekunden bis er mit einem Timeout reagiert. Solange wartet aber kein Shopbesucher, bevor er sich "ausklinkt". Tipps für den Umgang, wenn man solche Services nutzen möchte Zusehen, dass alle relevanten Aktionen im Footer Hook stattfinden. Wenn es dann eine Störung gibt, ist nicht gleich der gesamte Seitenaufbau tangiert. Teilweise kann man auch Hooks deaktivieren. Interessant sind vor allem die Daten, wenn eine Warenkorb angelegt oder eine Bestellung durchgeführt wird. Oft kann man deshalb die meisten Hooks löschen, welche nicht mit diesen Aktivitäten in Zusammenhang stehen. Unnötige Redirects Auch häufig beobachtet sind redirects (Umleitungen), welche mehrfach in ungünstiger Sequenz ablaufen. Jeder Redirect liefert erst einmal die gewünschte Seite aus, was seine Zeit beansprucht. Wenn man nun z.B. von http://beispiel.de auf http://www.beispiel.de und dann auf https://www.beispiel.de umleitet, dann wird die aufgerufene Seite drei mal ausgeliefert. Bei redirects ist des daher sinnvoll, bei Bedarf Regeln in .htaccess so zu hinterlegen, dass obige Kombinationen gar nicht auftreten. In diesem Kontext sei auch darauf hingewiesen, dass das Weglassen des Präfix "www" in der Regel ein Vorteil ist. Tippt man in der Browseradresszeile eine URL ein, dann lässt man www i.d.R. weg. Das heisst - der Browser sucht ersmal, ob er die Domain auch ohne Präfix findet. Findet dann eine Umleitung auf www statt, kostet auch diese Zeit. Datenbank Von Hause aus läuft PrestaShop auf den meisten MySQL - Standardeinstellungen ganz gut. InnoDB ist in der Regel MyISAM als Engine vorzuziehen. Ein Mix unterschiedlicher Engines ist negativ in Punkto Performance. Wer sehen möchte, wie optimal der Shop auf der eigenen Datenbank läuft, kann z.B. das Script mysqltuner.pl auf den Server herunterladen und ausführen. https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl Es zeigt in anschaulicher Weise, wie die verschiedenen Ressourcen und Buffers genutzt weden. Datenbank-Tabellen von Zeit zu Zeit optimieren Die Datenbanken und die dazugehörigen Indexe sollten von Zeit zu Zeit neu aufgebaut werden. Der Grund ist, dass die Tabellen-Indizes mit zunehmenden Einträgen fragmentiert werden, d.h. der Indexzugriff dadurch verlangsamt wird. Wichtig sind dabei vor allem diejenigen Tablelen mit vielen Einträgen. Über phpmyadmin kann man in der Tabellenansicht diese Tabellen auswählen und am Ende der Liste im Drop-Down den Befehl "optimize table" bzw. "Optimiere Tabellen" auswählen. Hier eine Auswahl von Tabellen, in denen das sinnvoll wäre: ps_search_index ps_product_tag ps_search_word ps_category_product ps_image_shop ps_image_lang ps_image ps_tag_count ps_product_lang ps_stock_available ps_specific_price_priority ps_layered_price_index ps_product ps_specific_price ps_product_shop ps_feature_product NGINX nginx ist auf unseren System nicht im Einsatz. Meines Erachtens erhöht es die Komplexität des Systems, rewrite Rules und anderes muss dafür adaptiert werden. Indes führte es nach bei uns durchgeführten Tests kaum zu signifikanten Verbesserungen, jedoch immer mal wieder zu Stolpersteinen. Wer ohne nginx bereits 10 Sekunden Ladezeit für die Startseite hat, wird es auch mit nginx nicht auf einen passablen Wert bringen.
×
×
  • Create New...

Important Information

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