Meningkatkan Kode WordPress Dengan PHP Modern

WordPress lahir lima belas tahun yang lalu, dan karena secara historis mempertahankan kompatibilitas ke belakang, versi kode yang lebih baru tidak dapat sepenuhnya menggunakan kemampuan terbaru yang ditawarkan oleh versi PHP yang lebih baru. Sementara versi terbaru PHP adalah 7.3.2, WordPress masih menawarkan dukungan hingga PHP 5.2.4.

Tapi hari-hari itu akan segera berakhir! WordPress akan meningkatkan dukungan versi PHP minimumnya, meningkatkan hingga PHP 5.6 pada April 2019, dan PHP 7 pada Desember 2019 (jika semuanya berjalan sesuai rencana). Kami akhirnya dapat mulai menggunakan kemampuan pemrograman penting PHP tanpa takut merusak situs klien kami. Hore!

Karena kode fungsional WordPress selama lima belas tahun telah memengaruhi cara pengembang membangun dengan WordPress, situs, tema, dan plugin kami mungkin dipenuhi dengan kode yang kurang optimal yang dengan senang hati dapat menerima peningkatan.

Artikel ini terdiri dari dua bagian:

1. Fitur baru yang paling relevan
   Fitur lebih lanjut telah ditambahkan ke PHP versi 5.3, 5.4, 5.5, 5.6 dan 7.0 (perhatikan bahwa tidak ada PHP 6) dan kami akan menjelajahi yang paling relevan.
2. Membangun perangkat lunak yang lebih baik
   Kami akan melihat lebih dekat melalui fitur-fitur ini dan bagaimana fitur tersebut dapat membantu kami membangun perangkat lunak yang lebih baik.

Mari kita mulai dengan menjelajahi fitur "baru" PHP.

Kelas, OOP, SOLID, dan Pola Desain

Kelas dan objek ditambahkan ke PHP 5, jadi WordPress sudah menggunakan fitur-fitur ini, namun, tidak terlalu ekstensif atau komprehensif: Paradigma pengkodean di WordPress sebagian besar adalah pemrograman fungsional (melakukan perhitungan dengan memanggil fungsi tanpa status aplikasi) alih-alih objek -oriented programming (OOP) (melakukan komputasi dengan memanipulasi keadaan objek). Oleh karena itu saya juga menjelaskan kelas dan objek dan bagaimana menggunakannya melalui OOP.

OOP sangat ideal untuk memproduksi aplikasi modular: Kelas memungkinkan pembuatan komponen, yang masing-masing dapat mengimplementasikan fungsionalitas tertentu dan berinteraksi dengan komponen lain, dan dapat menyediakan penyesuaian melalui properti dan pewarisan yang dienkapsulasi, memungkinkan penggunaan ulang kode tingkat tinggi. Akibatnya, aplikasi lebih murah untuk diuji dan dipelihara, karena fitur individual dapat diisolasi dari aplikasi dan ditangani sendiri; ada juga peningkatan produktivitas karena pengembang dapat menggunakan komponen yang sudah dikembangkan dan menghindari penciptaan kembali roda untuk setiap aplikasi.

Sebuah kelas memiliki properti dan fungsi, yang dapat diberikan visibilitas dengan menggunakan private (hanya dapat diakses dari dalam kelas yang mendefinisikan), protected (dapat diakses dari dalam kelas yang mendefinisikan dan leluhurnya serta kelas yang mewarisi) dan public (dapat diakses dari mana saja). Dari dalam suatu fungsi, kita dapat mengakses properti kelas dengan menambahkan nama mereka dengan $this-> :

 class Person { protected $name; public function __construct($name) { $this->name = $name; } public function getIntroduction() { return sprintf( __('My name is %s'), $this->name ); } }

Sebuah kelas diinstansiasi menjadi objek melalui kata kunci new , setelah itu kita dapat mengakses properti dan fungsinya melalui -> :

 $person = new Person('Pedro'); echo $person->getIntroduction(); // This prints "My name is Pedro"

Kelas pewarisan dapat menimpa fungsi public dan fungsi yang protected dari kelas leluhurnya, dan mengakses fungsi leluhur dengan menambahkannya dengan parent:: :

 class WorkerPerson extends Person { protected $occupation; public function __construct($name, $occupation) { parent::__construct($name); $this->occupation = $occupation; } public function getIntroduction() { return sprintf( __('%s and my occupation is %s'), parent::getIntroduction(), $this->occupation ); } } $worker = new WorkerPerson('Pedro', 'web development'); echo $worker->getIntroduction(); // This prints "My name is Pedro and my occupation is web development"

