Σταματήστε να Ξαναχτίζετε Κάθε Ιστότοπο WordPress

Σύνοψη

Οι περισσότερες εταιρείες αναπτύσσουν κάθε ιστότοπο WordPress από ένα κενό θέμα, ακόμα και όταν ένα κοινό θεμέλιο θα έκοβε βδομάδες από το χρονοδιάγραμμα. Αυτό το άρθρο υποστηρίζει ότι το theme.json, τα block patterns και τα δυναμικά blocks σάς επιτρέπουν να τυποποιήσετε το δομικό επίπεδο, διατηρώντας παράλληλα τον ξεχωριστό σχεδιασμό κάθε πελάτη. Αντιμετωπίζει άμεσα τις πέντε αντιρρήσεις που εμποδίζουν τις ομάδες να αλλάξουν: «έχουμε διαφορετικούς πελάτες», «τα προσαρμοσμένα blocks είναι ακριβά», «ο επεξεργαστής είναι μπερδεμένος», «θα χάσουμε τα hooks και τα φίλτρα μας» και «το FSE δεν είναι έτοιμο για παραγωγή». Κάθε αντίρρηση λαμβάνει μια πρακτική αντεπιχείρηση και ένα συγκεκριμένο μοτίβο που μπορείτε να υιοθετήσετε σταδιακά. Το κέρδος είναι μια επαναλαμβανόμενη διαδικασία κατασκευής που εξακολουθεί να τιμά την εξατομικευμένη εργασία εκεί που ανήκει. Προειδοποίηση: δεν υπόσχονται κουμπιά επαναφοράς με ένα κλικ.

Πόσοι από τους ιστότοπους των πελατών σας μοιράζονται έστω και μία γραμμή κώδικα; Όχι τη γραμμή πνευματικών δικαιωμάτων—πραγματικός κώδικας. Αν η απάντηση είναι «ελάχιστοι», έχετε ήδη νιώσει τον πόνο: το ίδιο hero section ξαναχτίζεται για ένατη φορά, το ίδιο markup για το grid της ομάδας αντιγράφεται από ένα έργο στο επόμενο, οι ίδιες μικρορυθμίσεις προεπεξεργασίας διασταυρώνονται σε μισή ντουζίνα θέματα. Έχετε ακούσει επίσης την υπεράσπιση: «Κάθε πελάτης έχει διαφορετικές ανάγκες». Σωστό. Το συμπέρασμα όμως που βγάζουν όλοι—ότι κάθε ιστότοπος χρειάζεται ένα εξατομικευμένο θεμέλιο—είναι λάθος. Το οικοσύστημα του WordPress σάς δίνει πλέον τη δυνατότητα να τυποποιήσετε τα δομικά κομμάτια χωρίς να τυποποιήσετε τον σχεδιασμό: theme.json για τα design tokens, block patterns για επαναλαμβανόμενη διάταξη και δυναμικά blocks για τα λίγα χαρακτηριστικά που χρειάζονται πραγματική λογική από την πλευρά του διακομιστή. Αυτό το άρθρο αφορά τις αντιρρήσεις που κρατούν τις εταιρείες από αυτό το βήμα και τι λειτουργεί πραγματικά όταν τις αντικρούετε.

Η αντίρρηση «αλλά κάθε πελάτης είναι διαφορετικός»

Η υποκείμενη αρχή: τυποποιήστε το θεμέλιο, όχι την επιφάνεια. Ο λόγος να κρατάτε τη δομή σε μια κοινή βιβλιοθήκη είναι ακριβώς για να αφήνετε το οπτικό επίπεδο ελεύθερο. Ένα αρχείο theme.json δεν είναι σχεδιασμός—είναι ένα σύνολο design tokens. Χρώματα, αποστάσεις και τυπογραφία είναι τιμές, όχι markup. Αυτή είναι η κρίσιμη αλλαγή: μπορείτε να μοιράζεστε το markup ενώ ένα theme.json ανά ιστότοπο κάνει τον ιστότοπο να φαίνεται εντελώς διαφορετικός για μια διαφορετική μάρκα.

