Ένας από τους καλύτερους τρόπους για να βελτιώσετε την κατάστασή σας ως Προγραμματιστής WordPress , τουλάχιστον στα μάτια των πελατών σας, είναι να εξοικειωθείτε με την κατανάλωση API. Ακολουθεί ένα κοινό σενάριο για την εφαρμογή API του WordPress: Ο πελάτης σας σας ζητά να προσθέσετε ένα widget στον ιστότοπό του — ας πούμε, για παράδειγμα, ένα widget συνδρομής μέσω email. Παίρνετε κάποιον κωδικό από την υπηρεσία ηλεκτρονικού ταχυδρομείου τρίτου μέρους τους - ίσως είναι μια ετικέτα σεναρίου ή μια iframe - επικολλήστε τη στη σελίδα και απαντήστε στον πελάτη σας, 'Το κατάλαβα!'

Δυστυχώς, αντιμετωπίζετε έναν κάπως πιο απαιτητικό πελάτη και παρατηρούν τις ακόλουθες ατέλειες:

• Παρόλο που το widget, όπως και ο υπόλοιπος ιστότοπος, διαθέτει γραμματοσειρά sans-serif, δεν είναι το σωστό. Το widget χρησιμοποιεί το Helvetica αντί της προσαρμοσμένης γραμματοσειράς που έχετε εγκαταστήσει.
• Η φόρμα συνδρομής του widget ενεργοποιεί μια νέα φόρτωση σελίδας, η οποία μπορεί να είναι ενοχλητική εάν τοποθετηθεί στα μισά του άρθρου.
• Το widget φαίνεται να παίρνει μια επιπλέον στιγμή για να φορτώσει μετά την υπόλοιπη σελίδα, κάτι που αισθάνεται ενοχλητικό και φθηνό.
• Ο πελάτης θα ήθελε οι συνδρομητές να επισημαίνονται με μεταδεδομένα με βάση την ανάρτηση από την οποία εγγράφηκαν και το widget δεν προσφέρει τίποτα που μοιάζει με αυτήν τη λειτουργικότητα.
• Ο πελάτης το θεωρεί ενοχλητικό που θα πρέπει τώρα να διαχειριστούν δύο πίνακες ελέγχου (wp-admin και την περιοχή διαχειριστή για την υπηρεσία email).

Σε αυτό το σημείο, ένα από τα δύο πράγματα μπορεί λογικά να συμβεί. Θα μπορούσατε να δηλώσετε αυτά τα αντικείμενα 'ωραία-χαίροντα' και να διαβεβαιώσετε τον πελάτη σας για τα πλεονεκτήματα ενός 80/20 λύση , ή θα μπορούσατε να ανταποκριθείτε σε αυτά τα αιτήματα. Από την προσωπική μου εμπειρία, έχω διαπιστώσει ότι η παροχή τέτοιων αιτημάτων - δηλαδή, η απόδειξη της γνώσης των υπηρεσιών τρίτων - είναι ένας αξιόπιστος τρόπος για να πείσετε τον πελάτη ότι είστε ένας μάγος WordPress. Επιπλέον, είναι συχνά διασκεδαστικό να το κάνετε.

Κατά την τελευταία δεκαετία, έχω χρησιμοποιήσει το WordPress ως πλατφόρμα κατανάλωσης API έναντι πιθανώς 50 διαφορετικών API. Μερικά από τα πιο συνηθισμένα API ήταν το MailChimp, το Google Analytics, οι Χάρτες Google, το CloudFlare και το Bitbucket. Τι γίνεται όμως αν πρέπει να κάνετε περισσότερα, τι γίνεται αν χρειάζεστε μια προσαρμοσμένη λύση;

Πώς να αναπτύξετε έναν πελάτη API του WordPress

Σε αυτό το άρθρο, πρόκειται να αναπτύξω ένα γενικό API 'υπηρεσίας email', προσπαθώντας το καλύτερό μου για να κρατήσω τα πράγματα όσο το δυνατόν πιο αγνωστικά. Ωστόσο, πιστεύω ότι είναι λογικό να υποθέσουμε ότι ασχολούμαστε με ένα JSON REST API. Ακολουθούν ορισμένα θέματα που μπορούν να σας βοηθήσουν να απολαύσετε τα τεχνικά σημεία σε αυτό το άρθρο:

