Lima Kesalahan Pengembangan WordPress Terburuk Saya

Atau, Kepada Semua Server yang Pernah Saya Lakukan Sebelumnya: Melihat Kembali Horror di Lima Kesalahan WordPress Terburuk yang Saya Buat

Sebagai pengembang, kami membuat berbagai jenis kesalahan di berbagai titik dalam karier kami. Dalam pengembangan WordPress, khususnya, kami membuat berbagai jenis kesalahan saat keakraban kami dengan basis kode WordPress tumbuh.

Beberapa tahun yang lalu saya mendengar Matt Mullenweg menyatakan sesuatu yang menyatakan bahwa kebanyakan orang mengulangi kesalahan mereka, orang yang lebih pintar belajar dari kesalahan mereka, dan orang yang paling pintar di antara kita belajar dari kesalahan orang lain. Saya lebih suka ini, dan saya akan menambahkan konsekuensi wajar: Setiap orang membuat kesalahan, orang yang rendah hati berbagi kesalahan itu secara pribadi, dan yang paling berani di antara kita menuliskannya dan mempublikasikannya di blog!

Tapi ada waktu untuk merenung nanti. Anda membaca artikel ini karena ingin mendengar tentang kecelakaan kereta api, dan saya adalah insinyurnya. Tanpa basa-basi lagi, bergabunglah dengan saya untuk melihat ke belakang dengan ngeri pada lima kesalahan paling memalukan yang saya buat sebagai pengembang WordPress.

Saat Saya Memperbarui Versi WordPress Core yang Diretas

Saya baru saja lulus dari melakukan pertunjukan pengkodean CraigsList yang sangat tidak jelas, untuk benar-benar bekerja di agensi langsung yang nyata. saya telah tiba! Saya gugup bekerja dari tempat lain selain sofa saya, dengan sesuatu selain piyama saya. Tetapi meskipun demikian, saya biasanya tahu WordPress Right dari WordPress Doing It Wrong, dan saya merasa bangga dengan membanggakan praktik terbaik WordPress, seperti tidak pernah “meretas inti.”

Tugas pengembangan WordPress pertama saya di agensi ini adalah melanjutkan proyek yang terhenti—proyek yang agak rumit untuk keahlian saya saat itu. Ini melibatkan banyak penyesuaian pada pendaftaran WordPress dan alur masuk. Pengembang sebelumnya dianggap telah mencapai kemajuan yang signifikan hanya dengan mengedit wp-login inti.

Saya tahu ini tidak berkelanjutan, jadi urutan bisnis pertama saya adalah menginstal plugin cadangan/pemulihan dan mengganti inti WordPress dengan versi yang baru diunduh. Saya yakin bahwa tidak ada yang sangat mengesankan yang telah dilakukan pada proyek ini, dan bahwa saya dapat meniru set fitur yang ada melalui filter.

Kemampuan pengkodean apa pun yang mungkin atau mungkin tidak saya miliki pada saat itu dengan cepat menjadi tidak relevan, karena majikan baru saya benar-benar gila. Dia tidak mengerti pentingnya "hacking core" dan saya tidak cukup dewasa untuk menjelaskannya dengan cara yang mudah dicerna. Satu-satunya hal yang mendinginkan alisnya untuk sementara adalah ketika saya meyakinkannya bahwa saya dapat kembali melalui plugin cadangan/pemulihan yang saya instal.

Bisakah Anda menebak ke mana arahnya?

Plugin itu, seperti sudah ditakdirkan, hanya mencadangkan folder wp-content . Apa pun peretasan WordPress yang ada di file inti itu hilang selamanya. Saya masih ingat email saya kembali kepadanya (dia sudah lama mengusir saya kembali ke kantor rumah saya pada saat ini):

Guys, saya tidak bisa melakukan backup.

Saya benar-benar siap untuk menyelesaikan set fitur yang diinginkannya melalui filter dan tindakan, tetapi dia tidak akan mendengarnya. Dia memecat saya di tempat, mengancam akan menuntut saya, dan tidak pernah membayar saya selama dua minggu kerja keras. Saya sangat dipermalukan.

