Atnaujinome PrestaShop 1.7.6 parduotuvę iki 9.2: ką sakė atnaujinimo įrankis ir kas iš tikrųjų sugedo

Oficialus atnaujinimo įrankis mūsų parduotuvę iš PrestaShop 1.7.6 į 9.2 perkėlė maždaug per tris minutes. Kad parduotuvė vėl veiktų taip, kaip turi, prireikė gerokai daugiau laiko, o didžioji dalis gedimų neparodė jokios klaidos.

Norėjome tai pamatyti patys, o ne kartoti, kas parašyta versijų aprašymuose. Todėl sukūrėme PrestaShop 1.7.6.7 parduotuvę, panašią į tas, kurias mūsų prašo atnaujinti, atnaujinome ją oficialiu įrankiu ir užsirašėme viską: ką įrankis pranešė, ko nepastebėjo ir ką teko taisyti rankomis.

Parduotuvė#

Tai mūsų pačių sukurta bandomoji parduotuvė, ne kliento. Ją paruošėme taip, kad atrodytų kaip tipiška kelerius metus veikianti 1.7 parduotuvė:

• 2020 m. mokėjimų ir rinkodaros moduliai: Mollie 4.0.9, PayPal 5.2.1 (su jame esančia Guzzle 6 biblioteka), prekių atsiliepimai, norų sąrašas ir Google Analytics.
• Classic vaikinė tema su savu bloku prekės puslapyje, CSS ir JavaScript.
• Prekės puslapio valdiklio override, kuris prideda pristatymo datą („Užsakykite šiandien, pristatysime iki…“).
• Nedidelis savas modulis, parašytas taip, kaip parašyta daug to meto agentūrų kodo: kainos per Tools::displayPrice(), Tools::jsonEncode(), PHP each(), sena klasė Attribute, atskiras ajax.php modulio aplanke, addJquery() ir jQuery .size().
• Demo prekės, pirkimas be registracijos ir mokėjimas bankiniu pavedimu.

Po kiekvieno žingsnio leidome tą patį automatinį testą: atidaryti prekės puslapį ir patikrinti kiekvieną savą bloką, įdėti į krepšelį, apmokėti be registracijos, pateikti užsakymą ir atidaryti pagrindinius administravimo puslapius. Kiekvieno žingsnio pilną atsarginę kopiją pasilikome, tad kiekvieną radinį galima pakartoti.

Kelias#

Iš 1.7.6 į 9 vienu šuoliu nepereisi, o kartu turi keistis ir serveris:

1. PHP 7.1 → 7.2. Dabartinis atnaujinimo modulis (7.6.6) su PHP 7.1 apskritai neveikia, todėl tai pirmas žingsnis. PrestaShop 1.7.6 su PHP 7.2 dar veikia.
2. PrestaShop 1.7.6.7 → 8.2.8 oficialiu atnaujinimo moduliu.
3. PHP 8.1. PrestaShop 8.2 su ja veikia, o PrestaShop 9 jos reikalauja.
4. PrestaShop 8.2.8 → 9.2.0. Atkreipkite dėmesį: numatytasis rekomenduojamas kanalas 9 versijos apskritai nesiūlė. Ją siūlė tik kanalas online.

Prieš 1 žingsnį paleidome savo nemokamą parengties patikrą. Ji rado penkias problemas savame modulyje, override be grąžinamo tipo, 18 radinių senajame Mollie ir 4 senajame PayPal, per seną PHP versiją ir 309 duomenų bazės lenteles, dar ne utf8mb4.

1 žingsnis: 1.7.6 → 8.2, „atnaujinta, bet yra įspėjimų“#

Pats atnaujinimas truko 105 sekundes. Prieš tai įrankis įspėjo, kad išdiegs tris nedidelius standartinius modulius. Apie Mollie ir PayPal – nieko.

Kas nutiko iš tikrųjų:

• Mollie ir PayPal failai pakeisti naujausiais, bet jų pačių atnaujinimo scenarijai nepavyko, todėl PrestaShop abu modulius tyliai išjungė. Duomenų bazėje liko senos versijos. Parduotuvė atsidarė kaip įprastai, tik be mokėjimų kortelėmis ir be jokios matomos klaidos.
• Taip pat buvo išjungti dar keturi moduliai: dalinimosi mygtukai, PrestaShop Checkout, mūsų savas modulis ir mūsų pačių parengties patikra.
• Pasitikėjimo ženkliukai po mygtuku „Į krepšelį“ kiekviename puslapyje grąžino 404 (30 užklausų viename puslapyje), nes duomenų bazėje liko seni ženkliukų keliai.
• Užsakymai bankiniu pavedimu veikė, tad greitas patikrinimas „ar galiu pateikti užsakymą“ būtų praėjęs.

Dar buvo tylios klaidos, dėl kurių greito žvilgsnio neužtenka:

• Iš likučio eilutės dingo kombinacijos pavadinimas. PrestaShop 8 versijoje klasė Attribute pervadinta į ProductAttribute. Su PHP 8 senas pavadinimas dabar rodo į paties PHP klasę Attribute, todėl new Attribute($id) neužlūžta, o tiesiog grąžina tuščią pavadinimą. Jokiame žurnale nieko.
• Modulio ajax.php grąžino klaidą 500: Tools::jsonEncode() PrestaShop 8 versijoje nebėra.

Kaip sutaisėme:

• Mollie, PayPal ir dalinimosi mygtukų atnaujinti vietoje nepavyko. Juos teko išdiegti ir įdiegti iš naujo. Tai reiškia, kad nustatymus ir API raktus reikia įvesti iš naujo, o Mollie lentelės su senų užsakymų duomenimis ištrinamos. Tikroje parduotuvėje tam reikia pasiruošti.
• Savas modulis perrašytas vieną kartą taip, kad veiktų ir 8, ir 9 versijoje: ProductAttribute vietoj Attribute, json_encode(), foreach vietoj each(), kainos formatuojamos pagal dabartinę lokalę, modulio front valdiklis vietoj ajax.php, skriptas registruojamas per registerJavascript(). Nedidelis atnaujinimo scenarijus išsaugotus nustatymus perveda į naują formatą.
• Override gavo : void prie initContent(). Tai veikia jau 8 versijoje, o 9 versijoje yra privaloma.
• Pasitikėjimo ženkliukams duomenų bazėje įrašyti nauji keliai.

2 žingsnis: PHP 8.1#

Klaidų nebuvo. Pastebėjome tik viena: grįžtančio lankytojo naršyklė iš talpyklos rodė seną theme.css, ir šešios dalinimosi mygtukų ikonėlės nesimatė, kol talpykla nepasibaigė. Švarioje naršyklėje viskas atrodė gerai. Po atnaujinimo dalis pirkėjų kurį laiką mato seną parduotuvės versiją iš talpyklos.

3 žingsnis: 8.2 → 9.2#

Atnaujinimas truko 73 sekundes. Verta žinoti du dalykus.

Įrankis būtų išdiegęs PayPal. Jis pažymėjo PayPal 6.7.1 kaip nesuderinamą su PrestaShop 9 ir siūlė jį pašalinti kartu su nustatymais. Paties PayPal pakeitimų sąraše PrestaShop 9 palaikymas nurodytas nuo 6.5.0 versijos. Atnaujinome su parinktimi, kuri nesuderinamų modulių nešalina, PayPal liko įjungtas, o jo nustatymų puslapis 9.2 versijoje veikia. Jei būtume sutikę su numatytuoju pasirinkimu, parduotuvė be rimtos priežasties būtų netekusi PayPal nustatymų.

Iškart po atnaujinimo administravimas grąžino klaidą 500 dėl senos talpyklos. Padėjo viso var/cache išvalymas.

Kad pamatytume, nuo ko mus apsaugojo 1 žingsnis, trumpam grąžinome seną kodą:

• Senas override visus prekių puslapius baigė klaida 500: Declaration of ProductController::initContent() must be compatible with ProductControllerCore::initContent(): void. Vienas trūkstamas grąžinamas tipas išjungia visą katalogą.
• Senas ajax.php buvo užblokuotas su 403. PrestaShop 9 nebeleidžia naršyklei tiesiogiai atidaryti PHP failų modulių aplankuose.
• addJquery(), Tools::displayPrice(), Tools::jsonEncode(), ajaxDie() ir Swift Mailer 9.2 versijoje nebeegzistuoja. Senas modulis addJquery() kvietė antraštės hook'e, todėl būtų sustojęs kiekvienas parduotuvės puslapis.

Kas nesugedo: senieji jQuery .size() ir .bind() PrestaShop 9.2 su Classic tema vis dar veikė. Vis tiek juos pataisėme, bet tai nėra tokia skubi problema, kaip teigia kai kurie gidai.

4 žingsnis: ko atnaujinimo įrankis taip ir nepaminėjo#

Kai parduotuvė jau veikė su 9.2, dar kartą paleidome savo parengties patikrą. Ji rado problemų, apie kurias atnaujinimo įrankis nepranešė:

• Oficialus GDPR modulis liko 1.4.4 versijos. 9.2 versijoje užklausa, kuri įrašo pirkėjo sutikimą, kai jis pažymi GDPR varnelę, baigėsi fatal klaida (ajaxDie()). Apmokėjimas veikė, tik sutikimas taip ir nebuvo išsaugotas. Tai lengva praleisti, o tai tikra atitikties problema. 2.0.1 versija tai pataiso. Spąstai: modulio atnaujinimas per komandinę eilutę iš PrestaShop katalogo vėl atsisiuntė 1.4.4 ir perrašė mūsų 2.0.1, todėl teko įdiegti rankomis.
• Mollie 6.4.7 vis dar turi kodo, kuris 9.2 versijoje neveiks: du seni front valdikliai kviečia pašalintą metodą, viena nustatymų forma naudoja seną klasę Attribute, o paslauga, rodanti mokėjimo antkainius, kviečia Tools::displayPrice(). Dabartinis mokėjimo kelias senų valdiklių nenaudoja, tad mokėjimai kortelėmis neturėtų nukentėti. Bet jei mokėjimo būdui taikote antkainį, apmokėjimas greičiausiai lūš. Be Mollie paskyros to patikrinti negalėjome, tad tai radinys kode, o ne patvirtintas gedimas.
• PayPal 6.7.1 administravime atsijungimo veiksme vis dar kviečia Tools::jsonEncode().

Galutinis testas 9.2 versijoje praėjo: prekės puslapis su visais savais blokais, krepšelis, pirkimas be registracijos, užsakymo patvirtinimas ir administravimas (skydelis, užsakymai, prekių sąrašas ir redagavimas, klientai, moduliai, Mollie ir PayPal nustatymai). Naršyklės konsolėje klaidų nebuvo.

Ir mūsų įrankis turėjo spragų#

Savo nemokamą patikrą leidome kiekviename žingsnyje, tad būtų nesąžininga jos rezultatų nevertinti taip pat.

• Ji praleido $this->context->controller->addJquery() – būtent tą kvietimą, kuris būtų sugadinęs kiekvieną puslapį. Ji ieškojo tik $this->addJquery().
• Veikiančioje 9.2 parduotuvėje ji rodė 16 klaidų, ir dalis jų buvo netikros: Mollie kodas, kuris prieš pasirinkdamas metodą patikrina PrestaShop versiją, patikra class_exists('AttributeCore') ir ps_facetedsearch cron failai, kuriuos modulis pats leidžia savo .htaccess faile.

Abu dalykus pataisėme 1.1.3 versijoje, išleistoje tą pačią dieną. Toje pačioje parduotuvėje ji dabar rodo 8 klaidas, ir kiekviena yra tikras kodas, kuris 9.2 versijoje neveikia. Kodas, kuris pirma patikrina versiją ar klasę, dabar rodomas kaip tai, ką verta patikrinti, o ne kaip klaida.

Ką patartume parduotuvės savininkui#

• Pats atnaujinimas greitas. Tikrasis darbas – viską patikrinti po jo. Po trijų minučių atnaujinimo turėjome išjungtus mokėjimų modulius, dingusius ženkliukus, tuščią kombinacijos pavadinimą ir neįrašomus GDPR sutikimus, ir nė vienas neparodė klaidos.
• „Atnaujinimas baigtas“ mokėjimų moduliams nieko nereiškia. Skiltyje Moduliai patikrinkite, ar kiekvienas mokėjimų modulis įjungtas ir tokios versijos, kokios tikitės, tada su kiekvienu atlikite tikrą bandomąjį mokėjimą.
• Nesutikite aklai su „išdiegti nesuderinamus modulius“. Pirmiau kiekvieną modulį patikrinkite jo paties pakeitimų sąraše.
• Branduolio valdiklių override – didžiausia atskira rizika PrestaShop 9 versijoje. Viena eilutė gali išjungti visus prekių puslapius.
• Po kiekvieno žingsnio išvalykite visą talpyklą ir tikėkitės, kad dalis pirkėjų kurį laiką matys seną CSS.
• Pirmiausia atnaujinkite kopiją, su testu, kuris tikrina jūsų savas funkcijas, o ne tik užsakymą.

Ko netikrinome#

Kad ribos būtų aiškios: tikrų mokėjimų kortelėmis su Mollie ar PayPal neatlikome (tam reikia bandomųjų paskyrų), todėl pateikėme tik užsakymus bankiniu pavedimu. Netikrinome daugiaparduotuvio režimo, didelio katalogo ir tikro serverio greičio. O savą kodą parašėme mes, kad jis atrodytų kaip tipiškas senas kodas. Tikroje parduotuvėje jo paprastai būna daugiau ir keistesnėse vietose.

Kokia versija veikia parduotuvė, galite patikrinti pagal adresą.

Jei norite sužinoti, kas laukia jūsų parduotuvės, nemokama parengties patikra per kelias sekundes perskaito modulius, temą ir override'us ir nieko nekeičia. Jei nenorite to daryti patys, PrestaShop parduotuves į 9 versiją atnaujiname už fiksuotą kainą nuo 900 €, pirmiausia kopijoje, su tokiu pat žingsnis po žingsnio testavimu kaip čia. Atskiroms klaidų žinutėms – PrestaShop 9 klaidos – po vieną.