Πάρτε δύο πελάτες: ένα δικηγορικό γραφείο και έναν έμπορο εξοπλισμού εξωτερικού χώρου. Οι σχεδιαστικές τους γλώσσες είναι έτη φωτός μακριά. Αλλά και οι δύο χρειάζονται ένα hero section, ένα grid μαρτυριών, μια ζώνη παρότρυνσης για δράση. Αντί να ξαναχτίζετε το markup για τον καθένα, διατηρήστε τρία block patterns και αφήστε το theme.json κάθε πελάτη να ορίσει χρώματα, γραμματοσειρές και αποστάσεις. Η δομή παραμένει ίδια· τα design tokens τη μετατρέπουν από τη μια μάρκα στην άλλη. Όταν ο έμπορος αλλάξει την παλέτα του την επόμενη άνοιξη, επεξεργάζεστε ένα αρχείο στον ιστότοπό του—όχι το markup σε έξι πρότυπα.

Στην πράξη, αυτό σημαίνει ότι η ομάδα σας δημιουργεί patterns ως κώδικα, τα καταχωρίζει σε ένα κοινό plugin και αφήνει το theme.json σε κάθε ιστότοπο πελάτη να χειριστεί τη βαφή. Τα class names του pattern γίνονται η αρχιτεκτονική σας· οι τιμές γίνονται οι μεταβλητές. Μπορείτε να πάτε ακόμα παραπέρα και να επεκτείνετε το theme.json ώστε να περιλαμβάνει προσαρμοσμένες ρυθμίσεις για τύπους περιεχομένου ή έξοδο plugin, αν και σε κάποιο σημείο χτίζετε μια διεπαφή διαμόρφωσης αντί για ιστότοπο—μια παγίδα που συζητείται στην παρουσίασή μας για την επέκταση του theme.json. Κρατήστε το κοινό επίπεδο λιτό: πρέπει να περιέχει μόνο ό,τι επαναλαμβάνεται σε πελάτες. Τη στιγμή που θα πιάσετε τον εαυτό σας να προσθέτει μια ρύθμιση «μήπως κάποιος τη θελήσει κάποια μέρα», έχετε δημιουργήσει μια αφαίρεση που θα κοστίσει περισσότερο να συντηρηθεί από ό,τι εξοικονομεί.

Όταν ξεκινάτε με έναν νέο πελάτη, τα πρώτα τριάντα λεπτά θα πρέπει να είναι: κλωνοποιήστε το κοινό plugin patterns, δημιουργήστε ένα νέο theme.json με την παλέτα και την κλίμακα γραμματοσειράς του πελάτη και καταχωρίστε το λογότυπο και το υποσέλιδό του. Αυτό δεν είναι προσαρμοσμένη κατασκευή· είναι εργασία διαμόρφωσης. Η υπόλοιπη εργασία που αφορά τον πελάτη πηγαίνει στο περιεχόμενο, τη δομή και σε ό,τι είναι πραγματικά εξατομικευμένο. Αυτή είναι η διαφορά ανάμεσα στο να χτίζεις κάθε σπίτι από την αρχή και στο να έχεις ένα σύνολο προκατασκευασμένων κατόψεων που μπορείς να ξαναβάψεις και να ξαναταπετσάρεις. Η αναλογία είναι χαλαρή, αλλά η αρχή ισχύει: όσο περισσότερο περνάτε σε τιμές theme.json, τόσο λιγότερο χρειάζεται να αγγίξετε το markup.

Ένα από τα πιο απλά κέρδη είναι να δείτε πραγματικά πώς λειτουργούν τα block patterns. Ένα pattern είναι απλώς μια συλλογή blocks με προκαθορισμένο περιεχόμενο και στιλ. Μπορείτε να αποθηκεύσετε οποιαδήποτε διαμόρφωση block ως pattern και οι πελάτες μπορούν να το εισάγουν χωρίς να χρειάζεται να γνωρίζουν πώς είναι κατασκευασμένο. Αυτό σημαίνει ότι το pattern γίνεται «σημείο εισόδου» για μη τεχνικούς χρήστες. Όταν η ομάδα σας συντηρεί το υποκείμενο pattern σε κώδικα, ο πελάτης αποκτά μια συνεπή βιβλιοθήκη χωρίς να αγγίζει ούτε μία ετικέτα PHP.

