12 Kesalahan Terburuk yang Dilakukan Pengembang WordPress Tingkat Lanjut

WordPress adalah cara yang sangat populer untuk membuat situs aktif dan berjalan dengan cepat. Namun, karena tergesa-gesa, banyak pengembang akhirnya membuat keputusan yang mengerikan. Beberapa kesalahan, seperti membiarkan WP_DEBUG disetel ke true mungkin mudah dilakukan. Lainnya, seperti menggabungkan semua JavaScript Anda ke dalam satu file, sama umum dengan insinyur yang malas. Kesalahan apa pun yang Anda buat, baca terus untuk mengetahui 12 kesalahan WordPress paling umum yang dilakukan pengembang baru dan berpengalaman. Jika Anda menemukan diri Anda melakukan salah satu kesalahan ini, jangan putus asa. Setiap kesalahan adalah kesempatan untuk belajar.

1. Menempatkan Kode JavaScript Tema WordPress ke Dalam Satu File Utama

Suatu kali, saat melakukan pengoptimalan kecepatan halaman untuk situs web klien, saya perhatikan mereka menggunakan tema premium yang memiliki semua pustaka yang mereka gunakan, termasuk kode khusus, dalam satu file bernama main.js , theme.js atau custom.js . Praktik ini buruk karena alasan berikut:

1. File, pada waktunya, bisa menjadi sangat besar karena tema, yang sedang dikembangkan secara aktif, akan bertambah fiturnya dan terkadang Anda akan melihat file berukuran sebesar 1 MB. File akan dimuat di seluruh situs meskipun hanya 10% kode dari file yang diperlukan di beberapa halaman. Ini akan membuat halaman membutuhkan waktu lebih lama untuk diunduh dan lebih lambat untuk dirender, terutama jika itu membuat kode pemblokiran di dalam bagian kepala halaman.
2. Itu membuat pengelolaan kode di dalam file lebih sulit, karena Anda tidak dapat menggunakan fungsi seperti wp_dequeue_script() untuk membongkar beberapa kode di beberapa halaman untuk meningkatkan kecepatan halaman atau untuk mencegah konflik dengan kode JavaScript lain yang mungkin dimuat oleh salah satu plugin yang aktif. Tentu, file dapat dipecah menjadi beberapa file dan dimasukkan ke dalam antrean di WordPress, tetapi jika di kemudian hari, administrator situs web melakukan pembaruan file main.js tema, maka seluruh proses harus dimulai dari awal lagi.

2. Menggunakan Nama yang Terlalu Umum untuk Variabel, Fungsi, Konstanta, atau Kelas

Saat mengembangkan plugin, lebih baik menggunakan konvensi penamaan yang mencegah konflik kode jika ada plugin lain yang menggunakan nama yang sama. Itu sebabnya banyak pengembang awalan variabel dan nama fungsi mereka dengan sesuatu yang unik dan terkait dengan plugin itu sendiri. Selain menghilangkan konflik kode, itu juga membuat segalanya lebih mudah ditemukan ketika Anda mengaktifkan banyak plugin.

Ada pengembang, di sisi lain, yang lebih suka menggunakan ruang nama PHP untuk merangkum item dan memecahkan dua masalah yang dihadapi penulis perpustakaan dan aplikasi saat membuat elemen kode yang dapat digunakan kembali seperti kelas atau fungsi:

1. Beri nama tabrakan antara kode yang mereka buat, dan PHP internal, atau pihak ketiga, kelas, fungsi, atau konstanta
2. Kemampuan untuk alias (atau mempersingkat) Extra_Long_Names dirancang untuk memperbaiki masalah pertama atau meningkatkan keterbacaan kode sumber. Yang ini favorit saya karena saya sering mengembangkan tema atau plugin yang memiliki banyak kode. Dengan ini, saya dapat membaca dan mengelola kode dengan mudah tanpa harus terlalu khawatir memiliki nama unik yang panjang.

Saya akan merekomendasikan pemahaman yang baik tentang ruang nama sebelum menggunakannya karena sering kali dapat digunakan dengan cara yang salah.

