Menaik Taraf ke Adobe Commerce 2.4.8: Apa yang Sebenarnya Rosak

Halaman keperluan sistem Adobe Commerce 2.4.8 — dibuka dalam tab baharu akan memberitahu anda versi mana yang perlu dijalankan. Ia tidak akan memberitahu anda versi mana antaranya yang senyap-senyap memusnahkan seminggu jadual anda. Bahagian kedua itu hanya muncul selepas anda benar-benar menyiapkan beberapa migrasi begini, jadi inilah apa yang kami pelajari sambil menjalankannya untuk pelanggan yang berpindah daripada 2.4.6.

Persekitarannya, sepintas lalu

Di sebalik tabir, beberapa daripadanya membawa berat jauh melebihi apa yang ditunjukkan oleh satu nombor versi. Sokongan PHP 8.1 bukan diisytiharkan usang, ia dibuang, jadi tiada landasan beransur-ansur di sini. Elasticsearch pula cerita serupa: OpenSearch kini ialah satu-satunya enjin carian yang disokong, bukan pilihan alternatif. Beberapa pustaka pihak ketiga teras turut dinaikkan (Monolog kepada 3.x, PHPUnit kepada 10, Composer kepada 2.8+), dan Adobe menukar mod pengindeks lalai — dibuka dalam tab baharu daripada "Update on Save" kepada "Update by Schedule" bagi pemasangan baharu serta penaiktarafan, khusus demi mengurangkan beban dan menyusutkan halangan prestasi sepanjang operasi biasa.

Bahagian yang benar-benar memakan jadual anda

Tiada satu pun nombor versi di atas menjadi bahagian sukarnya. Bahagian sukarnya, secara konsisten, ialah modul serta sambungan pihak ketiga yang rosak.

PHP 8.3/8.4 menguatkuasakan pengendalian jenis data jauh lebih ketat berbanding 8.1, Monolog 3.x menukar antara mukanya dengan cara yang tidak dijangka oleh kod lama, dan kod yang sekadar cuai di bawah PHP 8.1 mula membuang ralat maut di bawah 8.3/8.4, bukan lagi sekadar amaran. Modul tersuai lama serta sambungan pasaran yang tidak pernah dikemas kini bagi penjenisan ketat ialah punca pembaziran masa terbesar dalam hampir setiap penaiktarafan yang kami jalankan. Pembetulannya biasanya bermakna menunggu tampalan vendor, mencabang sendiri sambungan itu, atau dalam keadaan paling teruk menggantikannya sepenuhnya, dan lazimnya anda tidak tahu yang mana satu daripada tiga itu sehingga anda benar-benar mencuba menjalankannya.

Nasihat kami, secara terus terang: audit setiap sambungan pihak ketiga bagi keserasian PHP 8.3/8.4 sebelum anda menyentuh apa-apa lagi. Buat perkara ini dahulu, bukan akhir sekali. Ia langkah yang paling berkemungkinan meletupkan jadual anda, dan ia juga langkah yang boleh anda mulakan sebelum selebihnya persekitaran itu siap sedia.

Apa yang berlaku merentas 4 penaiktarafan

Ini bukan risiko hipotesis. Kami sudah menjalankan 4 penaiktarafan ke 2.4.8 setakat ini, dan coraknya bertahan setiap kali: secara purata, 9 daripada 10 sambungan yang dipasang perlukan tampalan sebelum kedai itu berfungsi dengan betul semula. Sambungan daripada penyedia besar yang sudah mantap, Firebear serta Amasty antaranya, rosak secara konsisten merentas projek berkenaan, bukan nasib malang sekali sekala pada satu binaan tunggal. Berbaloi memandang perkara ini dengan mata terbuka: vendor bereputasi baik yang diselenggara secara aktif pun masih tiada jaminan serasi pada hari pertama. Dan ia bukan sekadar kod pihak ketiga. Sambungan tersuai dalaman kami sendiri, kod yang kami tulis dan selenggara sendiri, turut perlukan tampalan bagi berjalan atas 2.4.8. Tiada kod sesiapa terlepas percuma dalam penaiktarafan ini.

Perangkap lain yang tersembunyi dalam lonjakan versi

Tiga daripadanya berbaloi diketahui sebelum ia mengejutkan anda di tengah penaiktarafan:

• Pengesahan kunci asing MySQL 8.4 lebih ketat secara lalai. restrict_fk_on_non_standard_key kini hidup terus daripada kotak, dan ia akan merosakkan jadual pangkalan data tersuai atau modul warisan yang dibina atas kunci bukan piawai yang tidak pernah dirungut oleh MySQL 8.0.
• Pengendalian parameter null PHP turut menjadi lebih ketat. Kod yang senyap-senyap menghantar null ke dalam parameter fungsi dalaman yang menolak null di bawah PHP 8.1 kini akan membuang notis usang pada tahap paling ringan, atau ralat jenis data keras pada tahap paling teruk.
• Elasticsearch kepada OpenSearch bukan satu bendera konfigurasi. Ia perlukan penyediaan pelayan sebenar, kerja pemetaan indeks, serta ujian sebelum dilancarkan, ataupun anda akan mengetahui kegagalan carian katalog daripada pelanggan anda, bukan daripada proses QA anda.

Jika anda merancang penaiktarafan ini

Mulakan dengan audit sambungan, dan peruntukkan belanjawan sewajarnya. Jika 9 daripada 10 sambungan perlukan tampalan ialah lebih kurang apa yang patut dijangka, "semak keserasian" bukan sekadar semakan ringkas sebelum berlepas, ia satu fasa projek tersendiri, dengan jadualnya sendiri serta risikonya sendiri berupa kelewatan vendor di luar kawalan anda.

Satu lagi perkara untuk dimasukkan ke dalam kalendar awal-awal: tempah janji temu sokongan Adobe sekurang-kurangnya 7 hari lebih awal daripada tarikh anda benar-benar bercadang memulakan penaiktarafan itu. Pasukan sokongan Adobe memang berguna apabila sesuatu tersasar di tengah migrasi, tetapi anda tidak mahu sedang menunggu slot penjadualan pada saat anda memerlukan mereka.

Setelah penaiktarafan itu sendiri selesai, jangan anggap ia sudah tamat. Setiap ciri dan setiap integrasi perlu diuji semula terhadap persekitaran baharu, bukan sekadar yang anda jangka terkesan. Lonjakan versi sebesar ini menyentuh cukup banyak kebergantungan asas sehingga andaian "ia dikerah dengan bersih, jadi ia okey" ialah cara isu sampai ke pengeluaran dan bukan ke QA.

Kami sudah menjalankan migrasi ini bagi pelanggan Adobe Commerce peringkat perusahaan dengan campuran modul tersuai serta skema pangkalan data warisan yang sama persis begini. Jika anda merancang penaiktarafan Adobe Commerce, berbual dengan kami.

---

Sumber: Keperluan sistem Adobe Commerce — dibuka dalam tab baharu serta nota keluaran 2.4.8 — dibuka dalam tab baharu (Adobe Experience League), berserta pengalaman migrasi kami sendiri merentas 4 penaiktarafan.