OOP Lanjutan untuk WordPress: Menyesuaikan titik akhir API REST

(artikel ini pada asalnya diterbitkan oleh majalah Torque dan dicetak semula dengan kebenaran.)

Pada tahun-tahun kebelakangan ini, penulis telah menulis banyak artikel mengenai PHP berorientasikan objek dan API REST WordPress dalam majalah tork, yang juga melibatkan penggunaan komposer untuk pengurusan ketergantungan dan pemuatan automatik, serta ujian unit. Titik teras semua artikel adalah: dengan menggunakan amalan terbaik pembangunan perisian yang ditetapkan untuk pembangunan WordPress, kita boleh membuat plugin yang lebih baik.

Ini adalah yang pertama dalam satu siri artikel yang akan mengintegrasikan konsep -konsep ini dalam contoh yang praktikal dan berfungsi. Saya akan berjalan melalui cara membuat plugin WordPress untuk mengubahsuai fungsi titik akhir API WordPress REST untuk mengoptimumkan carian dengan lebih baik. Plugin ini boleh didapati di GitHub. Anda mungkin perlu melayari log komit untuk memahami proses membina saya.

Dalam siri ini, saya akan meliputi cara membina plugin dan kelas menggunakan PHP berorientasikan objek moden, dan bagaimana untuk menjadikannya boleh diuji, dan bagaimana menulis ujian automatik untuknya. Saya akan menampung perbezaan antara ujian unit, ujian integrasi, dan ujian penerimaan dan menunjukkan kepada anda cara menulis dan mengautomasikan setiap jenis ujian. Artikel ini mula-mula memperkenalkan cara menggunakan kaedah berorientasikan objek untuk mengubah suai API REST WordPress menggunakan penapis.

mata utama

Meningkatkan titik akhir API WordPress REST dengan PHP berorientasikan objek untuk keupayaan carian yang lebih baik dan mengintegrasikan dengan alat carian canggih seperti Elasticsearch.
Ubah suai parameter endpoint API REST dan interaksi WP_Query untuk memintas batasan carian WordPress lalai dan meningkatkan kualiti tindak balas pertanyaan kompleks.
Gunakan ujian unit, ujian integrasi dan ujian penerimaan untuk kod yang mantap dan mudah untuk memastikan bahawa setiap komponen berjalan dengan betul dalam ekosistem WordPress.
Gunakan suntikan ketergantungan dan ciri -ciri PHP untuk menguruskan kebergantungan kelas secara bersih, membolehkan penyelenggaraan dan kod ujian yang lebih mudah.
Sesuaikan mod endpoint API REST untuk memasukkan parameter tambahan seperti
• , yang membolehkan keupayaan carian yang lebih fleksibel dan berkuasa. post_type
Secara dinamik menyesuaikan parameter WP_Query melalui permintaan API REST tertentu, dan gunakan penapis untuk memperbaiki hasil carian dengan berkesan dan tingkah laku endpoint.

Meningkatkan carian WordPress dengan REST API

biasanya menggunakan plugin seperti SearchWP atau Relevansi, atau integrasi dengan Elasticsearch (teknologi yang menggunakan timbunan yang sama sekali berbeza dari WordPress) untuk meningkatkan carian WordPress. Jenis-jenis plugin ini memberikan hasil carian yang lebih baik dan sering digunakan dengan antara muka carian yang pelbagai, yang sangat berguna untuk aplikasi e-dagang.

Cari melalui API REST WordPress mewarisi semua masalah yang sama dan penyelesaian yang sama. Dalam siaran ini, saya akan mula memperkenalkan bagaimana carian berfungsi dan batasannya. Kami kemudian akan melihat cara mengubah suai carian dan mengintegrasikan dengan SearchWP menggunakan dua kaedah yang berbeza.

Fungsi carian terbina dalam WordPress biasanya memerlukan peningkatan menggunakan perkhidmatan luaran. Walaupun artikel ini adalah mengenai pendekatan yang berorientasikan objek untuk mengubahsuai bagaimana routing API REST WordPress berfungsi, contoh sebenar adalah untuk meningkatkan carian.

