Leaderboard

I created a free module for this if someone is interested prioritycurrency.zip

Hi, I took a quick look at your page, and I need to point out a critical UX issue that might be driving away customers, especially from the younger demographic. First off – great job on the visual side, shop looks nice. The Problem: Scroll Hijacking The site uses a script that overrides the browser's native scrolling behavior (often called "smooth scroll"). Instead of reacting instantly to the finger or mouse wheel, the page "floats" with a noticeable delay. Why this hurts you (Gen Z / Millennial perspective): Loss of Control: As a user accustomed to fast-paced content consumption (Instagram/TikTok standards), I scan pages rapidly. This artificial delay makes the site feel sluggish, laggy, or even broken. Frustration = Bounce: The brain perceives this delay as friction. Instead of scrolling down to "Add to Cart," I feel like I'm fighting the interface. In e-commerce, any resistance leads to a higher bounce rate. Best regards,

https://www.twenteeoneprints.com/ If you can give me some feedback on my website.

Hello community! I’m excited to introduce Accessibility Total Pro, a module designed to transform any PrestaShop store into an inclusive space, making navigation easier for people with visual, motor, or cognitive disabilities. With new web accessibility regulations (such as the European Accessibility Act), this module doesn't just improve your customer experience—it helps your business meet essential legal standards. Key Features: Disability Profiles: Pre-configured settings for Colorblindness, Dyslexia, ADHD, Blindness, Low Vision, Motor Impairment, and Epilepsy. Visual Personalization: Users can adjust text size, spacing, contrast, and saturation in real-time. Reading Tools: Includes screen reader support, reading mask, and link highlighting. Animation Control: Ability to pause moving elements, which is vital for users with photosensitive epilepsy. Fully Customizable for Admins: Change widget colors to match your brand, upload your custom icon, and manage your accessibility statement directly from the backoffice. Why choose this module? Boosts SEO (Search engines prioritize accessible websites). Increases conversion rates by removing barriers to checkout. Demo / Purchase: Accessibility Total Pro I look forward to your feedback!

It seems I'm not the only one with the problem. I just went to report it on GitHub, but somebody beat me to it https://github.com/PrestaShop/PrestaShop/issues/40695

Bonjour, voici une piste https://github.com/PrestaShop/PrestaShop/issues/40688

Buenas, por motivos de cambio de trabajo y otras circunstancias personales vendo mi tienda online. Tiene 10 años de antiguedad y en su nicho es líder de ventas a nivel nacional. Consta de una base de datos de 20.000 clientes y su facturación es creciente cada mes. La dedicación como dueño que le dedico no sube de 20 horas semanales y tiene un beneficio neto en el actual año de 60.000 euros. Interesados por favor hablenme por privado. Gracias