Ada banyak hal (sekarang jelas) yang bisa saya pelajari dari pengalaman ini. Pelajaran umum, bahwa pencadangan bukanlah pencadangan sampai telah dilatih dan dikonfirmasi, adalah pelajaran yang baik. Tapi satu yang lebih melekat dengan saya adalah pelajaran khusus tentang bagaimana tepatnya melakukan backup di WordPress — terutama dengan inti WordPress.

Saya telah belajar untuk sangat menghargai lingkungan terkelola seperti WP-Engine, dengan sistem pencadangan/pemulihan yang kuat. Banyak host butik memiliki berbagai alat baris perintah dan fitur yang berfokus pada pengembang lainnya untuk melakukan pencadangan, tetapi WP-Engine adalah favorit saya. Ini cukup cepat kecuali Anda memiliki jaringan yang sangat besar. UI-nya sederhana. Ini memiliki UI, titik: Siapa pun yang tahu cara menggunakan WordPress dapat bekerja dengan ini. Yaitu, berbeda dengan beberapa pendekatan CLI yang mungkin jauh lebih cepat, atau sesuatu yang tidak jelas terkubur di Plesk, klien saya dapat menggunakan ini, memahaminya, memantaunya, dan memverifikasi bahwa saya menggunakannya. Saya penggemar berat.

Saat Saya Menyeret Seluruh Platform Kami ke Direktori Saudaranya

Saya masih cukup baru di tempat kerja profesional dan selalu menjadi orang Windows. Namun, pekerjaan baru saya adalah di toko Mac dan saya belajar untuk mencintai segala sesuatunya dengan sangat cepat. Yah, hampir semuanya. Sepertinya saya mengalami banyak masalah dengan "tikus ajaib". Saya memiliki kecenderungan untuk kehilangan koneksi Bluetooth saya, yang mengarah ke tindakan drag-and-drop yang tidak disengaja dan sering menakutkan setelah terhubung kembali. Lebih dari itu, saya hanya canggung dengan keterampilan motorik halus yang baru.

Saat ini, alur pengembangan WordPress kami masih menyertakan penerapan ke produksi melalui FTP. Bukan hal yang aneh bagi saya untuk menghabiskan seluruh hari kerja menulis kode, mengobrol, menjawab email, biasanya berputar-putar melalui mouse ajaib baru saya, dengan Cyberduck terbuka untuk produksi di desktop saya. Astaga, apakah itu terdengar buruk! Tapi begitulah adanya.

Suatu hari seluruh platform kami hilang begitu saja. Sysadmin kami dengan cepat menganggap itu semacam DDoS atau sesuatu yang umumnya pada levelnya. Adapun kami pengembang, kami mempercayai instingnya dan berasumsi dia akan segera mengetahuinya.

Berjam-jam berlalu. Hari itu datang dan pergi. Masih turun.

Keesokan paginya, semuanya pulih, dan CTO kami dengan lembut meminta saya untuk bergabung dengannya di ruang konferensi. Sysadmin kami telah mengidentifikasi masalahnya. Dia menarik log FTP dan mengamati bahwa pengguna saya telah memindahkan seluruh platform kami ke direktori saudara. Artinya, wp-content telah menjadi bersarang di bawah wp-includes .

Saya kecewa, tetapi CTO kami hebat tentang hal itu. Dia dapat melihat bahwa pada umumnya saya adalah karyawan yang membantu dan bertanggung jawab, tetapi dia menantang saya untuk tidak sekadar menyesali dan menemukan cara untuk mencegah hal ini terjadi lagi. Saya menemukan dua hal yang sangat membantu.

Yang pertama adalah menemukan perintah CLI untuk mencegah Cyberduck mengizinkan pemindahan file dari jarak jauh sama sekali. Ini adalah tindakan keamanan yang baik dan kami segera mengadopsinya sebagai kebijakan perusahaan.

