Szacowana data dostawy

Checkout Revolution wyświetla opcje wysyłki udostępniane przez moduły przewoźników, w tym wszelkie informacje o czasie dostawy, które dostarczają. Jeśli Twój moduł przewoźnika zawiera szacowane daty dostawy, pojawią się one w formularzu zamówienia. Sam moduł checkout nie oblicza dat dostawy — ta logika należy do modułów wysyłkowych/przewoźników.

Learn more in our one-page checkout guide.

OPcache to rozszerzenie PHP, które przechowuje skompilowany kod PHP w pamięci, dzięki czemu PHP nie musi go rekompilować przy każdym żądaniu. Zdecydowanie warto go włączyć — może poprawić wydajność PrestaShop o 30–50% bez żadnych negatywnych skutków na produkcji. Większość hostingodawców ma go domyślnie włączonego. Ważne ustawienie to opcache.validate_timestamps: ustaw na 1 w środowisku deweloperskim, ale wiele serwerów produkcyjnych ustawia go na 0 dla maksymalnej wydajności (co oznacza, że musisz ręcznie zresetować OPcache po wdrożeniu zmian w kodzie).

See our full guide on PHP optimization

Why Regular Technical Audits Matter

PrestaShop stores degrade over time. Modules get installed and forgotten. PHP versions fall behind. Error logs fill up with warnings that nobody reads. Database tables grow bloated with abandoned cart data and expired sessions. Security patches go unapplied. Each of these issues is small on its own, but together they compound into slow page loads, security vulnerabilities, and eventually downtime or data loss.

The problem is that most store owners only discover these issues when something breaks. A customer complains about slow checkout. Google drops your rankings because your site fails Core Web Vitals. Or worse, you discover your admin panel is compromised because you never changed the default admin path and your PHP version had a known vulnerability.

A 30-minute technical health audit, performed monthly, prevents all of this. It is not a deep dive into every configuration setting. It is a focused checklist that catches the most common and most dangerous issues before they become emergencies. This guide walks through each check with approximate time estimates, giving you a repeatable process you can follow every month.

Check 1: PHP Version and Configuration (3 Minutes)

PHP is the engine that runs PrestaShop, and running an outdated version is both a performance and security risk. PHP versions receive active support for two years and security fixes for one additional year after that. After that, known vulnerabilities go unpatched.

Checking Your PHP Version

Go to your PrestaShop back office and navigate to Advanced Parameters > Information. The PHP version is listed in the Server Information section. Alternatively, you can check in your hosting control panel (cPanel, Plesk, or similar).

As of 2026, the actively supported PHP versions are 8.2, 8.3, and 8.4. If you are running PHP 8.1 or older, upgrading should be a priority. PrestaShop 8.x requires PHP 7.2 or later but performs significantly better on PHP 8.1 and above. PrestaShop 1.7.x supports PHP 7.1 through 8.1, depending on the specific version.

Key PHP Settings to Verify

While on the Information page, check these PHP configuration values:

memory_limit should be at least 256M for PrestaShop. If it is lower, you may experience white pages or incomplete operations when handling large catalogs or generating reports.

max_execution_time should be at least 300 (5 minutes). Lower values can cause timeouts during import operations, cache rebuilds, and module installations.

upload_max_filesize and post_max_size should be at least 16M, or higher if you regularly upload large product images or import files.

OPcache should be enabled. OPcache stores compiled PHP code in memory, dramatically reducing page load times. If it is disabled, your store is running significantly slower than it could be.

Check 2: Error Log Review (4 Minutes)

Error logs tell you what is breaking behind the scenes, even when the front end appears to work normally. Warnings and notices that do not crash the page still indicate problems that waste server resources and can escalate into real failures.

PrestaShop Logs

In the back office, go to Advanced Parameters > Logs. Sort by date (newest first) and scan the last week of entries. Focus on Severity 3 (Error) and Severity 4 (Critical) messages. Common critical errors include database connection failures, file permission errors, module exceptions, and payment processing errors.

If you see repeated errors from the same module, that module has a bug that needs attention. If you see database errors, your database server may be running out of connections or disk space.

PHP Error Log

The PHP error log location depends on your hosting environment. Common locations include /var/log/php/error.log, /var/log/apache2/error.log, or a path specified in your hosting control panel. Check the last 100 lines for fatal errors, warnings, and deprecation notices.

Deprecation notices are especially important to track. They warn you that a function or feature your code uses will be removed in a future PHP version. Addressing these now prevents your store from breaking when you upgrade PHP.

What to Do with Errors

Do not try to fix every error during the audit. The audit is for identification. Create a list of the most critical and most frequent errors, prioritized by severity. Fatal errors and critical errors need immediate attention. Warnings should be addressed within the month. Notices and deprecation warnings can be scheduled for your next maintenance window.

Check 3: Module Audit (5 Minutes)

Modules are the most common source of security vulnerabilities, performance problems, and compatibility issues in PrestaShop. A quick module audit identifies dead weight and potential risks.

Identifying Unused Modules

