Cara Mendekati Pengembangan WordPress Modern (Bagian 1)

Diterbitkan: 2022-03-11

Bukan rahasia lagi bahwa basis kode WordPress berantakan. Secara pribadi, setiap kali saya melewatinya, yang saya inginkan hanyalah meringkuk dan menangis. Di sisi lain, WordPress jauh di depan para pesaingnya. CMS yang mudah digunakan dan kuat adalah tugas besar, dan WordPress tetap populer karena memberikan ini.

Jadi mengapa kita peduli dengan kualitas kode di inti WordPress? Ini bekerja, kan?

Ya, itu berhasil, dan basis kode berusia 15 tahun tidak mungkin sepenuhnya di-refactored oleh pengelola sukarelawannya. Sayangnya, ini berarti juga berfungsi sebagai contoh pengkodean "cara WordPress", yang memaafkan banyak pengembang karena tidak mengikuti praktik terbaik dan teknik pengembangan modern. Begitu banyak plugin dan tema WordPress memiliki kode yang sangat buruk, dan mengikuti praktik warisan secara membabi buta hanya melanjutkan tren.

Tetapi siapa yang peduli dengan kode buruk yang masih berfungsi? Yah, tidak ada yang gratis, dan seseorang membayar untuk pekerjaan yang dilakukan dengan buruk. Dengan basis kode WordPress itu sendiri, pengelolanya membayar dengan waktu mereka, untungnya. Tetapi dengan kode Anda sendiri, klien Anda yang membayar.

Untuk sistem yang bahkan cukup kompleks, biaya pengembangan awal tidak signifikan dibandingkan dengan biaya pemeliharaannya, dan pemeliharaan juga berarti menambahkan fungsionalitas baru. Menyewa pengembang untuk memperbaiki perangkat lunak yang dirancang dan diimplementasikan dengan buruk akan menghabiskan biaya beberapa kali lebih banyak daripada mengembangkannya dengan benar sejak awal.

Solusi murah selalu yang paling mahal dalam jangka panjang. Atau mereka ditinggalkan setelah kehabisan anggaran. Kami benar-benar menghemat uang klien ketika kami mengikuti prinsip dan praktik desain perangkat lunak yang telah terbukti. Metode-metode ini bukan sekadar iseng-iseng, atau perubahan demi perubahan. Kebijaksanaan di sini lahir dari pengalaman pengembang kolektif, dan mengikutinya benar-benar membuahkan hasil.

Jelas, ini tidak berlaku untuk tugas yang benar-benar sederhana seperti menambahkan beberapa baris CSS atau beberapa posting dan penulisan ulang kustom. Tetapi menggabungkan beberapa plugin (atau lebih umum beberapa lusinan plugin) atau membuat situs yang didukung Visual Composer bukanlah rekayasa perangkat lunak.

Itu bukan hal yang buruk, sebenarnya — fakta bahwa beberapa solusi sesederhana ini adalah alasan mengapa WordPress sangat populer. Namun dalam seri ini saya akan berbicara tentang pengembangan WordPress yang sebenarnya : menulis kode PHP, HTML, CSS, dan JavaScript yang signifikan. Saya akan mulai dengan alur kerja umum dan kemudian fokus pada pengembangan front-end WordPress di artikel ini.

Alur Kerja Pengembangan WordPress Modern

Secara umum, kode kualitas adalah:

  • Dapat dibaca. Sangat mudah untuk memahami apa yang dilakukan kode dan mengapa.
  • Modular. Blok kode kecil dengan tujuan yang jelas mudah dipahami, dikembangkan, dan diuji.
  • Dapat digunakan kembali. Menggunakan kembali modul yang sudah dikembangkan untuk memecahkan masalah serupa secara signifikan mempercepat pengembangan.
  • Dapat dipelihara. Memodifikasi fungsionalitas lama atau memperkenalkan fitur baru itu mudah.

Hasil utama—biaya pengembangan dan kepemilikan yang lebih rendah—memiliki banyak manfaat tambahan yang tidak akan saya bahas di sini.