Yang kedua adalah saya sangat tertarik untuk menerapkan melalui Git. Akhirnya, saya akhirnya menulis plugin WordPress untuk menenun versi Bitbucket kami ke dalam aliran pembaruan wp-admin normal. Sejak saat itu, kami hampir tidak memiliki alasan untuk memiliki akses FTP ke produksi. Plugin ini adalah salah satu pencapaian profesional favorit saya. Tentu saja, ketertarikan terhadap Git merupakan prasyarat bagi pengembang saat ini.

Waktu Saya Menghapus Semua Konten Front-end melalui add_filter()

Saya benar-benar berpikir saya telah menjadi cukup pintar dengan praktik WordPress saya pada saat ini. Permintaannya adalah untuk menambahkan "lencana" ke posting dari kategori tertentu. Untuk beberapa alasan saya berpikir bahwa hanya noobs yang akan menambahkan persyaratan lain ke file template untuk sesuatu seperti ini, jadi dengan bangga, saya menerapkan filter berikut:

 add_filter( 'the_content', 'myprefix_add_a_badge' ); function myprefix_add_a_badge( $content ) { global $post; if( ! has_category( 'sponsored', $post ) ) { return false; } $out = $content . myprefix_get_badge(); return $out; }

Lihat ada yang salah dengan ini? Saya mengujinya dengan cepat dalam pementasan untuk mengonfirmasi bahwa pos yang diperlukan telah menerapkan lencana mereka. Kemudian saya menyebarkannya dan meninggalkan pekerjaan untuk hari itu. Seperti yang Anda duga, alam semesta meledak.

Secara khusus, hasilnya adalah posting tanpa lencana ditampilkan di bagian depan tanpa konten sama sekali! Dapatkah Anda melihat mengapa? Masalahnya adalah alih-alih mengembalikan $content dalam kondisi penjagaan saya, saya mengembalikan false . Tapi sebenarnya ada banyak lapisan kesalahan di sini.

Mengapa saya puas hanya menguji bahwa posting menerima lencana? Mengapa saya tidak juga menguji bahwa pos lain tetap tidak terluka? Mengapa saya menyebarkan ke produksi di sore hari? Mengapa kontrol kualitas kami sepenuhnya terdiri dari saya mengklik sedikit dan menyegarkan halaman?

Jawaban atas semua pertanyaan ini dapat diringkas sebagai kedewasaan . Hanya perlu beberapa saat untuk bosan membuat kesalahan semacam ini, sebelum kita tergerak untuk berinvestasi dalam hal-hal seperti pengujian regresi visual dan pengujian unit. Kesalahan khusus ini adalah kesalahan, di antara ratusan, yang akhirnya mematahkan punggung unta dan membuat saya menjadi sangat berinvestasi di phpUnit dan xDebug. Pada gilirannya, alat-alat itu telah mengajari saya tentang menulis kode yang dapat diuji, yang mungkin mencegah lebih banyak bug daripada pengujian itu sendiri.

Waktu Saya Dibagi dengan Nol Di Dalam Lingkaran Tak Terbatas

Permintaan klien adalah memformat ulang baris posting blog WordPress sedemikian rupa sehingga tanggalnya akan terbaca "XYZ lalu" sebagai lawan dari "10 November 2011." Saya tidak begitu yakin bagaimana mencapai ini, tetapi saya sadar bahwa itu adalah format tanggal yang tampaknya semakin populer, dan memang Dr. Google memberi saya cuplikan dengan sangat cepat. Ini berhasil di lokal saya! Itu memiliki banyak matematika, khususnya, banyak pembagian . Saya tidak begitu yakin mengapa itu berhasil—ada banyak loop bersarang, sisa, pembulatan, dan semacamnya. Tapi itu ada di Google dan sepertinya berhasil, dan saya cukup senang untuk menyebarkannya ke produksi.

Sekitar 30 menit kemudian, saya mendapat Skype yang tidak ramah dari sysadmin kami. Produksi turun. Mati di dalam air. Dia bertanya apakah saya telah membagi dengan nol akhir-akhir ini dan saya tidak tahu apa yang dia maksud. Inilah yang terjadi.

