Leaderboard

Merci Grok/ChatGPT^^

8.2, dar în ambele cazuri este mai bine să faci o instalare curată și să migrezi datele. În orice caz, dacă faci o instalare curată sau actualizezi, dezactivează modulele personalizate, treci la tema clasică și fă o copie de rezervă înainte de orice acțiune.

Ca marche si je réinitialise le module. Cdlt, Fred

Just fyi - the "Recently Viewed" module fetches the entire list of product ID's (no filters involved) into RAM 3 times and does a for-loop style walk through looking for matching ID's from the cookies. This is the memory flaw I mentioned and uses an undue amount of CPU time. With 3.4MM items, this required upwards of 1.5GB of RAM per visitor to display a list of a half dozen recently viewed items. Thanks to bot traffic these days, it is not uncommon to have dozens of simultaneous requests being made against the site which offer little to no return value. Cloudflare catches most of these, but it can't catch them all. The fix was simple - adding an IN clause to the select for IDs, but still required custom modifications. The 450 queries (reduced to around 150 with caching enabled) the software executes are mainly to determine all of the feature, layout options, and customizations a site uses. This issue is not related to catalog size.

I appreciate the suggestions, however disk I/O wasn't any part of the issue. Any software which fires 450 queries at the database server and consumes 1.5GB of RAM per visitor to display a product detail page has flaws that storage performance and database configuration tweaks won't solve. This was the results of the profiling done against the default install of PrestaShop with their catalog loaded. I submitted a pull request to deal with some of the initial memory issues I ran into, but the query counts are inherent in the way Presta's code is written. Some of these issues can be partially mitigated by reducing the functionality of the site, but that was honestly the initial appeal of using Presta. In this case, I am the agency working with the customer to update their site / software. I have years of experience in database administration, working with systems much larger than 3.4 million records. Some of my other customers have databases with billions of records and terabytes of data. They, however, are in the tech industry, not the lawn equipment industry. This was merely a test case for PrestaShop as it might have been a simple solution for their shop. The test systems used to initially profile the software had NVMe storage, hundreds of gigabytes of RAM available, and each test instance could be allocated dozens of cores if needed. However, the target hosting platform can not contain these sorts of specs as it is cost prohibitive to allocate such resources... unless self or co-locating the hosting. They do not have the technical resources for this. As mentioned previously, the solution ultimately chosen was to create a custom site. The resulting code and software have no problems querying the customer's catalog on much more modest hardware platforms. This is not a knock on PrestaShop. As I mentioned, I really enjoy the software and have used it for other projects. It just wasn't a good fit for this particular customer's needs. There is no such thing as a truly one size fits all e-Commerce solution. Aside from the size of the catalog, their needs included things like large supersession chains, product substitution lists, and the ability to lookup no longer available parts for cross referencing. These are not part of Presta's base functionality and would have required additional custom modules to be written. There were simply too many modifications needed to make it suit the purpose of the site.

PrestaShop 8.2 vs 9.0: WebP (and AVIF) — what actually works • In PS 8.2 there’s a native WebP toggle, but it’s experimental. Path: Advanced Parameters → New & Experimental Features → Enable WebP. Then go to Design → Image Settings → Regenerate thumbnails (All images). • How it behaves in 8.2 – URLs may still show .jpg/.png, but browsers that support it get image/webp. – Most thumbnails convert; some originals remain JPG/PNG. – Requires GD or Imagick with WebP enabled; otherwise PS quietly falls back to JPG/PNG. – Some themes/modules don’t love the MIME swap. • Verify quickly – DevTools → Network → click an image → Content-Type: image/webp. – Or terminal: curl -I "https://yourshop.com/img/p/1/2/12-large_default.jpg" | grep -i content-type • Works in 8.2: regenerated thumbs, WebP delivery in supported browsers. • Limits in 8.2: no AVIF, inconsistent coverage, confusing file names; many shops still use an optimizer module for full coverage & fallbacks. • PS 9.0: WebP becomes first-class (not experimental), adds AVIF, and is more consistent across all image types. Full guide (steps, checks, tips): 👉 HERE