Τώρα, η προειδοποίηση στην οποία επανέρχομαι: μην υπερκεντροποιείτε. Ένα theme.json με ρύθμιση για κάθε πιθανή απόχρωση είναι ένας βάλτος συντήρησης. Τα κοινά patterns θα πρέπει να έχουν άποψη, όχι να είναι παντοδύναμα. Αν ένας πελάτης χρειάζεται μια ριζικά διαφορετική διάταξη—ας πούμε, μια αρχική σελίδα περιοδικού με ένα μεγάλο προβεβλημένο grid—μπορεί να μην ταιριάζει στην τυπική βιβλιοθήκη patterns σας. Αυτό είναι εντάξει. Τυποποίηση σημαίνει ότι κερδίζετε στο 80% των έργων που είναι παρόμοια, όχι ότι αναγκάζετε κάθε ιστότοπο να γίνει ίδιος.

Η αντίρρηση «τα προσαρμοσμένα blocks ξεπερνούν τον προϋπολογισμό»

Ορίστε μια ανταρχή που ακούγεται βαρετή αλλά εξοικονομεί χρήματα: τα περισσότερα πράγματα που νομίζετε ότι χρειάζονται προσαρμοσμένο block δεν το χρειάζονται. Τα βασικά blocks συν ένα pattern μπορούν να καλύψουν τη συντριπτική πλειονότητα των διατάξεων. Το προσαρμοσμένο block είναι η έσχατη λύση, όχι η πρώτη πρόθεση.

Το κλασικό παράδειγμα είναι το grid της ομάδας. Αν είναι μοναδικό, χρησιμοποιήστε τα βασικά blocks «στήλες» και «ομάδα» και αφήστε τον πελάτη να προσθέσει ένα avatar χειροκίνητα. Αν τρεις πελάτες ζητήσουν το ίδιο grid με την ίδια δομή «σύνδεσμοι κοινωνικών κάτω από το όνομα», τώρα έχετε υποψήφιο για block pattern. Όταν αυτό το pattern αρχίσει να συγκεντρώνει νέες επιλογές—εφέ hover, ταξινόμηση, αστέρια αξιολόγησης—το pattern γίνεται ένα μη διαχειρίσιμο συνονθύλευμα, και τότε είναι ώρα να γράψετε ένα προσαρμοσμένο block. Το λάθος που χτυπά τον προϋπολογισμό είναι να πηδήξετε κατευθείαν στο προσαρμοσμένο block με το πρώτο αίτημα.

Ένα πιο ύπουλο σενάριο: ο πελάτης ζητά «carousel μελέτης περίπτωσης». Το πρώτο ένστικτο είναι να σκεφτείτε: «Χρειάζομαι ένα block carousel». Αλλά χρειάζεται πραγματικά carousel; Ίσως χρειάζονται μια οριζόντια κυλιόμενη ομάδα αναρτήσεων, την οποία τα βασικά blocks μπορούν να διαχειριστούν με ένα block «ομάδα» και λίγο CSS. Ή ίσως χρειάζονται μια δυναμική λίστα πρόσφατων μελετών περίπτωσης, που είναι ένα δυναμικό block που κάνει ερώτημα στο CPT. Το ερώτημα δεν είναι «ποιο χαρακτηριστικό θέλει ο πελάτης;» αλλά «σε ποια δεδομένα εξαρτάται;» Αν τα δεδομένα είναι στατικά και επεξεργάσιμα από τον πελάτη, ένα pattern αρκεί. Αν τα δεδομένα προέρχονται από ερώτημα βάσης δεδομένων, ένα δυναμικό block δικαιολογείται. Αν τα δεδομένα πρέπει να ενημερώνονται σε πραγματικό χρόνο από ένα API, μάλλον κοιτάτε μια ενοποίηση REST API—αυτό μπαίνει σε διαφορετικό είδος κατασκευής.

