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

@Nickz Ich werde jetzt Thirtybees austesten. Ich habe die Nase im Moment von Prestashop voll. Seit der PHP Version3 (?) arbeite ich damit, aber so viele Probleme und auftretende Fehler habe ich noch nie in einem Script erlebt. Ob ich da etwas falsch mache oder nur derjenige bin der das Pech hat ausgerechnet den Punkt zu treffen, an dem ein Fehler sitzt - ich weiß es nicht. Ich habe auch im Moment keinerlei Antrieb mehr, noch mehr Arbeitszeit in dieses System zu investieren. Dank an alle, die versucht haben mir zu helfen! Norbert

We have some developers working under Windows 10 and 11, with Wamp or Xamp, and it works normally. First all, if you have antivirus as said @El Patron deactivate it when running sites, or put in white list apache, mysql, mariadb, php executables. Change realpath_cache_size size in php.ini to a large value like: realpath_cache_size = 5M Also make sure you mariadb or mysql settings are corrects especially for innodb.

Um Gottes willen, nicht auch noch erhöhen, 8.2 ist schon nicht kompatibel, da funktioniert zwar vieles, aber es treten halt auch Fehler auf, Prestashop 8.2 läuft maximal mit PHP 8.1!

Hi this is a basic edition?

I developed the module “Merge Carts – Prevent Lost Shopping Carts on Login” that elegantly and efficiently solves this issue. If a customer adds items as a guest and then log in, this module intelligently merges the old saved cart with the new cart. The module “Merge Carts” fixes the default behavior of replacing one cart with the other upon login. Simply no more lost carts. Get the module — The module “Merge Carts” is available at: https://addons.prestashop.com/en/social-login-connect/96287-merge-carts-prevent-lost-shopping-carts-on-login.html Demo — You can try the demo at: https://www.bulletproof.se/_demos/mergecarts/ (btw, the demo is darn easy to use. It's got some cool features, and it's super easy to create an account and log in). Video — I explain the logic of how PrestaShop handles carts and how the module “Merge Carts” will fix it in this video: https://youtu.be/mXKQUnPAjw8

Rendez-le vide au lieu de null. OU effectuez une sauvegarde de la table d'adresses et exécutez la requête suivante dans la base de données. UPDATE `ps_address` SET address2 = '' WHERE address2 IS NULL; Assurez-vous que le préfixe de la table est correct dans la requête en fonction de votre préfixe d'installation.

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

Tutaj masz podobny temat: https://github.com/PrestaShop/PrestaShop/issues/38305 Próbowałeś zmienić wersję PHP?

Test with this one: if ($this->ps_below_7) { $total_to_pay = Context::getContext()->getCurrentLocale()->formatPrice( $params['total_to_pay'], $params['currencyObj']->iso_code ); $order = $params['objOrder']; } else { $total_to_pay = Context::getContext()->getCurrentLocale()->formatPrice( $params['order']->getOrdersTotalPaid(), (new Currency($params['order']->id_currency))->iso_code ); $order = $params['order']; }

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.

Ibilang ti pananglapped kadagiti kasta nga url iti robots.txt

You're right. I did not expect it. But that is the way. Thank you.

C’est une solution fortement déconseillée, car vous ne pouvez pas anticiper la réaction du module. S’il implémente des éléments en base de données, il y a de fortes chances qu’une réinstallation entraîne une suppression complète des données et une réinitialisation de sa configuration. Ce serait particulièrement regrettable de perdre l’intégralité d’un menu soigneusement paramétré en plusieurs heures de travail.

Merci de votre réponse et de toute l'aide donnée pour mon site. Claire

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 “…”).

SOLVED - it was the PHP version.

Avec grand plaisir envoies les moi en mp. Ca sera plus efficace.

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."

De estos sitios ya hay muchos, pero es lo que hablamos, en todos los casos tienes es una opción de pago mensual.

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!

No incluye plantillas móviles, eso seguro. Tienes que crearlo. Si necesitas ayuda, avísame por privado.

New version available now.

Pardon me for the google translation: Hallo an alle Deutschen softwareentwickler von Prestashop! Sie können diesen fehler beheben, indem sie diese zeile löschen: modules/ps_checkout/views/css/payments.css:434 display: inline !important; In case the translation doesn't make sense, you can fix this error by deleting this line: modules/ps_checkout/views/css/payments.css:434 display: inline !important;

Hello, I faced exactly the same problem I think. My website was perfectly working, but impossible to access the back office. I can now access after applying this : 1013 -> 1016. Hope this will help.

Uninstall and delete this version of autoupgrade module and install previous version 6.3.0 or less you can download it here.

Hello, what is the PS version? When this problem started?

