Proposal untuk Pembaruan Otomatis WordPress Versi Lama ke 4.7 Percikan Debat Panas

Kontributor, pengembang, dan anggota komunitas WordPress saat ini sedang memperdebatkan proposal untuk menerapkan kebijakan baru terkait dukungan keamanan untuk versi yang lebih lama. Diskusi dimulai minggu lalu ketika pemimpin tim keamanan Jake Spurlock meminta umpan balik tentang berbagai pendekatan untuk mendukung perbaikan keamanan ke versi yang lebih lama. Menindaklanjuti diskusi ini, Ian Dunn, kontributor penuh waktu untuk inti WordPress, disponsori oleh Automattic, telah menerbitkan proposal untuk bergerak maju dengan kebijakan baru:

Dukung 6 versi terbaru, dan perbarui otomatis situs yang tidak didukung ke versi terlama yang didukung.

Itu berarti bahwa versi yang saat ini didukung adalah 4.7 – 5.2, dan cabang 3.7 – 4.6 pada akhirnya akan diperbarui secara otomatis ke 4.7.

Dalam praktiknya, itu akan memberikan dukungan sekitar 2 tahun untuk setiap cabang, dan sekitar 10% dari situs saat ini pada akhirnya akan diperbarui secara otomatis ke 4.7. Setelah 5.3 dirilis, versi tertua yang didukung akan menjadi 4.8.

Dunn menguraikan rencana terperinci untuk menerapkan kebijakan baru yang melibatkan pengujian sebagian kecil situs untuk mengidentifikasi masalah sebelum memperbarui situs lama secara bertahap dari satu versi utama ke versi berikutnya (tidak sekaligus). Administrator situs akan diberi tahu setidaknya 30 hari sebelum pembaruan otomatis dengan email dan pemberitahuan di admin yang juga akan menawarkan kesempatan untuk memilih keluar.

Proposal tersebut telah menerima lusinan komentar, dengan beberapa kontributor mendukung, beberapa mendukung modifikasi peluncuran, dan lainnya yang dengan tegas menentang gagasan memperbarui situs lama secara otomatis ke versi utama.

Salah satu kekhawatiran yang umum adalah bahwa banyak admin tidak akan menerima pemberitahuan apa pun karena alamat email yang tidak berfungsi atau tidak cukup sering masuk ke dasbor admin mereka. Lawan juga berpendapat bahwa meskipun ada fallback untuk situs yang gagal ditingkatkan, beberapa situs mungkin rusak dengan cara yang tidak dapat dideteksi WordPress, karena masalah dengan plugin atau tema.

“Pemberitahuan back-end bahkan tidak akan menggantikan kurangnya komunikasi email yang andal,” kata Glenn Messersmith. “Ada banyak pemilik situs yang tidak pernah menjelajah ke back-end setelah situs mereka dikembangkan. Ini adalah orang-orang yang juga tidak akan mendapatkan pemberitahuan email karena alamat emailnya adalah milik beberapa pengembang yang sudah lama pergi.

“Tidak mungkin deteksi kesalahan apa pun dapat bertindak sebagai jaring pengaman bagi mereka yang tidak pernah melihat pemberitahuan apa pun. Ada berbagai cara yang mungkin dianggap oleh pemilik situs sebagai 'rusak' yang tidak mungkin dideteksi oleh skrip pembaruan.”

Menanggapi kekhawatiran tentang kerusakan situs yang ditinggalkan atau administrator yang sangat bergantung pada plugin yang telah ditinggalkan, Dunn setuju bahwa jenis situasi ini mungkin tidak dapat dihindari berdasarkan proposal saat ini.

"Saya pasti bisa bersimpati dengan situasi itu, tetapi kita harus menarik garis di suatu tempat," kata Dunn. “Kami tidak memiliki sumber daya yang tidak terbatas, dan kebijakan saat ini memiliki efek merusak bagi seluruh ekosistem WordPress.

“Pada kenyataannya, pilihan tidak pernah antara hal yang benar-benar baik dan hal yang benar-benar buruk; mereka selalu berada di antara tradeoff yang saling bersaing.

“Saya benar-benar setuju bahwa itu buruk jika sejumlah kecil pemilik situs harus melakukan pekerjaan ekstra untuk meningkatkan situs mereka, tetapi dalam skema besar, itu jauh, jauh lebih baik daripada membuat tim keamanan kami terhalang oleh kebijakan dukungan yang sangat berat. .”

Penulis Proposal Mengklaim "Tidak Ada yang Akan Dipaksa untuk Memperbarui;" Lawan Berargumen bahwa Mengharuskan Pengguna untuk Memilih Keluar Bukanlah Persetujuan

Selain masalah kemungkinan melanggar situs, mereka yang menentang proposal tidak setuju dengan WordPress yang memaksa pembaruan tanpa mendapatkan persetujuan eksplisit dari administrator situs. Memberikan pengguna cara untuk memilih pembaruan otomatis untuk rilis inti utama adalah salah satu dari sembilan proyek yang telah diidentifikasi Matt Mullenweg untuk dikerjakan pada tahun 2019. Namun, rencana proposal ini lebih agresif karena akan membutuhkan pemilik situs di 3.7 – 4.6 cabang untuk memilih keluar jika mereka tidak ingin secara bertahap diperbarui secara otomatis ke 4.7.