Percaya atau tidak, cuplikan "bekerja di lokal saya" yang tidak dapat dibaca yang saya temukan, dengan ukuran sampel yang cukup besar, mampu melakukan beberapa perilaku menyimpang. Disertakan dengan beberapa kombinasi hari, jam, dan menit yang tidak menguntungkan, loop Rube Goldberg kadang-kadang mencoba membagi angka dengan nol. Ingat dari matematika sekolah menengah:

Dalam aritmatika biasa, ekspresi tidak memiliki arti, karena tidak ada bilangan yang, ketika dikalikan dengan 0, menghasilkan a (dengan asumsi a 0), dan pembagian dengan nol tidak terdefinisi. - Wikipedia

Jadi apa artinya ini untuk komputer? Biasanya hanya pesan kesalahan di log, tetapi dalam kasus saya, itu lebih buruk: Kesalahan matematika mengganggu logika loop saya, menyebabkan loop bersarang saya berjalan tanpa pernah menyelesaikan — loop tak terbatas yang mengarah ke layar putih kematian. Dan itu menjadi lebih buruk! Karena setiap iterasi loop menulis kesalahan untuk membagi dengan nol, log kesalahan tumbuh ke proporsi yang fantastis dan mulai menghambat sistem file kami. Ini memiliki efek serangan DDoS, meskipun serangan yang dilakukan sendiri secara absurd.

Hal buruk tentang kesalahan ini adalah bahwa ia menghapus situs dengan lalu lintas tinggi. Hal yang baik tentang kesalahan ini adalah bahwa hal itu secara dramatis mengubah pendekatan saya untuk bekerja. Lebih dari segalanya, saya malu dengan kesediaan saya untuk menerapkan tanpa pemahaman. Saya bersumpah untuk tidak pernah lagi menempelkan cuplikan tanpa melakukan segala upaya yang mungkin untuk memahami setiap baris, bahkan menindaklanjuti dengan pembuat cuplikan jika perlu.

Lebih dari itu, saya bersumpah untuk tidak pernah lagi mengirimkan kode yang tidak terlalu mudah dibaca oleh pengembang pemula. Saya menjadi terobsesi dengan standar pengkodean WordPress, ekstensi editor teks, komentar sebaris dan docblock, dan bahkan tab versus spasi, ritual peralihan klasik itu! Singkatnya, saya memutuskan untuk lebih peduli tentang betapa mudahnya membaca kode saya daripada betapa mudahnya menulisnya . Pemberontakan terhadap menempel tanpa pemahaman ini membuat saya mengambil minat profesional yang mendalam dalam mengelola ketergantungan pihak ketiga, topik yang memicu berbagai kesempatan menulis dan berbicara bagi saya selama dekade berikutnya.

Oh, dan hal yang sangat lucu tentang kesalahan ini? Inti WordPress memiliki solusi satu baris untuk itu.

Waktu Saya Membiarkan Proyek Berputar Di Luar Kendali Sampai Semua Orang Muak Dengannya

Saya telah mendapatkan proyek yang sangat menarik. Saya akan menjadi pemimpin teknis dan insinyur pengembangan WordPress, dan saya akan memiliki pengembang Amazon AWS Lambda dan pakar mendalam dalam JavaScript yang melapor kepada saya. Ini adalah pertama kalinya saya memiliki banyak orang yang melapor kepada saya, dan sejauh ini merupakan proyek paling kompleks yang pernah saya kerjakan. Bahkan untuk menyebutnya sebagai proyek WordPress sangat mengecilkan masalah ini, tetapi WordPress adalah perekat yang menyatukan semuanya, jadi masuk akal bagi saya untuk bertindak sebagai pemimpin teknologi.

Karena peran utama saya biasanya menjadi teknisi, dan juga karena saya memiliki ketertarikan pada minimalis, tidak pernah terpikir oleh saya untuk menerapkan sesuatu seperti Jira atau Basecamp atau platform nyata apa pun untuk manajemen tugas. Segalanya berjalan cukup baik untuk iterasi pertama proyek. Kami dapat mengerjakan komponen individual kami sendiri, merujuk ke dokumen spesifikasi klien sebagai peta jalan produk kami, dan hanya melakukan ping satu sama lain melalui Slack ketika kami perlu menggabungkan beberapa hal bersama-sama.