• Το WordPress Οικογένεια λειτουργιών HTTP
• JSON
• ΥΠΟΛΟΙΠΟ

Εάν βρίσκεστε οριακά εξοικειωμένοι με αυτά τα θέματα και ενδιαφέρεστε να σκάψετε βαθύτερα, κάντε παύση τώρα και κατεβάστε το εξαιρετικό Ταχυδρόμος εφαρμογή. Σας επιτρέπει να επικοινωνείτε με API χωρίς να γράφετε κώδικα.

Ταχυδρόμος. Ίσως το αγαπημένο μου εργαλείο ανάπτυξης;

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

Σημείωση: Σε περίπτωση που χρειάζεστε ένα γρήγορο μάθημα ανανέωσης, μπορείτε να δείτε το δικό μας Οδηγός API REST WordPress .

Χωρίς άλλο προοίμιο, επιτρέψτε μου να μοιραστώ μαζί σας μια χούφτα διαφορετικών τεχνικών που εκτιμώ τον εαυτό μου σε κάθε API, έργο και ομάδα με την οποία εργάζομαι.

Μεταβατικά: Πότε να τα κρατήσετε, Πότε να τα διπλώσετε

Στην αρχική μου παράγραφο, σημείωσα ότι ο πελάτης το θεωρούσε ενοχλητικό να διασχίζει δύο περιοχές διαχειριστή: wp-admin και τον πίνακα ελέγχου για την υπηρεσία email τους. Ένας καλός τρόπος για να επιλύσετε αυτό θα ήταν να τους παρέχετε ένα widget πίνακα εργαλείων στο wp-admin, για να δείξετε μια σύνοψη της πρόσφατης δραστηριότητας των συνδρομητών τους.

Ένα παράδειγμα του τύπου της διεπαφής χρήστη του πίνακα ελέγχου που ενδέχεται να παρέχουμε στο WordPress, για να σώσουμε τους πελάτες μας ένα ταξίδι στον τρίτο πάροχο υπηρεσιών email.

Αλλά και πάλι, αυτό θα μπορούσε να απαιτεί πολλαπλά αιτήματα HTTP στο απομακρυσμένο API (το API που παρέχεται από την υπηρεσία email), με αποτέλεσμα τη φόρτωση μεγάλων σελίδων. Η λύση σε αυτό το πρόβλημα απόδοσης είναι η αποθήκευση κλήσεων API ως παροδικών. Αυτό Άρθρο Codex παρέχει μια εξαιρετική εξήγηση που πρέπει σίγουρα να διαβάσετε, αλλά θα το συνοψίσω έτσι:

1. Λάβετε τα δεδομένα από το απομακρυσμένο API.
2. Αποθηκεύστε το χρησιμοποιώντας set_transient() με χρόνο λήξης της επιλογής σας με βάση τη δική σας κρίση σχετικά με την απόδοση, τα όρια τιμών και το περιθώριο σφάλματος στην εμφάνιση ξεπερασμένων δεδομένων σε αυτήν τη συγκεκριμένη εφαρμογή.
3. Προχωρήστε στη λογική της επιχείρησής σας - επεξεργαστείτε τα δεδομένα, επιστρέφοντας μια τιμή, ανεξάρτητα από την περίπτωση.
4. Όταν χρειάζεστε ξανά τα δεδομένα, όπως στην επόμενη φόρτωση σελίδας, ελέγξτε τα στην προσωρινή προσωρινή μνήμη χρησιμοποιώντας get_transient() πριν καταλήξετε στο συμπέρασμα ότι πρέπει να το λάβετε από το API.

Θεωρώ ότι αυτό είναι ένα χρήσιμο και βιώσιμο θεμέλιο, αλλά μπορείτε να το πάρετε ένα βήμα παραπέρα εάν σκεφτείτε για λίγο για τα ρήματα REST. Από τις πέντε πιο κοινές μεθόδους (GET, POST, PATCH, PUT, DELETE), μόνο μία από αυτές ανήκει στην προσωρινή προσωρινή μνήμη. Μπορείτε να μαντέψετε ποιο; Είναι. Στις προσθήκες μου, έχω σχεδόν πάντα μια κλάση PHP αφιερωμένη στην απόκρυψη κλήσεων στο απομακρυσμένο API και ένα επιχείρημα κατά την παρουσίαση αυτής της κλάσης είναι η μέθοδος HTTP. Εάν δεν είναι μια κλήση GET, τότε δεν πρόκειται να επικαλεστώ καθόλου επίπεδο προσωρινής αποθήκευσης.