Sebagai gantinya, saya akan fokus pada teknik pengembangan dan praktik terbaik mana yang dapat membantu Anda menghasilkan kode berkualitas. Mari kita mulai dengan kontrol versi.

Gunakan Kontrol Versi

Ini berarti menggunakan Git. Sayangnya, "pengkodean koboi" pada produksi melalui FTP masih cukup banyak. Baru-baru ini saya bekerja untuk agensi yang berbasis di Inggris dan mereka memiliki file dengan nama seperti ini di seluruh basis kode mereka:

  • functions copy.php
  • functions copy 2.php
  • functions test.php
  • functions2.php
  • functions test2.php

Hal pertama yang harus Anda lakukan saat membuka situs WordPress adalah meletakkannya di bawah kontrol versi. Tanking Servers adalah retrospektif yang menyenangkan dari kesalahan pengembangan WordPress. Akan sangat mudah untuk mengubahnya—dan kecelakaan serupa yang mungkin terjadi pada semua orang—menggunakan Git.

Membuat kesalahan dalam kode Anda dan seluruh situs mati? git reset semuanya seperti semula. Pembaruan versi baru merusak segalanya? git reset berfungsi sebagai mesin waktu. Beberapa kode berbahaya muncul entah dari mana? git status menunjukkan file baru, file yang dihapus, atau perubahan pada file yang dilacak. Kemudian Anda hanya git checkout , memulihkan aslinya.

Waspadalah terhadap Mengekspos Folder .git

Oke, jelas penting untuk menggunakan Git. Tetapi ketika Anda melakukannya, sama pentingnya untuk menghindari mengekspos repositori Git Anda untuk diretas. Masalahnya muncul ketika Anda membuka folder .git dan menyimpan kredensial Anda di dalamnya.

Instalasi WordPress standar sepenuhnya berada di folder web publik, dan folder .git kemungkinan besar juga ada di sana. Jelas, tidak ada kredensial login yang harus disimpan di repositori Git, tetapi kebetulan sebagian besar repositori memang berisi beberapa informasi sensitif yang tidak boleh bocor ke luar.

Jadi akses publik ke folder .git harus diblokir. Jika Anda menggunakan Apache, menambahkan cuplikan di bawah ini di bagian atas file .htaccess akan memblokir akses ke folder .git dan juga ke file log. File log sering kali berisi informasi sensitif, jadi sebaiknya juga membuatnya tidak tersedia. Untuk penyiapan server web yang berbeda, harap minta bantuan pakar DevOps Anda.

 RedirectMatch 404 /\.git RedirectMatch 404 ^.*\.log

Gunakan Lingkungan Terpisah

Jangan lakukan pengembangan di situs langsung—ini adalah resep untuk waktu henti dan klien yang tidak puas. OK, tapi bagaimana Anda harus mengaturnya?

Idealnya, harus ada tiga lingkungan pengembangan, dengan kode selalu berjalan dalam satu arah: lokal → pementasan → produksi. Ini adalah metode yang terbukti untuk menghindari tabrakan. Semua pembaruan inti, plugin, dan tema pertama-tama dilakukan secara lokal, kemudian diuji pada staging, dan akhirnya disebarkan ke produksi.

Misalnya, konfigurasi khusus server dapat disimpan dalam file terpisah. Anda dapat membuat wp-config-local.php untuk setiap lingkungan lokal dan staging. (Jangan lupa untuk menambahkannya ke file .gitignore Anda!) Kemudian tambahkan potongan berikut ke wp-config.php :

 if (file_exists(dirname(__FILE__) . '/wp-config-local.php')) : // use local settings require_once(dirname(__FILE__) . '/wp-config-local.php'); else : // production settings endif;

Seringkali cara terbaik untuk menyiapkan lingkungan yang berbeda adalah menggunakan variabel lingkungan. Jika Anda tidak terbiasa dengan konsep ini, saya sarankan menggunakan solusi modern lengkap seperti Roots.

Gunakan WP-CLI