Go to Modules > Module Manager. Look for modules that are installed but disabled. These modules still have files on your server and potentially have database tables, but they are not serving any purpose. They increase your attack surface (a vulnerability in a disabled module's files can still be exploited) and slow down backups.

For each disabled module, decide whether you will use it again. If not, uninstall it completely (not just disable). Uninstalling removes the module's database tables and configuration. After uninstalling, also delete the module's directory from /modules/ to remove its files from the server entirely.

Checking for Updates

In the Module Manager, look for modules with available updates. Outdated modules are a primary vector for security exploits. Update notifications appear as badges on the module listing. Prioritize updates for modules that handle sensitive data: payment modules, customer account modules, and any module that processes forms.

Before updating any module, check the changelog to understand what changed. If the update includes security fixes, apply it immediately. If it is a feature update, test it on a staging environment first if possible.

Counting Total Modules

Check how many modules are installed in total. PrestaShop ships with many modules by default, and stores accumulate more over time. Each active module adds hooks that execute on every page load, increasing response time. If you have more than 80 to 100 active modules, review the list critically. Many default PrestaShop modules (like the social sharing buttons, customer data privacy notice, and statistics modules) can be disabled if you do not use them, resulting in measurable performance improvement.

Check 4: Database Health (4 Minutes)

Your PrestaShop database grows continuously. Every customer visit creates session data. Every abandoned cart stays in the database. Every log entry accumulates. Over months and years, this bloat slows down queries and increases backup times.

Checking Database Size

In your hosting control panel (cPanel > phpMyAdmin, for example), check the total database size. A healthy PrestaShop database for a small to medium store (under 10,000 products) should be under 500 MB. If yours is significantly larger, data bloat is likely the cause.

Identifying Large Tables

In phpMyAdmin, click on your database and sort tables by size. The usual culprits for bloat are: ps_connections and ps_connections_page (visitor tracking data that can grow to gigabytes), ps_log (PrestaShop's internal log table), ps_mail (email history), ps_cart and ps_cart_product (abandoned cart data), ps_guest (anonymous visitor records), and ps_pagenotfound (404 error tracking).

These tables can be safely cleaned of old data. For example, you do not need connection data from two years ago. PrestaShop has a built-in feature for cleaning some of these tables: go to Advanced Parameters > Administration and look for the "Automatically check for module updates" and data cleanup options. For more thorough cleanup, the free PrestaShop Cleaner module can purge old statistics data, abandoned carts, and expired sessions.

Checking for Missing Indexes

While in phpMyAdmin, check the structure of your most important tables (ps_product, ps_category_product, ps_stock_available) and verify that indexes exist on the columns used in search and filtering. Missing indexes cause slow queries that affect page load times. However, do not add indexes without understanding the trade-offs, as each index slows down write operations slightly.

Check 5: Security Basics (5 Minutes)

Security vulnerabilities in PrestaShop stores are actively exploited. Automated scanners continuously probe the internet for vulnerable installations. Five minutes of security checks can prevent a catastrophic breach.

Admin Panel URL

Your admin panel should not be accessible at a predictable URL like /admin/ or /backoffice/. PrestaShop generates a randomized admin directory name during installation (like /admin738xyz/). Verify that your admin URL is still randomized by checking the admin directory name on your server. If someone has renamed it to something guessable, rename it back to a random string.

SSL Certificate

Your entire store must run on HTTPS. Check by visiting your store's URL with http:// and verifying that it redirects to https://. In the back office, go to Shop Parameters > General and verify that "Enable SSL" and "Enable SSL on all pages" are both set to Yes.

Also check your SSL certificate's expiration date. Let's Encrypt certificates expire every 90 days and should auto-renew, but auto-renewal fails silently more often than you would expect. Click the padlock icon in your browser's address bar to see the certificate details and expiration date. If it expires within the next 30 days, verify that auto-renewal is configured and working.

File Permissions

Incorrect file permissions are a security risk. On Linux servers, your PrestaShop files should generally be owned by the web server user (typically www-data or apache) and have these permissions: directories at 755 (owner can read/write/execute, others can read/execute), files at 644 (owner can read/write, others can read only), and configuration files like config/settings.inc.php or app/config/parameters.php at 640 or 440 (restricted read access).

Check a few critical files to verify permissions are not too open. No file should be 777 (world-writable). If you find 777 permissions, fix them immediately. They allow any user on the server to modify those files.

Debug Mode

Verify that debug mode is disabled on your production store. Debug mode exposes detailed error messages, file paths, and database queries to visitors, which is valuable information for attackers. Check the file /config/defines.inc.php and ensure _PS_MODE_DEV_ is set to false. In PrestaShop 8.x, also check the .env file for the APP_DEBUG setting.

Known Vulnerabilities

Check whether your PrestaShop version has known security vulnerabilities. Visit the PrestaShop security advisories page and compare the listed versions with yours. If your version is affected by any advisory that you have not patched, prioritize applying the fix.

Check 6: Performance Quick Test (4 Minutes)

Performance directly affects conversion rates. Every additional second of page load time reduces conversions measurably. A quick performance test identifies major bottlenecks.

Running a Lighthouse Audit

Open Google Chrome, navigate to your store's homepage, open Chrome DevTools (F12), and click the Lighthouse tab. Run an audit for Performance, Best Practices, and SEO on a Mobile device. The test takes about 30 seconds.

Focus on the Performance score. A score below 50 indicates serious performance problems. Between 50 and 89 means there is room for improvement. Above 90 is good. The audit report shows specific issues and estimates of how much time each fix would save.

Key Metrics to Check

From the Lighthouse report, pay attention to Largest Contentful Paint (LCP), which measures how long it takes for the main content to appear. It should be under 2.5 seconds. First Input Delay (FID) or Interaction to Next Paint (INP) measures responsiveness. It should be under 200 milliseconds. Cumulative Layout Shift (CLS) measures visual stability. It should be under 0.1.

If LCP is high, the most common causes in PrestaShop are unoptimized images (large product images served without compression or proper sizing), slow server response time (check your hosting plan and database performance), render-blocking CSS and JavaScript (disable unnecessary modules that add their assets to every page), and disabled caching (Smarty cache and CCC should be enabled in production).

Checking Cache Configuration

In the back office, go to Advanced Parameters > Performance. Verify these settings: Smarty cache should be Yes with the cache type set to "File". CCC (Combine, Compress, Cache) should have CSS and JavaScript minification and combination enabled. Template compilation should be set to "Recompile templates if the files have been updated" (not "Force compilation" which is for development only).

If any of these are misconfigured, fixing them provides an immediate and noticeable performance improvement.

Check 7: SEO Basics (3 Minutes)

Technical SEO issues prevent search engines from properly crawling and indexing your store. A few quick checks catch the most impactful problems.

Robots.txt

Visit yourdomain.com/robots.txt in your browser. Verify that it exists and contains sensible rules. PrestaShop generates a robots.txt file automatically. Check that it is not blocking important pages. Your product pages, category pages, and CMS pages should not be disallowed. Common mistakes include blocking all URLs with parameters (which blocks filtered category pages and search results) and blocking the /modules/ directory (which can prevent CSS and JavaScript from being loaded by search engine renderers).

Also verify that the robots.txt includes a sitemap directive pointing to your XML sitemap: Sitemap: https://www.yourdomain.com/1_index_sitemap.xml.

XML Sitemap

Visit the sitemap URL listed in your robots.txt. Verify that it loads, that it is recent (check the last modification dates), and that it contains your important pages. If the sitemap is outdated or empty, regenerate it. If you use the built-in PrestaShop sitemap generator, go to Modules > Module Manager, find the Google Sitemap module, and click Configure to regenerate.

Check the number of URLs in the sitemap against your expected count. If you have 1,000 products but the sitemap only lists 200 URLs, something is wrong with the generation process. Common causes include products being disabled or out of stock being excluded from the sitemap, category visibility settings filtering out products, and the sitemap generation process timing out before completing.

Canonical URLs

Visit a few product pages and view the page source (Ctrl+U). Look for the <link rel="canonical"> tag in the head section. It should contain the clean URL of the current page without any query parameters. If canonical tags are missing or incorrect, duplicate content issues will harm your SEO. In the back office, go to Shop Parameters > Traffic & SEO and verify that "Disable Apache's MultiViews option" and "Disable Apache's mod_security module" are configured correctly for your server.

Check 8: Backup Verification (3 Minutes)

Backups that have never been tested are not backups. They are wishful thinking. This check verifies that your backup system is actually working.

Checking Backup Recency

Determine where your backups are stored. This varies by hosting provider. Check your hosting control panel for backup tools (cPanel has a Backup section, Plesk has a Backup Manager). If you use a backup module in PrestaShop, check its configuration and recent backup log.

Your most recent backup should be no more than 24 hours old for active stores. If your last backup is older than a week, your backup system is either not configured, not running, or failing silently. Fix this immediately. Data loss from a server failure or hack without a recent backup can be business-ending.

Verifying Backup Completeness

A complete PrestaShop backup includes the entire database (all tables, not just product data) and the file system (all PrestaShop files, including uploaded images, module files, and theme customizations). Many backup solutions only capture the database or only capture the files. Verify that yours captures both.

Check the backup file sizes. A database backup for a small store should be at least several megabytes. If it is suspiciously small (under 1 MB for an active store), it might be empty or corrupted. A file backup should include your /img/ directory, which is typically the largest directory and can be several gigabytes for stores with many product images.

Offsite Backup Storage

Backups stored on the same server as your store are vulnerable to the same failures. If the server's hard drive fails, you lose both the store and the backup. Verify that your backups are copied to a separate location: a different server, cloud storage (like Amazon S3, Google Cloud Storage, or Dropbox), or downloaded to a local computer.

Check 9: Update Status (2 Minutes)

Running outdated software is the single most common reason PrestaShop stores get hacked. This final check verifies that your core installation and critical modules are up to date.

PrestaShop Core Version

Check your current PrestaShop version in the back office footer or on the Advanced Parameters > Information page. Compare it against the latest stable release on the PrestaShop website or GitHub releases page. If you are more than one minor version behind (for example, running 8.1.2 when 8.1.5 is available), plan an update. If you are running a version with known security vulnerabilities, update urgently.

PrestaShop major version upgrades (like 1.7 to 8.x) are complex migration projects, not simple updates. Do not attempt these without thorough planning and testing. But minor version updates (like 8.1.2 to 8.1.5) are generally safe and primarily contain security and bug fixes.

Critical Module Updates

Some modules handle sensitive operations and must be kept current: payment modules (any module that processes credit cards, PayPal, or other payment methods), the PrestaShop autoupgrade module (used for core updates), and any security-related modules. Check the Module Manager for available updates on these specific modules.

Your 30-Minute Audit Checklist Summary

Here is the complete checklist with time allocations that you can follow each month:

Minutes 1-3: PHP Version and Configuration. Check PHP version is supported. Verify memory_limit, max_execution_time, and OPcache status.

Minutes 4-7: Error Log Review. Scan PrestaShop logs for Severity 3 and 4 entries. Check PHP error log for fatal errors and deprecation notices. Note recurring errors for follow-up.

Minutes 8-12: Module Audit. Review disabled modules and uninstall unused ones. Check for available updates, especially on payment and security modules. Count total active modules and identify candidates for removal.

Minutes 13-16: Database Health. Check total database size. Identify bloated tables. Plan cleanup of old connection, log, and cart data.

Minutes 17-21: Security Basics. Verify admin URL is randomized. Check SSL certificate and expiration. Verify file permissions. Confirm debug mode is off. Check for known vulnerabilities in your version.

Minutes 22-25: Performance Quick Test. Run Lighthouse audit on homepage. Check LCP, INP, and CLS metrics. Verify cache and CCC settings in back office.

Minutes 26-28: SEO Basics. Check robots.txt for errors. Verify sitemap is current and complete. Spot-check canonical URLs on product pages.

Minutes 29-30: Backup and Updates. Verify backup recency and completeness. Check PrestaShop core and critical module versions against latest releases.

This audit does not fix problems. It identifies them. After completing the checklist, you should have a prioritized list of issues to address. Critical security issues and broken functionality come first. Performance optimizations and cleanup tasks come second. Minor improvements and future planning come third. By performing this audit monthly, you catch problems early, maintain a clear picture of your store's technical health, and avoid the nasty surprises that come from months of neglected maintenance.

Jak dzialaja szablony e-mail PrestaShop

PrestaShop wysyla e-maile transakcyjne w kazdym kluczowym momencie sciezki klienta: utworzenie konta, potwierdzenie zamowienia, powiadomienie o wysylce, reset hasla i inne. Te e-maile sa generowane z plikow szablonow przechowywanych na serwerze i sa w pelni konfigurowalne. Zrozumienie dzialania systemu szablonow to pierwszy krok do tworzenia profesjonalnych, markowych e-maili z potwierdzeniem zamowienia, ktore wzmacniaja tozsamosc Twojego sklepu.

Kazdy e-mail PrestaShop sklada sie z dwoch plikow szablonow: wersji HTML dla klientow pocztowych obslugujecych formatowanie oraz wersji tekstowej (TXT) dla klientow, ktore tego nie obsluguja. Oba pliki musza istniec, aby e-mail zostal wyslany poprawnie. Wersje HTML zobaczy zdecydowana wiekszosc klientow. Wersja TXT sluzy jako rozwiazanie awaryjne i jest rowniez uzywana przez narzedzia dostepnosci oraz niektore firmowe filtry pocztowe.

Szablony e-mail znajduja sie w strukturze katalogow mails/. Dokladna lokalizacja zalezy od tego, czy uzywasz e-maili rdzenia, e-maili nadpisanych przez motyw, czy e-maili specyficznych dla modulow. Zrozumienie tej hierarchii jest kluczowe, poniewaz PrestaShop sprawdza wiele lokalizacji dla kazdego szablonu i uzywa pierwszego znalezionego.

Struktura katalogow szablonow e-mail

PrestaShop organizuje szablony e-mail w specyficznej hierarchii katalogow. Gdy musi wyslac e-mail, przeszukuje te lokalizacje w kolejnosci priorytetu:

Nadpisania na poziomie motywu (najwyzszy priorytet)

Szablony w /themes/twoj-motyw/mails/pl/ (gdzie pl to kod ISO jezyka) maja priorytet nad wszystkimi innymi lokalizacjami. Jesli chcesz dostosowac szablon e-mail bez modyfikowania plikow rdzenia, tutaj powinny trafic Twoje niestandardowe szablony. Takie podejscie przetrwa aktualizacje PrestaShop, poniewaz pliki motywu nie sa nadpisywane podczas aktualizacji rdzenia.

Szablony rdzenia (domyslne)

Domyslne szablony znajduja sie w /mails/pl/ w katalogu glownym PrestaShop. Sa to szablony dostarczane z PrestaShop i uzywane, gdy nie istnieje nadpisanie motywu. Bezposrednia edycja tych plikow dziala, ale nie jest zalecana, poniewaz zmiany zostana utracone po aktualizacji PrestaShop.

Szablony specyficzne dla modulow

Moduly wysylajace wlasne e-maile przechowuja szablony w /modules/nazwa-modulu/mails/pl/. Na przyklad e-maile z powiadomieniami o zamowieniach wysylane przez rdzennie moduly platnosci sa przechowywane w ich odpowiednich katalogach modulow. Mozesz je nadpisac, umieszczajac zmodyfikowane kopie w katalogu mails/ motywu z ta sama nazwa pliku.

Podkatalogi jezykowe

Kazdy katalog mails/ zawiera podkatalogi dla kazdego zainstalowanego jezyka, uzywajac kodu ISO jezyka: en dla angielskiego, fr dla francuskiego, de dla niemieckiego i tak dalej. Gdy PrestaShop wysyla e-mail, uzywa szablonu z katalogu odpowiadajacego preferencji jezykowej klienta. Jesli szablon nie istnieje w jezyku klienta, PrestaShop wraca do jezyka domyslnego.

Anatomia szablonu potwierdzenia zamowienia

E-mail z potwierdzeniem zamowienia to najwazniejszy e-mail transakcyjny wysylany przez Twoj sklep. To plik o nazwie order_conf.html (i towarzyszacy mu order_conf.txt) w katalogu mails. Przyjrzyjmy sie jego strukturze.

Struktura szablonu HTML

Szablony e-mail PrestaShop sa samodzielnymi dokumentami HTML. Nie uzywaja zewnetrznych plikow CSS, poniewaz wiekszosc klientow pocztowych usuwa zewnetrzne arkusze stylow. Wszystkie style musza byc inline CSS. Typowy szablon potwierdzenia zamowienia zawiera nastepujace sekcje:

Dokument zaczyna sie od standardowego doctype HTML i sekcji head. Body zawiera uklad oparty na tabelach (poniewaz klienty pocztowe maja slaba obsluge nowoczesnych metod ukladu CSS jak flexbox i grid). W tym ukladzie znajdziesz sekcje naglowka z logo sklepu, glowny obszar tresci ze szczegolami zamowienia, tabele produktow z kazdym zamowionym produktem, podsumowanie cen z sumami czesciowymi i calkowitymi, informacje o wysylce, szczegoly metody platnosci oraz stopke z danymi kontaktowymi sklepu i informacjami prawnymi.

System zmiennych

PrestaShop uzywa prostego systemu zamiany zmiennych w szablonach e-mail. Zmienne sa ujete w nawiasy klamrowe: {nazwa_zmiennej}. Gdy e-mail jest generowany, PrestaShop zastepuje kazda zmienna jej rzeczywista wartoscia. Szablon potwierdzenia zamowienia uzywa tych kluczowych zmiennych:

{firstname} i {lastname} zawieraja imie i nazwisko klienta. {order_name} to numer referencyjny zamowienia (jak ABCDEF123). {shop_name} to nazwa sklepu skonfigurowana w panelu administracyjnym. {shop_url} to adres URL sklepu. {shop_logo} to sciezka do logo sklepu. {date} to data zamowienia. {payment} to uzyta metoda platnosci. {total_paid} to calkowita zaplacona kwota. {delivery_company} i {delivery_address} zawieraja informacje o przewozniku i adresie dostawy.

Dla listy produktow PrestaShop uzywa specjalnej skladni blokowej. Sekcja elementow produktowych jest opakowana w petle, ktora powtarza sie dla kazdego produktu w zamowieniu: {items} zawiera wstepnie sformatowany HTML dla calej tabeli listy produktow, wlaczajac nazwy produktow, ilosci, ceny i wszelkie szczegoly personalizacji.

Referencja dostepnych zmiennych

Aby zobaczyc wszystkie dostepne zmienne dla konkretnego szablonu e-mail, sprawdz kod PHP wysylajacy e-mail. Dla potwierdzenia zamowienia sprawdz klase PaymentModule (w /classes/PaymentModule.php). Metoda validateOrder() buduje tablice zmiennych szablonu. Kazdy klucz w tablicy odpowiada nazwie zmiennej, ktorej mozesz uzyc w szablonie.

Czesto dostepne zmienne w e-mailach potwierdzenia zamowienia obejmuja: {id_order}, {order_name}, {delivery_block_txt}, {invoice_block_txt}, {delivery_block_html}, {invoice_block_html}, {delivery_company}, {delivery_firstname}, {delivery_lastname}, {delivery_address1}, {delivery_address2}, {delivery_city}, {delivery_postal_code}, {delivery_country}, {delivery_phone}, {invoice_company}, {invoice_firstname}, {invoice_lastname}, {invoice_address1}, {invoice_address2}, {invoice_city}, {invoice_postal_code}, {invoice_country}, {invoice_phone}, {message} i {total_products}.

Personalizacja szablonu potwierdzenia zamowienia

Krok 1: Utworz nadpisanie motywu

Nigdy nie edytuj bezposrednio plikow szablonow rdzenia. Zamiast tego skopiuj szablon do katalogu mails motywu:

Skopiuj /mails/pl/order_conf.html do /themes/twoj-motyw/mails/pl/order_conf.html. Zrob to samo dla order_conf.txt. Jesli katalog mails/pl/ nie istnieje w motywu, utworz go.

Jesli Twoj sklep obsluguje wiele jezykow, skopiuj szablony do kazdego katalogu jezykowego. Twoje angielskie potwierdzenie zamowienia trafia do /themes/twoj-motyw/mails/en/order_conf.html i tak dalej.

Krok 2: Modyfikuj uklad HTML

Otworz szablon HTML w edytorze tekstu (nie w edytorze wizualnym, ktory moze dodac niechciany kod). HTML e-mailowy rozni sie od HTML webowego w kilku waznych aspektach:

Uzywaj tabel do ukladu, nie divow. Klienty pocztowe, szczegolnie Outlook, maja bardzo ograniczona obsluge CSS. Uklad trzech kolumn musi uzywac <table> z trzema elementami <td>, nie kolumn CSS czy flexboxa.

Uzywaj stylow inline na kazdym elemencie. Zamiast <p class="heading"> z oddzielnym arkuszem stylow, uzyj <p style="font-size:18px; font-weight:bold; color:#333333;">. Kazdy stylizowany element potrzebuje wlasnego atrybutu stylu inline.

Ustaw jawne szerokosci na tabelach i komorkach. Klienty pocztowe nie zawsze respektuja szerokosci procentowe. Uzyj stalej szerokosci dla glownej tabeli tresci (600 pikseli to standard) z procentowymi kolumnami wewnetrznymi.

Uzywaj bezpiecznych czcionek webowych. Nie wszystkie klienty pocztowe obsluguja niestandardowe czcionki. Trzymaj sie Arial, Helvetica, Georgia, Times New Roman, Verdana lub Trebuchet MS. Mozesz sprobowac zaladowac niestandardowa czcionke jako fallback, ale zawsze okresl bezpieczna czcionke webowa jako koncowy fallback.

Krok 3: Dodaj swoj branding

Zastap domyslny naglowek PrestaShop brandingiem swojego sklepu. Obejmuje to zazwyczaj aktualizacje logo (zmienna {shop_logo} automatycznie uzywa logo sklepu, ale mozesz chciec specjalnej wersji e-mailowej), zmiane koloru tla naglowka na zgodny z marka, dodanie schematu kolorow marki do naglowkow i linkow oraz dolaczenie sloganu sklepu lub krotkiego komunikatu marketingowego.

Utrzymuj ogolna strukture prosta. Zbyt skomplikowane projekty e-maili rozpadaja sie w roznych klientach pocztowych. Czysty, jednokolumnowy uklad z kolorami marki i logo jest bardziej efektywny i niezawodny niz rozbudowany wielokolumnowy projekt.

Krok 4: Dostosuj tabele produktow

Domyslna tabela produktow w potwierdzeniu zamowienia PrestaShop jest funkcjonalna, ale podstawowa. Mozesz ja ulepszyc, dodajac obrazy produktow (uzyj bezwzglednych URL do obrazow hostowanych na serwerze, nie sciezek wzglednych), dodajac linki do stron produktow, aby klienci mogli latwo zamowic ponownie lub zostawic opinie, dodajac niestandardowe pola jak szacowane daty dostawy lub spersonalizowane wiadomosci, oraz dostosowujac styl tabeli do marki.

Dodajac obrazy produktow, utrzymuj je male (50 do 80 pikseli szerokosci) i zawsze dodawaj atrybut alt. Niektore klienty pocztowe domyslnie blokuja obrazy, a tekst alternatywny zapewnia, ze klienci moga nadal zidentyfikowac produkty.

Dodawanie niestandardowych pol do e-maili zamowien

Domyslne zmienne PrestaShop pokrywaja standardowe informacje o zamowieniu, ale mozesz chciec dolaczyc dodatkowe dane jak zdobyte punkty lojalnosciowe, szacowana date dostawy, spersonalizowane podziekowanie lub rekomendacje produktow powiazanych.

Dodawanie zmiennych przez modul

Najczystszym sposobem dodania niestandardowych zmiennych jest modul podlaczajacy sie do procesu wysylania e-maili. Utworz modul rejestrujacy hook actionEmailSendBefore (dostepny od PrestaShop 1.7.6) lub hook actionGetExtraMailTemplateVars. W handlerze hooka dodaj niestandardowe zmienne do tablicy zmiennych szablonu:

Funkcja hooka otrzymuje tablice zmiennych szablonu przez referencje. Mozesz dodac nowe zmienne do tej tablicy i staja sie one dostepne w szablonie przy uzyciu standardowej skladni {nazwa_zmiennej}. Na przyklad po dodaniu loyalty_points do tablicy w hooku, mozesz uzyc {loyalty_points} w szablonie HTML potwierdzenia zamowienia.

Uzywanie istniejacych danych z bazy

Mozesz pobierac dowolne dane z bazy PrestaShop do zmiennych e-mail. Czeste przyklady obejmuja calkowita liczbe zamowien klienta (aby wyswietlic "Dziekujemy za 5. zamowienie!"), saldo punktow lojalnosciowych klienta, niestandardowe pola produktow przechowywane w cechach lub atrybutach produktow oraz informacje o magazynie lub dostawcy zamowionych produktow.

Konfiguracja wielojezyczna e-maili

Jesli Twoj sklep obsluguje klientow w wielu jezykach, kazdy szablon e-mail potrzebuje wersji dla kazdego jezyka. PrestaShop automatycznie wybiera jezyk na podstawie preferencji klienta, ale musisz dostarczyc szablony.

Tworzenie szablonow specyficznych dla jezyka

Dla kazdego jezyka obslugiwanego przez sklep utworz katalog w folderze mails motywu: /themes/twoj-motyw/mails/en/, /themes/twoj-motyw/mails/fr/, /themes/twoj-motyw/mails/de/ i tak dalej. Skopiuj i przetlumacz kazdy plik szablonu do odpowiedniego katalogu.

Nie uzywaj automatycznego tlumaczenia e-maili transakcyjnych. Te e-maile reprezentuja komunikacje sklepu z klientami, a slabe tlumaczenia podkopuja zaufanie. Kazda wersje jezykowa powinna napisac lub sprawdzic native speaker.

Obsluga jezykow od prawej do lewej

Jesli obslugiwane sa jezyki takie jak arabski lub hebrajski, szablony e-mail potrzebuja wsparcia RTL (od prawej do lewej). Dodaj dir="rtl" do glownego elementu tabeli i dostosuj wyrownanie tekstu oraz padding w stylach inline. Utworz oddzielne szablony dla jezykow RTL zamiast probowac uzywac jednego szablonu dla obu kierunkow.

Formatowanie dat i walut

PrestaShop automatycznie formatuje daty i wartosci walut zgodnie z ustawieniami jezyka i waluty klienta. Zmienne {date}, {total_paid} i inne sformatowane wartosci juz odzwierciedlaja prawidlowa lokalizacje. Jednak jesli dodajesz niestandardowe zmienne z datami lub wartosciami walut, upewnij sie, ze sa prawidlowo sformatowane dla jezyka docelowego.

Konfiguracja SMTP dla niezawodnej dostarczalnosci

Najlepszy szablon e-mail na swiecie jest bezuzyteczny, jesli e-maile nie docieraja do skrzynki odbiorczej. Domyslna konfiguracja e-mail PrestaShop uzywa wbudowanej funkcji PHP mail(), ktora jest nieniezawodna dla e-maili transakcyjnych. Wiekszosc tych e-maili trafia do folderu spam lub jest calkowicie odrzucana przez nowoczesnych dostawcow poczty.

Dlaczego SMTP jest wazne

SMTP (Simple Mail Transfer Protocol) z odpowiednia autoryzacja jest kluczowe dla dostarczalnosci e-maili. Gdy wysylasz e-maile przez funkcje PHP mail(), e-mail pochodzi z adresu IP serwera bez zadnej autoryzacji. Dostawcy poczty jak Gmail, Outlook i Yahoo widza to jako sygnial ostrzegawczy i czesto klasyfikuja takie e-maile jako spam.

Z SMTP e-maile sa wysylane przez uwierzytelniony serwer pocztowy z odpowiednimi rekordami SPF, DKIM i DMARC. To dowodzi serwerom pocztowym, ze e-mail jest legalny i autoryzowany przez Twoja domene.

Konfiguracja SMTP w PrestaShop

Przejdz do Zaawansowane > E-mail w panelu administracyjnym PrestaShop. Zmien metode z "Uzyj funkcji mail() PHP" na "Ustaw wlasne parametry SMTP". Wprowadz dane serwera SMTP: adres serwera, port (typowo 587 dla TLS lub 465 dla SSL), typ szyfrowania, nazwe uzytkownika i haslo.

Popularni dostawcy SMTP dla PrestaShop obejmuja Gmail SMTP (smtp.gmail.com, port 587, TLS, wymaga hasla aplikacji przy wlaczonym 2FA), Amazon SES (przystepny cenowo dla duzych wolumenow), SendGrid (hojny darmowy plan), Mailgun (przyjazny dla programistow z dobrym logowaniem) oraz serwer SMTP Twojego dostawcy hostingu (sprawdz ustawienia u swojego hosta).

Testowanie konfiguracji SMTP

Po skonfigurowaniu SMTP uzyj przycisku "Wyslij testowy e-mail" na dole strony konfiguracji e-mail. Wprowadz wlasny adres e-mail i sprawdz, czy testowy e-mail dotarl do skrzynki (nie do spamu). Jesli testowy e-mail nie dotarl, sprawdz dane SMTP, upewnij sie, ze serwer moze polaczyc sie z serwerem SMTP na skonfigurowanym porcie (niektore firmy hostingowe blokuja porty wychodzace 25 i 587) oraz sprawdz, czy dostawca SMTP wymaga okreslonych ustawien bezpieczenstwa.

Rekordy SPF, DKIM i DMARC

Dla maksymalnej dostarczalnosci skonfiguruj te rekordy DNS dla swojej domeny. SPF (Sender Policy Framework) okresla, ktore serwery sa uprawnione do wysylania e-maili w imieniu domeny. DKIM (DomainKeys Identified Mail) dodaje podpis cyfrowy do e-maili potwierdzajacy, ze zostaly wyslane z Twojej domeny. DMARC (Domain-based Message Authentication, Reporting, and Conformance) informuje serwery odbiorcze, co robic z e-mailami niespelniajacymi sprawdzen SPF lub DKIM.

Dostawca SMTP dostarczy konkretne rekordy DNS do dodania. Na przyklad przy korzystaniu z SendGrid otrzymasz rekordy SPF i DKIM podczas procesu uwierzytelniania domeny. Dodaj je jako rekordy TXT w ustawieniach DNS domeny.

Testowanie szablonow e-mail

Wysylanie testowych e-maili

PrestaShop nie ma wbudowanej opcji podgladu konkretnych szablonow e-mail. Aby przetestowac szablon potwierdzenia zamowienia, musisz zlozyc prawdziwe zamowienie testowe. Utworz testowe konto klienta, dodaj produkty do koszyka i sfinalizuj zamowienie testowa metoda platnosci. Jesli masz skonfigurowany modul platnosci sandbox, uzyj go. W przeciwnym razie metody platnosci przelewem bankowym lub czekiem pozwalaja sfinalizowac zamowienie bez rzeczywistego przetwarzania platnosci.

Testowanie w roznych klientach pocztowych

Renderowanie e-maili dramatycznie rozni sie miedzy klientami pocztowymi. To co wyglada idealnie w Gmail, moze byc uszkodzone w Outlooku. Przetestuj szablony co najmniej w Gmail (web), Outlook (desktop i web), Apple Mail, Yahoo Mail i przynajmniej jednej mobilnej aplikacji pocztowej. Uslugi jak Litmus lub Email on Acid automatyzuja to testowanie, renderujac e-mail w dziesieciach klientow pocztowych jednoczesnie, ale sa to uslugi platne.

Czeste problemy z renderowaniem

Jesli e-mail wyglada zle w Outlooku, jest to prawie na pewno problem CSS. Outlook uzywa silnika renderowania Microsoft Word dla e-maili HTML, ktory ma niezwykle ograniczona obsluge CSS. Nie obsluguje obrazow tla na komorkach tabeli (uzyj kolorow tla), paddingu na elementach blokowych (uzyj paddingu komorek tabeli), max-width (uzyj stalych szerokosci), margin do centrowania (uzyj align="center" na tabelach) ani CSS float.

Dla responsywnosci mobilnej opakuj tabele tresci w kontener z max-width:600px i dodaj media query w bloku stylu head (obslugiwana przez niektore klienty pocztowe), ktora ustawia szerokosci tabel na 100% na malych ekranach. To nie jest idealny responsywny design, ale zapobiega przewijaniu poziomemu na wiekszosci urzadzen mobilnych.

Czeste problemy i rozwiazywanie

Brakujace obrazy w e-mailach

To najczestszy problem z szablonami e-mail. Obrazy w e-mailach musza uzywac bezwzglednych URL (zaczynajacych sie od https://), nie sciezek wzglednych. Jesli szablon odwoluje sie do /img/logo.png, zmien na https://www.twojadomena.pl/img/logo.png. Zmienna {shop_logo} automatycznie generuje bezwzgledny URL, ale wszystkie obrazy dodane recznie musza uzywac pelnych URL.

Sprawdz rowniez, czy obrazy sa dostepne spoza sieci. Jesli sklep jest za zapora lub uwierzytelnianiem HTTP, klienty pocztowe nie moga zaladowac obrazow. Przetestuj otwierajac URL obrazu w prywatnym oknie przegladarki.

Uszkodzony uklad po edycji

HTML e-mailowy jest kruchy. Pojedynczy niezamkniety tag lub brakujaca komorka tabeli moze zniszczyc caly uklad. Zawsze waliduj HTML po edycji. Policz otwierajace i zamykajace tagi table, tr i td. Kazdy <table> potrzebuje </table>, kazdy <tr> potrzebuje </tr>, a kazdy <td> potrzebuje </td>. Upewnij sie, ze kazdy wiersz w tabeli ma taka sama liczbe komorek (lub uzywa colspan).

Zmienne nie sa zastepowane

Jesli w wyslanych e-mailach widzisz literalny tekst {nazwa_zmiennej} zamiast rzeczywistych wartosci, sprawdz nazwe zmiennej pod katem literowek. Nazwy zmiennych sa wrazliwe na wielkosc liter. Sprawdz rowniez, czy zmienna istnieje dla konkretnego typu e-maila. Nie wszystkie zmienne sa dostepne we wszystkich szablonach. Zmienne specyficzne dla zamowien jak {order_name} sa dostepne tylko w e-mailach zwiazanych z zamowieniami.

E-maile nie sa wysylane

Jesli e-maile nie sa wysylane, sprawdz panel administracyjny PrestaShop w Zaawansowane > E-mail. Mozesz tam zobaczyc dziennik wyslanych e-maili. Jesli dziennik pokazuje bledy, sprawdz konfiguracje SMTP. Jesli zaden e-mail nie pojawia sie w dzienniku, e-mail moze nie byc w ogole wyzwalany. Sprawdz, czy przejscia statusow zamowien sa skonfigurowane do wysylania e-maili (Zamowienia > Statusy > edytuj status > zaznacz "Wyslij e-mail do klienta").

Sprawdz rowniez dziennik bledow PHP serwera pod katem bledow zwiazanych z e-mailami. Czeste problemy to wylaczona funkcja PHP mail() przez dostawce hostingu, bledy uwierzytelniania SMTP z powodu zmienionego hasla oraz problemy z polaczeniem sieciowym miedzy serwerem a serwerem SMTP.

E-maile trafiaja do spamu

Nawet przy poprawnej konfiguracji SMTP e-maile moga nadal trafiac do spamu. Najczestsze przyczyny to brakujace lub nieprawidlowe rekordy SPF/DKIM/DMARC, tresc e-maila wyzwalajaca filtry spam (nadmierne uzycie duzych liter, slowa wyzwalajace spam jak "za darmo" czy "dzialaj teraz", zbyt duzo obrazow z mala iloscia tekstu), wysylanie z adresu IP o zlej reputacji (czeste przy hostingu wspoldzielonym) oraz domena adresu nadawcy niezgodna z domena serwera SMTP.

Najpierw napraw rekordy DNS, potem przejrzyj tresc e-maili. Uzyj narzedzia takiego jak mail-tester.com do analizy e-maili pod katem wyzwalaczy spamu. Wyslij testowy e-mail na podany adres, a otrzymasz szczegolowy raport pokazujacy, co moze powodowac klasyfikacje jako spam.

Nadpisania e-maili specyficzne dla motywu

Niektore motywy PrestaShop zawieraja wlasne szablony e-mail pasujace do designu motywu. Jesli motyw ma szablony w /themes/twoj-motyw/mails/, automatycznie nadpisuja one szablony rdzenia.

Sprawdzanie szablonow e-mail motywu

Sprawdz w katalogu aktywnego motywu, czy istnieje folder mails. Jesli istnieje, motyw dostarcza niestandardowe szablony e-mail. Te szablony zazwyczaj pasuja do schematu kolorow i designu naglowka/stopki motywu, zapewniajac wizualna spojnosc e-maili z witryma sklepu.

Dostosowywanie szablonow e-mail motywu

Jesli motyw dostarcza szablony e-mail, edytuj te zamiast kopiowac z katalogu mails/ rdzenia. Szablony motywu moga uzywac innej struktury HTML lub zawierac dodatkowe CSS specyficzne dla systemu designu motywu. Rozpoczecie od wersji motywu zapewnia wizualna spojnosc.

Synchronizacja szablonow z aktualizacjami motywu

Aktualizujac motyw, sprawdz czy aktualizacja zawiera zmiany w szablonach e-mail. Jesli tak, Twoje dostosowania moga zostac nadpisane. Przed aktualizacja zrob kopie zapasowa dostosowanych szablonow. Po aktualizacji porownaj nowe szablony z kopiami i ponownie zastosuj dostosowania do zaktualizowanych wersji. Jest to zmdune, ale konieczne, aby zachowac zarowno dostosowania, jak i ewentualne ulepszenia lub poprawki dewelopera motywu.

Dobre praktyki dla e-maili potwierdzenia zamowienia

Dobrze zaprojektowany e-mail z potwierdzeniem zamowienia robi wiecej niz tylko potwierdza transakcje. Buduje zaufanie, zmniejsza liczbe zapytan do obslugi klienta i tworzy mozliwosci zaangazowania.

Umiesc wyraznie widoczny numer referencyjny zamowienia na gorze. Klienci potrzebuja tego numeru kontaktujac sie z obsluga lub sledzac zamowienie. Wymien kazdy produkt z nazwa, iloscia, cena i wszelkimi opcjami lub personalizacjami. Dolacz pelne zestawienie sumy czesciowej, kosztow wysylki, podatkow, rabatow i sumy calkowitej. Pokaz adres dostawy, aby klienci mogli go zweryfikowac i natychmiast skontaktowac sie w razie bledu. Podaj uzyta metode platnosci i odpowiednie szczegoly transakcji. Udostepnij link do strony sledzenia zamowienia lub historii zamowien w koncie klienta. Dodaj dane kontaktowe obslugi klienta, aby wiedzieli jak sie skontaktowac w razie problemow.

Utrzymuj design czysty i przyjazny dla urzadzen mobilnych. Ponad polowa wszystkich e-maili jest czytana na urzadzeniach mobilnych. Uzyj jednokolumnowego ukladu, duzego czytelnego tekstu (minimum 14px dla tresci) i przyciskow z odpowiednimi celami dotykowymi (minimum 44px wysokosci). E-mail z potwierdzeniem zamowienia odzwierciedla profesjonalizm sklepu. Zainwestuj czas, aby zrobic to dobrze.

Przekierowania .htaccess w PrestaShop: pisanie regul bez psucia sklepu

Plik .htaccess jest jednym z najpotezniejszych i najbardziej niebezpiecznych plikow w Twojej instalacji PrestaShop. Jeden zle umieszczony znak moze wylaczyc caly Twoj sklep. Ale opanowanie przekierowan .htaccess jest niezbedne dla SEO.

Jak PrestaShop uzywa .htaccess

PrestaShop automatycznie generuje i zarzadza plikiem .htaccess. Gdy wlaczysz przyjazne URLe w ustawieniach SEO i URLe, PrestaShop zapisuje reguly przepisywania miedzy dwoma komentarzami znacznikowymi.

Krytyczna zasada - Nigdy nie dodawaj niestandardowych przekierowan wewnatrz tego bloku. PrestaShop nadpisze je przy nastepnej regeneracji. Umieszczaj swoje reguly PRZED blokiem PrestaShop.

Typy przekierowan

301 - Przekierowanie stale

Uzywaj gdy strona zostala trwale przeniesiona. Wyszukiwarki przenoszą wartosc SEO na nowy URL.

302 - Przekierowanie tymczasowe

Uzywaj gdy strona jest tymczasowo niedostepna.

410 - Gone (Usuniety)

Uzywaj gdy strona zostala trwale usunieta bez zamiennika.

Podstawowa skladnia przekierowan

# Przekieruj pojedynczy URL
Redirect 301 /stara-strona.html https://twojsklep.com/nowa-strona.html

# Przekieruj stary URL produktu
Redirect 301 /stary-produkt.html https://twojsklep.com/pl/nowy-produkt.html

Przekierowania oparte na wzorcach z RewriteRule

RewriteEngine On
RewriteRule ^stary-folder/(.*)$ https://twojsklep.com/nowy-folder/$1 [R=301,L]

Typowe scenariusze przekierowan PrestaShop

Scenariusz 1 - Migracja z innej platformy

# WooCommerce do PrestaShop
RewriteRule ^product/stary-slug/?$ https://twojsklep.com/pl/nowy-url.html [R=301,L]

Scenariusz 2 - Wymuszenie HTTPS i WWW

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Reguly ktore moga zepsuc PrestaShop

Nieskonczone petle przekierowan

Najniebezpieczniejszy blad. Zawsze uzywaj warunkow do zapobiegania petlom.

# NIEBEZPIECZNE
RewriteRule ^(.*)$ https://twojsklep.com/$1 [R=301,L]

# BEZPIECZNE
RewriteCond %{HTTP_HOST} !^www\.twojsklep\.com$ [NC]
RewriteRule ^(.*)$ https://www.twojsklep.com/$1 [R=301,L]

Psucie dostepu do back office

# BEZPIECZNE - wyklucz admin i API
RewriteCond %{REQUEST_URI} !^/admin [NC]
RewriteCond %{REQUEST_URI} !^/api [NC]
RewriteCond %{REQUEST_URI} !^/modules [NC]
RewriteRule ^(.*)$ https://twojsklep.com/pl/$1 [R=301,L]

Bezpieczne testowanie przekierowan

# Zawsze najpierw zrob kopie
cp .htaccess .htaccess.backup

# Testuj z curl
curl -I -L https://twojsklep.com/stara-strona.html

Gdzie umieszczac niestandardowe reguly

# TWOJE PRZEKIEROWANIA TUTAJ (przed blokiem PrestaShop)
Redirect 301 /stara-strona.html https://twojsklep.com/nowa-strona.html

# ~~start~~ Blok PrestaShop
# ... automatycznie generowane reguly ...
# ~~end~~ Blok PrestaShop

Kiedy uzywac modulu

Rozwaz modul przekierowan gdy nietechniczny personel musi zarzadzac przekierowaniami, masz setki przekierowan lub potrzebujesz automatycznego wykrywania 404.

Limitowanie zapytan i ochrona przed botami w PrestaShop bez WAF

Boty stanowia ponad 40% calego ruchu w sieci w 2026. Ten przewodnik pokazuje jak wdrozyc skuteczna ochrone za pomoca konfiguracji serwera, regul .htaccess i lekkich modulow.

Metoda 1 - Rate Limiting Apache .htaccess

RewriteCond %{HTTP_USER_AGENT} (SemrushBot|AhrefsBot|MJ12bot) [NC]
RewriteRule .* - [F,L]

Metoda 2 - Rate Limiting Nginx

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location ~ /login$ {
    limit_req zone=login burst=3 nodelay;
}

Metoda 3 - fail2ban przeciw brute force

fail2ban monitoruje logi serwera i automatycznie blokuje IP z zlosliwym zachowaniem.

Metoda 4 - Rate Limiting na poziomie PHP

Dla hostingu wspoldzielonego: plikowy rate limiter w PHP.

Metoda 5 - robots.txt i kontrola crawlowania

User-agent: SemrushBot
Crawl-delay: 10

Metoda 6 - CAPTCHA na krytycznych formularzach

Dodaj reCAPTCHA na logowaniu, rejestracji, formularzu kontaktowym i newsletterze.

Metoda 7 - Cloudflare Free

Browser Integrity Check, Bot Fight Mode i Rate Limiting sa dostepne za darmo.

Podsumowanie warstw ochrony

Lazy Loading w 2026: co przeglądarki obsługują natywnie, a co wymaga modułu

Lazy loading to technika optymalizacji wydajności, która odwleka ładowanie zasobów poza ekranem do momentu, gdy użytkownik przewinie w ich pobliże. W 2026 roku natywne wsparcie przeglądarek dla lazy loadingu znacząco dojrzało, ale wciąż istnieją scenariusze, w których właściciele sklepów PrestaShop potrzebują dodatkowych modułów lub niestandardowych implementacji. Ten przewodnik wyjaśnia dokładnie, co przeglądarki obsługują samodzielnie, jakie luki pozostają i jak wdrożyć najlepszą strategię lazy loading dla Twojego sklepu PrestaShop.

Co natywny lazy loading obejmuje w 2026

Atrybut HTML loading="lazy" jest teraz obsługiwany przez ponad 95% przeglądarek na świecie. Obejmuje to Chrome (od v77), Firefox (od v75), Safari (od v15.4), Edge (od v79) i wszystkie przeglądarki oparte na Chromium.

Jak działa natywny lazy loading

Dodanie loading="lazy" do tagu <img> lub <iframe> mówi przeglądarce, aby odroczyła ładowanie tego zasobu do momentu, gdy znajdzie się w określonej odległości od viewportu.

<img src="obraz-produktu.jpg" 
     loading="lazy" 
     width="800" 
     height="600" 
     alt="Nazwa produktu">

Co przeglądarki obsługują natywnie

Czego przeglądarki NIE obsługują

Implementacja natywnego lazy loadingu w PrestaShop

Dla motywów PrestaShop 8.x i 9.x

Nowoczesne motywy PrestaShop (jak Hummingbird dla PS 9) często zawierają natywny lazy loading domyślnie. Aby zweryfikować lub dodać go do swojego motywu, edytuj pliki szablonów.

{* Przed - bez lazy loadingu *}
<img src="{$product.cover.bySize.home_default.url}" 
     alt="{$product.name}">

{* Po - z natywnym lazy loadingiem *}
<img src="{$product.cover.bySize.home_default.url}" 
     loading="lazy" 
     width="{$product.cover.bySize.home_default.width}"
     height="{$product.cover.bySize.home_default.height}"
     alt="{$product.name}">

Krytyczna zasada: nigdy nie stosuj lazy loading do obrazów above-the-fold

Najczęstszym błędem lazy loadingu jest stosowanie go do obrazów widocznych bez przewijania. To w rzeczywistości pogarsza wydajność, ponieważ przeglądarka opóźnia ładowanie treści, które użytkownik widzi natychmiast.

Obrazy, które NIE powinny być lazy ładowane:

• Logo Twojego sklepu
• Obrazy hero/baner na górze strony
• Pierwsze 1-2 obrazy produktów na stronach kategorii

<img src="hero-baner.jpg" 
     loading="eager" 
     fetchpriority="high" 
     width="1200" 
     height="400" 
     alt="Baner letniej wyprzedaży">

Kiedy potrzebujesz modułu: obrazy tła CSS

Motywy PrestaShop często używają obrazów tła CSS dla sliderów, banerów i nagłówków kategorii. Atrybut loading="lazy" nie działa dla teł CSS.

document.addEventListener('DOMContentLoaded', function() {
    const lazyBackgrounds = document.querySelectorAll('[data-bg]');
    const observer = new IntersectionObserver(function(entries) {
        entries.forEach(function(entry) {
            if (entry.isIntersecting) {
                entry.target.style.backgroundImage = 'url(' + entry.target.dataset.bg + ')';
                observer.unobserve(entry.target);
            }
        });
    }, { rootMargin: '200px 0px' });
    lazyBackgrounds.forEach(function(bg) { observer.observe(bg); });
});

Kiedy potrzebujesz modułu: efekty placeholder

• Efekt blur-up (LQIP) - Załaduj najpierw małą, rozmytą wersję
• Ekrany szkieletowe - Szare bloki placeholder odpowiadające wymiarom
• Placeholdery dominującego koloru - Użyj dominującego koloru obrazu jako tła

Wpływ na wydajność PrestaShop i Core Web Vitals

• LCP - Lazy loading obrazów above-the-fold POGARSZA LCP
• CLS - Obrazy bez atrybutów width/height powodują przesunięcia układu
• INP - Mniej jednocześnie ładowanych zasobów poprawia interaktywność

<!-- ŹLE - powoduje przesunięcie układu -->
<img src="produkt.jpg" loading="lazy" alt="Produkt">

<!-- DOBRZE - rezerwuje miejsce -->
<img src="produkt.jpg" loading="lazy" 
     width="400" height="400" alt="Produkt">

Rekomendacje specyficzne dla PrestaShop

Strony z listą produktów

Lazy ładuj wszystkie obrazy produktów oprócz pierwszego rzędu. Zastosuj fetchpriority="high" do pierwszego rzędu.

Strony szczegółów produktu

Główny obraz produktu powinien być ładowany eager z fetchpriority="high". Miniatury galerii mogą być lazy ładowane.

Strona główna

Obrazy slidera above the fold powinny być ładowane eager. Bloki modułów below the fold powinny używać lazy loadingu.

Podsumowanie: Moduł vs. Natywny

Wydajnosc panelu administracyjnego PrestaShop: dlaczego Back Office jest wolny

Wolny panel administracyjny PrestaShop to jeden z najbardziej frustrujacych problemow. Ten przewodnik identyfikuje najczestsze przyczyny i podaje konkretne rozwiazania.

Najczestsze przyczyny

1. Polaczenie z API PrestaShop Addons

Przyczyna numer jeden. Back office wykonuje zapytania HTTP do addons.prestashop.com. Gdy to API jest wolne, caly back office czeka.

Rozwiazanie - Wyloguj sie z konta Addons lub wylacz wywolania API.

2. Wlaczony tryb debug

Wylacza wszystkie cache i rekompiluje szablony przy kazdym zadaniu.

define('_PS_MODE_DEV_', false);

3. Za duzo zainstalowanych modulow

Kazdy modul dodaje narzut. Odinstaluj nieuzywane moduly, szczegolnie statystyki i gamifikacje.

4. Duza baza danych bez optymalizacji

DELETE FROM ps_cart WHERE id_cart NOT IN (
    SELECT id_cart FROM ps_orders
) AND date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);

OPTIMIZE TABLE ps_cart, ps_connections, ps_guest;

5. Ograniczenia hostingu wspoldzielonego

Rekomendacja: VPS z 2+ CPU, 4 GB RAM, SSD i PHP 8.1+.

6. OPcache nie wlaczony

opcache.enable = 1
opcache.memory_consumption = 256

7. Wolne widgety dashboardu

Uproscisc dashboard. Usunac niepotrzebne widgety.

8. Duzy katalog produktow

Zmniejszyc produkty na strone do 20-50. Uzywac wyszukiwania zamiast przegladania.

Checklista optymalizacji

1. Wylacz tryb debug
2. Kompilacja szablonow: "Nigdy nie rekompiluj"
3. Wlacz cache (Redis preferowany)
4. Wlacz OPcache
5. Odlacz od API Addons
6. Odinstaluj nieuzywane moduly
7. Wyczysc baze danych
8. Uproscisc dashboard
9. Zmien hosting na VPS/dedykowany
10. Uzyj PHP 8.1+

Gdy kombinacje PrestaShop zabijaja wydajnosc: limity i obejscia

System kombinacji PrestaShop pozwala tworzyc warianty produktow. Dziala doskonale dla produktow z kilkoma wariantami. Ale gdy produkty maja setki lub tysiace kombinacji, wydajnosc drastycznie spada.

Dlaczego kombinacje powoduja problemy z wydajnoscia

Architektura bazy danych

PrestaShop przechowuje dane kombinacji w wielu tabelach: ps_product_attribute, ps_product_attribute_combination, ps_stock_available, ps_specific_price. Produkt z 5 rozmiarami i 10 kolorami tworzy 50 kombinacji z ponad 350 wierszami w bazie.

Problem wzrostu wykladniczego

Praktyczne limity

Rozwiazanie 1 - Restrukturyzacja katalogu

Zamiast jednego produktu z 50 kombinacjami, stworz oddzielne produkty na kolor z 5 kombinacjami kazdy. Szybsze i lepsze dla SEO.

Rozwiazanie 2 - Optymalizacja bazy danych i serwera

ALTER TABLE ps_product_attribute 
  ADD INDEX idx_product_default (id_product, default_on);

ALTER TABLE ps_stock_available 
  ADD INDEX idx_product_attribute (id_product, id_product_attribute);

Rozwiazanie 3 - Lazy loading kombinacji

Zamiast ladowac wszystkie kombinacje przy wczytywaniu strony, pobieraj dane przez AJAX gdy klient wybiera atrybut.

Rozwiazanie 4 - Strategie cachowania

Cache calej strony (Varnish, LiteSpeed) dla stron produktow. Redis lub Memcached zamiast cachowania plikowego.

Kiedy unikac kombinacji calkowicie

• Produkty konfigurowalne z 4+ atrybutami - Modul konfiguratora produktow
• Produkty wymiarowe - Modul niestandardowych wymiarow
• Produkty print-on-demand - Modul projektanta produktow

Rekomendacje wedlug liczby kombinacji

Macierz kompatybilności wersji PHP dla PrestaShop

Wybór odpowiedniej wersji PHP dla Twojego sklepu PrestaShop to jedna z najważniejszych decyzji infrastrukturalnych, jakie podejmiesz. Uruchomienie niekompatybilnej wersji PHP może spowodować białe ekrany, niedziałające procesy płatności, awarie modułów i luki w zabezpieczeniach. Ten kompleksowy przewodnik obejmuje każdą wersję PrestaShop od 1.6 do 9.x i przyporządkowuje każdą z nich do obsługiwanych wersji PHP, zalecanych konfiguracji i kwestii aktualizacji.

Dlaczego wersja PHP ma znaczenie dla PrestaShop

PHP to serwerowy język programowania, który napędza PrestaShop. Każda główna wersja PHP wprowadza poprawki wydajności, nowe funkcjonalności języka i wycofuje starsze funkcje. Kod źródłowy PrestaShop ewoluuje równolegle z PHP, co oznacza, że nowsze wersje PrestaShop wykorzystują nowoczesne funkcje PHP, jednocześnie rezygnując ze wsparcia dla przestarzałych wersji.

Używanie niewłaściwej wersji PHP powoduje trzy kategorie problemów:

• Błędy fatalne - Funkcje usunięte w nowszych wersjach PHP (np. funkcje mysql_* usunięte w PHP 7.0, each() usunięta w PHP 8.0) powodują natychmiastowe awarie.
• Ostrzeżenia o wycofaniu - Wycofane funkcje generują ostrzeżenia, które mogą uszkodzić odpowiedzi AJAX, wyjście JSON i generowanie PDF, gdy display_errors jest włączone.
• Narażenie na zagrożenia bezpieczeństwa - Wersje PHP, które osiągnęły koniec życia, nie otrzymują już łatek bezpieczeństwa, pozostawiając Twój sklep podatnym na ataki.

Pełna macierz kompatybilności

PrestaShop 1.6.x

Zalecane PHP dla 1.6.x - PHP 7.1. Oferuje najlepszą równowagę między wydajnością a kompatybilnością. Uruchamianie 1.6.x na PHP 7.2+ wymaga modyfikacji plików rdzeniowych, co przerywa ścieżkę aktualizacji i nie jest zalecane.

PrestaShop 1.7.x

Krytyczne ostrzeżenie - Żadna wersja PrestaShop 1.7 nie obsługuje PHP 8.0 ani nowszego. Jeśli uruchomisz PS 1.7.6 na PHP 8, Smarty natychmiast się zawiesi, ponieważ silnik szablonów używa funkcji usuniętych w PHP 8.0. Usunięcie funkcji each() i zmiany w działaniu array_key_exists() z obiektami powodują błędy fatalne.

PrestaShop 8.x

Zalecane PHP dla 8.x - PHP 8.1. Jest to optimum oferujące pełną kompatybilność, aktywne wsparcie bezpieczeństwa i doskonałą wydajność z kompilacją JIT. PHP 8.1 wprowadza Fibers, Enums, właściwości readonly i typy intersection, z których PrestaShop 8 może korzystać.

PrestaShop 9.x

Zalecane PHP dla 9.x - PHP 8.3 lub 8.4. PrestaShop 9 działa na Symfony 6.4 LTS i wymaga PHP 8.1 jako minimum. PHP 8.4 wprowadza Property Hooks i asymetryczną widoczność, które przyszłe aktualizacje PrestaShop będą wykorzystywać.

Daty zakończenia wsparcia PHP, które musisz znać

Jeśli w 2026 roku używasz PHP 7.4 lub 8.0, pracujesz na niewspieranej wersji, która nie otrzymuje już poprawek bezpieczeństwa. Jest to krytyczne ryzyko dla każdego sklepu e-commerce obsługującego dane płatnicze.

Jak sprawdzić aktualną wersję PHP

Metoda 1 - Panel administracyjny PrestaShop

Przejdź do Zaawansowane > Informacje. Sekcja Informacje o serwerze wyświetla Twoją wersję PHP wraz z limitem pamięci, maksymalnym czasem wykonania i innymi istotnymi ustawieniami.

Metoda 2 - Plik PHP Info

Utwórz plik o nazwie phpinfo.php w katalogu głównym sklepu o następującej treści:

<?php phpinfo();

Uzyskaj do niego dostęp przez przeglądarkę pod adresem https://twojsklep.com/phpinfo.php. Usuń ten plik natychmiast po sprawdzeniu - ujawnia wrażliwe szczegóły konfiguracji serwera.

Metoda 3 - Linia poleceń

php -v
php -r "echo PHP_VERSION;"

Pamiętaj, że wersja PHP CLI może różnić się od wersji PHP serwera web. Zawsze weryfikuj przez interfejs webowy lub phpinfo().

Typowe problemy przy nieprawidłowej wersji PHP

Biały ekran śmierci (WSOD)

Najczęstszy objaw niekompatybilności PHP. Sprawdź log błędów PHP (zazwyczaj pod /var/log/php-errors.log lub dostępny przez panel hostingowy). Typowe błędy to:

Fatal error: Uncaught Error: Call to undefined function mysql_connect()
Fatal error: Uncaught Error: Call to undefined function each()
Fatal error: Cannot use "parent" when current class scope has no parent

Ostrzeżenia o wycofaniu psują AJAX

Gdy display_errors = On i aktualizujesz PHP, ostrzeżenia o wycofaniu są dołączane do odpowiedzi AJAX. To psuje parsowanie JSON w panelu administracyjnym, powodując ciche awarie funkcji takich jak wyszukiwanie produktów, wyszukiwanie klientów i tworzenie zamówień. Rozwiązanie:

; php.ini
display_errors = Off
log_errors = On
error_log = /sciezka/do/php-error.log

Niekompatybilność modułów

Moduły firm trzecich mogą nie obsługiwać Twojej wersji PHP. Przed aktualizacją PHP sprawdź kompatybilność każdego zainstalowanego modułu. Typowe problematyczne obszary:

• Moduły używające create_function() - usunięta w PHP 8.0
• Moduły używające funkcji mysql_* - usunięte w PHP 7.0
• Moduły używające pozycyjnego dostępu do ciągów z nawiasami klamrowymi $str{0} - usunięte w PHP 8.0
• Moduły nieobsługujące nullable typów zwracanych - bardziej restrykcyjne od PHP 8.1+

Jak bezpiecznie zaktualizować PHP dla PrestaShop

Krok 1 - Audyt aktualnej konfiguracji

Zanim cokolwiek zmienisz, udokumentuj swoje obecne środowisko:

php -v                    # Aktualna wersja PHP
php -m                    # Załadowane rozszerzenia
php -i | grep memory      # Limit pamięci
php -i | grep max_exec    # Limit czasu wykonania

Krok 2 - Sprawdź kompatybilność modułów

Przejrzyj każdy zainstalowany moduł. Sprawdź dokumentację dewelopera modułu pod kątem obsługi wersji PHP. Jeśli moduł nie był aktualizowany od ponad dwóch lat, prawdopodobnie jest niekompatybilny z PHP 8.x.

Krok 3 - Najpierw przetestuj na stagingu

Nigdy nie aktualizuj PHP na serwerze produkcyjnym bez testów. Utwórz kopię staging swojego sklepu i przetestuj z nową wersją PHP. Sprawdź:

• Strony front office ładują się prawidłowo
• Strony produktów, kategorii, strony CMS
• Proces koszyka i zamówienia kończy się poprawnie
• Moduły płatności przetwarzają transakcje testowe
• Funkcjonalność back office działa (edycja produktów, zarządzanie zamówieniami)
• Wszystkie moduły firm trzecich działają prawidłowo
• Zadania cron wykonują się bez błędów

Krok 4 - Aktualizacja z planem wycofania

Większość dostawców hostingu pozwala na zmianę wersji PHP z panelu sterowania (cPanel, Plesk, DirectAdmin). Zachowaj poprzednią wersję PHP dostępną do szybkiego wycofania, jeśli pojawią się problemy.

Krok 5 - Wyczyść wszystkie cache po aktualizacji

Po zmianie wersji PHP wyczyść każdą warstwę cache:

# Wyczyść cache PrestaShop
rm -rf var/cache/prod/* var/cache/dev/*

# Wyczyść skompilowane szablony Smarty
rm -rf var/cache/smarty/compile/* var/cache/smarty/cache/*

# Jeśli używasz OPcache, uruchom ponownie PHP-FPM
systemctl restart php8.3-fpm

# Wyczyść cache CDN (Cloudflare, itp.)

Najlepsze praktyki konfiguracji PHP dla PrestaShop

Niezależnie od wybranej wersji PHP, te ustawienia są niezbędne dla optymalnej wydajności PrestaShop:

; Zalecane ustawienia php.ini
memory_limit = 512M
max_execution_time = 300
max_input_vars = 10000
post_max_size = 32M
upload_max_filesize = 32M

; Ustawienia OPcache (krytyczne dla wydajności)
opcache.enable = 1
opcache.memory_consumption = 256
opcache.interned_strings_buffer = 32
opcache.max_accelerated_files = 16229
opcache.revalidate_freq = 60
opcache.fast_shutdown = 1

; Wymagane rozszerzenia
extension = intl
extension = zip
extension = gd
extension = curl
extension = mbstring
extension = openssl
extension = pdo_mysql
extension = fileinfo

Uwagi dla deweloperów modułów

Jeśli rozwijasz moduły PrestaShop, musisz starannie rozważyć kompatybilność PHP:

• Minimalna wersja PHP - Celuj w PHP 7.2 jako minimum dla modułów, które powinny działać na PrestaShop 8.0+, lub PHP 8.1 dla modułów przeznaczonych wyłącznie dla PrestaShop 9.
• Używaj PHPStan lub Psalm - Narzędzia analizy statycznej wykrywają niekompatybilności wersji PHP, zanim zrobią to Twoi użytkownicy.
• Unikaj składni specyficznej dla wersji - Funkcjonalności takie jak wyrażenia match (PHP 8.0), enums (PHP 8.1) i właściwości readonly (PHP 8.1) ograniczają Twój moduł do tych wersji PHP i wyższych.
• Testuj na wielu wersjach - Używaj kontenerów Docker z różnymi wersjami PHP, aby testować moduł na całym zakresie kompatybilności.

Często zadawane pytania

Czy mogę uruchomić PrestaShop 1.7 na PHP 8?

Nie. Żadna wersja PrestaShop 1.7 oficjalnie nie obsługuje PHP 8.0 ani nowszego. Chociaż niektórzy użytkownicy zastosowali łatki, aby częściowo to uruchomić, nie jest to wspierane i będzie powodować problemy przy aktualizacjach. Właściwą drogą jest migracja do PrestaShop 8.x.

Czy powinienem używać PHP 8.4 z PrestaShop 8.1?

Niezalecane. PrestaShop 8.1 został opracowany i przetestowany głównie z PHP 8.1. Chociaż PHP 8.2 jest częściowo obsługiwany w późniejszych wersjach 8.1.x, PHP 8.4 wprowadza zmiany, które mogą powodować problemy ze starszymi komponentami Symfony. Pozostań przy PHP 8.1 dla PrestaShop 8.x.

O ile szybszy jest PHP 8.x w porównaniu z 7.x?

Benchmarki pokazują, że PHP 8.1 jest około 20-30% szybszy niż PHP 7.4 dla typowych obciążeń PrestaShop. Kompilator JIT zapewnia największą korzyść przy zadaniach obliczeniowych. Dla operacji związanych z I/O (zapytania do bazy danych, odczyt plików) poprawa jest mniejsza, ale nadal mierzalna.

Czy aktualizacja PHP wymaga aktualizacji PrestaShop?

Niekoniecznie, ale obie rzeczy idą w parze. Możesz zaktualizować PHP w obsługiwanym zakresie dla swojej wersji PrestaShop bez aktualizacji samego PrestaShop. Jednak jeśli chcesz używać nowoczesnej wersji PHP (8.3+), będziesz potrzebować PrestaShop 8.1 lub 9.x.