Apabila WordPress digunakan sebagai backend untuk decoupling front-ends (seperti aplikasi mudah alih asli atau aplikasi web, yang boleh dibina menggunakan Vue, React, atau Sudut), adalah penting untuk melakukan carian berkualiti tinggi melalui selebihnya API. Kod yang dibentangkan dalam artikel ini akan membantu anda jika pengguna aplikasi anda perlu mencari varian produk yang tepat atau mencari kandungan berdasarkan algoritma kompleks berdasarkan pelbagai taksonomi dan anda menulis kod tersuai dan bukan hanya memasang plugin.

Carian Carian Menggunakan WordPress Rest Api

Jika anda ingin mencari semua jawatan dengan jenis pos "produk" di satu laman web, gunakan istilah carian "baju taco" dan anda akan membuat permintaan ke titik akhir /wp/v2/product?s=Taco Shirt. Jika anda ingin meningkatkan kualiti hasil anda, penyelesaian yang disenaraikan di atas akan membantu.

Seperti yang disebutkan di atas, WP_Query (perkara yang digunakan oleh titik akhir pos API REST WordPress) bukan alat carian yang baik. Lebih khusus lagi, WP_Query mungkin kurang berkemungkinan daripada alat carian yang berdedikasi yang cenderung dibina menggunakan pangkalan data NoSQL kerana pergantungannya pada MySQL.

Pertama, mari kita lihat bagaimana untuk memintas interaksi WP_Query dengan pangkalan data WordPress ketika membuat permintaan API REST.

Ini adalah strategi yang digunakan oleh banyak plugin carian untuk menggantikan hasil sistem carian mereka sendiri (yang dihasilkan secara lalai untuk WP_Query). Sistem carian boleh menggunakan pangkalan data yang sama. Ia juga boleh menyambung ke pangkalan data lain, mungkin melalui permintaan API, seperti pelayan Elasticsearch atau Apache Solr.

Jika anda melihat kod teras WordPress, anda akan mendapati bahawa penapis "POSTS_PRE_QUERY" berjalan sebelum pangkalan data pertanyaan WP_Query, tetapi selepas pertanyaan SQL sudah siap. Penapis ini mengembalikan null secara lalai. Jika nilai itu adalah batal, WordPress meneruskan tingkah laku lalainya: pertanyaan pangkalan data WordPress dan mengembalikan hasilnya sebagai pelbagai objek WP_POST yang mudah.

Sebaliknya, jika nilai pulangan penapis ini adalah array (yang ingin mengandungi objek WP_POST), tingkah laku lalai WordPress tidak digunakan.

mari kita lihat cara menggunakan posts_pre_query untuk mengembalikan simulasi wp_post. Strategi ini sangat berguna untuk ujian, tetapi versi yang lebih kompleks dari skema yang sama boleh digunakan untuk mengintegrasikan pangkalan data berasingan dengan laman WordPress anda:

// ... (代码示例与原文相同) ...

Dalam contoh ini, kami menggunakan data mock, tetapi kami boleh menggunakan kelas pertanyaan carianwp atau apa -apa lagi. Satu lagi perkara yang perlu diperhatikan mengenai kod ini ialah ia akan dijalankan di mana -mana WP_Query, bukan hanya objek WP_Query yang dibuat oleh API REST WordPress. Mari kita ubahnya supaya kita tidak menggunakan penapis kecuali permintaan API REST WordPress:

// ... (代码示例与原文相同) ...

Ubah suai Parameter Endpoint API WordPress REST

kami hanya melihat cara menukar hasil carian yang dihasilkan untuk permintaan API REST WordPress. Ini membolehkan kami mengoptimumkan pertanyaan untuk hasil carian yang lebih baik, tetapi ia mungkin mendedahkan keperluan untuk corak yang berbeza dari titik akhir.

Sebagai contoh, jika anda ingin membenarkan carian untuk titik akhir produk secara pilihan membenarkan jenis pos lain dimasukkan ke dalam carian, saya memperkenalkan penyelesaian lain kepada masalah yang sama tahun lepas.

Fokus mendatar

kita akan melihat cara mengubah suai parameter endpoint yang dibenarkan dan cara menggunakannya untuk membuat parameter WP_Query. Ini adalah dua kebimbangan yang berasingan, dan prinsip tanggungjawab tunggal menyatakan bahawa kita perlu membuat kelas untuk setiap kebimbangan. Tetapi kedua -dua kelas ini akan berkongsi kebimbangan.

