Πέντε τρόποι με τους οποίους ένα deploy στο Magento χαλάει το checkout
Το checkout του Magento 2 είναι μια μεγάλη client-side εφαρμογή πάνω σε μια μεγάλη server-side. Ένα release μπορεί να περάσει κάθε έλεγχο στο staging και να το χαλάσει στην παραγωγή. Αυτά είναι τα μοτίβα που εμφανίζονται ξανά και ξανά.

1. Static content που δεν έγινε deploy
Το checkout χτίζεται από modules RequireJS και templates Knockout που σερβίρονται ως στατικά αρχεία. Αν το setup:static-content:deploy έτρεξε για λάθος locale, λάθος theme ή δεν έτρεξε καθόλου, το checkout φορτώνει το σκελετό της σελίδας και σταματάει: ένα spinner που δεν τελειώνει ποτέ, ή ένα άδειο βήμα πληρωμής. Το HTML είναι εντάξει· ένα αρχείο JavaScript που λείπει δεν είναι.
Το πιάνετε φορτώνοντας το checkout σε πραγματικό browser μετά από κάθε deploy — όχι με curl στη σελίδα.
2. Παλιές caches και ασυμφωνίες εκδόσεων
Το full-page cache, το Varnish, ένα CDN και ο browser κρατάνε όλοι αντίγραφα από κάτι. Μετά από ένα deploy, μια cached σελίδα μπορεί να δείχνει σε μια static έκδοση που δεν υπάρχει πια, ή μια νέα σελίδα να συναντήσει ένα παλιό cached section. Το σύμπτωμα είναι συχνά διακοπτόμενο: σε εσάς δουλεύει μετά από hard refresh, στους πελάτες αποτυγχάνει.
Καθαρίστε με τη σωστή σειρά, και ελέγξτε από καθαρό browser χωρίς cookies — που είναι ακριβώς αυτό που κάνει ένας συνθετικός έλεγχος.
3. Ενημέρωση ενός module τρίτου
Τα modules πληρωμών, αποστολής, one-step checkout και φόρων μπαίνουν βαθιά στο layout και στα JavaScript mixins του checkout. Ένα composer update φέρνει μια νέα minor έκδοση, ένα mixin στοχεύει πλέον μια μέθοδο που άλλαξε, και το βήμα πληρωμής πετάει σφάλμα. Σπάνια φαίνονται στο log του server, γιατί το σφάλμα είναι στον browser.
Όταν το checkout αποτυγχάνει αμέσως μετά από ένα deploy, η διαφορά στη λίστα των modules είναι το πρώτο σημείο που κοιτάτε.
4. Διαφορές ρυθμίσεων ανάμεσα στα περιβάλλοντα
Οι τρόποι αποστολής, τα διαπιστευτήρια πληρωμών, οι επιτρεπόμενες χώρες και τα ελάχιστα ποσά παραγγελίας ζουν στη βάση, όχι στον κώδικα. Το staging έχει sandbox κλειδιά και χαλαρές ρυθμίσεις· η παραγωγή κάτι άλλο. Ένα deploy που εισάγει config — ή μια χειροκίνητη αλλαγή το ίδιο απόγευμα — μπορεί να αφήσει την παραγωγή χωρίς ενεργό τρόπο αποστολής για μια χώρα, ή με έναν τρόπο πληρωμής απενεργοποιημένο.
Παρακολουθήστε μια πραγματική διεύθυνση σε κάθε αγορά όπου πουλάτε. Ένας έλεγχος που βλέπει «κανένας τρόπος αποστολής» είναι αποτυχία SHIPPING, όχι αργή σελίδα.
5. Content Security Policy
Από το Magento 2.4.7, το CSP εφαρμόζεται αυστηρά στις σελίδες του checkout. Ένα νέο tracking script, ένα domain παρόχου πληρωμών ή ένα inline script που δεν είναι στη λίστα επιτρεπόμενων μπλοκάρεται από τον browser. Η σελίδα φαίνεται κανονική μέχρι τη στιγμή που θα έπρεπε να εμφανιστεί το widget πληρωμής.
Κοιτάξτε την κονσόλα του browser στο checkout μετά από κάθε release, ή αφήστε ένα monitor να την καταγράψει για εσάς ως τεκμήριο του ελέγχου. Σχετικά: ασφαλής αναβάθμιση Magento 2.4 και full page cache και checkout.
Ελέγξτε το δικό σας κατάστημα τώρα με το δωρεάν τεστ checkout Magento: περνά το checkout σε πραγματικό browser, Luma ή Hyvä, και δείχνει το βήμα όπου σταματά.
Αν το checkout παγώνει στο βήμα χρέωσης ή πληρωμής, δείτε το Magento checkout κολλημένο στο billing.
Συχνές ερωτήσεις
Γιατί χαλάει το checkout του Magento μετά από deploy;
Συνήθως δεν έγινε static content deploy για το θέμα ή τη γλώσσα που τρέχει, οι caches κρατούν παλιές εκδόσεις, ένα update module άλλαξε JavaScript του checkout, οι ρυθμίσεις διαφέρουν ανάμεσα σε περιβάλλοντα, ή ένα Content Security Policy μπλοκάρει script πληρωμής.
Τι τρέχω μετά από deploy στο Magento;
setup:upgrade, setup:di:compile και setup:static-content:deploy για κάθε θέμα και γλώσσα, μετά καθαρισμό cache, και μια πλήρη διαδρομή checkout στην παραγωγή.
Πώς βρίσκω τι χάλασε μετά από deploy;
Ανοίξτε το checkout με ανοιχτή την console του browser: ένα αρχείο RequireJS που απέτυχε, ένα 404 σε static αρχείο ή μια παραβίαση CSP δείχνει την αιτία.