Όταν τελικά χτίζετε ένα block, το block.json είναι ο φίλος σας. Είναι η μοναδική πηγή αλήθειας για χαρακτηριστικά, σενάρια και στιλ, γεγονός που καθιστά το φορητό σε όλα τα έργα. Σας επιτρέπει επίσης να δηλώνετε εξαρτήσεις και μεταφράσεις με καθαρό τρόπο, κάτι που είναι απαραίτητο όταν διανέμετε μια βιβλιοθήκη σε πολλούς ιστότοπους πελατών. Για περιεχόμενο που εξαρτάται από ζωντανά δεδομένα, ένα δυναμικό block αποδίδεται στον διακομιστή, οπότε δεν χρειάζεται να στείλετε ένα πακέτο JavaScript σε κάθε προβολή σελίδας. Και αν το block σας εξελίσσεται, μπορείτε να χειριστείτε τις καταργήσεις με χάρη ώστε το υπάρχον περιεχόμενο να μην σπάσει—ο οδηγός μας για την κατάργηση block εξετάζει το ακριβές μοτίβο.

Πριν φτιάξετε οτιδήποτε, περάστε την απόφαση από αυτό το πλέγμα:

Προσέγγιση	Καλύτερο για	Αποφύγετε όταν
Βασικό block	Μεμονωμένο περιεχόμενο, απλές σελίδες	Η διάταξη επαναλαμβάνεται σε πολλούς πελάτες και χρειάζεται πλούσιες επιλογές
Block pattern	Επαναλαμβανόμενες διατάξεις χωρίς λογική	Η διάταξη χρειάζεται υποθέσεις, δυναμικά δεδομένα ή πολύπλοκες αλληλεπιδράσεις
Προσαρμοσμένο block	Επαναλαμβανόμενη, βασισμένη σε δεδομένα ή εξαιρετικά συγκεκριμένη συμπεριφορά	Ο μόνος λόγος είναι ένα μεμονωμένο τμήμα που μπορεί να αντιμετωπιστεί με μια κλάση

Θα πρέπει επίσης να σκεφτείτε την ονομασία των blocks από την πρώτη μέρα. Ένα όνομα block είναι ουσιαστικά μια σύμβαση με το περιεχόμενό σας. Αν το ονομάσετε wagent/team-grid και αργότερα το μετονομάσετε σε wagent/team-carousel, θα σπάσετε το υπάρχον περιεχόμενο εκτός αν παρέχετε μια διαδρομή κατάργησης. Επιλέξτε γενικά ονόματα βασισμένα στον σκοπό, που δεν θα γίνουν παραπλανητικά καθώς το block εξελίσσεται. Αυτή είναι μια γεύση από την πειθαρχία ονομασίας που όλοι έχουμε μάθει από τα προθέματα plugin, και ισχύει εξίσου και για τα ονόματα blocks.

Η αντίθετη άποψη εδώ είναι το πιο χρήσιμο πράγμα που μπορώ να πω: το προσαρμοσμένο block που χτίζετε επειδή ένας πελάτης ζήτησε «μόνο ένα κομμάτι» είναι σχεδόν πάντα λάθος. Πείτε όχι ευγενικά, στείλτε ένα βασικό block με μια κλάση και κερδίστε ώρες. Θα έχετε περισσότερο σεβασμό από τον πελάτη—και μια μικρότερη γραμμή στον προϋπολογισμό συντήρησης.

Η αντίρρηση «οι πελάτες θα σπάσουν τον επεξεργαστή»

Αυτή η αντίρρηση είναι μισή σωστή. Ο ίδιος ο επεξεργαστής block δεν είναι το πρόβλημα· το πρόβλημα είναι να δίνετε στους πελάτες πάρα πολύ σχοινί. Το theme.json μπορεί να κλειδώσει ό,τι είναι επεξεργάσιμο: να απενεργοποιήσει τον επεξεργαστή προτύπων, να περιορίσει τα επιτρεπόμενα blocks και να ορίσει προεπιλεγμένα στιλ ώστε μια λάθος τοποθετημένη στήλη να κάνει λιγότερη ζημιά. Ορισμένοι πελάτες θα καταφέρουν πάντως να σπάσουν πράγματα, αλλά μπορείτε να επαναφέρετε μια σελίδα σε ένα αποθηκευμένο pattern με ένα κλικ—κάτι που ο κλασικός επεξεργαστής δεν μπορούσε να προσφέρει.

