El Patron

Hi, You can and should know how to use Chrome Dev Tools to View and change CSS, it will also tell you which .css file in your PrestaShop needs to be updated. https://developer.chrome.com/docs/devtools/css To run PrestaShop on default template, it's not the best...but allows new prestashop users to build their catalogs. Typically after catalog is built and tested the next step is to get a 3rd party theme with design choices that fit your product vertical. But it is possible to update classic theme if you have right tools and are willing to learn how to update .css.

For newbies, really for anyone without a lot of experience, DO NOT USE PS9 yet. PrestaShop has ruined so many shops with their sloppy new releases, shame on them! Just delete all the files/db for ps9, install PS8.2.3 and yes you will have to start over. It's a crying shame, every new major release is the same every time all the way back to 1.4, 1.5, 1.6, 1.7, 8 and NOW 9

Où placer vos redirections personnalisées L’emplacement sûr est le suivant : Placez vos règles de redirection juste après RewriteEngine On, mais avant le bloc généré par PrestaShop. Assurez-vous qu’elles soient en dehors de la section PrestaShop (au-dessus de la ligne # ~~start~~). Exemple de mise en page : <IfModule mod_rewrite.c> <IfModule mod_env.c> SetEnv HTTP_MOD_REWRITE On </IfModule> RewriteEngine On # --- Redirections canoniques personnalisées (protégées de la régénération) --- RewriteCond %{HTTPS} off RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] RewriteCond %{HTTP_HOST} !^www\.monsite\.fr$ [NC] RewriteRule ^ https://www.monsite.fr%{REQUEST_URI} [R=301,L] # --- Début du bloc généré par PrestaShop --- # ~~start~~ Ne pas supprimer ce commentaire, Prestashop régénérera automatiquement les lignes ci-dessous... RewriteRule . - [E=REWRITEBASE:/] RewriteRule ^api(?:/(.*))?$ %{ENV:REWRITEBASE}webservice/dispatcher.php?url=$1 [QSA,L] RewriteRule ^upload/.+$ %{ENV:REWRITEBASE}index.php [QSA,L] ... # ~~end~~ enable 301 redirection to canonical URL https://app.screencast.com/LdbL8t7rjvZqM

Oui, exactement — utiliser le www reste un très bon choix. Cela permet de garder le domaine racine libre pour d’autres services (mail, ftp, cdn, etc.) et d’éviter des problèmes de partage de cookies si vous développez des sous-domaines plus tard. Du point de vue de PrestaShop, l’important n’est pas de choisir www ou non-www, mais de faire un choix et de l’appliquer de manière cohérente. Concrètement : Dans le Back Office (Paramètres de la boutique > Trafic & SEO) définissez le domaine et le domaine SSL sur www.example.com et activez la redirection vers l’URL canonique en 301. Au niveau du serveur, ajoutez une redirection dans le fichier .htaccess afin que tout ce qui arrive sans www soit envoyé vers https://www.example.com. RewriteEngine On RewriteCond %{HTTPS} off RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC] RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L] De cette façon, toutes les URL pointent vers un seul hôte canonique, ce qui est mieux pour le SEO, les statistiques et pour éviter le contenu dupliqué. Et au final, le meilleur SEO reste d’offrir la meilleure expérience visiteur : un affichage immédiat above the fold des informations essentielles dont l’utilisateur a besoin. Le reste du “SEO” ressemble souvent plus à du vaudou.

in modules folder rename hicookielaw to _hicookielaw

Hi, here is a guideline that I follow for every shop I work with. prestashop_performance_practices_branded.pdf

La suppression de PrestaShop Checkout était une décision judicieuse, car ce module est réputé pour son instabilité. Afin de continuer à traiter les paiements par carte bancaire, il est nécessaire d’installer un module de passerelle de paiement dédié. Stripe constitue une excellente option (particulièrement répandue aux États-Unis), mais je vous invite à consulter attentivement la place de marché PrestaShop Addons afin d’identifier la solution la plus adaptée à vos besoins spécifiques. Pour être tout à fait transparent : il m’arrive d’avoir recours à un traducteur automatique, et je me réserve naturellement la liberté de contribuer aux discussions, qu’elles soient en français ou dans une autre langue. Je précise également que je ne suis pas ici pour chercher du travail ou promouvoir des services — je partage simplement mon expérience dans un esprit constructif et bienveillant.

Well, the French market to the French, loool. I’m the same—I market in English. In Chrome you can just right-click (if your mouse has a right-click button) and choose “Translate” to view any page in your language. Yes, translators can be expensive, and for some shops that cost is prohibitive. But there are plenty of PrestaShops generating enough sales that they can budget for professional translations. Here’s a link to some translation modules (though they do look a bit pricey): https://addons.prestashop.com/en/search?search_query=translation+module Another option is simply using AI for translations. For example, you could export the required data with SQL, run it through AI to translate, then reupload it. First, you’d need to add the translation pack. I’d recommend testing this on a staging copy first—but it seems very doable. translated to spanish via chatgpt Bueno, el mercado francés para los franceses, loool. Yo igual: hago marketing en inglés. En Chrome puedes hacer clic derecho (si tu ratón tiene botón derecho) y elegir “Traducir” para ver cualquier página en tu idioma. Sí, los traductores pueden ser caros, y para algunas tiendas ese costo es prohibitivo. Pero hay muchas PrestaShops que generan suficientes ventas como para presupuestar traducciones profesionales. Aquí tienes un enlace a algunos módulos de traducción (aunque se ven un poco caros): https://addons.prestashop.com/en/search?search_query=translation+module Otra opción es simplemente usar IA para las traducciones. Por ejemplo, podrías exportar los datos necesarios con SQL, pasarlos por IA para traducirlos y luego volver a subirlos. Primero tendrías que añadir el paquete de traducción. Recomiendo probarlo en una copia de pruebas (staging) primero, pero parece muy factible.

You should consider using latest stable prestashop 8 to avoid using very early versions of PS9. I have never used a free version from Leo Themes but historically had good success with the paid themes. https://www.leotheme.com/prestashop/themes/free-prestashop-themes.html Have fun!

Bonjour, Oui, ce problème a déjà été signalé avec le module ps_checkout sur PrestaShop 1.7.x. Voir par exemple : discussion sur le forum PrestaShop « Module ps_checkout – Expected an order id to be passed » https://www.prestashop.com/forums/topic/1082720-module-ps_checkout-expected-an-order-id-to-be-passed/ et le ticket GitHub « Error in Checkout after Upgrade from 1.7.6.7 to 1.7 » https://github.com/PrestaShop/PrestaShop/issues/22353 La plupart des correctifs consistaient à vérifier la version de PHP (1.7.7.x fonctionne avec PHP 7.1–7.3), à réinstaller ps_account + ps_checkout sur la branche 1.7, à vider le cache et à consulter prod.log pour identifier précisément l’erreur. J’espère que cela vous aidera.

SEO is dead — long live visitor experience. Search engines no longer reward tricks or keyword stuffing. They reward how real visitors use your site. For large catalogs this means: Keep menus simple — send visitors to category pages where faceted filters make product discovery easy. Ensure speed and above-the-fold content so users see what they need right away. Add instant checkout options (Amazon Pay, Apple Pay, PayPal) and seamless cart access. Use meta titles/descriptions only to improve click-through rates in search results — they don’t drive ranking. Sitemaps are no longer essential. Search engines can crawl and discover content through internal links. They’re useful for large or complex sites, but not the foundation of SEO anymore. In today’s environment, visitor experience is the strongest SEO signal. Google tracks engagement — if your site is fast, simple, and intuitive, rankings follow.

https://devdocs.prestashop-project.org/9/basics/keeping-up-to-date/update/update-from-the-back-office/

share with community what type of environment you need to support, i.e. for multiple developers? think github...and connect that to a staging machine on hosting, or docker...but if you share what your platform requirements are I'm sure the new generation of PrestaShop enthusiasts can provide good feedback.

PS 8.x sits on Symfony and loads a lot more PHP files than PS 1.6 did. On Windows stacks (WAMP/XAMPP) that file-I/O is notoriously slow, especially when antivirus scans each read. That can easily turn a ~0.5s prod request into 7–10s locally. Make sure Xdebug is fully disabled/uninstalled for normal runs. Many WAMP/XAMPP builds enable it by default, and even when your IDE isn’t “listening,” it can 10× slow PHP. Remove/disable the extension and restart Apache/PHP. Enable OPcache and verify it’s actually working (info.php or phpinfo in WAMP/XAMPP). Without OPcache, every request recompiles heaps of PHP files = pain. I stopped using localhost after PrestaShop 1.4 — just too slow, and that’s even on a really fast computer. These days I always build on hosting, usually on a subdomain. There are a lot of tweaks you can do to speed up localhost, but if you don’t already know them it’s usually faster and easier to just use real hosting space.

Hello, this issue (“Invalid token” in Back Office with load balancer) is normally caused by a combination of session handling, IP checks, and proxy headers. Here’s a step-by-step checklist: 1) enable sticky sessions or shared sessions o on your load balancer, turn on stickiness/persistence o or configure php sessions to be stored in a shared service like redis, memcached, or database 2) disable cookie ip check in back office o go to advanced parameters → administration → “check the cookie’s ip address” → set to no o if you cannot stay logged in long enough, run this sql: update ps_configuration set value='0' where name='PS_COOKIE_CHECKIP'; (replace ps_ with your table prefix) 3) configure trusted proxies in prestashop/symfony o add your load balancer ip(s) to the trusted_proxies setting o this allows prestashop to trust x-forwarded-for and x-forwarded-proto headers 4) forward correct headers from load balancer o make sure the balancer sends: – x-forwarded-proto https – x-forwarded-for – x-forwarded-host o in apache you can add: SetEnvIfNoCase X-Forwarded-Proto https HTTPS=on o in nginx: proxy_set_header X-Forwarded-Proto https; 5) check shop domain/ssl settings o in ps_shop_url and in back office → traffic & seo, make sure domain and domain_ssl match the public url through the balancer clear all caches o delete var/cache/* in prestashop o clear php opcache if enabled o flush any proxy or load balancer cache with one or more of these changes, the invalid token and login loop should be resolved.