Le principal problème aujourd'hui c'est le piège organisé. A partir du moment où vous allez mettre à jour vous serez obligé de faire les majs suivantes, il n'y a aucune rétro-compat. Prestashop pousse (force) tous les éditeurs de modules à suivre leurs nouvelles règles, à intégrer ps_account (si pas présent les modules et leurs mises à jour ne s'installent plus), le fameux module qui envoie toutes vos données BO à Prestashop SA en Italie (depuis qu'ils ont été rachetés par MBE logistics). Et donc, si vous regardez les évolutions en cours, vous perdrez en fonctionnalités. Exemple sur les "nouvelles règles paniers": Si j'ai lancé PhenixSuite c'est justement pour rester rétro-compatible, sans rien casser et continuer d'évoluer. Le projet actuel Prestashop suit le parti pris d'une toute petite minorité de décideurs qui savent mieux que vous ce dont vous auriez besoin et comment vous devez gérer votre boutique. Il y a de bonnes choses dans la 8 mais les choix sont devenus trop restreints et orientés.

le message ci dessus c'est de l'IA..

Hi. ./src/Core/Context/CurrencyContextBuilder.php Find public function build(), change $legacyCurrency->precision to (int)$legacyCurrency->precision

Performance optimization should become a priority as soon as you notice backend sluggishness or intermittent frontend delays, not only when traffic is high. In PrestaShop, performance issues tend to accumulate quietly as products, categories, combinations, and modules grow. The good news is that the biggest gains usually come from a few foundational improvements rather than drastic changes. When optimization should move to the top of the list If you’re seeing any of the following, it’s time: Back office pages loading slowly (especially product edit, orders, or modules) Delays when adding or editing products and combinations Random frontend slowness despite modest traffic Timeouts during imports, indexing, or cache operations These symptoms almost always point to database and storage bottlenecks rather than PrestaShop itself. High-impact optimizations that deliver early results NVMe-SSD hosting If your store is still on traditional SSD or shared hosting, moving to NVMe-SSD storage is often the single biggest improvement. PrestaShop is extremely database-heavy, and NVMe drastically reduces I/O latency. Back-office actions frequently feel several times faster immediately after migration, with no code changes or risk. MySQL tuning Default MySQL settings are rarely appropriate for a growing PrestaShop store. Proper tuning of InnoDB memory, temporary tables, and slow queries makes a noticeable difference in both the back office and front office. I’ve written several practical, PrestaShop-specific articles on this here: 👉 https://prestaheroes.com/blogs/mysql-optimization Module discipline Every enabled module adds queries and hooks. Disable anything you’re not actively using, review modules that hook into every page (header, footer, display hooks), and avoid overlapping functionality such as multiple SEO or analytics tools. This alone can remove hundreds of unnecessary queries on larger shops. Key takeaway Most PrestaShop performance problems start with storage and the database, not traffic volume or themes. Upgrading to NVMe-SSD hosting, tuning MySQL for your catalog size, and keeping module usage intentional will usually restore backend responsiveness and frontend stability long before performance becomes a crisis. Addressing this early is far easier — and far cheaper — than waiting until the shop becomes painful to manage. For nearly all shop administrators, there comes a point where having an experienced agency involved makes sense — not to add “voodoo” performance modules, but to improve performance in a safe, measurable way. PrestaShop tuning is genuinely complex, and many of the most effective gains come from proper database configuration and upgraded hosting rather than front-end tricks. Improving the underlying infrastructure, especially storage and MySQL performance, often delivers significant, reliable speed improvements without risking shop stability.

I have no idea what the numbers of the conflicting versions are. And even if I did: I don't know that kind of details. But if you hoster thinks that it works ok and you don't see problems either it likely is ok.

oui n'importe quoi ou effectivement vous pouvez la supprimer si la commande n'existe plus en bdd. (sinon le module détectera le transporteur MR et voudra la réassocier)

Vous pouvez virer les 3

pas de settings.inc dans PS 1.7 + mais dans /app/config/parameters.php

Bonjour, changer le préfixe ps_ par le votre. SELECT c.id_customer, c.firstname, c.lastname, c.email, a.phone, a.phone_mobile FROM ps_customer c LEFT JOIN ps_address a ON a.id_customer = c.id_customer AND a.deleted = 0 AND a.active = 1 WHERE c.deleted = 0 ORDER BY c.id_customer ASC;

It's been a long time since I've posted, but I've come up with a helpful tip while helping a friend develop a PrestaShop 9 website. I came up with a free way to embed responsive videos in product descriptions and any other HTML fields on the website. Enable the "Allow iframes on HTML fields" option (if it's disabled) on the "Shop Parameters > General" tab in the Back Office. Create a child theme (if you haven't already) to enable custom CSS to be added. Add the following to the themes/child_theme/assets/css/custom.css (this code makes the YouTube video responsive so it looks good on desktop, tablet and mobile): .embed-container { position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%; margin-bottom: 1rem; } .embed-container iframe { position: absolute; top: 0; left: 0; width: 100%; height: 100%; } Upload the video to YouTube and choose either "Public" or "Unlisted" depending on whether you want the video searchable on your channel. Click the "Share" button on the video and then choose "Embed". Copy the <iframe> code to the product description or other HTML field in the Back Office and then add <p class="embed-container"> before the <iframe> code and </p> after the </iframe> code. I hope this helps someone.

Hey, if you can attach the module here I can update it to work. Also make sure to include your prestashop version. I would need to know payment received order stat id. or from phpmyadmin or ps sql manager First, get the order_state ID(s) SELECT id_order_state, name FROM ps_order_state_lang WHERE name LIKE '%Payment%' OR name LIKE '%Received%'; Use those IDs in this report query This returns product + total qty for orders whose current status is “Payment Received”, within a date range: SELECT od.product_id, od.product_reference, od.product_name, SUM(od.product_quantity) AS qty_sold FROM ps_orders o JOIN ps_order_detail od ON od.id_order = o.id_order WHERE o.current_state IN (/* put id_order_state(s) here */) AND o.date_add >= '2026-01-01 00:00:00' AND o.date_add <= '2026-01-31 23:59:59' GROUP BY od.product_id, od.product_reference, od.product_name ORDER BY qty_sold DESC;

Dans la table ps_mondialrelay_selected_relay remplissez les colonnes avec des valeurs fictives tracking_url label_url expedition_num date_label_generation pour cette commande

PrestaShop does not support customer-entered pricing natively, but this can be implemented properly via a dedicated module (not a core hack). I have the expertise to build this feature so customers can enter an amount, have it validated, and proceed through checkout safely with correct totals, taxes, and reporting. Beyond the feature itself, my agency specializes in full migrations from non-PrestaShop platforms to PrestaShop. This includes preserving existing workflows, data integrity, and SEO while rebuilding the shop to fully leverage PrestaShop’s strengths rather than fighting against them. If you’d like, I’m happy to provide a free, detailed migration and new-shop build plan tailored to your current platform and requirements. Just message me with your email address. Migrations into PrestaShop are something we’ve always excelled at—we enjoy the challenge, go the extra mile, and focus on building a clean, scalable, and well-architected shop from day one.

Jetez un œil ici avant de vous lancer dans une migration compliquée: https://eoliashop.com/phenixsuite/prestashop-new

Hi, Musicmaster, I got advice from my hosting on this issue. First of all they agree that this is cause by some upgrades to server (DD, SQL or php), but it can't be downgraded because of security and because it is shared server. So looking into login1.php code they advised to ignore warnings in that particular place of the code. Adding this around original code: $old_level = error_reporting(); error_reporting($old_level & ~E_WARNING); // original code block with mysqli_connect error_reporting($old_level); I added it and it actually it did the trick. At least Combination_delete now works as it used before. I am not sure if it is a good practice for you to add it tot the code as standard. If you see it not usable, I believe I'll need to update login1.php manually every time I take an update from your website. On your POV - can this cause any issues? Thanks!

Hi, PS9 email preview uses the Twig email theme system, not only /mails/<lang>/*.html. That’s why footer.twig changes apply but the body looks “generic”. Fix: BO → Design → Email theme → select your theme → Generate Edit the actual Twig templates in /mails/themes/classic/ Clear cache Also, the preview relying on /mails/themes/classic is basically the fallback in PS9, so don’t remove/rename that folder.

Sì, il campo “UBICAZIONEMAGAZZINO” è quello giusto. Inserisci lì scaffale e ripiano per ogni variante, usando un formato chiaro e coerente per trovare facilmente i prodotti.

I got the same error. The weirdest part about this error is that it didn't show up in a local and an ubuntu vps installation but it does break on my managed hosting environment. There is a discussion here https://github.com/PrestaShop/PrestaShop/issues/38894 but the hosting environment is never mentioned. edit: The environment was mentioned here after all https://github.com/PrestaShop/PrestaShop/pull/38905 tl;dr make the following changes https://github.com/PrestaShop/PrestaShop/pull/38905/files and the backoffice will probably be fixed.

@rachel01 try this free solution

To have all data backed up makes sense. Save your shop as more hacking is most likely to happen the coming decade.

It seems to work for mee after I did an additional change to the changes suggested above in LInk.php class . The additional change I did was in ovveride Tools function switchLanguage: from: if ( ($iso = Tools::getValue('isolang')) && Validate::isLanguageIsoCode($iso) && ($id_lang = (int) Language::getIdByIso($iso)) ) { $_GET['id_lang'] = $id_lang; } to if ( ($iso = Tools::getValue('isolang')) && Validate::isLanguageIsoCode($iso) && ($id_lang = (int) Language::getIdByIso($iso)) ) { $_GET['id_lang'] = $id_lang; } else { $_GET['id_lang'] = (int) Configuration::get('PS_LANG_DEFAULT'); } basically adding the else block to handle when there is no isolang posted: else { $_GET['id_lang'] = (int) Configuration::get('PS_LANG_DEFAULT'); } I hope that helps the community.

Bueno pues me respondo yo mismo por si le pasa a alguien más: resulta que además de activar el permiso para ver las estadísticas, debe tener permiso para ver los módulos de cada sección de las estadísticas, algo que yo había deshabilitado porque no permito ver ningún módulo a los empleados. Es decir, en la columna de la derecha, Módulos, deben tener "Ver" activado los módulos: Tabla de mando de estadísticas, Mejores fabricantes, Mejores productos, etc. Saludos.

Comme son nom l'indique le groupe défaut est le groupe de tous les clients lors de leur inscription, mais malheureusement aussi lorsqu'ils ne sont pas inscrits. J'entends par là que lors du calcul du tarif c'est le groupe defaut qui est utilisé même si le client n'est pas authentifié. Pour avoir un tarif différent et remisé il va falloir créer un autre groupe et ajouter un tarif spécifique pour ce groupe, et faire en sorte que tout nouveau client enregistré soit automatiquement. Ce n'est pas un gros oeuvre mais ça demande un petit développement de module. Il faut souscrire au hook correspondant à une création de compte (actionCustomerAccountAdd par ex) et un bout de code ajoute le membre au groupe remisé. Votre approche était bonne cela dit , mais le fait est qu'un utilisateur non authentifié/enregistré appartien au groupe defaut ce qui lui confère les droits aux réductions dudit groupe...

Bonjour à tous, Nous exploitons actuellement une boutique PrestaShop 1.6.0.6, développée en PHP 5.4, en production depuis maintenant près de 10 ans. Dans un objectif de modernisation globale (thème, fonctionnalités, performances et expérience utilisateur), nous souhaitons migrer vers une version plus récente de PrestaShop. L’idée serait de mettre en place une pré-production sur un sous-domaine, probablement en PrestaShop 9.0.2, afin de travailler proprement avant bascule. Concernant les modules : nous utilisons des modules achetés sur Addons, mais aussi beaucoup de modules développés en interne. Cela ne nous pose pas de problème d’adapter nos modules, ni même d’en redévelopper une grande partie, sachant que 90 % d’entre eux sont relativement simples. Sachant que maintenant ChatGPT ou Gemini sont là si on veut accélérer le truc ;) Notre question est donc la suivante : Est-il pertinent de partir directement sur PrestaShop 9.0.2, afin de bénéficier d’une base solide, moderne et scalable pour les prochaines années, avec des mises à jour régulières ? Ou vaut-il mieux se concentrer sur une version 8.x, plus éprouvée aujourd’hui, même si elle peut sembler déjà « obsolète » à moyen terme ? Merci d’avance pour vos retours d’expérience et vos conseils 👍