Masalah dimulai ketika kami mulai menunjukkan kemajuan kepada klien dan menerapkan umpan baliknya. Apa yang dimulai sebagai tim tiga orang langsung merasa telah dibawa ke urutan besarnya yang baru: Tidak jelas siapa yang bertanggung jawab atas sedikit umpan balik, apa status penerapan umpan balik itu, atau bahkan siapa yang berbicara dengan siapa . Kami beberapa kali melampaui batas 100 balasan per utas Gmail!

Keadaan mulai tidak nyaman. Saya pikir klien merasa seperti dia telah kehilangan kendali atas arah proyek, dan sama pentingnya, dia merasa seperti dia telah kehilangan visibilitas status proyek. Pengembang Amazon saya menyebutkan suatu hari, "Saya ingin tahu apakah kita harus menggunakan Trello."

Hah , pikirku. Apakah tim yang terdiri dari tiga orang membutuhkan platform seperti itu? Sekali lagi, kecenderungan saya yang biasa adalah lebih memilih alat yang lebih sedikit, lebih sedikit overhead, lebih sedikit kerumitan. Tapi proyek itu sudah menyeret kita semua ke tanah, jadi apa salahnya mencobanya?

Saya menyisir semua email kami, semua dokumen spesifikasi kami, semua utas komentar kami yang berbeda, dan memetakan semuanya di papan Trello. Segera, proyek itu bangkit kembali dari makam digitalnya karena kami dapat berkomunikasi dengan biaya mental yang jauh lebih sedikit. Alih-alih mencari teks di kotak masuk email saya atau sebagian besar dokumen spesifikasi usang, kami memiliki papan, daftar, dan kartu yang indah. Sangat mudah untuk melihat status fitur apa pun, memasukkan umpan balik, dan membagikan tugas baru. Rasanya seperti kami secara bertahap menjadi buta, begitu lambat sehingga kami tidak menyadarinya, dan kemudian tiba-tiba bisa melihat lagi.

Memang, kode tidak menulis sendiri, itu masih proyek yang sangat menantang, dan kami masih harus menggunakan setiap ons keterampilan teknis kami. Tapi itulah intinya: Karena kami akhirnya memiliki infrastruktur untuk memahami proyek, kami sekarang bebas menerapkan keterampilan teknis kami.

Saya senang mengatakan bahwa proyek itu diselesaikan dengan kepuasan penuh klien. Saat ini, saya menganggap Trello atau Jira sebagai persyaratan de facto untuk tim yang terdiri dari dua orang atau lebih.

Majulah dan Belajar dari Kesalahan Orang Lain

Inilah salah satu hal paling cerdas yang saya dengar diajarkan selama saya di militer: “Tidak apa-apa bagi letnan untuk membuat kesalahan letnan dan tidak apa-apa bagi kapten untuk membuat kesalahan kapten. Yang tidak baik adalah kapten membuat kesalahan letnan, atau letnan membuat kesalahan pribadi.”

Dengan kata lain, tidak apa-apa untuk membuat kesalahan umum yang merupakan hal biasa untuk tingkat tanggung jawab Anda saat ini. Yang lebih penting adalah bagaimana Anda tumbuh dari mereka.

Saya berharap kita sebagai pengembang belajar untuk berbelas kasih kepada orang lain ketika mereka melakukan kesalahan, seperti yang diharapkan orang lain telah bersama kita. Saya berharap untuk tetap ingin tahu dan bertanggung jawab ketika saya melakukan kesalahan sehingga saya terus berinovasi melewatinya. Saya berharap untuk selalu dikelilingi oleh komunitas pakar WordPress yang menginspirasi—orang-orang yang kesalahannya dapat saya pelajari dan hindari membuat diri saya sendiri. Dan yang terpenting, saya berharap orang lain dapat belajar dari pengalaman saya, seperti kesalahan WordPress yang saya bagikan di sini.