Antarmuka baris perintah WordPress (WP-CLI) adalah alat yang sangat berguna untuk mengelola instalasi WordPress. Memiliki akses ke WP-CLI berarti memiliki kemampuan untuk menjalankan hampir semua fungsi API WordPress. Misalnya, Anda dapat menambah, menghapus, dan mengedit pengguna dan kata sandi mereka dengan WP-CLI. Berguna jika Anda baru saja mewarisi situs dan pemiliknya telah mengunci diri.

Contoh lain adalah bahwa penerapan awal sangat mudah dengan WP-CLI. Ini dapat dicapai dengan beberapa perintah:

  • Mengunduh inti, tema, dan plugin
  • Mencari dan mengganti dalam database
  • Menambahkan pengguna admin

Selain itu, tindakan ini dapat ditulis dan diotomatisasi.

Gunakan Opsi Penerapan Tingkat Lanjut

Berbicara tentang otomatisasi, ada baiknya mempelajari beberapa teknologi dan proses penerapan seperti:

  • Integrasi berkelanjutan/penerapan/pengiriman berkelanjutan (CI/CD)
  • Buruh pelabuhan
  • Pengujian otomatis (termasuk uji regresi front-end)

Memang, beralih dari tidak menggunakan kontrol versi ke berurusan dengan Docker adalah lompatan besar yang harus dilakukan dan kemungkinan akan luar biasa untuk proyek WordPress satu orang yang khas. Beberapa opsi bahkan mungkin tidak dapat dilakukan tergantung pada penyedia hosting Anda. Tetapi penerapan lanjutan harus dimiliki oleh tim dan untuk proyek yang lebih besar.

Gunakan Linting

Namun, untuk proyek dengan ukuran berapa pun, linting adalah anugerah bagi sebagian besar pengembang. Linting berarti secara otomatis memeriksa kode Anda untuk kesalahan. IDE berfitur lengkap seperti PHPStorm sudah melakukannya di luar kotak; namun, editor yang lebih sederhana seperti VSCode atau Sublime Text memerlukan program khusus yang disebut linter. Salah satu cara untuk mengatur ini adalah mengonfigurasi editor Anda untuk menjalankan linter setiap kali Anda menyimpan file.

PHP_CodeSniffer adalah linter de-facto untuk PHP. Selain memeriksa kesalahan sintaks, itu juga dapat memeriksa apakah kode Anda mengikuti pedoman gaya seperti PSR-2. Ini sangat menyederhanakan standar pengkodean berikut.

Untuk JavaScript, ESLint adalah linter yang populer. Ini memiliki seperangkat aturan yang luas dan mendukung konfigurasi khusus untuk semua rasa dan kerangka kerja JavaScript di luar sana.

Kasus penggunaan yang hebat di sini adalah menggabungkan linting ke dalam pipeline build CI/CD sehingga semua kode divalidasi secara otomatis sebelum diterapkan.

Teknik Pengembangan Front-end WordPress Modern

Dengan alur kerja yang tepat sekarang disiapkan untuk keseluruhan proyek WordPress Anda, mari selami praktik terbaik untuk front end.

Gunakan Perkakas Modern: Sass dan ES6+

Dunia pengembangan front-end selalu berubah dan selalu bergerak. Setelah kami berpikir bahwa Sass adalah alat terbaik untuk menulis CSS—dan untuk pengembangan WordPress pra-Gutenberg, masih demikian—tetapi kemudian semua orang mulai berbicara tentang CSS-in-JS dan komponen gaya.

Bahkan WordPress tidak dapat menolak dan mengambil beberapa dari teknologi baru tersebut. Gutenberg, editor blok baru, dibangun di atas React dan REST API.

Anda pasti harus mempercepat dengan teknologi inti front-end ini:

  • ES6+. Dokumentasi WordPress menyebutnya ESNext dan bahkan mendorong untuk menggunakannya.
  • Kelancangan. Digunakan oleh WooCommerce dan cara terbaik untuk menulis CSS jika Anda belum mendalami CSS-in-JS.
  • paket web. Bahkan inti WordPress menggunakan Webpack dan Babel sekarang.

