Memodifikasi file inti WordPress


21

Mengapa?

Terkadang perbaikan yang mudah untuk mengubah perilaku WordPress itu sendiri atau sebuah plugin bisa dengan mengubah file plugin atau WordPress secara langsung. Ketika muncul dengan ide seperti itu, respons yang biasa adalah:

Jangan meretas inti.

Mengapa umumnya ide buruk untuk mengubah file inti?

Mempertimbangkan?

Namun, kadang-kadang, hal-hal yang sangat penting bagi sebuah situs tidak mungkin dilakukan, dengan cara yang baik tanpa mengubah file inti. Ketika dalam situasi seperti itu, apa yang perlu Anda ketahui, sebelum Anda melanjutkan dan mulai meretas inti?

Bagaimana?

Anda telah mempertimbangkan semua opsi, tetapi satu-satunya solusi adalah meretas file inti. Bagaimana seharusnya Anda melakukan ini? Bagaimana cara memiliki inti yang diubah, memengaruhi alur kerja, seperti memperbarui?


1
Saya sangat tidak setuju dengan rekomendasi untuk meretas inti karena saya belum menemukan satu pun hal yang tidak dapat saya atasi. Satu-satunya orang yang memiliki inti peretasan bisnis untuk situs produksi adalah mereka yang sama sekali tidak perlu membaca apa pun tentang topik ini karena mereka mungkin sudah berada di tim inti WordPress. Menjelaskan kepada orang-orang bagaimana melakukannya hanya memberi 99 dari 100 orang yang jelas tidak seharusnya melakukan cara untuk merasionalisasi keputusan mereka. Dan saya benar-benar benci melihatnya diaktifkan di sini. JMTCW.
MikeSchinkel

Sebagai tindak lanjut, inilah contoh pertanyaan yang merupakan jawaban pertama "Tidak mungkin" dan saya menjawab dengan contoh yang menunjukkan caranya: wordpress.stackexchange.com/questions/972/#984 Ada (hampir selalu) cara untuk lakukan tanpa inti peretasan.
MikeSchinkel

2
Jika Anda mengubah inti, Anda harus melakukan kembali perubahan setelah setiap kali Anda meningkatkan, dan Anda akan membuat instalasi Anda tidak standar sehingga lebih sulit bagi orang untuk membantu Anda. Cukup buat plugin, widget, templat, kail, atau salah satu dari banyak metode yang disediakan wordpress agar Anda tidak perlu mengubah intinya.
Wadih M.

Wadih benar. Saya telah membuat perubahan pada beberapa file inti untuk memperbaiki / meningkatkan / menyesuaikan berbagai hal dan saya selalu merasa frustrasi ketika memutakhirkan karena saya harus memeriksa perubahan dan menerapkan tambalan saya ke file baru. Ini bahkan lebih membuat frustrasi ketika file baru terlalu berbeda dari yang lama dan lokasi perubahan tidak lagi jelas (atau bahkan ada sama sekali).
Synetech

1
Seperti yang saya takutkan; kadang-kadang ketika tidak ada kait yang disempurnakan (seperti memodifikasi Situs Saya), satu-satunya kait yang bekerja untuk trik buffered-output adalah admin_body_classdan admin_footeryang berarti menangkap seluruh halaman . Saya baru saja mencobanya dan ada> 2MB konten yang harus dicari untuk bagian yang relevan, kemudian diuraikan dan dimodifikasi sebelum menghasilkan. Atau, saya dapat menambahkan satu baris kode ke bagian kanan my-sites.phpdan menggunakan alat diff untuk menerapkan tambalan setelah pembaruan (dengan asumsi itu dimodifikasi sama sekali). Sangat sulit untuk membuat kasus menentang memodifikasi inti dalam skenario seperti ini.
Synetech

Jawaban:


21

Jika Anda harus meretas inti, pertimbangkan untuk melakukannya dengan cara yang memungkinkannya untuk orang lain.

Tambahkan Hook Tindakan