Επιπλέον, εάν δεν είναι μια κλήση GET, τότε είναι λογικό να κάνω κάποια ενέργεια για να αλλάξω τα απομακρυσμένα δεδομένα με κάποιο τρόπο, ίσως προσθέτοντας, επεξεργάζοντας ή αφαιρώντας έναν συνδρομητή email. Μπορεί να είναι η κατάλληλη στιγμή για να ακυρώσετε την υπάρχουσα προσωρινή μνήμη για αυτόν τον πόρο, μέσω delete_transient().

Για να επιστρέψετε στο παράδειγμά μας ενός API συνδρομής email στο WordPress, δείτε πώς θα λειτουργούσε στην πράξη:

• Ένα widget πίνακα ελέγχου για την εμφάνιση πρόσφατων συνδρομητών θα καλέσει το τελικό σημείο του API για /subscribers μέσω αίτησης GET. Επειδή είναι ένα αίτημα GET, αποθηκεύεται στην προσωρινή μου προσωρινή μνήμη.
• Ένα widget πλευρικής γραμμής για εγγραφή στη λίστα email θα καλέσει το τελικό σημείο του API για το /subscribers μέσω ενός αιτήματος POST. Επειδή πρόκειται για αίτημα POST, όχι μόνο θα αποφύγει την προσωρινή προσωρινή μνήμη μου, αλλά θα με προκαλέσει να διαγράψω το σχετικό μέρος της προσωρινής προσωρινής μνήμης μου, έτσι ώστε το γραφικό στοιχείο του πίνακα ελέγχου να αντικατοπτρίζει αυτόν τον νέο συνδρομητή.
• Κατά την ονομασία παροδικών, συχνά τα οργανώνω ονομαστικά κυριολεκτικά μετά την απομακρυσμένη διεύθυνση URL API που καλώ. Αυτός είναι ένας εύχρηστος τρόπος αναγνώρισης του σωστού παροδικού προς διαγραφή. Εάν είναι ένα τελικό σημείο που παίρνει επιχειρήματα, θα τα συνδυάσω σε μια συμβολοσειρά και θα τα προσθέσω και στο παροδικό όνομα.

Ως πελάτης ή άλλος λιγότερο τεχνικός ενδιαφερόμενος, θα πρέπει να ζητάτε συγκεκριμένα προσωρινή προσωρινή αποθήκευση - ή τουλάχιστον μια συζήτηση σχετικά με αυτό - κάθε φορά που η εφαρμογή αντλεί δεδομένα από μια απομακρυσμένη υπηρεσία. Θα πρέπει να εξοικειωθείτε με το εξαιρετικό Παρακολούθηση ερωτημάτων plugin για να δείτε πώς λειτουργούν τα μεταβατικά. Θα σας δώσει μια διεπαφή για περιήγηση σε ποια δεδομένα αποθηκεύονται ως παροδικά, πόσο συχνά και για πόσο καιρό.

Μερικές φορές τα μεταβατικά δεν είναι αρκετά καλά

Ορισμένες premium υπηρεσίες φιλοξενίας WordPress δεν σας επιτρέπουν να χρησιμοποιείτε μεταβατικά στην παραγωγή. Έχουν κώδικα που τρέχει, ίσως με τη μορφή προσθήκης MU ή κάποιου άλλου σεναρίου, που θα υποκλέψει την προσπάθειά σας να χρησιμοποιήσετε το μεταβατικό API και να αποθηκεύσετε αυτές τις πληροφορίες μέσω του προσωρινή μνήμη αντικειμένου αντι αυτου. WP-Engine , στην πιο κοινή του διαμόρφωση, είναι ένα πρωταρχικό παράδειγμα αυτού.

Ένα ανησυχητικό θέαμα στο phpMyAdmin UI: Ένας ιστότοπος παραγωγής εντελώς χωρίς μεταβατικά; Αυτό πιθανότατα σημαίνει ότι η προσωρινή αποθήκευση αντικειμένων λειτουργεί.