ES6 dan Sass masing-masing adalah JavaScript dan CSS modern, dan Webpack adalah alat yang memungkinkan penggunaan semua fitur modern ini tanpa mengkhawatirkan kompatibilitas mundur. Webpack dapat disebut sebagai kompiler aplikasi front-end yang menghasilkan file untuk digunakan di browser.

Transisi dari jQuery ke Vue.js atau React

Inti WordPress dan hampir semua plugin WordPress bergantung pada jQuery, jadi Anda tidak bisa berhenti menggunakannya. Sebenarnya, tidak masuk akal untuk berhenti menggunakannya untuk tugas-tugas sederhana seperti menyembunyikan beberapa <div> atau melakukan permintaan AJAX satu kali ketika Anda terbiasa melakukannya dengan cara itu. jQuery akan tetap dimuat, dan sederhana serta mudah digunakan.

Aplikasi kompleks adalah tempat jQuery berjuang: Logika yang sulit diikuti, neraka panggilan balik, variabel global, dan tidak ada templating HTML. Ini jelas membutuhkan cara berbeda untuk mengatur aplikasi front-end.

Pustaka front-end modern seperti React menggunakan prinsip pemrograman berorientasi objek (OOP) dan mengatur arsitektur aplikasi front-end ke dalam komponen modular yang dapat digunakan kembali. Sebuah komponen berisi semua kode, markup, dan "status komponen" (variabel) untuk elemen tertentu. Elemen dapat berupa apa saja: Tombol, bidang input, formulir pengguna, atau widget yang menampilkan posting terbaru dari bagian belakang REST API WordPress. Komponen dapat berisi komponen lain, membentuk hubungan hierarkis.

Dengan kompleksitas halaman web saat ini, mengatur aplikasi ke dalam komponen adalah cara yang terbukti untuk membangun aplikasi web cepat yang dapat dipelihara dengan kompleksitas apa pun. Komponen sangat dapat digunakan kembali, terisolasi, dan dengan demikian "batu bata" yang mudah diuji, jadi sangat bermanfaat untuk mempelajari konsep ini.

Ada dua library berbasis komponen yang sedang tren saat ini: Vue.js dan React. Bereaksi akan menjadi pilihan yang jelas karena sudah digunakan oleh Gutenberg. Namun, untuk seseorang yang baru mengenal JavaScript modern, Vue.js bisa lebih baik untuk memulai.

React membawa Anda ke ujung terdalam dengan menggunakan fitur ES6, kelas, sintaks JSX berpemilik, dan pipa build Webpack langsung. Kurva pembelajarannya cukup curam.

Vue.js, di sisi lain, jauh lebih ramah-pemula, dan dapat digunakan hanya dengan memasukkan <script> . Vue.js menggunakan JavaScript biasa (ES5), HTML, dan CSS. Pengenalan konsep baru jauh lebih bertahap.

Setelah mengerjakan beberapa proyek Vue.js, Anda akan lebih siap untuk mendalami React. Bukan berarti selalu dibutuhkan, tetapi pengembangan Gutenberg, misalnya, memang membutuhkannya.

Gunakan API REST WordPress

REST API WordPress hanyalah antarmuka standar untuk meminta dan memodifikasi data dari WordPress dari jarak jauh. Ini lebih merupakan arsitektur perangkat lunak daripada cara pengkodean yang sama sekali berbeda. Cuplikan jQuery AJAX lama yang sama dapat digunakan dengan parameter yang sedikit berbeda.

Manfaat yang paling penting? Karena REST API WordPress menstandarkan komunikasi antara ujung belakang dan ujung depan, ini adalah langkah besar menuju modularitas, kegunaan kembali, dan keterbacaan dalam kode Anda. Template mengerikan dengan HTML dan PHP dicampur bersama dan beberapa SQL dilemparkan ke dalam campuran harus pergi. Setelah template hanya HTML dengan placeholder untuk data yang diteruskan sebagai parameter, tidak ada perbedaan besar antara meneruskan data tersebut dalam PHP atau melalui REST API ke aplikasi front-end.