Bergantung pada proyek yang akan Anda ikuti, kemungkinan Anda harus tetap menggunakan gaya pengkodean yang ada, kecuali jika pekerjaan Anda sebagian besar terpisah dari yang sudah ada. Jika Anda harus memperluas plugin atau tema yang sudah ada yang sudah mengikuti standar pengkodean PHP untuk WordPress, maka yang terbaik adalah tetap menggunakannya agar memiliki gaya yang konsisten sehingga kode menjadi bersih dan mudah dibaca. Perhatikan bahwa beberapa aturan diterapkan secara universal untuk meningkatkan kinerja, dengan mengabaikan gaya pengkodean. Misalnya, selalu yang terbaik untuk menggunakan tanda kutip tunggal (bukan tanda kutip ganda) jika Anda tidak mengevaluasi apa pun dalam string. Selain itu, kode harus diindentasi agar dapat dibaca, terutama jika kode tersebut memiliki kode bersarang (misalnya, IF s dalam IF s, FOREACH s dan FOR s bersarang).

3. Tidak Memanfaatkan Fungsi Inti WordPress yang Ada ke Potensi Sebenarnya

Karena WordPress hadir dengan rangkaian pustaka yang diperbarui secara berkala yang dapat dipanggil begitu saja di plugin dan tema kami, sebaiknya gunakan sebanyak mungkin fungsi inti yang ada. Saya telah melihat tema dan plugin WordPress yang memiliki file di direktori aset mereka yang sudah ada di file inti WordPress (misalnya, jQuery atau Color Picker). Selain fakta bahwa paket akan menjadi lebih besar dan membutuhkan waktu lebih lama untuk memuat melalui jaringan, Anda juga harus memastikan bahwa semua perpustakaan pihak ketiga diperbarui secara berkala, yang merupakan hal lain yang perlu diperhatikan.

Manfaatkan apa yang sudah ditawarkan WordPress, karena perpustakaan sudah diperbarui oleh tim inti pengembangan WordPress dan Anda dapat memiliki proyek yang ringan dan lebih mudah dirawat. Dengan secara teratur melakukan pembaruan WordPress, Anda mendapatkan akses ke lebih banyak fitur (apakah itu plugin, tema, atau inti WordPress itu sendiri karena Dasbornya ditingkatkan secara konsisten) dan membuat situs web lebih aman jika ditemukan kerentanan dalam rilis kode lama.

4. Tidak Membuat Plugin atau Tema Mudah Diubah melalui Tindakan dan Filter

Mengedit plugin atau tema WordPress secara langsung adalah ide yang buruk, kecuali, tentu saja, Anda terlibat langsung dalam pengembangan paket itu dan berkontribusi pada kodenya. Jika pembaruan otomatis dilakukan pada plugin atau tema, maka setiap perubahan langsung pada paket akan hilang dan Anda harus mengedit file dari awal lagi.

Itulah mengapa menggunakan tindakan dan filter serta membuat tema Anak (yang memperluas tema induk) adalah pendekatan paling efektif untuk memodifikasi tema karena Anda dapat mengubah fungsi yang ada tanpa mengedit tema induk atau plugin itu sendiri. Selain itu, jika Anda menawarkan plugin untuk diunduh gratis di WordPress.org dan kemudian Anda ingin membuat ekstensi premium yang akan bergantung pada plugin induk, maka Anda harus mengembangkan plugin gratis sedemikian rupa sehingga akan mudah untuk memperpanjang dan menambahkan ekstensi premium.

5. Berkembang dengan WP_DEBUG Set ke false

Secara default, konstanta WP_DEBUG disetel ke 'false' untuk menghindari pencetakan kesalahan, peringatan, dan pemberitahuan PHP apa pun. Pada lingkungan langsung, ini adalah pilihan yang disarankan karena membuat jalur server pribadi dan skrip tersembunyi dari tampilan publik, yang sangat bagus untuk alasan keamanan. Namun, selama tahap pengembangan, sebaiknya disetel ke 'true' karena akan memberi tahu kami jika ada kesalahan dalam kode kami. Bahkan jika kesalahan tidak secara langsung mempengaruhi fungsionalitas, sering kali akan memaksa Anda untuk menulis kode yang lebih baik dan mengembangkan kebiasaan pengkodean yang lebih baik. Itu terjadi pada saya. Ini juga akan memastikan bahwa plugin atau tema yang Anda kembangkan tidak menghasilkan kesalahan PHP di instalasi WordPress apa pun.