Acabo de desarrollar un módulo para n8n que permite interactuar fácilmente con el Webservice/API de PrestaShop, abriendo un mundo de posibilidades en la automatización de procesos eCommerce. Si quieres una guía visual de instalación, funcionamiento y ejemplos prácticos de flujos de trabajo listos para importar en n8n, este video te interesa: 👉 El proyecto es open source y está disponible para colaboración: 👉 https://github.com/prestaalba/n8n-nodes-prestashopadvanced La automatización no es solo ahorrar tiempo, es abrir nuevas oportunidades para crecer. ¿Te sumas?

Hi, i'll add a few more tips to what was written by El Patron. This is a bug of new Ps9 that will be fixed i think in the end of August with new release. Actually the code of the module is updated!!...but in backoffice it continue to show the message ..well to fix this you have to update the module and than reset the module and you will see the new version:-) https://github.com/PrestaShop/PrestaShop/issues/39151 Cheers

Hi, you need to delete folder var/cache/prod and var/cache/dev. And also in database replace old domain with new one but not only ps settings, but all url in database like cms page or product description that contains links. Example move from dev.mydom.ext to www.mydom.ext in SQL dump file replace all occurrences of dev.mydom.ext by www.mydom.ext

Utilisez PHPMyAdmin et accédez aux tables de devises. Vérifiez la valeur dans la colonne « précision ». Il doit s'agir de valeurs entières comme 1 ou 2, etc. Ou essayez d'installer avec une autre version locale (États-Unis, etc.). Ajoutez ensuite la devise ultérieurement.

En los assets puedes encontrar el XML correspondiente: https://github.com/PrestaShop/PrestaShop/releases/tag/8.2.3

little late for the party but since you answered 6 months later, then I will have elementor as part of theme is helpful. I've had many great successes using Leo Themes in the past, before warehouse, panda, transformer...they originally came from Joomla, which is a 'very' good platform, still is but not as popular as it once was. https://www.leotheme.com/prestashop/themes.html

You could hide it with css but white place will stays. Either remove / commend it from tpl if you find it. Its kpi-container either class="row orders-kpi". ( not sure how BO will react to it - so dont do it if it just a irritating ).

The installer or server sometimes changes names if, for example, it wants to overwrite a file, but it already exists (to avoid deleting it, it adds a prefix such as .old, _old, etc.). I'm glad the problem has been solved 🙂

This error indicates a problem in the ps_eventbus module (the action column is missing). First, check the table to see if the ACTION column exists using a query (e.g., via phpMyAdmin): SHOW CREATE TABLE ps_eventbus_incremental_sync; The table structure should be as follows: If not, add it with the query: ALTER TABLE ps_eventbus_incremental_sync ADD COLUMN action VARCHAR(50) NOT NULL; Remember to adjust the ps_ prefix to the one used by your store. Alternatively, try disabling the ps_eventbus module completely and see what happens. If the problem is solved, consider reinstalling this module (uninstall and reinstall) - if you need it at all.

Bonjour, j'aimerais savoir comment forcer le préfixe www. devant mon nom de domaine ? Les directives sur .htaccess créent des "too many redirect" Les impressions écrans pour changer l'adresse de la boutique ne sont pas les mêmes que les miennes, et j'ai peur de mettre www. et que si quelqu'un viennent sans www. ca ne marche plus. Merci de votre aide.

Überprüfen Sie Cloudflare Turnstile und das hcaptcha Modul.

Ive just re-installed this because I had to remove due to a bad bug. After installing this one, its working, but there is some error in the css file "payments.css" This is how it looks So you need to add this css to your custom.css /* CHECKOUT PROCESS */ .ps_checkout-payment-option label { display: flex !important; } then it looks like this If you share your url then maybe a little bit of css changes will resolve your issue.

