- Patryk Marek
- News
- 0 líbí
- 267 pohledy
- 0 komentáře
Pro spolehlivé ocenění aktualizace PrestaShopu jsou potřeba plná verze obchodu, serverové prostředí, šablona, klíčové moduly a popis vlastních změn. Samotné číslo verze neurčuje rozsah práce. Dva obchody na stejné verzi mohou vyžadovat zcela odlišnou přípravu, pokud jeden používá standardní funkce a druhý má upravený checkout, skladovou integraci a vlastní cenová pravidla.

Tento průvodce pomáhá připravit poptávku na aktualizaci a dohodnout kritéria převzetí. Není to návod ke spuštění aktualizátoru bez předchozí zálohy a kontroly závislostí.
Verze PrestaShopu a PHP musí tvořit podporovanou kombinaci
Zapište si plné označení současné a plánované verze obchodu. Zkontrolujte PHP obsluhující web i PHP používané pro CRON a konzolové příkazy. Hosting může pro tyto způsoby spuštění poskytovat různé verze. Změna nastavení v panelu domény nemusí změnit interpret používaný cyklickými úlohami.
V dokumentaci ověřené 13. září 2026 PrestaShop 9.0 podporuje PHP 8.1–8.4 a PrestaShop 9.1 — PHP 8.1–8.5. Doporučené verze PHP se mezi těmito větvemi také liší. To je příklad, proč informace „podporuje PrestaShop 9“ nestačí při volbě prostředí. Zdroj: oficiální požadavky PrestaShop 9.
Podporované prostředí samotného jádra obchodu ještě nepotvrzuje kompatibilitu šablony ani modulů. Před navýšením PHP zkontrolujte také jejich požadavky, serverová rozšíření, limity paměti a způsob provádění integrací. Nezačínejte změnou PHP v produkci jen proto, že novější číslo vypadá výhodněji.
Inventarizace: začněte od kritických funkcí
Seznam všech modulů je užitečný, ale dodavatel by měl především vědět, které funkce udržují každodenní prodej. Uveďte platby, dopravy, výdejní místa, fakturaci, sklad, importy cen a stavů, rezervace a speciální B2B pravidla. Přidejte informaci, kdo spravuje každou integraci.
| Oblast | Co uvést | Proč to ovlivňuje rozsah |
|---|---|---|
| Obchod | Současná verze, plánovaná verze, počet obchodů a jazyků. | Určuje cestu aktualizace a rozsah kontroly dat. |
| Hosting | PHP webu a CRONu, databáze, dostupné místo, možnost vytvoření zálohy. | Umožňuje naplánovat prostředí a operace se soubory. |
| Šablona | Název, verze, child theme, vlastní šablony a skripty. | Změny vzhledu mohou vyžadovat přenos nebo obnovení. |
| Nákup | Checkout, platby, dopravy, výdejní místa, firemní pole. | Vymezuje scénáře vyžadující převzetí před přepnutím. |
| Integrace | Externí systémy, směry výměny, frekvence a vlastníci propojení. | Odhaluje závislosti přesahující samotný obchod. |
| Vlastní kód | Override, změny v souborech jádra, dedikované moduly, dokumentace. | Umožňuje posoudit, co je třeba upravit nebo nahradit. |
| Provoz obchodu | Prodejní hodiny, přípustné okno prací, osoby pro převzetí. | Ovlivňuje plán přepnutí a dostupnost týmu. |
Ve fázi prvního kontaktu stačí technické informace a popis procesu. Hesla, API klíče ani údaje zákazníků neuvádějte do veřejně dostupného dokumentu. Pokud bude potřeba přístup ke kopii, dohodněte způsob jeho předání a rozsah oprávnění.
Co zůstává, co aktualizujeme a co měníme?
Každý důležitý prvek by měl dostat rozhodnutí a jeho zdůvodnění. „Zůstává“ znamená potvrzenou použitelnost v plánované konfiguraci. „K prověření“ je správný status před analýzou; předstíraná jistota komplikuje ocenění i následné převzetí.
| Prvek ukázkového obchodu | Pracovní rozhodnutí | Podmínka potvrzení |
|---|---|---|
| Šablona s dostupnou verzí pro nový obchod | Aktualizujeme. | Kontrola licence a přenosu vlastních šablon. |
| Platební modul s deklarovanou podporou | Aktualizujeme a testujeme. | Objednávka, potvrzení operátora, zrušení a opakování. |
| Vlastní cenové pravidlo v override | K prověření. | Dohledání kódu a obnovení příkladů výpočtů. |
| Opuštěný modul bez aktualizací | Zvažujeme výměnu. | Určení potřebné funkce a přenosu jejích dat. |
| Externí skladový systém | Zůstává jako systém, propojení k prověření. | Ověření API, mapování identifikátorů a obsluhy fronty. |
Modul neposuzujte pouze podle toho, zda jej lze nainstalovat. Instalace nepotvrzuje výpočet slevy, uložení výdejního místa ani dokončení komunikace se skladem. Stejně tak správně fungující domovská stránka není důkazem správné aktualizace obchodu.
Vlastní změny: největší riziko bývá v panelu neviditelné
Zeptejte se lidí, kteří obchod spravují, na úpravy vzniklé v průběhu let: dodatečná pole, netypické stavy objednávek, změny cen, vypnutí dopravců nebo speciální exporty. Část z nich může existovat mimo moduly viditelné v panelu.
Užitečný je krátký popis chování: „pro tuto skupinu zákazníků se cena počítá takto“, „tyto produkty vylučují tohoto dopravce“, „po tomto stavu odesíláme dokument do systému“. Z takového popisu lze připravit akceptační test. Samotný název souboru override nevysvětluje jeho obchodní význam.
Obnovení chybějící funkce může vyžadovat samostatnou práci. Mělo by být rozpoznáno v rozsahu nebo výslovně označeno jako závislost k vyjasnění, místo aby se objevilo až po přepnutí obchodu.
Testovací kopie a kritéria převzetí
Aktualizace se nejprve provádí na kopii s kontrolovanými integracemi. Příprava kopie zahrnuje také ochranu přístupu, zastavení produkčních odesílání a oddělení konfigurace externích služeb. Kopie má umožnit vyzkoušení procesu, ne nevědomky kopírovat fungování produkčního obchodu.
Oficiální průvodce aktualizací z administrace popisuje obsluhu aktualizačního nástroje. Rozsah převzetí by měl navíc odrážet funkce obchodu; referenčním bodem je kontrolní seznam po aktualizaci.
- Porovnejte vybrané produkty, kombinace, ceny a stavy.
- Zkontrolujte účet zákazníka, košík, adresy a důležité metody dopravy a plateb.
- Zkontrolujte výsledek objednávky v administraci a v systémech, do kterých má dorazit.
- Spusťte kontrolované testy importů, exportů a CRON úloh.
- Porovnejte důležité adresy, canonicaly, přesměrování, jazykové verze a mapy webu.
- Zaznamenejte chyby, rozhodnutí a podmínky akceptace, ne jen obecné „testy dokončeny“.
Podrobnější kontrolní kartu nákupu najdete v průvodci o změně checkoutu. Při práci s adresami využijte také existující text o zachování starých odkazů a přesměrováních.
Plán přepnutí a návratu musí zohlednit nové objednávky
Před pracemi určete okamžik vytvoření konečné kopie souborů a databáze, způsob omezení změn dat a pořadí zastavení a obnovení integrací. Určete osobu, která rozhodne o spuštění obchodu, a podmínky, za kterých se vrátíte k předchozí verzi.
Návrat ke kopii před aktualizací může z aktuální databáze odstranit objednávky nebo změny zapsané později. Proto záloha bez určeného bodu obnovy není kompletním havarijním plánem. Je třeba zohlednit také platby, které mohou být potvrzeny se zpožděním, a data odeslaná do externích systémů.
Zásady přípravy kopie popisuje dokumentace zálohy PrestaShopu. Pro konkrétní obchod navíc určete, kdo ověřil možnost obnovy a jak budou odsouhlasovány změny vzniklé během prací. Nepředpokládejte předem aktualizaci bez odstávky.
Z čeho se skládá cenová nabídka?
Cenová nabídka může zahrnovat analýzu a inventarizaci, přípravu kopie, samotnou aktualizaci, úpravu kódu a šablony, testy, přepnutí a podporu po spuštění. Samostatně je třeba uvést licence, placené aktualizace externích modulů a funkce vyžadující obnovení.
Požádejte o jasný rozsah, závislosti a kritéria dokončení. Fixní cena dává smysl pro rozpoznanou práci; při neznámých úpravách může být nejprve užitečná fáze analýzy. Neexistuje jedna poctivá částka pro každý obchod označený „PrestaShop 1.7“ nebo „PrestaShop 8“.
Připravte verzi obchodu, název šablony a seznam klíčových integrací. Na tomto základě lze začít plánovat aktualizaci obchodu PrestaShop, určit potřebné kontroly a připravit rozsah, který lze vyúčtovat.
Věcná kontrola: 13. září 2026. Požadavky verzí byly ověřeny v dokumentaci PrestaShopu. Matice rozhodnutí je ukázková; cílová cesta a kompatibilita integrací se určují pro konkrétní obchod.
Komentáře (0)