Anda mungkin juga ingin melihat ke WPGraphQL. Ini mungkin atau mungkin tidak pada akhirnya menggantikan API REST WordPress, tetapi mendapatkan daya tarik dengan cepat.

Learn Gutenberg (Klien Akan Membutuhkannya Segera)

Tujuan akhir Gutenberg adalah kustomisasi situs penuh, di antara rencana lainnya.

Ini meletakkan dasar untuk model baru untuk WordPress Core yang pada akhirnya akan memengaruhi seluruh pengalaman penerbitan platform.

Halaman proyek WordPress Gutenberg di GitHub

Gutenberg memang menerima penolakan besar dari pengembang WordPress. Beberapa argumen yang menentang penggabungannya ke inti WordPress adalah:

  • Sebagian besar pengguna akhir tidak membutuhkannya, jadi itu harus menjadi plugin opsional dan bukan bagian dari inti
  • Itu merusak beberapa situs
  • Itu sama sekali belum siap dan bisa menggunakan lebih banyak pemolesan dan lebih sedikit bug

Namun, bagi penulis konten yang menggunakan WordPress sebagai platform blogging, Gutenberg jelas memberikan pengalaman yang lebih baik daripada editor lama.

Menonaktifkan Gutenberg akan didukung selama diperlukan, ya. Tapi melonggarkannya sekarang adalah ide yang bijaksana: Ketika klien mendekati Anda dan meminta untuk melakukan pengembangan Gutenberg, Anda akan siap.

Saatnya Mempercepat: Bahkan "Cara WordPress" Berkembang

Argumen paling umum yang menentang penggunaan semua alat dan teknik yang dijelaskan di atas dalam pengembangan WordPress adalah ini: "Cara WordPress" dalam melakukan sesuatu masih berfungsi, dan cara itu seharusnya lebih baik daripada semua hal baru yang mengkilap ini.

Tetapi Anda sekarang telah melihat bahwa pengembang inti WordPress sangat menyadari semua perkembangan terbaru. Tidak hanya itu, mereka menggunakannya sebanyak mungkin di bagian inti yang lebih baru karena keunggulannya yang jelas. Satu-satunya hal yang menahan kami adalah kode lawas yang tidak akan difaktorkan oleh siapa pun.

Untuk beberapa waktu, WordPress dan WooCommerce telah mengikuti praktik pengembangan "plugin fitur" yang menerapkan dan menggunakan teknologi baru. Ketika waktunya tepat, plugin ini digabungkan menjadi inti, seperti yang dilakukan Gutenberg. WooCommerce juga memiliki proyek React-nya sendiri. WordPress REST API juga dimulai sebagai plugin terpisah dan sekarang menjadi bagian dari inti WordPress.

Pertanyaannya bukanlah apakah kita harus mempelajari hal-hal baru dan menggunakannya dalam pekerjaan sehari-hari, tetapi bagaimana . Jawabannya adalah “secara bertahap,” selangkah demi selangkah. Entah mempelajari hal baru atau melakukan sesuatu yang Anda ketahui dengan baik dengan cara yang baru dan berbeda.

Misalnya, pelajari cara menggunakan Webpack dengan semua skrip lama Anda. Webpack dapat mengubah kode ES6+ baru Anda menjadi JavaScript "biasa" yang kompatibel dengan browser lama. Itu juga dapat mengecilkan skrip dan menggabungkannya. Itu satu hal baru. Selesai? Kemudian tulis ulang JavaScript Anda dengan memanfaatkan fitur ES6. Ini adalah cara baru untuk melakukan apa yang Anda ketahui dengan baik.

Hasilnya: Anda akan mempelajari Webpack dan ES6. Sebagai profesional, kita harus melangkah dan tidak mundur. Selalu terus belajar. Dan bagikan saat Anda melakukannya: Toptal menyimpan daftar praktik terbaik pengembangan WordPress dan menyambut baik kontribusi komunitas untuk itu.

Di Bagian 2 dari seri kami, kami akan menyelami bagian PHP dari pengembangan back-end WordPress modern.