Εάν απλώς αποθηκεύετε και ανακτάτε δεδομένα, στην πραγματικότητα δεν χρειάζεται να ανησυχείτε για αυτό και μπορεί ποτέ να μην παρατηρήσετε ότι συμβαίνει. Ολόκληρη η οικογένεια *_transient() Οι λειτουργίες θα σας προσφέρουν το ίδιο τελικό αποτέλεσμα, απλώς φιλτραρισμένο για χρήση της προσωρινής μνήμης αντικειμένου αντί της προσωρινής προσωρινής μνήμης. Όπου μπορεί να αντιμετωπίσετε προβλήματα, ωστόσο, είναι όταν προσπαθείτε να διαγράψετε μεταβατικά. Να γιατί.

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

Ένα παράδειγμα διεπαφής χρήστη που επιτρέπει στον πελάτη να αδειάσει την τοπική προσωρινή μνήμη για τα δεδομένα του API.

Ακόμα κι αν ήσασταν αρκετά έξυπνοι για να ορίσετε όλα τα προσωρινά κλειδιά σας, ώστε να έχετε κάποια ελπίδα να προσδιορίσετε καθένα από αυτά για delete_transient(), το καλύτερο σενάριο πιθανότατα εξακολουθεί να περιλαμβάνει την πρώτη SQL, την οποία προσπαθώ πάντα να αποφεύγω στο WordPress :

get_transient_prefix() ); $options = $wpdb -> options; $t = esc_sql( '_transient_timeout_$prefix%' ); $sql = $wpdb -> prepare ( ' SELECT option_name FROM $options WHERE option_name LIKE '%s' ', $t ); $transients = $wpdb -> get_col( $sql ); // For each transient... foreach( $transients as $transient ) { // Strip away the WordPress prefix in order to arrive at the transient key. $key = str_replace( '_transient_timeout_', '', $transient ); // Now that we have the key, use WordPress core to the delete the transient. delete_transient( $key ); } } ?>

Δεν είναι βολικό, δεν είναι αποτελεσματικό. Αντ 'αυτού, αυτή η κατάσταση απαιτεί προσωρινή αποθήκευση αντικειμένων επειδή η προσωρινή αποθήκευση αντικειμένων μας δίνει έναν βολικό τρόπο για να ομαδοποιήσουμε τις προσωρινές τιμές . Με αυτόν τον τρόπο, όταν πρέπει να αδειάσετε όλες τις προσωρινά αποθηκευμένες τιμές που σχετίζονται με την προσθήκη σας, είναι μια απλή κλήση μίας γραμμής προς wp_cache_delete( $key, $group ).

Θα τα συνοψίσω όλα αυτά λέγοντας: Δεν μπορείτε να είστε ειδικός στην κατανάλωση API εάν δεν είστε ακόμη ειδικός στη διαχείριση της προσωρινής μνήμης για αυτά τα δεδομένα.

Ως πελάτης, το βασικό πράγμα που πρέπει να προσέξετε είναι η παρεκκλίνουσα συμπεριφορά προσωρινής αποθήκευσης μεταξύ των σταδίων και των παραγωγικών περιβαλλόντων. Με άλλα λόγια, αν και η δοκιμή μιας νέας παρτίδας εργασίας στη σταδιοποίηση είναι πάντα μια καλή πρακτική, η προσωρινή αποθήκευση είναι κάτι που πρέπει επίσης να δοκιμαστεί στην παραγωγή με ίση φροντίδα.

Το απομακρυσμένο API μπορεί να βοηθήσει στην ενημέρωση της ιεραρχίας της κλάσης PHP

Κατά τον καθορισμό των διαφόρων τάξεων PHP για την προσθήκη μου, συχνά θεωρώ χρήσιμο να μιμηθώ τον τρόπο με τον οποίο καθορίζονται τα τελικά σημεία API - για παράδειγμα, τι φαίνεται να έχουν τα ακόλουθα τελικά σημεία;

• https://api.example-email-service.com/v1/subscribers.json
• https://api.example-email-service.com/v1/lists.json
• https://api.example-email-service.com/v1/campaigns.json