I’ve developed an n8n module that allows seamless interaction with the PrestaShop Webservice/API, unlocking countless possibilities for eCommerce process automation. If you want a guide on installation, usage, and practical workflow examples ready to import into n8n, this is for you: 👉 https://github.com/prestaalba/n8n-nodes-prestashopadvanced/tree/master/examples The project is open source and open for collaboration: 👉 https://github.com/prestaalba/n8n-nodes-prestashopadvanced Automation is not just about saving time, it’s about opening new opportunities to grow. Are you in?

Dans les paramètres payements le pays est bien activé sur les transporteurs ?

Dziękuję za cenne rady, wszystko działa jak w szwajcarskim zegarku Temat zamknięty Henryk

Problème résolu. J’ai développé un module spécial testé sur PrestaShop 8 et 9. Il fonctionne directement et ajoute en plus un paramètre de configuration pour définir le nombre maximum de caractères à afficher dans le nom du produit (tronqué avec “…”).

Par défaut, PrestaShop n’offre pas d’option dans le back-office pour limiter la longueur des titres de produits dans la liste du catalogue. Donc, il n’existe pas de réglage natif. La colonne “Nom du produit” prend toute la largeur que le titre occupe, ce qui peut vite casser l’affichage si tu as des titres très longs. Voici le style css qu il faut ajouter : table.table td.column-name { max-width: 250px; /* largeur max de la cellule */ white-space: nowrap; overflow: hidden; text-overflow: ellipsis; } Si tu ne parviens pas à faire la manipulation je peux t assister.

Hello, That text should be under Front office Translations -> Shop -> Theme -> Checkout. In my case it was on the 4th page, with the original text being: "The selected address will be used both as your personal address (for invoice) and as your delivery address."

Hi! I'm Daria, technical support manager of Paypal Official module. Thank you for the interest in our module! The release of the new version compatible with PS 9 is scheduled for September. If you have any further questions, I invite you to contact our support directly. Have a nice day! Daria 202-ecommerce

welcome to community tested looool ps_checkout has been a nightmare, I made a lot of money with client intakes of broken checkout...we just removed it...you should consider the same unless ps has no other option for the payment gateway you use.... Yep—this is a real bug in the latest ps_checkout update (rolled out around Aug 22–25, 2025). Multiple shop owners are reporting the exact same crash on the Back-Office/FO with this stack trace pointing at the module’s English XLIFF file: modules/ps_checkout/translations/en-US/ModulesCheckoutPscheckout.en-US.xlf (XLIFF parser: “source element not expected”, Error 1871). prestashop.com+1 Here’s the quickest way to get the site back up and keep ps_checkout usable: Restore access (if you’re locked out): via FTP/SSH, temporarily rename the module folder: modules/ps_checkout → modules/ps_checkout.off (site comes back). prestashop.com Target the bad file only: put the module folder name back to ps_checkout, then delete this file: modules/ps_checkout/translations/en-US/ModulesCheckoutPscheckout.en-US.xlf. Several users confirm the module will run without that file. prestashop.com Clear cache: delete var/cache/prod (and var/cache/dev if present). Reload Back-Office and test checkout. Why it breaks (short version) The shipped en-US XLIFF is not schema-valid for what Symfony’s XliffFileLoader expects in PS 8/9—hence the “[ERROR 1871] … source element not expected” crash during cache warm-up. Removing or replacing that one file avoids the fatal. prestashop.com let us know how that works for you!

Only adding this to the PrestaShop admin folder/.htaccess file solved my problem. Thanks <RequireAny> Require method DELETE GET POST PUT OPTIONS </RequireAny>

He lidiado con Alysum una vez durante varios meses y es una auténtica pesadilla. El último problema que no pudimos solucionar fue con los pedidos y el carrito en dispositivos iPhone. Pero solo en esos; en Android funcionaba bien. Alysum tiene Elementor, así que para móviles hay que crear bloques separados y ocultarlos en PC para que todo funcione correctamente. En cualquier caso, hemos terminado con Alysum y hemos recreado la tienda solo en Elementor.