Επιτρέψτε μου να περιγράψω ένα σενάριο. Ένας πελάτης καλεί και λέει: «Μετακίνησα ένα τμήμα και τώρα όλη η σελίδα φαίνεται λάθος». Με ένα κλασικό θέμα, θα συνδεόσασταν, θα ελέγχατε το CSS και μάλλον θα ξοδεύατε μια ώρα για να διορθώσετε τη διάταξη. Με μια ρύθμιση block, μπορείτε να ανοίξετε τη σελίδα, να επιλέξετε την περιοχή περιεχομένου και να την επαναφέρετε στο αποθηκευμένο pattern. Το pattern είναι η βασική γραμμή· οι αλλαγές του πελάτη είναι η επικάλυψη. Όταν η επικάλυψη πάει στραβά, την αφαιρείτε. Αυτό δεν είναι απλώς μια καλύτερη ροή εργασίας· είναι ένας θεμελιωδώς πιο ανεκτικός επεξεργαστής.

Τώρα η απόχρωση: οι περισσότεροι πελάτες δεν θέλουν να επεξεργάζονται και πολλά. Θέλουν να αλλάξουν κείμενο, να αντικαταστήσουν φωτογραφίες και ίσως να αναδιατάξουν μια ενότητα. Το block pattern σάς δίνει ακριβώς αυτό χωρίς να εκθέτει ολόκληρη τη δομή του ιστότοπου. Υπό αυτή την έννοια, ο επεξεργαστής δεν είναι παιχνίδι· είναι ένας σκόπευλος. Η δουλειά σας είναι να βαθμονομήσετε τι μπορούν να δουν οι πελάτες. Αυτό σημαίνει ότι μπορεί να απενεργοποιήσετε τις ρυθμίσεις «Πρότυπα», να περιορίσετε τον εισαγωγέα blocks σε μια επιμελημένη λίστα και ακόμη να προ-συμπληρώσετε κενά patterns με προσωρινό περιεχόμενο. Ο επεξεργαστής γίνεται φόρμα εισαγωγής περιεχομένου αντί για καμβά σχεδιασμού ιστού.

Από την πλευρά της προσβασιμότητας, η διαχείριση εστίασης και η υποστήριξη πληκτρολογίου του επεξεργαστή block είναι γενικά καλύτερες από τα πεδία προτύπων ενός κλασικού επεξεργαστή. Αλλά πρέπει να διασφαλίσετε ότι τα patterns έχουν σωστή ιεραρχία επικεφαλίδων και προσβάσιμα ονόματα. Επειδή το pattern είναι κοινόχρηστο σε όλους τους πελάτες, διορθώνετε αυτά τα ζητήματα μόνο μία φορά, που είναι ένα άλλο κρυφό κέρδος της τυποποίησης.

Το πραγματικά δύσκολο κομμάτι είναι εσωτερικό. Για την ομάδα σας, το να μάθετε να δημιουργείτε πρωτότυπα με blocks απαιτεί να ξεμάθετε τη συνήθεια «κάνε το σε PHP». Αυτό είναι ένα πραγματικό κόστος, αλλά είναι ένα εφάπαξ κόστος ανά άτομο. Δεν είναι λόγος να αποφύγετε την προσέγγιση· είναι λόγος να ξεκινήσετε με μία βιβλιοθήκη patterns και έναν συγχωρητικό πελάτη πριν το εφαρμόσετε παντού. Μην αφήσετε το σύνθημα «οι πελάτες μου δεν μπορούν να χειριστούν blocks» να κρύψει το γεγονός ότι δεν έχετε ακόμη διαμορφώσει μια ρύθμιση block που να τους βγαίνει στη μέση.

Η αντίρρηση «έχουμε ήδη hooks και φίλτρα»