Sebuah metode dapat dibuat abstract , artinya harus diimplementasikan oleh kelas yang mewarisi. Kelas yang berisi metode abstract harus dibuat abstract sendiri, artinya tidak dapat diinstansiasi; hanya kelas yang mengimplementasikan metode abstrak yang dapat dipakai:

 abstract class Person { abstract public function getName(); public function getIntroduction() { return sprintf( __('My name is %s'), $this->getName() ); } } // Person cannot be instantiated class Manuel extends Person { public function getName() { return 'Manuel'; } } // Manuel can be instantiated $manuel = new Manuel();

Kelas juga dapat mendefinisikan metode dan properti static , yang hidup di bawah kelas itu sendiri dan tidak di bawah instantiasi kelas sebagai objek. Ini diakses melalui self:: dari dalam kelas, dan melalui nama kelas + :: dari luarnya:

 class Factory { protected static $instances = []; public static function registerInstance($handle, $instance) { self::$instances[$handle] = $instance; } public static function getInstance($handle) { return self::$instances[$handle]; } } $engine = Factory::getInstance('Engine');

Untuk memaksimalkan OOP, kita dapat menggunakan prinsip-prinsip SOLID untuk membangun fondasi yang baik namun mudah disesuaikan untuk aplikasi, dan merancang pola untuk memecahkan masalah tertentu dengan cara yang telah dicoba dan diuji. Pola desain distandarisasi dan didokumentasikan dengan baik, memungkinkan pengembang untuk memahami bagaimana komponen yang berbeda dalam aplikasi berhubungan satu sama lain, dan menyediakan cara untuk menyusun aplikasi secara teratur yang membantu menghindari penggunaan variabel global (seperti global $wpdb ) yang mencemari lingkungan global.

Ruang nama

Ruang nama telah ditambahkan ke PHP 5.3, oleh karena itu mereka saat ini hilang sama sekali dari inti WordPress.

Ruang nama memungkinkan pengorganisasian basis kode secara struktural untuk menghindari konflik ketika item yang berbeda memiliki nama yang sama — dengan cara yang mirip dengan direktori sistem operasi yang memungkinkan untuk memiliki file yang berbeda dengan nama yang sama selama disimpan di direktori yang berbeda. Ruang nama melakukan trik enkapsulasi yang sama untuk item PHP (seperti kelas, sifat, dan antarmuka) menghindari tabrakan ketika item yang berbeda memiliki nama yang sama dengan menempatkannya di ruang nama yang berbeda.

Ruang nama adalah suatu keharusan ketika berinteraksi dengan perpustakaan pihak ketiga karena kami tidak dapat mengontrol bagaimana item mereka akan diberi nama, yang mengarah ke potensi tabrakan saat menggunakan nama standar seperti "File", "Logger" atau "Uploader" untuk item kami. Selain itu, bahkan dalam satu proyek, ruang nama mencegah nama kelas menjadi sangat panjang untuk menghindari bentrokan dengan kelas lain, yang dapat menghasilkan nama seperti "MyProject_Controller_FileUpload".

Namespaces didefinisikan menggunakan kata kunci namespace (ditempatkan pada baris segera setelah pembukaan <?php ) dan dapat menjangkau beberapa level atau subnamespaces (mirip dengan memiliki beberapa subdirektori tempat menempatkan file), yang dipisahkan menggunakan \ :

 <?php namespace CoolSoft\ImageResizer\Controllers; class ImageUpload { }

Untuk mengakses kelas di atas, kita harus sepenuhnya memenuhi syarat namanya termasuk namespace-nya (dan dimulai dengan \ ):

 $imageUpload = new \CoolSoft\ImageResizer\Controllers\ImageUpload();

Atau kita juga dapat mengimpor kelas ke dalam konteks saat ini, setelah itu kita dapat mereferensikan kelas dengan namanya secara langsung:

 use CoolSoft\ImageResizer\Controllers\ImageUpload; $imageUpload = new ImageUpload();

Dengan memberi nama namespace mengikuti konvensi yang telah ditetapkan, kita bisa mendapatkan manfaat tambahan. Misalnya, dengan mengikuti Rekomendasi Standar PHP PSR-4, aplikasi dapat menggunakan mekanisme autoloading Composer untuk memuat file, sehingga mengurangi kerumitan dan menambahkan interoperabilitas tanpa gesekan di antara dependensi. Konvensi ini menetapkan untuk menyertakan nama vendor (misalnya nama perusahaan) sebagai subnamespace teratas, opsional diikuti dengan nama paket, dan hanya kemudian diikuti oleh struktur internal di mana setiap subnamespace sesuai dengan direktori dengan nama yang sama. Hasilnya memetakan 1 ke 1 lokasi fisik file di drive dengan namespace elemen yang ditentukan dalam file.