“Mereka masih mempertahankan agensi tidak peduli apa, tidak ada yang akan dipaksa untuk memperbarui, semua orang memegang kendali atas situs mereka dan dapat memilih keluar jika mereka mau,” kata Dunn. “Sesuatu yang diaktifkan secara default sangat berbeda dari memaksa seseorang untuk melakukan sesuatu. Kami akan membuatnya sangat mudah untuk memilih keluar — cukup instal plugin, tidak perlu konfigurasi — dan instruksi untuk keluar akan disertakan dalam setiap email dan pemberitahuan admin.”

Dunn lebih lanjut mengklarifikasi dalam komentar mengenai siapa yang akan menerima pembaruan ini:

Tidak ada yang akan dipaksa, itu malah akan menjadi proses opt-out. Jika seseorang telah menonaktifkan pembaruan otomatis ke versi utama, itu akan dihormati dan situs mereka tidak akan diperbarui.

Jika seseorang mengklik tautan opt-out di email, atau jika mereka mengklik tombol opt-out di pemberitahuan admin, maka pembaruan juga akan dinonaktifkan.

Satu-satunya orang yang akan menerima pembaruan adalah orang-orang yang:

1) Ingin pembaruan
2) Tidak peduli
3) Telah meninggalkan situs atau akun email mereka

Beberapa peserta diskusi bertanya mengapa proses mendapatkan situs-situs ini di 4.7 tidak dapat ikut serta untuk persetujuan, alih-alih memaksa pembaruan pada mereka yang tidak memilih keluar. Tidak peduli seberapa nyaman mekanisme opt-out, memilikinya bukan berarti persetujuan. Banyak pemilik situs yang akan dipaksa ke dalam proses ini berpikir bahwa mereka akan aman dalam memilih pembaruan pemeliharaan dan keamanan dan meninggalkan situs mereka untuk melakukan "pembaruan saat Anda tidur", seperti yang dijelaskan oleh pos rilis 3.7 tentang fitur tersebut.

“Situs yang tidak aman itu buruk, tetapi bisa dibilang, memperbesar kekuatan yang diberikan kepada diri sendiri oleh mekanisme ini secara retrospektif lebih buruk,” kata pencipta UpdraftPlus, David Anderson. “Berpotensi itu bisa merusak kepercayaan + reputasi lebih dari rasa tidak aman. Saya berpendapat bahwa dasbor besar itu jelek, pemberitahuan yang tidak dapat dipindahkan pada versi yang lebih lama yang memperingatkan pengabaian yang akan datang + kebutuhan untuk memperbarui akan lebih baik. Biarkan pemilik situs bertanggung jawab. Jangan bermain pengasuh, menyalahgunakan kepercayaan, merusak situs, dan kemudian menulis posting blog tentang bagaimana kerusakan tambahan itu diperlukan. Tidak ada yang bangun ke situs yang rusak akan senang dengan itu. ”

Andrew Nacin, pemimpin rilis WordPress 3.7 dan rekan penulis fitur pembaruan latar belakang otomatis WordPress, mendorong mereka yang berada di balik proposal untuk mengklarifikasi bahwa WordPress hanya mendukung versi utama terbaru dan tidak pernah secara resmi mendukung versi lama.

“Butuh banyak pekerjaan, pasti, untuk mendukung,” kata Nacin. “Tetapi kita harus tetap berpegang pada bintang utara kita, yaitu bahwa WordPress kompatibel dari versi ke versi, bahwa pengguna WordPress tidak perlu khawatir tentang versi apa yang mereka jalankan, dan bahwa kita harus terus memperbarui situs jika kami mampu.”

Nacin menawarkan lebih banyak konteks pada strategi asli untuk memperkenalkan pembaruan otomatis, yang termasuk secara bertahap beralih ke rilis utama sebagai pembaruan otomatis sehingga semua situs pada akhirnya akan menggunakan versi terbaru:

Pertama, ketika kami pertama kali merilis pembaruan latar belakang otomatis, kami berpikir bahwa dorongan besar kami berikutnya adalah untuk mendapatkan pembaruan otomatis rilis utama dalam beberapa tahun ke depan. Dalam praktiknya, kita dapat melakukan ini kapan saja, dan, memang, 3.7 mendukung ini sebagai bendera. Tetapi idenya adalah kami akan menginvestasikan energi dalam sandboxing, perlindungan layar putih, meningkatkan fungsionalitas rollback kami, dll., sehingga tingkat keberhasilan kami sama tinggi untuk versi mayor seperti halnya untuk versi minor. (Tingkat kegagalan berskala agak linier dengan jumlah file yang perlu disalin, dan juga menjadi lebih kompleks ketika file perlu ditambahkan, bukan hanya diubah.) Setelah kami melakukan ini, kami hanya akan mulai memperbarui semua situs ke versi terbaru dan berhenti melakukan backport. Jelas kami masih belum sampai di sini.