Sebagai contoh, jika kita ingin membenarkan pertanyaan dengan jenis pos yang berbeza, kita perlu tahu jenis pos awam yang mana, dan apakah parameter slug dan REST_BASE mereka. Semua maklumat ini tersedia dari fungsi get_post_types.

output fungsi ini bukanlah apa yang kita perlukan. Oleh itu, mari kita bentuk kelas untuk memformat data mengikut keperluan yang saya baru disenaraikan dan memberi kita cara penolong untuk mengaksesnya.

Fikirkannya sebagai bentuk yang sama untuk semua data jenis pos yang perlu kita gunakan dalam bekas yang ada:

Perhatikan bahawa bukannya memanggil get_post_types () di dalam kelas, kami menggunakannya sebagai kebergantungan, disuntik melalui pembina. Oleh itu, kelas ini boleh diuji tanpa memuatkan WordPress.

// ... (代码示例与原文相同) ...

Inilah sebabnya saya menggambarkan jenis ini sebagai "Unit-Destable". Ia tidak bergantung pada API lain, dan kami tidak bimbang tentang kesan sampingan. Kita boleh mengujinya sebagai unit terpisah yang terpisah. Pisahkan tumpuan dan mengasingkan fungsinya ke bahagian kecil, dan apabila kita mempunyai liputan ujian unit, kita boleh membuat kod mudah untuk dikekalkan. Saya akan meliputi cara menguji jenis kelas ini dalam jawatan saya yang seterusnya.

ingat bahawa kelas ini bergantung pada wp_post_type. Ujian unit saya tidak akan menentukan kelas kerana hanya ujian integrasi boleh menggunakan WordPress atau sebarang kebergantungan luaran yang lain. Kelas ini hanya digunakan untuk mewakili data, bukan untuk melakukan apa -apa tindakan. Oleh itu, kita boleh mengatakan bahawa penggunaannya tidak akan mempunyai kesan sampingan. Jadi saya suka menggunakan mocks dalam ujian unit dan bukannya WP_POST_TYPE sebenar.

Bercakap tentang suntikan ketergantungan, kelas yang memerlukan objek kelas baru ini, kami ingin mengikuti corak yang sama. Daripada instantiating preparedposttypes dalam kelas yang memerlukannya, kita lulus dalam satu contoh. Ini bermakna bahawa kelas yang menggunakan PreparedPostTypes dan PreparedPostType disimpan diasingkan dan boleh diuji secara berasingan.

Ia juga boleh menyebabkan penggunaan semula kod kerana kita perlu membuat suntikan ketergantungan mungkin dan menetapkan harta untuk objek ini. Kita boleh menggunakan potongan dan tampal, atau kita boleh menggunakan sifat PHP, kaedah yang lebih maju dan boleh diperpanjang untuk menyalin kaedah dan sifat antara kelas.

Ini adalah sifat yang menetapkan corak untuk menyuntik objek PreparedPostTypes ke kelas lain:

// ... (代码示例与原文相同) ...

Salah satu kebimbangan kami ialah kami perlu mengetahui beberapa maklumat mengenai jenis pos di beberapa tempat. Sebagai contoh, slug jenis pos. Ini sedikit berbeza daripada kebimbangan silang sebelumnya. Masalah terakhir yang kami selesaikan melibatkan data dinamik. Sekarang kita hanya perlu menukar rentetan yang kita gunakan di beberapa tempat di satu tempat.

Kelas dengan pemalar kelas hanya menyelesaikan masalah ini untuk kita:

// ... (代码示例与原文相同) ...

Sekarang kita boleh membuat rentetan ini konsisten sepanjang kod. Ini seolah -olah menjadi langkah yang tidak perlu. Tetapi kod sampel saya berfungsi untuk jenis pos pos. Jika anda ingin menukar jenis pos yang anda gunakan, kelas ini perlu diubah tanpa mengubah apa -apa lagi. Ini mengikuti definisi pilihan Tom McFarlin mengenai prinsip tanggungjawab tunggal apabila dia menulis "Kelas sepatutnya hanya mempunyai satu sebab untuk berubah."