Η αρχή εδώ είναι: δεν πετάτε τα hooks· προσθέτετε ένα επίπεδο από πάνω. Τα blocks είναι το όριο παρουσίασης· τα hooks είναι ακόμα ο τρόπος με τον οποίο εισάγετε λογική. Το callback απόδοσης ενός δυναμικού block εκτελείται σε PHP, πράγμα που σημαίνει ότι μπορείτε να καλέσετε τις ίδιες συναρτήσεις και να εφαρμόσετε τα ίδια φίλτρα που ήδη εμπιστεύεστε.

Φανταστείτε ένα plugin που σας επιτρέπει να προσθέσετε ένα πεδίο «προτεινόμενο προϊόν» σε οποιαδήποτε ανάρτηση χρησιμοποιώντας ένα φίλτρο. Με ένα δυναμικό block, μπορείτε να συμπεριλάβετε ένα block που αποδίδεται στον διακομιστή, το οποίο τρέχει αυτό το φίλτρο και εκτυπώνει την έξοδο μέσα στο περιτύλιγμα του block. Ο πελάτης εισάγει το block· η υπάρχουσα λογική PHP κάνει τη δύσκολη δουλειά. Δεν πετιέται τίποτα. Για ένα ακόμα πιο συγκεκριμένο παράδειγμα, σκεφτείτε ένα προσαρμοσμένο block που παραθέτει πρόσφατες αναρτήσεις έργων. Στο callback απόδοσής του, καλείτε get_posts(), μετά κάνετε βρόχο και εφαρμόζετε the_title() και the_permalink()—τις ίδιες ετικέτες προτύπου που χρησιμοποιείτε εδώ και χρόνια.

Εδώ είναι επίσης το σημείο να είμαστε ειλικρινείς για το τι δεν μεταφράζεται. Ορισμένα έξυπνα παλιά θέματα χρησιμοποιούν template-parts με περίπλοκες υποθέσεις που δέχονται επιχειρήματα με βάση τα συμφραζόμενα της σελίδας. Το να το αναδημιουργήσετε ως block μπορεί να είναι ακατάστατο. Αλλά δεν χρειάζεται να το αναδημιουργήσετε όλο ταυτόχρονα. Η σταδιακή διαδρομή είναι να κρατήσετε τη λογική PHP, να την τυλίξετε σε ένα δυναμικό block και να μετακινήσετε το markup στο πρότυπο του block. Συχνά θα διαπιστώσετε ότι τα υπάρχοντα μοτίβα φίλτρων μπορούν να χειριστούν τη νέα έξοδο. Και αν η λογική είναι στενά συνδεδεμένη με μια ιεραρχία προτύπων (π.χ., «στα αποτελέσματα αναζήτησης, δείξε το διαφορετικά»), μπορείτε να χρησιμοποιήσετε το κλασικό πρότυπο για αυτές τις συγκεκριμένες προβολές ενώ χρησιμοποιείτε blocks για κανονικές σελίδες.

Το REST API ανοίγει επίσης μια διαφορετική πόρτα: μπορείτε να δημιουργήσετε blocks που αντλούν δεδομένα από άλλους ιστότοπους WordPress ή υπηρεσίες τρίτων. Ένα δυναμικό block μπορεί να καλέσει wp_remote_get() για να φέρει JSON και να το αποδώσει στο front end. Αυτό είναι ένα ισχυρό μοτίβο για κατασκευές εταιρειών όπου οι πελάτες θέλουν να δείχνουν social feeds, λίστες προϊόντων ή εσωτερικά δεδομένα χωρίς να διαχειρίζονται μια ξεχωριστή ενοποίηση. Το αντάλλαγμα είναι η προσωρινή αποθήκευση και η διαχείριση σφαλμάτων—αν το απομακρυσμένο API είναι αργό, η σελίδα σας είναι αργή. Κρατήστε τα blocks που βασίζονται σε API μακριά από κρίσιμο περιεχόμενο πάνω από την πτυχή ή χρησιμοποιήστε απόδοση από την πλευρά του πελάτη με σωστή κατάσταση φόρτωσης.

