WordPress izstrāde
Veidojam pielāgotas WordPress tēmas, WooCommerce veikalus un veiktspējas labojumus vietnēm, kas pāraugušas savu page builder. Lielākoties darbs ir ar rokām rakstītas Gutenberg-saderīgas tēmas, nevis pārpakoti ThemeForest komplekti, un WooCommerce veikali, kur kases ātrums un nodokļu apstrāde patiešām ir svarīgi. Tipisks projekts: izglābjam 3 sekundes lēnu WooCommerce veikalu, pārbūvējam tēmu, pārceļam hostingu un palaižam to ar Lighthouse 90+ produktu lapās.
Kā mēs strādājam ar WordPress projektu
Vispirms saņemam lasīšanas piekļuvi esošajai vietnei un veicam sākotnējo mērījumu. Lighthouse uz trim īstām produktu vai rakstu URL, Query Monitor admin sadaļā, svaiga staging kopija uz mūsu infrastruktūras un wp plugin list --status=active izvade, lai precīzi zinātu, kas ir uzstādīts. Aptuveni 30% WordPress vietņu, ko pārmantojam, ir core failu izmaiņas, pamesta child tēma vai spraudņi, kuru aktīvā versija uz diska neatbilst tam, kas ir WordPress.org repozitorijā. Pirms sākam ko mainīt, pierakstām, kas tur jau ir.
Izstrādes fāze norit divu nedēļu sprintos. Katrs sprints sākas ar kickoff sarunu, beidzas ar pārskatu uz staging, un Linear ticketus turam saskaņotus ar to, ko izmanto klients. Pielāgotai tēmai strādājam block-first pieejā: theme.json reģistrējam blokus, kas redakcionālajai komandai patiešām ir vajadzīgi, būvējam tos ar @wordpress/scripts un izvairāmies no ACF visur, kur native Gutenberg bloki jau dara to pašu. ACF joprojām derīgs atkārtotiem satura tipiem un opciju lapām, bet izkārtojumam vairs nevajadzētu dzīvot pielāgoto lauku grupās.
Deploy notiek caur Git push uz staging zaru, manuālu pārbaudi uz staging.client.com, tad tagged release, kas izsauc produkcijas deploy. WordPress admin nekad neizmantojam koda izvietošanai. Datu bāzes izmaiņas iet caur WP-CLI migration skriptiem, kas nokomitēti repo. Pēc palaišanas saņemat runbook, staging piekļuves un kalendāru, kad nākamie core vai spraudņu atjauninājumi jātestē.
Kas var iet greizi (un ko mēs ar to darām)
Visbiežākā kļūme WordPress vietnē, ko pārmantojam, ir spraudņu konflikts, kas parādās tikai uz reāla klienta kases lapas. Esam redzējuši, ka Yoast SEO plus WPML plus WooCommerce kombinācija rada 500 kļūdu uz produktu lapām poļu valodā un nekur citur. Risinājums ir garlaicīgs: glabājam produkcijas datu bāzes kopiju, ko atjaunojam katru nedēļu, atkārtojam reālus klientu ceļus uz staging un WPML turam ne tālāk par vienu minor versiju no WooCommerce. Ja darbojas 10 vai vairāk aktīvi spraudņi, vajag staging vidi, kas atspoguļo produkciju, nevis lokālu instalāciju ar testa datiem.
Otrais ir page builder rīki. Ja iepriekšējais izstrādātājs vietni veidoja Elementor vai Divi un jūs gribat pielāgotu tēmu, mēs nemigrējam lapu pa lapai. Šablonus pārbūvējam no nulles Gutenberg vidē, tad ar satura migrācijas skriptu pārceļam tekstu. Mēģinājums saglabāt Divi izkārtojumu pielāgotā tēmā ir sešu nedēļu slazds, un to pasakām jau pirmajā sarunā, pirms vispār sniedzam piedāvājumu.
Trešais ir managed WordPress hostings. WP Engine, Kinsta un Pressable kešo agresīvi, un tēma, kas labi strādā uz lēta shared hostinga, var sabojāties uz managed hosta dēļ edge cache noteikumiem ap autorizēto cookies. Pirms migrējam hostingu, testējam cache noteikumus pret reāliem lietotāju ceļiem, īpaši autorizētām WooCommerce sesijām, kur nepareizi konfigurēts cookie pattern var rādīt klienta A grozu klientam B.
Ir projekts, ko vajag sakārtot?
Pastāstiet, kas nestrādā, un mēs pateiksim, vai varam palīdzēt.