Clear var/cache/*, delete browser cookies, and try in private mode. Check that PS_SHOP_DOMAIN and PS_SHOP_DOMAIN_SSL match your exact URL. In database set PS_COOKIE_CHECKIP to 0 to avoid IP conflicts. If it still fails, switch to Classic theme and disable non-native modules to test.

Hi, I hope this helps, basically When you ran it in the back office, the DB backup failed with a “memory exhausted” error. When you ran it from CLI, the same backup step failed trying to create the compressed .bz2 file. In both cases the upgrade never started, because the module refuses to continue if its own backup didn’t complete. Since you’re already making backups at the hosting level (which is the safer way anyway), you don’t need PrestaShop’s built-in backup here. You can disable it: Option 1: Back office In Advanced Parameters → 1-Click Upgrade → Options, simply uncheck “Backup my database” (and even “Backup my files” if you don’t need those). Then run the upgrade from the admin again. The upgrade will proceed without trying to dump your large database. Option 2: CLI If you prefer the command line, you can achieve the same thing: On legacy CLI (cli-upgrade.php): edit adminXYZ/autoupgrade/config.json and set "skip_backup": 1. On the newer Update Assistant (bin/console): just run php bin/console update:start without calling backup:create. for db clean up here is guide your can follow.

Hola @davidescudero.com, Sobre las opciones para gestionar Verifactu con un módulo y sin tener los riesgos que mencionas arriba. La mejor opción sería que la FNMT (o alguna entidad autorizada) pudiera emitir certificados "scoped limited". En este caso podrías generarte un nuevo certificado de representante solo para la firma de facturas e instalar este en tu servidor. No se podría usar el certificado para nada más. El problema es que esta opción no está disponible para los certificados emitidos en España. Los certificados emitidos para persona jurídica, física o representante, se pueden usar para cualquier cosa.... Entre otras opciones, si no quieres utilizar un servicio de suscripción Verifactu y no quieres instalar el certificado/clave privada en tu servidor para evitar los problemas de seguridad, otra opción que queda es utilizar un servicio de "firma en la nube". Carmerfirma (que es CA autorizado para emitir certificados válidos de persona jurídica, física, etc... en España igual que la FNMT) tienen un servicio con un coste de 79 € cada 3 años: https://www.camerfirma.com/certificados-digitales/certificado-digital-firma-remota/ La FNMT también tiene un servicio similar pero no he encontrado información pública sobre los precios. Un módulo Prestashop podría gestionar la preparación del documento, cálculo del hash, solicitud de firma a Camerfirma, y envío por los webservices de la AEAT. El tema es que también requiere un servicio de suscripción para la firma en la nube, pero supongo que el coste es mucho menor (no lo he mirado realmente) que los servicios de suscripción Verifactu que están saliendo...

Hola, ¿Habéis encontrado algún modulo que sirva? Estoy teniendo la misma dificultad que vosotros... Yo he encontrado esta web https://verifactuprestashop.com pero no tiene link al módulo ni pone precio. ¿Alguien ha trabajado con ellos? Espero que salga una solución pronto. Saludos, David.

Check for oldest https://github.com/202-ecommerce/stripe_official/releases?page=3

Hello to all, I introduce myself as a member of the Friend of Presta association and I think many people on this forum already know me. Since a few months the FoP association has created a security cell that analyses the PrestaShop ecosystem. We have identified hundreds of modules with security holes. You can already find the list of modules for which we have already created CVEs by respecting a timeline for the authors of these modules. You can subscribe to the rss feed here this list is updated every Tuesday and Thursday. I will try to add on this post all the new vulnerabilities we publish.

This is known issue since Feburary, lear more here. Tip: you can delete the folders (dev/prod) as PS will recreate them.

I’m not sure what you’re asking. If your server doesn’t support exec and PrestaShop uses it, as clearly shown in the error you shared, then it simply won’t work. Unless you contact your hosting provider and they change the server settings. You can clear the cache manually by deleting the contents of these folders: var/cache/dev/* var/cache/prod/* You could also rewrite the function in PrestaShop, but that doesn’t make sense in the long run.

Bu modülü ben yeniden düzenlemiştim, deneyebilirsiniz

The API changed for a long time you should use the following in method WebServiceCheck() $url='https://ec.europa.eu/taxation_customs/vies/rest-api/ms/'.urlencode($prefix).'/vat/'.urlencode($vat);

Hi, I am getting messages about Polyfill as malware and I have been looking inside the archives and this software is completely full of Polyfill, I don't know how it is used or what it is used for and/or if they plan to replace it or remove it before we are affected by Mr Google blocks or if nothing is really going to happen. I would appreciate your comments, please.

@SchmidtSon I had a similar problem, on Prestashop 1.7.7.8 . I solved it by editing the file classes/hook.php, in lines 483 - 484: $results = Db::getInstance(_PS_USE_SQL_SLAVE_)->executeS( 'SELECT h.id_hook, h.name as h_name, title, description, h.position, hm.position as hm_position, m.id_module, m.name, active Just changed active by h.active, like this: $results = Db::getInstance(_PS_USE_SQL_SLAVE_)->executeS( 'SELECT h.id_hook, h.name as h_name, title, description, h.position, hm.position as hm_position, m.id_module, m.name, h.active

I finally found a solution for this. The pull request, which integrated this message, helped me find out: https://github.com/PrestaShop/PrestaShop/pull/16063 You can simply add a translation for the according text block. In the back office, go to Design -> E-Mail-Themes and click "Translate E-Mails" for your language. There, search for "(waiting for validation)" and add your translation. If you want to remove the message completely, simply type a single space character into the translation field. In my case, the message is gone from the order_conf e-mail then.

Hi moy, You could do something like this: Edit file (or better, override): controllers/front/ProductController.php: add the following code: (find black code, add red code): $default_carrier =new Carrier((int)Configuration::get('PS_CARRIER_DEFAULT')); $carrier_zones = $default_carrier->getZones(); if (isset($carrier_zones) && !empty($carrier_zones)) { $first_carrier_zone = $carrier_zones[0]['id_zone']; $delivery_price = $default_carrier->getDeliveryPriceByWeight($this->product->weight, $first_carrier_zone); } else $delivery_price = 'not found'; $this->context->smarty->assign(array( 'stock_management' => Configuration::get('PS_STOCK_MANAGEMENT'), 'customizationFields' => ($this->product->customizable) ? $this->product->getCustomizationFields($this->context->language->id) : false, 'accessories' => $this->product->getAccessories($this->context->language->id), 'return_link' => $return_link, 'product' => $this->product, 'product_manufacturer' => new Manufacturer((int)$this->product->id_manufacturer, $this->context->language->id), 'token' => Tools::getToken(false), 'features' => $this->product->getFrontFeatures($this->context->language->id), 'attachments' => (($this->product->cache_has_attachments) ? $this->product->getAttachments($this->context->language->id) : array()), 'allow_oosp' => $this->product->isAvailableWhenOutOfStock((int)$this->product->out_of_stock), 'last_qties' => (int)Configuration::get('PS_LAST_QTIES'), 'HOOK_EXTRA_LEFT' => Hook::exec('displayLeftColumnProduct'), 'HOOK_EXTRA_RIGHT' => Hook::exec('displayRightColumnProduct'), 'HOOK_PRODUCT_OOS' => Hook::exec('actionProductOutOfStock', array('product' => $this->product)), 'HOOK_PRODUCT_ACTIONS' => Hook::exec('displayProductButtons', array('product' => $this->product)), 'HOOK_PRODUCT_TAB' => Hook::exec('displayProductTab', array('product' => $this->product)), 'HOOK_PRODUCT_TAB_CONTENT' => Hook::exec('displayProductTabContent', array('product' => $this->product)), 'display_qties' => (int)Configuration::get('PS_DISPLAY_QTIES'), 'display_ht' => !Tax::excludeTaxeOption(), 'currencySign' => $this->context->currency->sign, 'currencyRate' => $this->context->currency->conversion_rate, 'currencyFormat' => $this->context->currency->format, 'currencyBlank' => $this->context->currency->blank, 'jqZoomEnabled' => Configuration::get('PS_DISPLAY_JQZOOM'), 'ENT_NOQUOTES' => ENT_NOQUOTES, 'outOfStockAllowed' => (int)Configuration::get('PS_ORDER_OUT_OF_STOCK') , // <- add comma here! 'delivery_price' => $delivery_price )); Then, in themes/<your theme folder>product.tpl, add this code wherever you need it: {if $delivery_price} <div class = "estimated_delivery_price"> {l s='Initial delivery costs estimate :'}{convertPrice price=$delivery_price} </div> {/if} Result: To modify the decoration of the price or text, you can add some css code to themes/<your theme folder>/css/global.css, like: .estimated_delivery_price { font-size: 18px; } Hope that does the trick, pascal. ------------ P.S. the initial suggestion given above: Carrier::getDeliveryPriceByWeight($weight, $id_zone) Doesn't work directly, as the function is not declared 'static', so therefore we first have to create an instance (object) : $default_carrier =new Carrier((int)Configuration::get('PS_CARRIER_DEFAULT')); and then use this instance (i.e. object) to get to the function: $default_carrier->getDeliveryPriceByWeight(...) FYI :-)

and what about preferences > store contacts? this is the right way to change shop name