Meskipun ini adalah sesuatu yang dilakukan oleh sebagian besar pengembang berpengalaman, ini terjadi, terutama saat terburu-buru. Tidak peduli seberapa mendesak pekerjaannya, pengembang harus selalu berusaha mempertahankan standar pengkodean WordPress, dengan memperhatikan praktik terbaik PHP.

6. Menulis Kode PHP tanpa Mempertimbangkan Bahwa Halaman Bisa Di-cache Suatu Hari

Ini adalah kesalahan umum PHP dan, seperti yang sebelumnya, relatif mudah untuk dihindari jika Anda tetap berpegang pada standar pengkodean PHP.

Beberapa pengembang memiliki kebiasaan mengimplementasikan cuplikan PHP ke dalam tema dan plugin yang hanya valid jika kode PHP dipicu sepanjang waktu. Misalnya, fungsi PHP yang merespons Agen Pengguna HTTP dengan tindakan tertentu harus diambil atau tidak (misalnya, skrip enqueuing yang dimaksudkan hanya untuk pengguna seluler).

Jika klien Anda memasang plugin yang menyimpan halaman (misalnya, W3 Total Cache atau WP Rocket) tanpa memicu persyaratan dalam tema atau plugin Anda, kode PHP Anda akan dianggap tidak berguna. Jika tujuannya adalah untuk membuat halaman responsif, maka ini harus dilakukan di sisi front-end melalui kueri media dan JavaScript. Yang terakhir, hanya jika itu benar-benar diperlukan. Idealnya, Anda ingin menghindari penggunaan JavaScript untuk membuat situs Anda responsif.

7. Tidak Melacak Perubahan yang Dibuat Secara Profesional melalui Sistem Kontrol Versi Seperti Git

File yang dikodekan khusus, seperti tema anak atau plugin khusus, idealnya berada di bawah kontrol versi. Git membuat catatan tentang apa yang diubah dan memungkinkan pengembang untuk bekerja sama pada proyek WordPress yang sama atau kembali ke versi sebelumnya dengan mudah setiap kali ada yang tidak beres dengan situs web. Selain itu, klien dapat menggunakan Git untuk melacak semua riwayat pekerjaan yang dilakukan oleh semua pengembang yang dipekerjakan untuk proyek tertentu, terutama jika itu adalah situs web kustom WordPress jangka panjang yang besar.

Meskipun pada awalnya mungkin menakutkan, terutama untuk pengembang junior, memahami Git akan sepadan dengan waktu dan perangkat lunak Git GUI seperti SourceTree (salah satu favorit saya) akan menjadi cara Anda berinteraksi dengan repositori Git Anda, membuat keseluruhan kurva belajar lebih menyenangkan. Setelah Anda memahami cara kerjanya, pertimbangkan untuk memeriksa Praktik Terbaik dan Kiat Git oleh Toptal Developers yang menjelaskan secara lebih mendalam beberapa cara menggunakan Git.

8. Mengantrekan File CSS dan JavaScript Saat Tidak Dibutuhkan

Memiliki banyak permintaan HTTP akan membuat situs web lebih lambat untuk memuat, sehingga memiliki skor yang lebih rendah di Google PageSpeed ​​yang kemungkinan akan mempengaruhi peringkat pencarian. Ini juga dapat menyebabkan kesalahan JavaScript karena konflik antar plugin. Misalnya, mungkin ada dua plugin yang menggunakan pustaka jQuery umum, yang mungkin dimuat dua kali dan dapat menyebabkan masalah. Dan sungguh, ini adalah contoh terbaik, karena jQuery sangat sering dimuat di situs web langsung beberapa kali. Ini mungkin terjadi karena plugin atau tema yang ditulis dengan buruk.

9. Menggunakan File .php untuk Output CSS atau Kode JavaScript Alih-alih File Statis .css dan .js