Sifat-sifat

Sifat ditambahkan ke PHP 5.4, oleh karena itu saat ini hilang sama sekali dari inti WordPress.

PHP mendukung pewarisan tunggal, jadi subkelas diturunkan dari kelas induk tunggal, dan bukan dari banyak kelas. Oleh karena itu, kelas yang tidak diperpanjang satu sama lain tidak dapat menggunakan kembali kode melalui pewarisan kelas. Sifat adalah mekanisme yang memungkinkan komposisi perilaku horizontal, memungkinkan untuk menggunakan kembali kode di antara kelas-kelas yang hidup dalam hierarki kelas yang berbeda.

Sebuah sifat mirip dengan kelas, namun tidak bisa dipakai sendiri. Sebagai gantinya, kode yang didefinisikan di dalam suatu sifat dapat dianggap sebagai "disalin dan ditempelkan" ke dalam kelas penulisan pada waktu kompilasi.

Suatu sifat didefinisikan menggunakan kata kunci trait , setelah itu dapat diimpor ke kelas mana pun melalui kata kunci use . Pada contoh di bawah, dua kelas yang sama sekali tidak terkait Person dan Shop dapat menggunakan kembali kode yang sama melalui sifat Addressable :

 trait Addressable { protected $address; public function getAddress() { return $this->address; } public function setAddress($address) { $this->address = $address; } } class Person { use Addressable; } class Shop { use Addressable; } $person = new Person('Juan Carlos'); $person->setAddress('Obelisco, Buenos Aires');