Bonjour @BrunsonDid, La version compatible Prestashop 9 devrait être mise en ligne d'ici la fin de la semaine, elle est prête 😉

The main module file will be in the root directory of the module, not in the src. The structure of the module files will be the same as in PS1.7 (Only some deprecated functions need to be done).

Dziękuję bardzo, brzmi sensownie. Sprawdzimy dzisiaj.

Bonjour à tous ? Vous n'êtes pas sur le bon forum... Avez vous vidé le cache ? Avez vous vérifié que votre version PHP est la meme que sur l'ancien serveur ?

The error shows that the backup namespace is not available in your CLI. The safest way is to handle backups directly on the server side using tools like mysqldump for the database and a simple archive command for the files. This is more reliable than depending on PrestaShop’s Upgrade Assistant which is not always stable for backups.

Ya tenemos un módulo gratuito para configurar Webhooks en PrestaShop 🚀 que nos permite enviar notificaciones a sistemas externos en tiempo real ante eventos ocurridos en nuestra tienda (creación, actualización o eliminación de cualquier entidad). Es una versión muy simple para comenzar, con mucho campo para mejoras. Las contribuciones son bienvenidas 😉 https://github.com/prestaalba/ps_webhooks Les dejo video con una pequeña muestra de lo que se puede hacer a partir de ahora usando este módulo.

Never trust an updater module. I have always been waiting for a working one… Each time there is new version of either prestashop free or paid module they just don’t always work. Sometimes, I tested them a clean prestashop version without any edit and it didn’t work. This is why the main turnover % of agencies was always the Upgrades. So if your website is working and you are getting sales just don’t upgrade. I have clients on 1.7 till now and I don’t advise them to upgrade. And others who I did the upgrade for. So business wise advice if it’s working invest money on what will bring you more money

How to replace your existing PrestaShop domain with your upgraded shop If you’ve built your upgraded PrestaShop 8.2 on a subdomain (e.g. new.mysite.com) and now want it to take over your main domain (e.g. mysite.com), here are the recommended steps you should follow. This process ensures you retire the old 1.6 site cleanly while putting your upgraded shop live on the existing domain. 1. Plan redirects first To protect SEO and ensure visitors don’t get lost, set up a 301 redirect from your temporary subdomain (new.mysite.com) to your main domain (mysite.com). You can do this in your hosting control panel or with .htaccess rules. Additionally, there are some good redirect management modules available on the official PrestaShop Addons marketplace. These can make it easier to manage complex redirects, track hits, and avoid SEO penalties. Having your redirect strategy ready before the move ensures Google and customers are sent to the correct place immediately. 2. Archive your old 1.6 shop Instead of deleting it outright, create a subdomain (for example archive.mysite.com) and move your PrestaShop 1.6 files + database there. This way you still have access to historical orders, customer records, and references if you ever need them. Once the 1.6 shop is safely archived, you can remove the 1.6 files from the main domain root to make room for your upgraded shop. 3. Put your upgraded shop on the main domain Use FTP or your hosting file manager to move all files from the upgraded 8.2 shop’s subdomain directory to the root directory of your main domain. If your host allows, you can simply change the domain’s document root to point to the subdomain folder instead of physically moving files. 4. Update database domain settings Log into phpMyAdmin (or any MySQL tool). Go to your shop’s database. Open the table ps_shop_url (replace ps_ with your prefix if different). Update the fields: (without prefix https://) domain → mysite.com domain_ssl → mysite.com physical_uri → / (Make sure there is no new. or subfolder path left.) 5. Clear cache and regenerate .htaccess Delete the contents of /var/cache/prod/ and /var/cache/dev/ (if they exist). In your back office, go to Shop Parameters > Traffic & SEO. Temporarily turn off Friendly URL, save, then turn it back on and save again. This will regenerate a fresh .htaccess with the correct domain rules. 6. Update configuration files (if needed) Most likely, since you are moving from a subdomain on the same hosting account, the database name, user, and password are already correct and you don’t need to change anything. But if you do need to check or update them: For PrestaShop 8 → open /app/config/parameters.php For PrestaShop 1.6 → open /config/settings.inc.php Inside these files you’ll see the DB settings (database_name, database_user, database_password, and database_host). 7. Test and fix links Visit the site on the main domain and check the homepage, category pages, product pages, and checkout. If you see links still pointing to the old subdomain, clear browser cache and PrestaShop cache again. Also check your sliders, banners, and custom modules — sometimes they store fully qualified URLs (like https://new.mysite.com/...) instead of relative paths. Update these manually in the back office if needed. Summary: The official way to replace your existing domain with the upgraded PrestaShop is: plan 301 redirects (manual or via a module) → archive 1.6 to its own subdomain → clear main root → move 8.2 shop → update ps_shop_url → clear cache → toggle Friendly URL to regenerate .htaccess → confirm DB settings → test links (including sliders/banners with hard-coded URLs).

v5.0 - Compatible PS 8 / 9

The problem solved. It was in root/classes/controller/FrontController.php:1709 1) 'favicon' => self::configuredImageUrl('PS_STORES_ICON', $psImageUrl), The mistake was here, just updated "PS_STORES_ICON" to correct key "PS_FAVICON". Then cleared cache.