Saya telah melihat tema dan bahkan plugin WordPress yang memiliki file seperti style.php yang digunakan hanya untuk menghasilkan kode CSS khusus dan mencetaknya. Hal-hal seperti warna, ukuran font dan spasi di sekitar elemen diatur dalam pengaturan tema dan kemudian disimpan dalam database. Kemudian style.php dibaca (misalnya, <link rel='stylesheet' type='text/css' href='css/style.php?ver=1' /> ) dan menghasilkan kode CSS berdasarkan pengaturan khusus yang telah diperbarui di dasbor.

Ini benar-benar praktik yang buruk dalam hal kinerja WordPress. Berikut adalah kerugian utama yang menyertainya:

1. Karena file CSS dimuat di dalam tag head (yang normal dan sebagian besar dimuat seperti ini), ada masalah kinerja yang menyertainya karena browser harus mengunduh file sepenuhnya sebelum merender halaman. Jika lingkungan WordPress lambat karena beberapa plugin, maka ini akan sangat menunda waktu buka. Bahkan jika teknik caching digunakan atau hanya sebagian dari lingkungan WordPress yang dimuat untuk mengambil nilai dari database. Sebaiknya gunakan file .css statis sebagai gantinya.
2. Dalam file PHP, kode (aturan CSS yang dicampur dengan variabel PHP dan klausa bersyarat) akan lebih sulit dibaca oleh pengembang ketika mereka perlu memeriksa sesuatu. Tentu, file dapat dijalankan di browser (walaupun saya yakin ketika dicetak, itu bahkan tidak akan menjorok atau terlihat bagus) tetapi jika Anda memiliki salinan lokal proyek dan menelusuri kode tema dan Anda perlu untuk menemukan sintaks CSS atau JavaScript (jika script.php akan digunakan), maka itu akan membuat keterbacaan lebih sulit.

Solusinya: Simpan CSS khusus apa pun di luar direktori plugin. Contoh: /wp-content/uploads/theme-name-custom-css/style-5.css . Dengan cara ini, jika tema atau plugin diperbarui, maka file kustom tidak akan hilang.

10. Tidak Menggunakan Arsitektur (Organisasi Kode) yang Tepat untuk Plugin dan Tema WordPress

Bergantung pada ukuran dan sifat plugin (misalnya, plugin mandiri atau ekstensi plugin yang hanya berfungsi jika plugin utama diaktifkan seperti WooCommerce), arsitektur dan organisasi kode yang tepat harus disiapkan.

Jika Anda harus membuat plugin WordPress tujuan tunggal untuk klien dan memiliki interaksi terbatas dengan inti WordPress, tema, dan plugin lainnya, itu tidak efektif untuk merekayasa kelas yang kompleks kecuali Anda yakin plugin akan berkembang pesat nanti. di.

Jika plugin akan ditampilkan kaya dengan banyak kode, maka menggunakan pendekatan pengkodean Pemrograman Berorientasi Objek (OOP) (memiliki banyak kelas) akan masuk akal. Misalnya, jika Anda memiliki banyak kode pendek, Anda dapat menyimpan semuanya dalam file kelas terpisah seperti class.shortcodes.php atau jika ada file CSS dan JavaScript yang dimaksudkan untuk dimuat dalam Dasbor dan tampilan front-end kemudian satu kelas seperti class.scripts.php dapat digunakan dan mengantrekan file front-end dalam metode seperti enqueue_public_scripts() sambil mengantrekan file yang dimaksudkan untuk dimuat di area admin dalam metode enqueue_admin_scripts() .

Daripada mencampur HTML dengan kode PHP, lebih baik memisahkannya dengan menerapkan pola MVC ke dalam plugin dan tema. Contoh yang bagus adalah plugin WooCommerce. Ini memiliki template untuk berbagai tata letak yang juga dapat ditimpa dengan mudah melalui tema atau berbagai filter hanya karena logikanya terpisah dari desain. Template yang berisi tata letak HTML sebagian besar digunakan untuk mencetak informasi yang sudah diproses. Memiliki kode HTML dalam metode PHP biasanya merupakan praktik yang buruk (tentu saja ada pengecualian untuk potongan kecil kode HTML), terutama untuk plugin yang dikelola oleh lebih dari satu pengembang seiring bertambahnya ukurannya.