Ubah suai mod endpoint API REST

Sekarang kita perlu mengubahsuai corak titik akhir jenis pos. Dengan berbuat demikian, WordPress akan berkomunikasi dengan titik akhir API REST bahawa parameter jenis pos dibenarkan dan parameter endpoint baru dibenarkan semasa menguraikan permintaan.

Ini adalah kelas kami untuk menambah harta post_type. Sila ambil perhatian bahawa ia menggunakan sifat yang digunakan oleh TRAIT yang baru saja dibincangkan:

// ... (代码示例与原文相同) ...

Dalam tetapan harta ini, kami memberitahu WordPress bahawa harta ini adalah harta array, dan kami menggunakan indeks "enum" array untuk menentukan nilai yang dibenarkan.

Dalam "enum", kami menghitung nilai yang dibenarkan. Dalam kes ini, kelas PreparedPostTypes menyediakan pelbagai nilai yang dibenarkan, kerana ini adalah kebimbangan silang yang telah diselesaikan sebelum ini.

Perhatikan bahawa kelas ini tidak digabungkan dengan mana -mana jenis pos atau bahkan kes penggunaan khusus ini. Kami tidak lama lagi akan kembali kepada apa yang digunakan untuk membuat kelas ini berfungsi untuk jenis pos tertentu.

Ubah suai REST API WP_Query Parameter

Bahagian sebelumnya menerangkan cara membuat Property Endpoint Baru Post_Type tersedia. Ini sebenarnya tidak mengubah parameter WP_Query yang dihasilkan oleh API REST WordPress. Kami sudah mempunyai semua yang kami perlukan kecuali penapis terakhir.

Jenis pos adalah parameter WP_Query yang kod teras secara khusus tidak membenarkan perubahan pada permintaan API REST. Kami mempunyai penapis dinamakan -dinamakan _ {$ post_type} _Query -boleh mengatasi sebarang parameter WP_Query.

ini kelas kami, yang menyuntik parameter post_type kami, yang tidak dibenarkan sebelum:

// ... (代码示例与原文相同) ...

Kebanyakannya hanya untuk mengesahkan bahawa kita harus membuat perubahan dan kemudian menggunakan kaedah get_param WP_REST_REQUEST untuk mendapatkan nilai dari permintaan. Kebanyakannya adalah automatik kerana kita mengubah suai corak terlebih dahulu untuk dipadankan.

Ubah suai objek WP_Query yang diminta oleh WordPress Rest API

Saya telah meliputi cara melakukan ini di bahagian pertama artikel ini. Ini adalah kelas yang melaksanakan corak yang sama:

// ... (代码示例与原文相同) ...

Saya harap anda dapati bahawa kod ini berkait rapat dengan WordPress dan tidak boleh diuji. Ia menggunakan WP_POST dari WordPress, yang memeriksa pemalar untuk WordPress dan berinteraksi dengan API plugin WordPress. Kita boleh mensimulasikan WP_POST, dan kita boleh menetapkan pemalar sendiri. Tetapi API plugin - ini adalah ciri penting yang perlu diuji. Dalam beberapa jawatan saya yang akan datang, saya akan meliputi bagaimana untuk refactor kelas ini supaya kita boleh menggunakan ujian unit untuk menampung segala -galanya kecuali kesan mengeluarkan penapis itu, dan menggunakan ujian integrasi untuk memeriksa kesan itu.

Saya memilih untuk menggunakan kaedah statik untuk dua sebab. Pertama, ia memudahkan untuk menambah dan mengeluarkannya di pelbagai lokasi. Sebagai contoh, dalam kelas ModifyQuery, saya hanya menyambungkan penapis ini jika diperlukan:

// ... (代码示例与原文相同) ...

Juga, mudah untuk membuat gelung rekursif apabila menggunakan penapis ini. Sangat bagus untuk dapat mengeluarkannya dengan mudah seperti dalam kod contoh ini.

Satu lagi sebab saya memilih untuk menggunakan kaedah statik ialah fungsi berinteraksi dengan API lain. Ia tidak akan benar-benar boleh diuji unit. Corak ini, kelas dengan kaedah statik, menjadikannya sangat mudah untuk mensimulasikan kelas dalam ujian integrasi, dengan itu meminimumkan kesan kekurangan pengasingan yang kuat dalam satu bahagian sistem ini.