Hola @ps_developer, Correcto. El intermediario utiliza su propio certificado digital para enviar facturas a VeriFactu en nombre de la empresa autorizada, y únicamente para ese fin. En todos los servicios de intermediación, la empresa debe firmar un documento de autorización para que el intermediario pueda actuar en su nombre. Este documento debe presentarse ante Hacienda para validar la relación. Es importante tener en cuenta que la infraestructura de envío debe contemplar que los servicios de Hacienda no están disponibles 24 horas al día. Por tanto, es necesario implementar mecanismos como colas de envío y reintentos automáticos, garantizando así que las facturas se envían correctamente en cuanto el servicio esté operativo. Este mismo criterio aplica a los módulos que se están empezando a comercializar para Odoo, WooCommerce u otras plataformas. Cualquier solución que requiera subir el certificado digital de empresa debe ser rechazada. Implica un riesgo crítico: en caso de compromiso del servidor, el certificado puede ser utilizado para firmar comunicaciones o transacciones en nombre de la empresa, sin ningún control.

Hola, Por lo que estoy viendo de momento todas las soluciones que se están ofreciendo son "APIs intermedios de pago" que requieren suscripción.... sin embargo el API proporcionado por la administración es un API público y gratuito (requiere autenticación con certificados, etc...) pero nada que impida desarrollar un módulo para Prestashop que se integre directamente con los APIs públicos de la administración. No queda mucho tiempo, no creeis que habrá algún desarrollador que se decida a desarrollar un módulo que no requiera suscripción? Me dan ganas de ponerme yo con ello.... (pero tengo muy poco tiempo...) saludos, Roberto.

Al parecer como siempre.. a nivel técnico no esta del todo claro las especificaciones técnicas, por eso no se ven módulos. Al final sólo los sistemas SAAS en la nube tipo holded tendrán músculo suficiente para adaptarse al infierno fiscal de este país y será mejor olvidarse de la facturación de prestashop.. Veremos

Hola te adjunto el modulo que necesitas de la version 8.2.1 @DaniMH ps_edition_basic.zip

Bonjour, Depuis la version 9 ( toujours en préparation ), PrestaShop ne publie pu un zip sans ses modules ( checkout, account, gamification ... ) Sur presta.zip vous pouvez retrouver les versions du projet open source sans tous ces modules préinstallés Enjoy

Ciao, hai un qualche plugin che ti sta affossando la macchina. Impossibile che con 700 prodotti saturi la cpu. Oh, poi dipende anche dal piano che hai preso. M.