Dia berkomentar bahwa secara keseluruhan proposal tersebut adalah “rencana yang bagus” tetapi menekankan manfaat mengkomunikasikan kepada pengguna bahwa aman untuk memperbarui dan bahwa WordPress hanya bermaksud untuk mendukung versi terbaru.

Sebagian besar peserta diskusi mendukung tim keamanan untuk menghentikan perbaikan backport ke versi WordPress yang lebih lama. Pertanyaan yang masih belum terjawab untuk lawan adalah mengapa tanggung jawab WordPress untuk memaksa situs lama untuk memperbarui.

“Saya tidak berpikir itu harus menjadi keputusan WordPress untuk memperbarui situs yang tidak mereka kelola ke versi mayor/breaking, tapi saya pikir mempertahankan cabang tersebut harus dihentikan,” kata Will Stocks. “Anda (WordPress) tidak memiliki infrastruktur atau proses bisnis, atau memahami dukungan yang ada untuk mengelola situs tersebut. Ada juga alasan mengapa situs-situs tersebut masih menggunakan versi itu hari ini dan belum ditingkatkan sebelumnya.”

Ada pendekatan lain yang masih dapat menarik garis untuk menghormati sumber daya tim keamanan yang terbatas tanpa memaksakan pembaruan non-konsensual ke versi utama. Rachel Cherry, direktur WPCampus, mengomentari proposal tersebut, sangat mendesak WordPress untuk membuat persetujuan sebelum memperbarui situs-situs ini:

Kami membahas apakah pembaruan paksa akan menyebabkan masalah teknologi dan melewatkan masalah sebenarnya sama sekali.

Kami sedang mendiskusikan pembaruan paksa perangkat lunak orang ketika mereka belum memberikan persetujuan.

Dan untuk tujuan apa? Apa masalah sebenarnya di sini? Karena kita tidak ingin repot memperbarui versi lama?

Ada cara lain untuk mengatasi masalah ini.

Kami dapat membuat kebijakan yang jelas mengenai dukungan EOL untuk rilis.

Kami dapat menambahkan pengaturan ke inti yang memungkinkan pengguna memilih apakah mereka ingin pembaruan otomatis atau tidak dan selanjutnya adalah pembuat keputusan. Kemudian kami memiliki persetujuan.

Kami dapat bekerja pada pendidikan dan komunikasi mengenai pembaruan.

Kami dapat mengirim email kepada orang-orang bahwa situs mereka sudah usang dan tidak aman dan mereka harus memperbarui secepatnya, bersama dengan tautan ke pendidikan dan praktik terbaik. Jika mereka masih membutuhkan bantuan, dorong mereka untuk menghubungi seorang profesional.

Kami dapat memperbaiki masalah ini untuk kedepannya, tetapi kami tidak memiliki persetujuan retroaktif tersirat hanya karena kami tidak pernah menerapkan mekanisme izin.

Jika seseorang tidak memperbarui situs mereka, mereka melakukannya karena suatu alasan. Atau ketidakpedulian. Apa pun itu, kami tidak berhak masuk seperti ini dan mengubah situs web orang.

Peserta diskusi masih bergulat dengan potensi implikasi dari perubahan kebijakan yang diusulkan. Pembaruan kecil telah terbukti sangat andal sebagai pembaruan otomatis. Dunn melaporkan bahwa pembaruan otomatis 3.7.29 hanya memiliki satu kegagalan yang harus dibatalkan ke 3.7.28. Menggunakan sistem pembaruan otomatis untuk mendorong pembaruan besar ke situs setua ini belum diuji secara menyeluruh.

“Apakah kami melakukan pembaruan otomatis 3.7 -> 5.x rilis, saya sepenuhnya mendukung memperjelas bahwa ini adalah sesuatu yang kami harapkan untuk mulai dilakukan di masa depan (5.x -> x.x+),” Jeremy Felt mengomentari proposal tersebut. “Pekerjaan dalam menguji infrastruktur dan kode untuk mendukung ini harus benar-benar dilakukan dengan cara apa pun.” Felt juga mengatakan bahwa dia menghargai penjadwalan peluncuran yang terhuyung-huyung untuk rilis yang diusulkan serta rencana untuk menyediakan plugin yang didukung secara resmi untuk menonaktifkan pembaruan otomatis.

Diskusi masih terbuka pada proposal, tetapi sejauh ini tampaknya ada ketidaksepakatan mendasar di antara para peserta tentang apakah WordPress memiliki hak untuk memaksa pembaruan versi utama tanpa persetujuan eksplisit, bahkan jika itu dengan tujuan menyelamatkan pemilik situs dari kemungkinan diretas. .

“Satu hal yang pasti, sejauh ini tampaknya menjadi perhatian mayoritas, sementara banyak dari kita menyukai niat mulia ini, saya tidak begitu yakin menjadi penguasa Internet yang baik hati adalah citra yang baik untuk WP bergerak maju. ,” kata pengembang plugin Philip Ingram.