Sembilan dari sepuluh, Anda bisa melakukan apa yang Anda inginkan jika hanya ada do_actionpanggilan tambahan dalam file tertentu. Dalam hal ini, tambahkan tindakan, dokumentasikan, dan kirim tambalan melalui Trac . Jika ada alasan bagus untuk tambalan Anda (yaitu Anda bukan satu-satunya yang akan menggunakannya) maka Anda mungkin bisa menambahkannya ke inti.

Selanjutnya, buat plug-in khusus (Anda tidak harus melepaskan / mendistribusikannya!) Yang terkait dengan hook baru ini dan melakukan fungsi apa pun yang Anda perlukan untuk melakukannya.

Refactor file inti

Di lain waktu, Anda mungkin hanya perlu sepotong kode untuk berperilaku berbeda. Lewatkan variabel dengan referensi, misalnya, atau kembalikan nilai alih-alih gema. Luangkan waktu untuk duduk dan memperbaiki kode sehingga melakukan apa yang Anda butuhkan untuk dilakukan ... kemudian kirim tambalan melalui Trac sehingga kami semua dapat mengambil manfaat dari pekerjaan Anda.


Apakah Anda melihat tema berkembang di sini? Inti peretasan belum tentu tidak boleh ... hanya sesuatu yang sebagian besar pengembang akan sangat mengecilkan hati bagi pengguna baru atau programmer pemula (jika Anda bertanya kepada kami bagaimana melakukan sesuatu, kami akan menyarankan plug-in setiap kali sebelum bahkan mempertimbangkan untuk menyarankan Anda meretas inti).

Inti peretasan adalah cara WordPress mengembangkan dan berevolusi, tetapi berbahaya bagi seseorang yang baru belajar PHP atau tanpa pengalaman bekerja dengan file WP. Silakan mulai dengan plug-in sebelum menyentuh inti - jika Anda memutuskan plug-in Anda dapat menghapus instalasinya dengan cepat (menghapus melalui FTP jika perlu) ... tetapi jika Anda memutuskan inti, hal-hal buruk dapat terjadi pada situs Anda dan berpotensi pada Anda database juga.

Tetapi jika Anda berada dalam situasi di mana peretasan inti tidak dapat dihindari, maka lakukan perubahan. Juga, publikasikan perubahan Anda di lokasi yang menonjol (jika blog Anda sangat terlihat, itu mungkin cukup ... tapi saya sarankan Trac karena itulah cara perubahan komunitas dapat ditarik ke rilis berikutnya). Perubahan Anda mungkin merupakan peluru ajaib yang dapat memperbaiki masalah di ratusan situs yang berbeda ... jadi berkontribusi kembali ke komunitas yang membantu Anda membangun situs Anda.

Jika perubahan dilakukan, maka peretasan Anda menjadi bagian dari inti dan Anda tidak perlu khawatir tentang hal itu di masa depan. Jika tidak, setidaknya Anda memiliki dokumentasi terperinci tentang cara menerapkan kembali peretasan setelah Anda memutakhirkan WP dalam 3 bulan.


Kata-kata yang jauh lebih baik daripada milikku :)
hakre

3

Jangan meretas inti.

Yah itu karena itu saran untuk pengguna tingkat pertama yang tidak berpengalaman. Inti peretasan itu akan merusak instalasi mereka, mereka tidak dapat memastikan bahwa perubahan mereka tetap ada pembaruan dll.

Tentu, hack core!

Tentu Anda benar-benar dapat meretas inti, misalnya dengan menggunakan sistem manajemen versi seperti SVN. Ini membantu Anda untuk menjaga perubahan Anda sendiri pada kode inti sejalan dengan pembaruan proyek. Ini juga membantu untuk membuat tambalan untuk Wordpress dan mengirimkannya ke proyek.

Inti peretasan sebenarnya membuat Wordpress berevolusi.

Pertimbangan