Buat semua kandungan berfungsi bersama

Kod yang telah kita lihat setakat ini sangat tidak dapat diselesaikan dari WordPress. Terdapat banyak manfaat untuk ini. Tetapi itu bermakna ia tidak melakukan apa -apa. Ini sangat bagus. Kami hanya menangani keperluan logik perniagaan setakat ini. Sekarang kita perlu mempertimbangkan integrasi.

Ini tidak sukar, tambah beberapa cangkuk. Cangkuk apa? Dua cangkuk yang sama seperti yang kami direka untuk kelas ModifyQuery dan ModifySchema. Keinginan untuk decoupling Logic Business tidak bermakna bahawa kita tidak dapat mempertimbangkan sebab -sebab sebenar mengapa kita menulis kod ketika merancang antara muka umum mereka. Jika tidak, kami hanya akan menambah kerumitan tambahan kepada kod kami tanpa alasan.

Secara umum, saya cuba meningkatkan kerumitan perisian hanya apabila ia menjadikan kehidupan lebih mudah. Saya telah menyimpang dari jalan ini pada masa lalu. Kita semua memilikinya, tidak penting, mengamalkan pengampunan.

Kaedah di dalam kelas kita hendak hook menggunakan parameter yang sama dan jenis pulangan sebagai cangkuk. Tugas mereka adalah untuk memberikan nilai -nilai ini kepada komponen lain.

// ... (代码示例与原文相同) ...

Langkah seterusnya: Ujian

Ini cukup dekat. Ia akan berfungsi. Oleh kerana kekurangan sistem formal untuk menambah cangkuk, ini adalah perkara terbaik yang boleh kita lakukan untuk permulaan. Ini sangat bagus. Saya akan merangkumi cara membuat proses boot yang lebih kompleks dan berskala dalam artikel masa depan mengenai ujian integrasi WordPress.

Dalam artikel ini, kita mengkaji WP_Query yang mendasari untuk membuat kod untuk mengubah suai skema, penjanaan parameter WP_Query, dan jenis pos. Saya menggalakkan anda untuk menukar kod ini ke dalam plugin dan menggunakan komposer untuk memuatkan automatik. Dalam jawatan saya yang seterusnya, kami akan melihat ujian unit untuk menampung kelas -kelas ini.

(berikut adalah bahagian FAQ asal, dan penciptaan pseudo-asal telah dibuat berdasarkan kandungan asal)

Soalan Lazim Mengenai OOP Lanjutan dan titik akhir API Custom REST di WordPress

Apakah maksud pengaturcaraan berorientasikan objek (OOP) di WordPress?

Pengaturcaraan berorientasikan objek (OOP) adalah paradigma pengaturcaraan untuk mereka bentuk aplikasi dan perisian menggunakan "objek". Dalam persekitaran WordPress, OOP menyediakan cara yang mudah, cekap dan mantap untuk membangunkan aplikasi yang kompleks. Ia membolehkan pemaju untuk mengelompokkan tugas -tugas yang relevan ke dalam kelas dan objek, menjadikan kod lebih mudah dibaca, digunakan semula, dan mengekalkan. OOP juga meningkatkan keselamatan aplikasi dengan merangkumi data dan mencegah akses luaran langsung.

Bagaimana untuk menyesuaikan titik akhir API REST di WordPress?

API REST WordPress menyediakan satu set titik akhir lalai untuk pelbagai jenis data. Walau bagaimanapun, anda boleh menyesuaikan titik akhir ini atau membuat titik akhir baru untuk memenuhi keperluan khusus anda. Ini boleh dilakukan dengan menggunakan fungsi register_rest_route() dalam plugin atau tema anda. Fungsi ini membolehkan anda menentukan laluan atau URL titik akhir dan menentukan kaedah yang harus dipertanggungjawabkan (mendapatkan, pos, dll.).

Apakah kelebihan menyesuaikan titik akhir API REST WordPress?

