PrestaShop risinājumi
Strādājam ar PrestaShop 1.7 un 8.x veikaliem: pielāgoti moduļi, multistore konfigurācijas, kases pielāgojumi un veiktspējas darbs, ko faceted search aprij, ja neviens to neoptimizē. Raksturīgs gadījums: migrējam 1.7 veikalu ar 200 pielāgotiem override'iem uz 8.x, pārbūvējam tēmu un samazinām kategorijas lapas ielādes laiku no četrām sekundēm līdz mazāk par vienu.
Kāpēc klienti pie mums nāk ar šādām lietām
Lielākā daļa PrestaShop darba, kas pie mums nonāk, iekrīt trīs grupās. Pirmā ir 1.7 veikals, kas vairs nesaņem drošības atjauninājumus, un tirgotājam beidzot pateicis hostinga sniedzējs, ka PHP versija, uz kuras tas darbojas, ir end-of-life. Vajag migrēt uz 8.x, bet iepriekšējais izstrādātājs atstājis 200 moduļu override'us un tēmu, kas pieāķējas pie smarty šabloniem, kuru jaunajā core vairs nav. Esam to redzējuši pietiekami daudz reižu, lai mums būtu sagatavots saraksts.
Otrā ir faceted search, kas salūzis zem reāla kataloga. PrestaShop kategorijas lapas ir labas, kamēr nepārsniedz 5000 produktus ar atribūtiem; tad SQL JOIN ķēde, kas būvē layered navigation, sāk aizņemt trīs līdz četras sekundes. Reizēm atbilde ir pārrakstīt meklēšanu uz Elasticsearch vai Meilisearch, reizēm vienkārši pievienot pareizos kompozītos indeksus un noregulēt prestashop.search. Veicam mērījumus, pirms iesakām, kuru ceļu iet.
Trešā ir multistore konfigurācija, kas aizgājusi greizi. ES tirgotāji, kas darbina .lv, .lt, .ee grupu no vienas PrestaShop instalācijas, bieži atklāj, ka PVN noteikumi, piegādes pārvadātāji un produktu tulkojumi ir tā sapinušies, ka šķietami maza izmaiņa skar vēl sešas citas. Mēs ienākam, lai to atpītu, parasti atdalot nodokļu noteikumus pēc shop group un izlabojot mantošanas secību admin pusē.
Posmi un termiņi
Lielākā daļa PrestaShop projektu, ko vadām, ir 8 līdz 14 nedēļas no sākuma līdz beigām, atkarībā no kataloga lieluma un cik daudz tēmu pielāgojumu ir scope'ā. Pirmā nedēļa ir tikai-lasīt režīmā: saņemam datu bāzes piekļuvi, paņemam snapshot, profilējam lēnākās lapas ar Xdebug un izveidojam rakstītu atskaiti par to, kas ir uzstādīts, kas ir override'ots un kas patiešām ir salūzis pretstatā tam, kas vienkārši ir lēns. Atskaite ir tā, no kuras strādājam pārējā projekta laikā.
No otrās līdz ceturtajai nedēļai ir pamatu likšana. Ja tā ir 1.7 uz 8.x migrācija, uzstādām jauno instalāciju uz staging servera, palaižam oficiālo upgrade moduli pret produkcijas kopiju un sākam pārnest override'us pa vienam modulim. Ja tas ir veiktspējas projekts, regulējam MySQL, pievienojam trūkstošos indeksus un pārbūvējam tēmas twig šablonus, lai noņemtu izsaukumus, kas dara N+1 vaicājumus uz kategorijas lapām.
No piektās līdz desmitajai nedēļai ir pati izstrāde: pielāgoti moduļi, tēmu darbs, maksājumu integrācijas un visi dati, ko klients solījis, ka būs gatavi trešajā nedēļā. Pēdējās divas līdz četras nedēļas ir testēšana ar reālu trafiku uz staging ar anonimizētiem klientu kontiem, tad svētdienas rīta cutover ar 24 stundu rollback logu. Vecais veikals turpina darboties uz legacy. apakšdomēna vēl divas nedēļas pēc palaišanas, ja kaut kas analītikā vai grāmatvedības eksportā jāpārbauda pret oriģinālu.
Ir projekts, ko vajag sakārtot?
Pastāstiet, kas nestrādā, un mēs pateiksim, vai varam palīdzēt.