Όλοι επιστρέφουν συλλογές , με το οποίο εννοώ το αποτέλεσμα ενός αιτήματος GET, επιστρέφοντας αποτελέσματα μηδέν σε πολλά, όπου κάθε αποτέλεσμα είναι μέλος ενός πίνακα. Αυτό μπορεί να ακούγεται αρκετά προφανές, αλλά το θεωρώ χρήσιμο για την ακόλουθη δομή τάξης στον κώδικα PHP μου:

• class.collection.php, μια αφηρημένη τάξη
• class.subscribers.php επεκτείνει την αφηρημένη κλάση, Collection.
• class.lists.php επεκτείνει την αφηρημένη κλάση, Collection.
• class.campaigns.php επεκτείνει την αφηρημένη κλάση, Collection.

Η αφηρημένη κλάση θα λάβει ως μοναδικό όρισμα μια σειρά παραμέτρων ερωτήματος: πράγματα όπως σελιδοποίηση, στήλη ταξινόμησης, σειρά ταξινόμησης και φίλτρα αναζήτησης. Θα είχε μεθόδους για κοινές εργασίες, όπως κλήση του απομακρυσμένου API, χειρισμός σφαλμάτων και ίσως μορφοποίηση των αποτελεσμάτων σε μενού HTML ή αυτόματη πρόταση jQueryUI. Οι τάξεις που δημιουργούν την αφηρημένη τάξη μπορεί να είναι αρκετά σύντομες, ίσως να κάνουν κάτι περισσότερο από το να καθορίσουν τη συμβολοσειρά που θα χρησιμοποιηθεί στο *.json URL τελικού σημείου API.

Το Mailchimp δημοσιεύει ένα API «παιδική χαρά» για κλήσεις API sandboxing και παρόμοια. Λειτουργεί επίσης ως ένας βολικός τρόπος για να περιηγηθείτε σε ολόκληρη την ιεραρχία δεδομένων του API τους, δίνοντάς μας μια χρήσιμη ματιά στο πώς μπορούμε να δομήσουμε τη δική μας ιεραρχία τάξης.

Παρομοίως, τι κοινό έχουν τα ακόλουθα τελικά σημεία;

• https://api.example-email-service.com/v1/subscribers/104abyh4.json
• https://api.example-email-service.com/v1/lists/837dy1h2.json
• https://api.example-email-service.com/v1/campaigns/9i8udr43.json

Όλοι επιστρέφουν ένα είδος , με το οποίο εννοώ ακριβώς ένα συγκεκριμένο, μοναδικό μέλος μιας συλλογής: πράγματα όπως ένας συγκεκριμένος συνδρομητής email, μία λίστα email ή μία καμπάνια email. Επομένως, μου αρέσει να χρησιμοποιώ την ακόλουθη δομή στον κωδικό PHP μου:

• class.item.php, μια αφηρημένη τάξη
• class.subscriber.php επεκτείνει την αφηρημένη κλάση, Item.
• class.list.php επεκτείνει την αφηρημένη κλάση, Item.
• class.campaign.php επεκτείνει την αφηρημένη κλάση, Item.

Η αφηρημένη τάξη θα χρησιμοποιούσε ως μοναδικό όρισμα μια συμβολοσειρά για να προσδιορίσει το συγκεκριμένο αντικείμενο που ζητήθηκε. Για άλλη μια φορά, τα μαθήματα που δημιουργούνται μπορεί να είναι αρκετά σύντομα, ίσως να κάνουν κάτι περισσότερο από το να καθορίσουν τη συμβολοσειρά που θα χρησιμοποιηθεί στο */duy736td.json.

Υπάρχουν πολλές προσεγγίσεις για τη δομή της κληρονομιάς της τάξης, αλλά ακόμα κι αν ακολουθήσετε μια διαφορετική προσέγγιση σε αυτό που έχω περιγράψει παραπάνω, στοιχηματίζω ότι υπάρχει μια καλή πιθανότητα η δομή του απομακρυσμένου API να βοηθήσει στην ενημέρωση της δομής της εφαρμογής σας.