Menurut Buku Pegangan Plugin WordPress, meskipun ada sejumlah kemungkinan pola arsitektur, mereka dapat dikelompokkan secara luas menjadi tiga variasi:

• File plugin tunggal, berisi fungsi
• File plugin tunggal, berisi kelas, objek instantiated, dan, opsional, fungsi
• File plugin utama, lalu satu atau lebih file kelas

11. Tidak Memperhatikan Keamanan WordPress dengan Serius Saat Menulis Kode

Keamanan seringkali tidak dianggap serius dalam pengembangan WordPress karena banyak pengembang pemula lebih fokus pada hasil yang diinginkan klien. Semuanya baik-baik saja sampai situs web klien diretas atau plugin Anda yang dipublikasikan di WordPress.org memiliki kerentanan, membuat ribuan situs web terpengaruh. Hal-hal ini kadang-kadang terjadi dan bahkan inti WordPress telah menangani cukup banyak kerentanan keamanan sejak hari-hari awal CMS. Merupakan tanggung jawab kami untuk membuatnya seaman mungkin dan, jika terjadi sesuatu, untuk bertindak segera dan memastikan bahwa kami merilis patch yang solid dan teruji dengan baik.

Beberapa tips keamanan yang paling penting adalah:

Kerentanan XSS: Untuk menghindari hal ini, dua hal yang harus dilakukan: membersihkan input data dan membersihkan data output. Bergantung pada data dan konteks yang digunakan, ada beberapa metode di WordPress untuk membersihkan kode. Seseorang seharusnya tidak mempercayai data input apa pun, atau data apa pun yang akan dicetak. Salah satu fungsi umum untuk membersihkan input data adalah sanitize_text_field() . Ini memeriksa karakter UTF-8 yang tidak valid, mengonversi < karakter tunggal menjadi entitas HTML, menghapus semua tag, menghapus jeda baris, tab dan spasi ekstra dan menghapus oktet. Untuk mencetak data, contoh yang baik untuk mengeluarkan tautan adalah fungsi esc_url() , yang menolak URL yang tidak valid, menghilangkan karakter yang tidak valid, dan menghapus karakter yang berbahaya.

Cegah akses langsung ke file Anda: File dapat langsung diakses karena sebagian besar host mengizinkannya. Namun, jika ini terjadi dan kode tidak ditulis dengan benar untuk mengatasinya, beberapa kesalahan mungkin dicetak (misalnya, fungsi atau variabel yang hilang yang tidak dideklarasikan) yang akan berisi informasi berharga bagi penyerang potensial. Salah satu cuplikan kode umum yang sering Anda lihat di plugin dan tema adalah:

 // Exit if accessed directly if ( ! defined( 'ABSPATH' ) ) exit;

Jika ABSPATH konstan tidak ditentukan (yang seharusnya untuk instalasi WordPress apa pun), maka skrip akan keluar dan tidak mencetak apa pun.

Gunakan Nonce: Sebagaimana dinyatakan dalam dokumentasi WordPress, nonce adalah "nomor yang digunakan sekali" untuk membantu melindungi URL dan formulir dari jenis penyalahgunaan tertentu, jahat atau lainnya.

Misalnya, URL berikut di dalam dasbor akan digunakan untuk membuang kiriman: http://example.com/wp-admin/post.php?post=123&action=trash —Saat mengakses URL ini, WordPress akan memvalidasi informasi cookie otentikasi dan jika Anda memiliki izin yang tepat (misalnya, Anda adalah administrator dengan semua hak istimewa), postingan tersebut akan dihapus.

Apa yang dapat dilakukan penyerang adalah membuat browser Anda mengakses URL itu tanpa sepengetahuan Anda dengan membuat tautan di halaman pihak ketiga seperti dalam contoh berikut: <img src="http://example.com/wp-admin/post.php?post=123&action=trash" /> Saat membuat permintaan ini ke WordPress, browser akan secara otomatis melampirkan cookie otentikasi Anda dan WordPress akan menganggap permintaan tersebut sebagai valid.

Saat itulah nonce muncul karena penyerang tidak akan bisa mendapatkan nilai nonce (dihasilkan untuk administrator yang benar-benar masuk ke WordPress) dengan mudah. URL permintaan baru akan terlihat seperti ini: http://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204