Τα actions και τα φίλτρα εξακολουθούν να εκτελούνται γύρω από την αποθήκευση και την απόδοση· η αρχιτεκτονική hooks δεν εξαφανίζεται όταν υιοθετείτε blocks, απλώς μετακινείται σε νέο πλαίσιο. Αν χρειάζεται να ανανεώσετε την κατανόησή σας για το πού συναντιούνται τα actions και τα φίλτρα με αυτόν τον νέο κόσμο blocks, η βαθιά κατάδυσή μας στα hooks είναι μια χρήσιμη υπενθύμιση.

Η αντίρρηση «το FSE δεν είναι έτοιμο για παραγωγή»

Δίκαιο, αλλά ρωτήστε τι σημαίνει πραγματικά «επικίνδυνο». Το Full Site Editing έχει περάσει από πολλές εκδόσεις και το theme.json έχει σταθεροποιηθεί σε ένα σταθερό σχήμα. Ο κίνδυνος δεν είναι ότι ο επεξεργαστής «σπάει ξαφνικά»—ο κίνδυνος είναι ότι ο προσαρμοσμένος κώδικας της ομάδας σας μπορεί να βασίζεται σε παλιά πρότυπα PHP που συνυπάρχουν άβολα με τα πρότυπα block. Επίσης, ορισμένα plugins τρίτων εξακολουθούν να υποθέτουν τον κλασικό επεξεργαστή ή τον προσαρμογέα. Αυτό είναι μια απόφαση συμβατότητας, όχι λόγος να πετάξετε όλο το μοντέλο.

Ένας χρήσιμος τρόπος να το σκεφτείτε: οι απλοί, επαναλαμβανόμενοι ιστότοποι με περιεχόμενο γραμμένο σε blocks είναι οι λιγότερο επικίνδυνοι. Οι πελάτες υψηλού κινδύνου είναι εκείνοι με βαθιά προσαρμοσμένα κλασικά θέματα ή ιδιόκτητα plugins που αποδίδουν το δικό τους front-end. Αυτός είναι ένας θεμιτός λόγος να μείνετε στα κλασικά θέματα για αυτή τη μικρή θέση. Το λάθος είναι να προσποιείστε ότι το «έτοιμο για παραγωγή» είναι ένας διακόπτης που είναι είτε ανοιχτός είτε κλειστός.

Πριν προτείνετε ένα θέμα block σε έναν πελάτη, περάστε από μια γρήγορη λίστα ελέγχου:

• Έχει ο πελάτης ένα θέμα με μεγάλη προσαρμογή που θα απαιτούσε μετεγκατάσταση;
• Υποστηρίζουν τα απαραίτητα plugins τον Επεξεργαστή Ιστότοπου και το REST API;
• Επιτρέπει το περιβάλλον φιλοξενίας την πρόσβαση σε αρχεία που αναμένει το θέμα block;
• Έχετε διαθέσει χρόνο για τον σχεδιασμό patterns, όχι μόνο για την καταχώριση blocks;
• Θα ανεχθεί η ομάδα του πελάτη τις αλλαγές στον επεξεργαστή ή χρειάζονται κλειδωμένο πρότυπο;

Αν οποιαδήποτε απάντηση είναι όχι, προσαρμόστε το εύρος ή χρησιμοποιήστε μια υβριδική προσέγγιση. Αυτό δεν είναι συμβιβασμός· είναι μηχανική κρίση. Και αν χτίζετε ένα υβριδικό σύστημα, θυμηθείτε την ιστορία με hooks και φίλτρα παραπάνω—μπορείτε ακόμα να τυλίξετε την παλιά λογική σε δυναμικά blocks ενώ το theme.json διαχειρίζεται τη συνολική εμφάνιση.

Η έκδοση του theme.json δεν είναι μόνο θεωρητική ανησυχία. Έχω δει τη βιβλιοθήκη προσαρμοσμένων blocks μιας εταιρείας να σπάει όταν ο πελάτης ενημέρωσε το WordPress και το αρχείο style του block καταχωρήθηκε με το wp_register_style() με αλλαγμένο handle. Η διόρθωση ήταν εύκολη, αλλά ο πανικός ήταν πραγματικός. Μια απλή διαδικασία δοκιμής—εκτελέστε την ενημέρωση σε ένα αντίγραφο staging του ιστότοπου, περιηγηθείτε στις βασικές σελίδες και μετά δημοσιεύστε—λύνει τα περισσότερα από αυτά τα απρόοπτα.