Jika Anda tidak ingin menginstal SVN lengkap dan Anda masih tahu mana (beberapa) file yang telah Anda ubah, Anda dapat menggunakan lebih banyak alat level rendah seperti Diff / Gabung (untuk menang: WinMerge ) atau editor dengan kemampuan membandingkan (mis. Notepad ++ dengan Bandingkan Plugin ). Di Linux Anda dapat dengan mudah menginstal utilitas baris perintah yang melakukan hal yang sama. The Geany Editor dilengkapi dengan integrasi shell bagus btw. .

Saya lebih suka Eclipse PDT untuk pekerjaan berat. Tapi itu bukan untuk edit cepat atau retas.

Jadi saya akan mengatakan, jika Anda menggunakan alat yang tepat dan Anda ingin berhati-hati meretas inti adalah cara untuk pergi. Jika Anda meretas sesuatu bersama yang tersisa di beberapa server pengguna Noob lainnya (ya, Wordpress cukup populer), cukup sediakan sebuah plugin yang dapat dibuang dengan mudah jika merusak sesuatu.


Inti peretasan TIDAK PERNAH merupakan solusi yang baik dalam jangka panjang. TAK PERNAH.
Fredy31

@ Fredy31; Ini satu-satunya cara agar instalasi wordpress Anda tetap mutakhir, bekerja, dan aman. Juga "jangka panjang" yang Anda bicarakan di sini sangat panjang jika perlu dua tahun dan lebih lama antara menyediakan tambalan untuk Wordpress dan kemudian memasukkannya. Bahkan lebih lama untuk melaporkan masalah tanpa tambalan. Hati hati.
hakre

1
Jelas inti peretasan merepotkan, tetapi saya menemukan perlawanan dan vitriol di sini mengejutkan. Di hampir semua area FOSS lainnya, forking dianjurkan secara aktif. Mengapa menyesuaikan WordPress begitu laknat? Saya telah melihat banyak proyek lain melakukan persis seperti yang disarankan hakre dengan menggunakan RCS untuk membuat versi program yang dimodifikasi sambil tetap mengikuti trunk. 1 untuk memberikan peringatan yang jelas tetapi mengatakan yang sebenarnya bahwa itu memang mungkin dan memberikan saran yang jelas tentang bagaimana hal itu dapat dilakukan dengan jumlah kesulitan paling sedikit.
Synetech

Oh, dan saya baru ingat bahwa tema anak melakukan hal ini! Saat Anda membuat tema anak, Anda pada dasarnya memalsukan induk dan kapan pun induk diperbarui, Anda harus menyalin perubahan apa pun secara manual ke anak tersebut. Jadi kebencian memodifikasi inti ini tidak konsisten dengan perilaku WordPress identik lainnya yang diterima.
Synetech

2

Masalahnya adalah:

  1. Setiap kali Anda melakukan pembaruan inti (misalnya karena perbaikan keamanan, dll), Anda harus memperbaruinya secara manual, alih-alih menjalankan pembaru otomatis.
    Jika Anda ingin melakukan ini, maka buatlah hidup Anda lebih mudah:
    • tandai setiap perubahan dengan penanda umum (.eg // PATCH STARTdan // PATCH END)
    • gunakan alat seperti WinMerge untuk membandingkan sumber yang ada dengan sumber baru, dan salin perubahan yang perlu dilakukan.
    • Anda harus berhati-hati jika area kode yang Anda salin telah berubah, dan buat perubahan yang sesuai untuk tambalan Anda
    • Ketahuilah bahwa ini adalah pekerjaan yang 'tidak pernah berakhir', menghabiskan waktu yang dapat ditagih, kecuali Anda dapat melakukan rebill pada klien Anda untuk itu.
  2. Anda dapat menyebabkan masalah ketidakcocokan dengan plugin yang mengharapkan inti berfungsi dengan cara tertentu - ini akan membutuhkan pengujian tambahan

Kadang-kadang ini 100% tidak dapat dihindari, tetapi saya hampir selalu dapat menemukan cara lain untuk mencapai sesuatu, atau mengubah spesifikasi karena kemungkinan biaya waktu yang dihabiskan untuk melakukan ini. Ini hanya mimpi buruk pemeliharaan, dan banyak orang menggunakan hacking core, daripada mencari solusi yang tepat.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.