Tanpa nonce yang valid, respons 403 Forbidden akan dikirim ke browser oleh WordPress dengan pesan kesalahan yang terkenal: "Apakah Anda yakin ingin melakukan ini?"

Meskipun kebanyakan orang tidak menganggap serius keamanan WordPress, berpikir bahwa situs web mereka tidak akan pernah diretas, mempercayai hosting (yang dapat membantu, tetapi hanya sampai titik tertentu) dan fakta bahwa mereka membeli plugin/tema komersial (yang sering menyebabkan dengan asumsi bahwa mereka sangat aman), kami harus selalu melakukan tes penetrasi untuk situs web kami untuk mengidentifikasi kerentanan yang dapat dieksploitasi sebelum peretas mana pun dapat mengidentifikasi dan mengeksploitasinya.

Perhatikan bahwa sejumlah besar peretasan di luar sana bahkan tidak dilakukan oleh satu orang dengan maksud untuk secara khusus meretas situs web Anda. Seringkali, ada bot yang memindai situs web WordPress secara otomatis secara konsisten dan saat kerentanan yang diketahui ditemukan, itu dieksploitasi dan server digunakan untuk spamming, mendapatkan informasi pribadi dari database, menempatkan tautan tersembunyi di dalam halaman tertentu dari situs web yang akan mengarah ke semua jenis situs web yang cerdik (misalnya, pornografi, obat-obatan terlarang). Terkadang, peretasan disembunyikan dengan sangat baik sehingga Anda memerlukan pemindaian situs web yang tepat dan melihat tanggal saat file tertentu diperbarui untuk mendeteksi kode yang diretas. Itulah mengapa ada baiknya bahkan menginstal ulang WordPress (ya, versi yang sama jika Anda memiliki yang terakhir) sehingga file yang diretas akan ditimpa oleh file inti WordPress asli.

12. Menggunakan Fungsi WordPress dan Cuplikan Kode tanpa Memahaminya

Seringkali, ketika pengembang terjebak dan menemukan solusi di tempat-tempat seperti StackOverflow, mereka hanya senang dengan kenyataan bahwa mereka berhasil membuat sesuatu bekerja tanpa repot-repot memahami logika di balik kode itu atau jika kode itu dapat diubah untuk memuat lebih cepat atau lebih sedikit. baris kode.

Saya telah melihat praktik ini berkali-kali ketika potongan kode disalin dalam skrip PHP ketika hanya sepertiga dari kode itu yang benar-benar digunakan.

Ini dapat memiliki beberapa kelemahan, termasuk:

1. Kode tidak menggunakan gaya yang sama dengan kode proyek yang ada. Ya, nyaman untuk hanya menyalin dan menempelkan cuplikan yang bekerja di luar kotak dan, meskipun baik untuk proyek pribadi kecil (bisa berubah menjadi proyek besar suatu hari nanti, siapa tahu), praktik ini seringkali tidak baik ketika datang untuk pekerjaan komersial di mana konsistensi gaya harus dijaga.
2. Meskipun kode melakukan tugasnya, kode tersebut dapat berisi fungsi yang tidak efektif yang tidak direkomendasikan untuk tugas yang perlu dicapai. Jika kode tidak dioptimalkan, praktik "salin dan tempel" ini dapat menyebabkan pemeliharaan situs web menjadi lambat dan sulit, terutama jika lebih dari satu cuplikan digunakan di berbagai lokasi dalam proyek.
3. Kode tersebut mungkin tidak dilisensikan untuk digunakan kembali, dan menyertakan kode dalam proyek klien dapat menyebabkan banyak masalah hukum.

Peningkatan Konstan

Setiap orang membuat kesalahan, dan setiap kesalahan adalah kesempatan untuk memperbaiki diri. Sebagai pengembang WordPress, industri kami bergerak dengan sangat cepat, dan tidak pernah ada satu "cara yang benar" untuk melakukan sesuatu. Namun, semakin Anda berlatih dan belajar, Anda akan menjadi lebih baik.

Apakah Anda tidak setuju dengan salah satu kesalahan yang saya tunjukkan, atau berpikir saya melewatkannya? Beri tahu saya di komentar dan kita akan berdiskusi.