Ως πελάτης, ένα κοινό σύμπτωμα της κακής αρχιτεκτονικής είναι όταν βρίσκεστε στον εαυτό σας να ζητάτε την ίδια αλλαγή ξανά και ξανά σε μια εφαρμογή. Για παράδειγμα, εάν ζητήσετε από τις αναφορές να επιστρέψουν 100 αποτελέσματα ανά σελίδα αντί για 10 και πρέπει να συνεχίσετε να επαναλαμβάνετε αυτό το αίτημα για αναφορές συνδρομητών, αναφορές καμπάνιας, αναφορές κατάργησης εγγραφής κ.λπ., ενδέχεται να εντοπίζετε κακή αρχιτεκτονική τάξης. Σε αυτήν την περίπτωση, αξίζει να ρωτήσετε την ομάδα σας εάν θα επωφεληθούν από έναν κύκλο επαναπροσδιορισμού: Ένα σώμα εργασίας όπου ο στόχος δεν είναι να αλλάξει τη συμπεριφορά του προϊόντος αλλά να βελτιώσει τον υποκείμενο κώδικα έτσι ώστε να γίνει ευκολότερο να αλλάξετε τη συμπεριφορά του προϊόντος στο μέλλον.

Η τέλεια θήκη χρήσης για WP_Error

Ντρέπομαι που παραδέχομαι ότι μου πήρε χρόνια περισσότερο από ό, τι θα έπρεπε να αρχίσω να χρησιμοποιώ σωστά το WP_Error οικογένεια λειτουργιών στον κωδικό μου. Έχω την τάση να κωδικοποιώ, είτε υποθέτοντας ότι δεν θα υπήρχαν ποτέ λάθη που αξίζει να φροντίσω μέσω προγραμματισμού ή να τα χειρίζομαι κατά περίπτωση. Η εργασία με απομακρυσμένα API περιορίζει αυτή τη νοοτροπία σαν μια ακτίνα λέιζερ, επειδή παρουσιάζει μια εξαιρετικά βολική και ισχυρή θήκη χρήσης για τη χρήση WP_Error.

Θυμάμαι νωρίτερα ότι ανέφερα ότι έχω συχνά μια κλάση PHP με σκοπό να κάνω αιτήματα HTTP στο απομακρυσμένο API. Όταν ξεφλουδίζετε όλο το boilerplate, όλους τους χειρισμούς δεδομένων, όλες τις δευτερεύουσες ανησυχίες, αυτή η κλάση πραγματικά καλείται να καλέσει wp_remote_request() για να λάβετε ένα αντικείμενο απόκρισης HTTP από το API. Βολικά, wp_remote_request() Αντ 'αυτού θα επιστρέψει ένα WP_Error εάν η κλήση αποτύχει να εκτελεστεί για κάποιο λόγο, αλλά τι γίνεται αν η κλήση καταφέρει να επιστρέψει μια απόκριση HTTP ενός δυσμενούς τύπου;

Από τεχνική άποψη, η κλήση API δούλεψε , αλλά δεν είναι ακριβώς απαλλαγμένο από επιφυλάξεις. Αυτές οι προειδοποιήσεις πρέπει να συλλαμβάνονται και να αναφέρονται με συνεπή τρόπο σε όλη τη βάση κώδικα.

Για παράδειγμα, ίσως κάναμε ένα τηλεφώνημα στο /lists.json τελικό σημείο, αλλά αυτός ο συγκεκριμένος λογαριασμός δεν έχει ακόμη ρυθμίσει λίστες. Αυτό θα επέστρεφε μια έγκυρη απόκριση HTTP, αλλά με κωδικό κατάστασης 400. Αν και αυτό δεν είναι ακριβώς ένα θανατηφόρο σφάλμα καθαυτό, από την προοπτική κάποιου κώδικα front-end που θέλει να μετατρέψει αυτήν την κλήση API σε ένα αναπτυσσόμενο μενού, ένα 400 μπορεί επίσης να είναι WSOD ! Επομένως, θεωρώ χρήσιμο να κάνω κάποια επιπλέον ανάλυση του αποτελέσματος του wp_remote_request(), ενδεχομένως να επιστρέψει ένα WP_Error παρά όλα αυτά:

url, $this -> args ); $code = wp_remote_retrieve_response_code( $response ); $first_digit = $code[0]; $good_responses = array( 2, 3 ); if( ! in_array( $first_digit, $good_responses ) { $body = wp_remote_retrieve_body( $response ); $out = new WP_Error( $code, $body ); } else { $out = $response; } return $out; } ?>

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