Kelas juga dapat membuat lebih dari satu sifat:

 trait Exportable { public class exportToCSV($filename) { // Iterate all properties and export them to a CSV file } } class Person { use Addressable, Exportable; }

Sifat juga dapat terdiri dari sifat lain, menentukan metode abstrak, dan menawarkan mekanisme resolusi konflik ketika dua atau lebih sifat yang tersusun memiliki nama fungsi yang sama, di antara fitur lainnya.

Antarmuka

Antarmuka ditambahkan ke PHP 5, jadi WordPress sudah menggunakan fitur ini, namun, sangat hemat: intinya mencakup kurang dari sepuluh antarmuka secara total!

Antarmuka memungkinkan pembuatan kode yang menentukan metode mana yang harus diimplementasikan, namun tanpa harus mendefinisikan bagaimana metode ini benar-benar diimplementasikan. Mereka berguna untuk mendefinisikan kontrak di antara komponen, yang mengarah ke modularitas dan pemeliharaan aplikasi yang lebih baik: Kelas yang mengimplementasikan antarmuka dapat berupa kotak kode hitam, dan selama tanda tangan fungsi di antarmuka tidak berubah, kode dapat ditingkatkan sesuka hati tanpa menghasilkan perubahan yang melanggar, yang dapat membantu mencegah akumulasi utang teknis. Selain itu, mereka dapat membantu mengurangi penguncian vendor, dengan memungkinkan untuk menukar implementasi beberapa antarmuka dengan vendor yang berbeda. Akibatnya, sangat penting untuk membuat kode aplikasi terhadap antarmuka alih-alih implementasi (dan mendefinisikan mana yang merupakan implementasi aktual melalui injeksi ketergantungan).

Antarmuka didefinisikan menggunakan kata kunci interface , dan harus mencantumkan hanya tanda tangan dari metodenya (yaitu tanpa kontennya ditentukan), yang harus memiliki visibilitas public (secara default, menambahkan tidak ada kata kunci visibilitas juga menjadikannya publik):

 interface FileStorage { function save($filename, $contents); function readContents($filename); }

Sebuah kelas mendefinisikan bahwa ia mengimplementasikan antarmuka melalui kata kunci implements :

 class LocalDriveFileStorage implements FileStorage { function save($filename, $contents) { // Implement logic } function readContents($filename) { // Implement logic } }

Sebuah kelas dapat mengimplementasikan lebih dari satu antarmuka, memisahkannya dengan , :

 interface AWSService { function getRegion(); } class S3FileStorage implements FileStorage, AWSService { function save($filename, $contents) { // Implement logic } function readContents($filename) { // Implement logic } function getRegion() { return 'us-east-1'; } }

Karena antarmuka mendeklarasikan maksud dari apa yang seharusnya dilakukan komponen, sangat penting untuk memberi nama antarmuka dengan tepat.

Penutupan

Penutupan ditambahkan ke PHP 5.3, oleh karena itu saat ini tidak ada sama sekali dari inti WordPress.

Penutupan adalah mekanisme untuk mengimplementasikan fungsi anonim, yang membantu mendeklarasikan ruang nama global dari fungsi sekali pakai (atau jarang digunakan). Secara teknis, penutupan adalah contoh dari kelas Closure , namun, dalam praktiknya, kita kemungkinan besar tidak menyadari fakta ini tanpa membahayakan.

Sebelum penutupan, setiap kali meneruskan fungsi sebagai argumen ke fungsi lain, kami harus mendefinisikan fungsi terlebih dahulu dan meneruskan namanya sebagai argumen:

 function duplicate($price) { return $price*2; } $touristPrices = array_map('duplicate', $localPrices);

Dengan penutupan, fungsi anonim (yaitu tanpa nama) sudah dapat diteruskan secara langsung sebagai parameter:

 $touristPrices = array_map(function($price) { return $price*2; }, $localPrices);

Penutupan dapat mengimpor variabel ke konteksnya melalui kata kunci use :

 $factor = 2; $touristPrices = array_map(function($price) use($factor) { return $price*$factor; }, $localPrices);

generator

Generator ditambahkan ke PHP 5.5, oleh karena itu saat ini tidak ada sama sekali dari inti WordPress.

Generator menyediakan cara mudah untuk mengimplementasikan iterator sederhana. Sebuah generator memungkinkan untuk menulis kode yang menggunakan foreach untuk mengulangi satu set data tanpa perlu membangun sebuah array di memori. Fungsi generator sama dengan fungsi normal, kecuali bahwa alih-alih kembali sekali, ia dapat yield sebanyak yang diperlukan untuk memberikan nilai yang akan diulang.

 function xrange($start, $limit, $step = 1) { for ($i = $start; $i <= $limit; $i += $step) { yield $i; } } foreach (xrange(1, 9, 2) as $number) { echo "$number "; } // This prints: 1 3 5 7 9

Deklarasi Tipe Argumen dan Pengembalian

Deklarasi tipe argumen yang berbeda diperkenalkan di versi PHP yang berbeda: WordPress sudah dapat mendeklarasikan antarmuka dan array (yang tidak: Saya hampir tidak menemukan satu contoh fungsi yang mendeklarasikan array sebagai parameter di inti, dan tidak ada antarmuka), dan akan segera dapat mendeklarasikan callable (ditambahkan dalam PHP 5.4) dan jenis skalar: bool, float, int dan string (ditambahkan dalam PHP 7.0). Deklarasi tipe pengembalian ditambahkan ke PHP 7.0.

Deklarasi tipe argumen memungkinkan fungsi untuk mendeklarasikan tipe spesifik apa yang harus menjadi argumen. Validasi dijalankan pada waktu panggilan, melemparkan pengecualian jika jenis argumen bukan yang dideklarasikan. Deklarasi tipe pengembalian adalah konsep yang sama, namun mereka menentukan tipe nilai yang akan dikembalikan dari fungsi. Deklarasi tipe berguna untuk membuat maksud fungsi lebih mudah dipahami dan untuk menghindari kesalahan runtime dari menerima atau mengembalikan tipe yang tidak diharapkan.

Tipe argumen dideklarasikan sebelum nama variabel argumen, dan tipe kembalian dideklarasikan setelah argumen, didahului oleh : :

 function foo(boolean $bar): int { }

Deklarasi tipe argumen skalar memiliki dua opsi: koersif dan ketat. Dalam mode koersif, jika tipe yang salah dilewatkan sebagai parameter, itu akan dikonversi ke tipe yang benar. Misalnya, suatu fungsi yang diberi bilangan bulat untuk parameter yang mengharapkan string akan mendapatkan variabel bertipe string. Dalam mode ketat, hanya variabel dengan tipe deklarasi yang tepat yang akan diterima.

Mode paksaan adalah default. Untuk mengaktifkan mode ketat, kita harus menambahkan pernyataan declare yang digunakan dengan deklarasi strict_types :

 declare(strict_types=1); function foo(boolean $bar) { }

Sintaks dan Operator Baru

WordPress sudah dapat mengidentifikasi daftar argumen panjang variabel melalui fungsi func_num_args . Mulai dari PHP 5.6, kita dapat menggunakan ... token untuk menunjukkan bahwa fungsi menerima sejumlah variabel argumen, dan argumen ini akan diteruskan ke variabel yang diberikan sebagai array:

 function sum(...$numbers) { $sum = 0; foreach ($numbers as $number) { $sum += $number; } return $sum; }

Mulai dari PHP 5.6, konstanta dapat melibatkan ekspresi skalar yang melibatkan literal numerik dan string, bukan hanya nilai statis, dan juga array:

 const SUM = 37 + 2; // A scalar expression const LETTERS = ['a', 'b', 'c']; // An array

Mulai dari PHP 7.0, array juga dapat didefinisikan menggunakan define :

 define('LETTERS', ['a', 'b', 'c']);

PHP 7.0 menambahkan beberapa operator baru: operator penggabungan Null ( ?? ) dan operator Spaceship ( <=> ).

Operator penggabungan Null ?? adalah gula sintaksis untuk kasus umum yang perlu menggunakan ternary bersama dengan isset(). Ia mengembalikan operan pertamanya jika ada dan bukan NULL; jika tidak, ia mengembalikan operan keduanya.

 $username = $_GET['user'] ?? 'nobody'; // This is equivalent to: // $username = isset($_GET['user']) ? $_GET['user'] : 'nobody';

Operator Spaceship <=> digunakan untuk membandingkan dua ekspresi, mengembalikan -1, 0 atau 1 ketika operan pertama masing-masing kurang dari, sama dengan, atau lebih besar dari operan kedua.

 echo 1 <=> 2; // returns -1 echo 1 <=> 1; // returns 0 echo 2 <=> 1; // returns 1

Ini adalah fitur baru terpenting yang ditambahkan ke PHP yang mencakup versi 5.3 hingga 7.0. Daftar fitur baru tambahan, yang tidak tercantum dalam artikel ini, dapat diperoleh dengan menelusuri dokumentasi PHP tentang migrasi dari versi ke versi.

Selanjutnya, kami menganalisis bagaimana kami dapat memaksimalkan semua fitur baru ini, dan dari tren terkini dalam pengembangan web, untuk menghasilkan perangkat lunak yang lebih baik.

Rekomendasi Standar PHP

Rekomendasi Standar PHP dibuat oleh sekelompok pengembang PHP dari kerangka kerja dan perpustakaan populer, mencoba untuk menetapkan konvensi sehingga proyek yang berbeda dapat diintegrasikan lebih mulus dan tim yang berbeda dapat bekerja lebih baik satu sama lain. Rekomendasi tidak statis: rekomendasi yang ada mungkin tidak digunakan lagi dan yang lebih baru dibuat untuk menggantikannya, dan yang baru dirilis secara berkelanjutan.

Rekomendasi saat ini adalah sebagai berikut:

Pikirkan Dan Kode Dalam Komponen

Komponen memungkinkan untuk menggunakan fitur terbaik dari kerangka kerja tanpa terkunci ke kerangka itu sendiri. Misalnya, Symfony telah dirilis sebagai satu set komponen PHP yang dapat digunakan kembali yang dapat diinstal secara independen dari kerangka kerja Symfony; Laravel, kerangka kerja PHP lainnya, menggunakan beberapa komponen Symfony, dan merilis kumpulan komponennya sendiri yang dapat digunakan kembali yang dapat digunakan oleh proyek PHP apa pun.

Semua komponen ini diterbitkan di Packagist, repositori paket PHP publik, dan dapat dengan mudah ditambahkan ke proyek PHP mana pun melalui Composer, manajer ketergantungan yang sangat populer untuk PHP.

WordPress harus menjadi bagian dari siklus pengembangan yang baik. Sayangnya, inti WordPress itu sendiri tidak dibangun menggunakan komponen (seperti yang dibuktikan dengan hampir tidak adanya antarmuka) dan, terlebih lagi, ia bahkan tidak memiliki file composer.json yang diperlukan untuk mengaktifkan penginstalan WordPress melalui Composer. Ini karena komunitas WordPress belum menyetujui apakah WordPress adalah ketergantungan situs (dalam hal ini menginstalnya melalui Composer akan dibenarkan) atau jika itu adalah situs itu sendiri (dalam hal ini Composer mungkin bukan alat yang tepat untuk pekerjaan itu) .

Menurut pendapat saya, jika kita mengharapkan WordPress untuk tetap relevan selama lima belas tahun ke depan (setidaknya WordPress sebagai CMS backend), maka WordPress harus diakui sebagai ketergantungan situs dan tersedia untuk diinstal melalui Composer . Alasannya sangat sederhana: dengan hampir satu perintah di terminal, Komposer memungkinkan untuk mendeklarasikan dan menginstal dependensi proyek dari ribuan paket yang diterbitkan di Packagist, memungkinkan untuk membuat aplikasi PHP yang sangat kuat dalam waktu singkat, dan pengembang menyukainya bekerja dengan cara ini. Jika WordPress tidak beradaptasi dengan model ini, mungkin kehilangan dukungan dari komunitas pengembangan dan terlupakan, seperti halnya FTP tidak disukai setelah pengenalan penerapan berbasis Git.

Saya berpendapat bahwa rilis Gutenberg sudah menunjukkan bahwa WordPress adalah ketergantungan situs dan bukan situs itu sendiri: Gutenberg memperlakukan WordPress sebagai CMS tanpa kepala, dan dapat beroperasi dengan sistem backend lain juga, seperti yang dicontohkan Drupal Gutenberg. Oleh karena itu, Gutenberg menjelaskan bahwa CMS yang memberi daya pada sebuah situs dapat ditukar, oleh karena itu harus diperlakukan sebagai ketergantungan. Selain itu, Gutenberg sendiri dimaksudkan untuk didasarkan pada komponen JavaScript yang dirilis melalui npm (seperti yang dijelaskan oleh pembuat inti Adam Silverstein), jadi jika klien WordPress diharapkan untuk mengelola paket JavaScript-nya melalui pengelola paket npm, mengapa tidak memperluas logika ini ke backend untuk mengelola dependensi PHP melalui Komposer?

Sekarang kabar baiknya: Tidak perlu menunggu masalah ini diselesaikan karena WordPress sudah dapat diperlakukan sebagai ketergantungan situs dan menginstalnya melalui Composer. John P. Bloch telah mencerminkan inti WordPress di Git, menambahkan file composer.json, dan merilisnya di Packagist, dan Roots' Bedrock menyediakan paket untuk menginstal WordPress dengan struktur folder yang disesuaikan dengan dukungan untuk alat pengembangan modern dan keamanan yang ditingkatkan. Dan tema dan plugin juga dibahas; selama mereka telah terdaftar di direktori tema dan plugin WordPress, mereka tersedia di bawah WordPress Packagist.

Akibatnya, ini adalah pilihan yang masuk akal untuk membuat kode WordPress tidak memikirkan tema dan plugin, tetapi berpikir dalam hal komponen, membuatnya tersedia melalui Packagist untuk digunakan oleh proyek PHP apa pun, dan juga dikemas dan dirilis sebagai tema dan plugin untuk penggunaan khusus WordPress. Jika komponen perlu berinteraksi dengan API WordPress, maka API ini dapat diabstraksikan di belakang antarmuka yang, jika diperlukan, dapat diimplementasikan untuk CMS lain juga.

Menambahkan Mesin Template Untuk Meningkatkan Lapisan Tampilan

Jika kami mengikuti rekomendasi pemikiran dan pengkodean dalam komponen, dan memperlakukan WordPress sebagai ketergantungan situs selain situs itu sendiri, maka proyek kami dapat membebaskan diri dari batasan yang diberlakukan oleh WordPress dan mengimpor ide dan alat yang diambil dari kerangka kerja lain.

Rendering konten HTML di sisi server adalah contohnya, yang dilakukan melalui template PHP biasa. Lapisan tampilan ini dapat ditingkatkan melalui mesin templat Twig (oleh Symfony) dan Blade (oleh Laravel), yang menyediakan sintaks yang sangat ringkas dan fitur canggih yang memberikan keunggulan dibandingkan templat PHP biasa. Secara khusus, blok dinamis Gutenberg dapat dengan mudah mendapatkan keuntungan dari mesin template ini, karena proses mereka untuk merender HTML blok di sisi server dipisahkan dari arsitektur hierarki template WordPress.

Arsitek Aplikasi Untuk Penggunaan Umum

Pengkodean terhadap antarmuka, dan pemikiran dalam hal komponen, memungkinkan kami untuk merancang aplikasi untuk penggunaan umum dan menyesuaikannya untuk penggunaan khusus yang perlu kami berikan, alih-alih pengkodean hanya untuk penggunaan khusus untuk setiap proyek yang kami miliki. Meskipun pendekatan ini lebih mahal dalam jangka pendek (ini melibatkan kerja ekstra), itu terbayar dalam jangka panjang ketika proyek tambahan dapat disampaikan dengan upaya yang lebih rendah dari hanya menyesuaikan aplikasi penggunaan umum.

Agar pendekatan ini efektif, pertimbangan berikut harus diperhitungkan:

Hindari Ketergantungan Tetap (Sebisa Mungkin)

jQuery dan Bootstrap (atau Foundation, atau <–masukkan perpustakaan favorit Anda di sini–> ) dapat dianggap sebagai must-have beberapa tahun yang lalu, namun, mereka terus kehilangan pijakan terhadap vanilla JS dan fitur CSS asli yang lebih baru. Oleh karena itu, proyek penggunaan umum yang dikodekan lima tahun lalu yang bergantung pada perpustakaan ini mungkin tidak cocok lagi saat ini. Oleh karena itu, sebagai aturan umum, semakin rendah jumlah dependensi tetap pada perpustakaan pihak ketiga, semakin mutakhir untuk jangka panjang.

Peningkatan Fungsionalitas Secara Progresif

WordPress adalah sistem CMS lengkap yang mencakup manajemen pengguna, oleh karena itu dukungan untuk manajemen pengguna disertakan di luar kotak. Namun, tidak semua situs WordPress membutuhkan manajemen pengguna. Oleh karena itu, aplikasi kita harus mempertimbangkan hal ini, dan bekerja secara optimal pada setiap skenario: dukung manajemen pengguna kapan pun diperlukan, tetapi jangan memuat aset terkait jika tidak. Pendekatan ini juga dapat bekerja secara bertahap: Katakanlah bahwa klien perlu menerapkan formulir Hubungi kami tetapi tidak memiliki anggaran, jadi kami mengkodekannya menggunakan plugin gratis dengan fitur terbatas, dan klien lain memiliki anggaran untuk membeli lisensi dari penawaran plugin komersial fitur yang lebih baik. Kemudian, kita dapat mengkodekan fungsionalitas kita ke default ke fungsionalitas yang sangat mendasar, dan semakin sering menggunakan fitur dari plugin mana pun yang paling mampu yang tersedia di sistem.

Tinjauan Kode Dan Dokumentasi Berkelanjutan

Dengan meninjau secara berkala kode yang telah kami tulis sebelumnya dan dokumentasinya, kami dapat memvalidasi apakah kode tersebut mutakhir mengenai konvensi dan teknologi baru dan, jika tidak, mengambil tindakan untuk meningkatkannya sebelum utang teknis menjadi terlalu mahal untuk diatasi. dan kita perlu mengkodekannya lagi dari awal.

Bacaan yang direkomendasikan : Waspadalah: Fungsi PHP dan WordPress yang Dapat Membuat Situs Anda Tidak Aman

Berusaha Meminimalkan Masalah Tapi Bersiaplah Ketika Itu Terjadi

Tidak ada perangkat lunak yang 100% sempurna: bug selalu ada, kami hanya belum menemukannya. Karena itu, kita perlu memastikan bahwa, begitu masalah muncul, masalah itu mudah diperbaiki.

Sederhanakan

Perangkat lunak yang kompleks tidak dapat dipertahankan dalam jangka panjang: Bukan hanya karena anggota tim lain mungkin tidak memahaminya, tetapi juga karena orang yang mengkodekannya mungkin tidak memahami kode kompleksnya sendiri beberapa tahun ke depan. Jadi memproduksi perangkat lunak sederhana harus menjadi prioritas, terlebih lagi karena hanya perangkat lunak sederhana yang bisa benar dan cepat.

Gagal Pada Waktu Kompilasi Lebih Baik Dari Pada Saat Runtime

Jika sepotong kode dapat divalidasi terhadap kesalahan baik pada waktu kompilasi atau waktu proses, maka kita harus memprioritaskan solusi waktu kompilasi, sehingga kesalahan dapat muncul dan ditangani pada tahap pengembangan dan sebelum aplikasi mencapai produksi. Misalnya, const dan define digunakan untuk mendefinisikan konstanta, namun, sedangkan const divalidasi pada waktu kompilasi, define divalidasi saat runtime. Jadi, bila memungkinkan, menggunakan const lebih disukai daripada define .

Mengikuti rekomendasi ini, mengaitkan fungsi WordPress yang terdapat dalam kelas dapat ditingkatkan dengan melewatkan kelas sebenarnya sebagai parameter, bukan string dengan nama kelas. Pada contoh di bawah ini, jika kelas Foo diganti namanya, sedangkan hook kedua akan menghasilkan kesalahan kompilasi, hook pertama akan gagal saat runtime, maka hook kedua lebih baik:

 class Foo { public static function bar() { } } add_action('init', ['Foo', 'bar']); // Not so good add_action('init', [Foo::class, 'bar']); // Much better

Untuk alasan yang sama seperti di atas, kita harus menghindari penggunaan variabel global (seperti global $wpdb ): ini tidak hanya mencemari konteks global dan tidak mudah untuk melacak dari mana asalnya, tetapi juga, jika diubah namanya, kesalahan akan diproduksi pada saat runtime. Sebagai solusinya, kita bisa menggunakan Dependency Injection Container untuk mendapatkan instance dari objek yang dibutuhkan.

Menangani Kesalahan/Pengecualian

Kita dapat membuat arsitektur objek Exception , sehingga aplikasi dapat bereaksi dengan tepat sesuai dengan setiap masalah tertentu, untuk memulihkannya bila memungkinkan atau menampilkan pesan kesalahan yang bermanfaat kepada pengguna bila tidak, dan secara umum mencatat kesalahan untuk admin untuk memperbaiki masalah. Dan selalu lindungi pengguna Anda dari layar putih kematian: Semua Error dan Exception yang tidak tertangkap dapat dicegat melalui fungsi set_exception_handler untuk mencetak pesan kesalahan yang tidak menakutkan di layar.

Mengadopsi Alat Bangun

Membangun alat dapat menghemat banyak waktu dengan mengotomatisasi tugas-tugas yang sangat membosankan untuk dijalankan secara manual. WordPress tidak menawarkan integrasi dengan alat build khusus apa pun, jadi tugas untuk memasukkannya ke dalam proyek akan sepenuhnya menjadi tanggung jawab pengembang.

Ada alat yang berbeda untuk mencapai tujuan yang berbeda. Misalnya, ada alat bantu untuk menjalankan tugas mengompresi dan mengubah ukuran gambar, mengecilkan file JS dan CSS, dan menyalin file ke direktori untuk menghasilkan rilis, seperti Webpack, Grunt dan Gulp; alat lain membantu membuat perancah proyek, yang berguna untuk menghasilkan struktur folder untuk tema atau plugin kita, seperti Yeoman. Memang, dengan begitu banyak alat di sekitar, menelusuri artikel yang membandingkan berbagai alat yang tersedia akan membantu menemukan yang paling cocok untuk kebutuhan kita.

Namun, dalam beberapa kasus, tidak ada alat pembangunan yang dapat mencapai persis apa yang dibutuhkan proyek kita, jadi kita mungkin perlu mengkode alat pembangunan kita sendiri sebagai ekstensi untuk proyek itu sendiri. Misalnya, saya telah melakukan ini untuk menghasilkan file service-worker.js untuk menambahkan dukungan untuk Service Worker di WordPress.

Kesimpulan

Karena penekanannya yang kuat pada menjaga kompatibilitas ke belakang, diperluas bahkan hingga PHP 5.2.4, WordPress belum dapat memanfaatkan fitur-fitur terbaru yang ditambahkan ke PHP, dan fakta ini telah membuat WordPress menjadi platform yang tidak terlalu menarik untuk dikodekan. untuk di antara banyak pengembang.

Untungnya, hari-hari suram ini akan segera berakhir, dan WordPress dapat menjadi platform yang mengkilap dan menarik untuk dikodekan sekali lagi: Persyaratan PHP 7.0+ mulai Desember 2019 akan membuat banyak fitur PHP tersedia, memungkinkan pengembang untuk menghasilkan lebih kuat dan perangkat lunak yang lebih berkinerja. Dalam artikel ini, kami meninjau fitur PHP terbaru yang paling penting dan cara memanfaatkannya secara maksimal.

Rilis Gutenberg baru-baru ini bisa menjadi pertanda masa-masa indah yang akan datang: bahkan jika Gutenberg sendiri belum sepenuhnya diterima oleh komunitas, setidaknya itu menunjukkan kesediaan untuk memasukkan teknologi terbaru (seperti React dan Webpack) ke dalam inti. . Pergantian peristiwa ini membuat saya bertanya-tanya: Jika frontend bisa mendapatkan perubahan seperti itu, mengapa tidak memperluasnya ke backend? Setelah WordPress membutuhkan setidaknya PHP 7.0, peningkatan ke alat dan metodologi modern dapat dipercepat: Sebanyak npm menjadi manajer paket JavaScript pilihan, mengapa tidak menjadikan Composer sebagai manajer ketergantungan PHP resmi? Jika blok adalah unit baru untuk membangun situs di frontend, mengapa tidak menggunakan komponen PHP sebagai unit untuk menggabungkan fungsionalitas ke backend? Dan akhirnya, jika Gutenberg memperlakukan WordPress sebagai CMS backend yang dapat ditukar, mengapa belum menyadari bahwa WordPress adalah ketergantungan situs dan bukan situs itu sendiri? Saya akan meninggalkan pertanyaan terbuka ini untuk Anda renungkan dan renungkan.