Η αντίρρηση που δεν έχετε πει στον εαυτό σας

Ορίστε η μετα-αντίρρηση που εμποδίζει τις εταιρείες να τυποποιήσουν: «Είναι μια μεγάλη αλλαγή και δεν υπάρχει χρόνος να την κάνουμε κατά τη διάρκεια εργασιών για πελάτες». Αυτό είναι αλήθεια—οπότε μην την κάνετε κατά τη διάρκεια εργασιών για πελάτες. Επιλέξτε ένα εσωτερικό έργο ή έναν μικρό πελάτη και φτιάξτε μία βιβλιοθήκη patterns. Χρησιμοποιήστε το theme.json ως σύστημα design tokens. Προσθέστε προσαρμοσμένο block μόνο όταν δικαιολογείται. Τυλίξτε τα παλιά hooks όπου βοηθούν. Επαναλάβετε.

Ορίστε ένα πρόχειρο πρώτο 30ήμερο:

1. Ελέγξτε τις τελευταίες πέντε κατασκευές για πελάτες και καταγράψτε τα δέκα πιο επαναλαμβανόμενα κομμάτια διάταξης.
2. Μετατρέψτε αυτά τα δέκα κομμάτια σε block patterns, με ένα μικρό σύνολο κλάσεων CSS.
3. Δημιουργήστε ένα κοινό plugin (ή mu-plugin) που καταχωρίζει αυτά τα patterns. Αν δεν έχετε σκεφτεί την οργάνωση plugin για αυτό, ρίξτε μια ματιά σε αυτόν τον οδηγό για την κατασκευή ισχυρών plugins πρώτα.
4. Δημιουργήστε ένα theme.json που ταιριάζει με τον βασικό σχεδιασμό σας· προσθέστε τιμές ειδικές για κάθε πελάτη καθώς ξεκινάτε έργα.
5. Επιλέξτε ένα μικρό εσωτερικό έργο ή έναν φιλικό πελάτη και μεταφέρετέ το στη στοίβα.
6. Τεκμηριώστε μια ιστορία επιτυχίας ενός πελάτη που επεξεργάστηκε την αρχική του σελίδα χωρίς να σας καλέσει.

Στο τέλος αυτού του πειράματος, δεν θα έχετε ένα σήμα «block-first» για να το κρεμάσετε στον τοίχο. Θα έχετε μια ομάδα που μπορεί να δημιουργήσει έναν νέο ιστότοπο πελάτη από μια κοινή βάση χωρίς να ζητά συγγνώμη για το χρονοδιάγραμμα. Θα είστε επίσης σε καλύτερη θέση να πείτε όχι στο αίτημα του πελάτη για ένα 42ο προσαρμοσμένο block—επειδή ξέρετε ακριβώς τι μπορούν να κάνουν τα βασικά blocks ή επειδή μπορείτε να δείξετε γιατί ένα δυναμικό block θα ήταν πραγματικά πιο γρήγορο.

Θα εξακολουθήσετε να χτίζετε μερικούς εξατομικευμένους ιστότοπους; Ναι. Ορισμένοι πελάτες θα χρειάζονται πάντα ένα προσαρμοσμένο πρότυπο, μια εξατομικευμένη σελίδα ή μια ιδιόκτητη ενοποίηση που δεν αξίζει να πιεστεί στο κοινό μοντέλο. Ο στόχος δεν είναι να εξαλείψετε την εξατομικευμένη εργασία—είναι να την κάνετε εξαίρεση αντί για κανόνα.

Η επαναληψιμότητα προέρχεται από τα βαρετά μέρη: ένα σταθερό σχήμα theme.json, μια σαφή βιβλιοθήκη patterns και η πειθαρχία να κρατάτε το κοινό επίπεδο λιτό. Αυτή δεν είναι η λαμπερή εκδοχή που ακούτε σε webinars. Είναι αυτή που νικά τη Δευτεριάτικη μελαγχολία του κενού θέματος.