Ως πελάτης, πρέπει περιστασιακά να παίζετε το ρόλο ενός κακόβουλου χρήστη, ενός μπερδεμένου χρήστη και ενός ανυπόμονου χρήστη. Χρησιμοποιήστε την εφαρμογή με τρόπους που δεν προοριζόταν να χρησιμοποιηθεί. Κάντε τα πράγματα που οι προγραμματιστές σας δεν φαίνεται να θέλουν να κάνετε. Σημειώστε τι συμβαίνει. Λαμβάνετε χρήσιμα μηνύματα σφάλματος; Λαμβάνετε καθόλου μηνύματα λάθους; Εάν όχι, μπορεί να αξίζει να υποστηρίξετε ένα σωστό έργο για καλύτερο χειρισμό σφαλμάτων.

Η όμορφη δύναμη εντοπισμού σφαλμάτων ob_get_clean()

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

Είναι συνηθισμένο τα απομακρυσμένα αιτήματα HTTP να είναι τα πιο χρονοβόρα μέρη μιας δεδομένης φόρτωσης σελίδας. Για αυτόν τον λόγο, πολλά στοιχεία που βασίζονται σε API εκτελούνται είτε μέσω Ajax είτε cron. Για παράδειγμα, μια αυτόματη πρόταση για αναζήτηση μέσω μιας λίστας συνδρομητών email θα πρέπει πιθανώς να κάνει ping στην απομακρυσμένη πηγή δεδομένων κατά παραγγελία, σε κάθε πληκτρολόγηση, αντί να φορτώνει και τους 100.000 συνδρομητές στο DOM καθώς φορτώνεται η σελίδα. Εάν δεν είναι αυτή η επιλογή, ίσως ένα μεγάλο ερώτημα θα μπορούσε να συγχρονιστεί σε μια νυχτερινή εργασία cron, έτσι ώστε τα αποτελέσματα να μπορούν να ληφθούν από έναν τοπικό καθρέφτη και όχι από το απομακρυσμένο API.

Το πρόβλημα με αυτήν την προσέγγιση είναι ότι μπορεί να είναι δύσκολο να εντοπιστεί το σφάλμα. Αντί απλώς να ενεργοποιήσετε το WP_DEBUG και αφήνοντας τα μηνύματα σφάλματος να εισέλθουν στο παράθυρο του προγράμματος περιήγησής σας, έχετε κολλήσει να κοιτάζετε στην κονσόλα δικτύου του προγράμματος περιήγησης ή να παρακολουθείτε ένα αρχείο καταγραφής ως εκτέλεση cron (ελπίζουμε;). Το βρίσκω άβολο.

Ένας τρόπος για να βελτιωθεί αυτή η κατάσταση είναι να κάνετε προσεκτικές και στρατηγικές κλήσεις error_log() . Αλλά και πάλι, ένα κοινό πρόβλημα με την καταγραφή είναι ότι με μεγάλες ή απασχολημένες εφαρμογές, τα αρχεία καταγραφής σφαλμάτων μπορούν να μεγαλώσουν πολύ, ή να αναπτυχθούν πολύ γρήγορα, για να είναι χρήσιμα για την παρακολούθηση ή την ανάλυση. Επομένως, πρέπει να είμαστε επιλεκτικοί με αυτό που καταγράφουμε, βάζοντας τόση σκέψη σε αυτό, όπως κάνουμε με την πραγματική λογική της εφαρμογής μας . Είναι κρίμα που αφιερώσατε λίγο χρόνο για να καταγράψετε κάποιο σφάλμα εξωτικής ακμής που φαίνεται να συμβαίνει κατά διαστήματα σε κάποια σπάνια εργασία cron μόνο για να συνειδητοποιήσετε ότι η πραγματική φύση του σφάλματος σας έχει αποφύγει για άλλη μια φορά επειδή δεν καταφέρατε να καταγράψετε κάποιο συγκεκριμένο μέλος του πίνακα , ας πούμε, της προσβλητικής αξίας.