titik akhir API REST Custom WordPress membolehkan anda membuat aplikasi yang lebih cekap, fleksibel dan selamat. Anda boleh menyesuaikan data yang dikembalikan oleh titik akhir untuk mengurangkan jumlah data yang tidak perlu yang dihantar melalui rangkaian. Anda juga boleh membuat titik akhir yang melaksanakan tugas-tugas tertentu, seperti penyerahan borang pemprosesan atau menghasilkan laporan, menjadikan aplikasi anda lebih interaktif dan mesra pengguna.

Bagaimana OOP meningkatkan keselamatan aplikasi WordPress?

OOP meningkatkan keselamatan aplikasi WordPress dengan merangkumi data dan kaedah ke dalam objek. Ini bermakna bahawa sifat (data) dan kaedah (fungsi) objek tersembunyi dari seluruh aplikasi dan hanya boleh diakses melalui kaedah objek. Ini menghalang akses dan manipulasi data yang tidak dibenarkan, dengan itu mengurangkan risiko pelanggaran keselamatan.

Bolehkah oop digunakan dengan versi lama WordPress?

Ya, anda boleh menggunakan OOP dengan versi lama WordPress. Walau bagaimanapun, adalah penting untuk diperhatikan bahawa versi WordPress yang lebih baru telah meningkatkan sokongan OOP dan memasukkan banyak ciri untuk memudahkan untuk membangunkan menggunakan paradigma ini. Oleh itu, sementara OOP boleh digunakan dengan versi yang lebih lama, secara amnya disyorkan untuk menggunakan versi terkini WordPress untuk pengalaman pembangunan terbaik.

Apakah peranan kelas dan objek di OOP?

Di OOP, kelas adalah cetak biru atau templat untuk membuat objek. Ia mentakrifkan sifat (data) dan kaedah (fungsi) yang harus dimiliki oleh objek. Sebaliknya, objek adalah contoh kelas. Ia mempunyai set sifat dan kaedah tersendiri yang mungkin berbeza dari objek lain kelas yang sama. Penggunaan kelas dan objek menjadikan kod lebih teratur, boleh diguna semula dan mudah dijaga.

Bagaimana untuk membuat kelas baru di WordPress?

Anda boleh menggunakan kata kunci class, diikuti dengan nama kelas dan satu set pendakap keriting {} untuk membuat kelas baru dalam WordPress. Dalam kurungan, anda boleh menentukan sifat dan kaedah kelas. Untuk membuat objek kelas, anda boleh menggunakan kata kunci new diikuti dengan nama kelas.

Apakah API REST di WordPress?

API REST dalam WordPress adalah antara muka yang membolehkan anda berinteraksi dengan tapak WordPress anda menggunakan permintaan HTTP. Ia menyediakan satu set titik akhir untuk pelbagai jenis data seperti jawatan, komen, dan pengguna yang boleh anda akses menggunakan kaedah HTTP standard seperti Get, Post, Put, dan Delete. API REST memudahkan anda membuat, membaca, mengemas kini, dan memadam data dari laman WordPress anda dari aplikasi luaran.

Bagaimana untuk mengakses API REST di WordPress?

Anda boleh mengakses API REST dalam WordPress dengan menghantar permintaan HTTP ke titik akhir yang sepadan. Setiap titik akhir sepadan dengan jenis data tertentu dan menyokong kaedah HTTP tertentu. Sebagai contoh, untuk mendapatkan senarai pos, anda boleh menghantar permintaan GET ke titik akhir /wp/v2/posts. API REST akan mengembalikan data dalam format JSON, yang kemudian anda boleh memproses dan memaparkan dalam aplikasi anda.

Bolehkah saya menggunakan API REST dengan aplikasi bukan kata-kata?

Ya, anda boleh menggunakan API REST dengan aplikasi bukan kata-kata. API REST adalah platform-agnostik, yang bermaksud ia boleh digunakan dengan sebarang aplikasi yang boleh menghantar permintaan HTTP dan memproses data JSON. Ini menjadikannya alat yang berkuasa untuk mengintegrasikan laman WordPress dengan aplikasi lain seperti aplikasi mudah alih, aplikasi desktop, dan perkhidmatan web lain.

Atas ialah kandungan terperinci OOP Lanjutan untuk WordPress: Menyesuaikan titik akhir API REST. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!