Ma réponse initiale était sur Crazy Elements et non Creative Elements, d'où mon édit. Quand j'ai vu vos problèmes de chargement, j'ai cru que vous étiez sur Crazy Elements car, par expérience, j'ai déjà croisé plusieurs clients qui avaient les mêmes problèmes de chargement ( et plus encore... ). Sauf que dans leurs cas, c'était la version Crazy Elements (exactement la même chose que Creative Elements mais réalisée par une autre société) et leurs problèmes n'ont jamais eu de réponse de leur support à eux (et non le support de Creative) pour Creative Elements ce n'est pas la même chose. Ils respectent les standards de développement de PrestaShop car ils sont sur PrestaShop Addon, ils ne peuvent pas faire n'importe quoi. Mais ça reste un page builder, donc gardez en tête que ça ne sera jamais aussi optimisé qu'un code fait "sur mesure", d'où mon commentaire sur le fait que ça reste une usine à gaz. Ce qui pourrait être utile, c'est d'expliquer ce que le support vous a recommandé de faire pour optimiser votre chargement, au cas où d'autres utilisateurs rencontreraient le même problème. Cela pourrait aider d'autres personnes dans la même situation que vous.

You don't debate, you simply suppress what you consider to be a problem. That a free module is not perfect bothers me much less than the thousands of copies of modules doing the same thing, or that paid modules are so poorly developed and insecure, or that themes are filled with modules without receiving the same control constraints, and so on. You criticize the French, but surprisingly, it is still this community that offers real community solutions to security problems in its universe, and of course for free. So I still think that by accompanying the good will to make free modules available can be a benefit for the whole community.

Volviste por el redsys?

awesome. Thanks.

Hello, just a note for 1.7.7.x search a lot time for find this almost all admin files chanced src/Core/Grid/Query/OrderQueryBuilder.php find private function getCustomerField() { return 'CONCAT(LEFT(cu.`firstname`, 1), \'. \', cu.`lastname`)'; } replace private function getCustomerField() { return 'CONCAT(cu.`firstname`, \' \', cu.`lastname`)'; } bests...

This problem is most of the times related to SSL issues. If you have HTTP to HTTPS redirects enabled while there is some other setting which redirects a https request to an http webpage, hen you will get this error. For example, if you have HTTP to HTTPS redirects enabled, but you have a setting in .htaccess which redirects like this: Redirect 301 * http://<DOMAIN_NAME>.com/ Or if you see some other settings in there which redirects to a http page. That's most commonly related to this issue in my opinion. Next is if you for example use Cloudflare. Cloudflare has 4 SSL options: 1. "Off (Not Secure)" 2. "Flexible" 3. "Full" 4. "Full (Strict)" What SSL setting should I use? This setting controls how Cloudflare’s servers connect to your origin for HTTPS requests. We recommend enabling the Full SSL (Strict) setting if possible. Common use cases for each are: Off: No visitors will be able to view your site over HTTPS; they will be redirected to HTTP. Flexible SSL: You cannot configure HTTPS support on your origin, even with a certificate that is not valid for your site. Visitors will be able to access your site over HTTPS, but connections to your origin will be made over HTTP. * Note: You may encounter a redirect loop with some origin configurations. Full SSL: Your origin supports HTTPS, but the certificate installed does not match your domain or is self-signed. Cloudflare will connect to your origin over HTTPS, but will not validate the certificate. Full (strict): Your origin has a valid certificate (not expired and signed by a trusted CA or Cloudflare Origin CA) installed. Cloudflare will connect over HTTPS and verify the cert on each request. And last one you can check is for when you get this error while you did just install Prestashop. 1. Try to log in to the backend via: https://<my-domain.com>/Backoffice/index.php 2. In PrestaShop Backend, click Shop Parameters (under Configure) > General. 3. Click "Yes" next to Enable SSL and click Save to apply the changes. 4. Then click "Yes" next to Enable SSL on all pages and click Save to apply the changes.