Επομένως, η φιλοσοφία μου έχει γίνει, Δεν καταγράφω πάντα, αλλά όταν το κάνω, καταγράφω τα πάντα . Με άλλα λόγια, αφού εντοπίσω μια ιδιαίτερα ανησυχητική συνάρτηση, θα την καταγράψω με όσο το δυνατόν ευρύτερο δίκτυο:

var_dump()

Αυτό ισοδυναμεί με

|_+_|

«ολόκληρη την τιμή λάθη σε μία μόνο καταχώριση στο αρχείο καταγραφής σφαλμάτων.

Ένα αρχείο καταγραφής σφαλμάτων που έχει γίνει πολύ μεγάλο για να είναι εργονομικό για εντοπισμό σφαλμάτων.

Ως πελάτης, αξίζει να ελέγχετε περιοδικά τη συνολική χρήση της μνήμης αρχείων για την εφαρμογή σας. Εάν παρατηρήσετε ότι ξαφνικά ξεπερνάτε τα όρια αποθήκευσης στον λογαριασμό φιλοξενίας σας, υπάρχει μια καλή πιθανότητα να φταίει το αρχείο καταγραφής σφαλμάτων. Οι προγραμματιστές σας θα επωφεληθούν από έναν κύκλο εργασίας που επικεντρώνεται στην καλύτερη καταγραφή - και οι πελάτες σας θα το κάνουν επίσης!

Όχι ακριβώς το Clickbait, αλλά θα το κάνει

Παρακαλώ συγχωρήστε τη δομή της λίστας αυτού του άρθρου. Δεν μπορούσα να αναγκάσω αυτά τα σημεία σε ένα πιο ενοποιητικό θέμα άρθρου, επειδή αυτά τα μοτίβα είναι πολύ γενικά: Εφαρμόζονται σε οποιοδήποτε τελικό σημείο JSON REST και σε οποιαδήποτε έξοδο WordPress .

Είναι τα μοτίβα που βλέπω να εμφανίζονται ξανά και ξανά, ανεξάρτητα από το τι είναι το απομακρυσμένο API ή για το οποίο το χρησιμοποιούμε στο WordPress. Έχω προχωρήσει τόσο πολύ ώστε να συλλέξω όλα αυτά τα είδη αρχών σε μια πρόσθετη πλάκα που επιταχύνει σημαντικά τη δουλειά μου. Έχετε παρόμοια σημεία που διατηρείτε για κάθε έργο; Παρακαλώ μοιραστείτε τα ώστε να μπορώ να τα κλέψω και να τα προσθέσω στο boilerplate μου!

Σχετίζεται με: Πώς να προσεγγίσετε τη σύγχρονη ανάπτυξη WordPress (Μέρος 1)

Κατανόηση των βασικών

Τι είναι το WordPress REST API;

Ένας βολικός τρόπος για τη χρήση του WordPress για τη δημοσίευση ενός API. Αυτό το API μπορεί να καταναλωθεί από άλλους ιστότοπους WordPress, άλλους ιστότοπους εκτός WordPress ή ακόμα και από τον ίδιο τον ιστότοπο δημοσίευσης. Πρόκειται για μια δημοφιλή προσέγγιση για τη χρήση του WordPress ως «χωρίς κεφάλι» CMS ή ακόμα και για μικρούς ακροατές Ajax.

Τι είναι το κλειδί API στο WordPress;

Τα κλειδιά API είναι ένας συνηθισμένος τρόπος διαχείρισης του ελέγχου ταυτότητας. Το WordPress API είναι συμβατό με διάφορες μεθόδους ελέγχου ταυτότητας. Ένα από αυτά είναι η προσθήκη WordPress REST API OAuth, η οποία δίνει στους χρήστες μια διεπαφή για τη διαχείριση των κλειδιών API.

Τι είναι το WP-JSON;

Το WP-JSON μπορεί να θεωρηθεί ως αδελφός της προβολής RSS του WordPress μαζί με την κανονική προβολή front-end. Είναι ένας άλλος τρόπος παραγωγής δεδομένων WordPress, αν και οι περισσότεροι ανθρώπινοι αναγνώστες δεν θα ήθελαν να καταναλώσουν WordPress σε αυτήν τη μορφή. Αντίθετα, ο σκοπός του είναι να καταναλωθεί από πελάτες API.