Ketika saya sedang dalam proyek peningkatan sistem, salah satu hal yang saya lakukan adalah membedakan sistem klien dengan instalasi Magento yang baru. Saya mencari peretasan inti atau file tambahan yang bukan bagian dari Magento standar untuk memastikan saya menangkap pekerjaan buruk tapi bisnis-kritis yang dilakukan oleh freelancer, kontraktor, konsultan, atau agensi sebelumnya.
Satu hal yang selalu mengejutkan saya adalah tambalan. Selama bertahun-tahun Magento telah mengeluarkan tambalan "antar versi" - biasanya untuk mengatasi perbaikan keamanan, atau perubahan API pengiriman / pembayaran vendor.
Masalahnya adalah, dari sudut pandang diff, tambalan tidak dapat dibedakan dari peretasan inti - terutama ketika Anda tidak tahu tambalan mana (jika ada) yang telah diterapkan pada sistem.
Yang mengarah ke pertanyaan saya.
Bagaimana Anda membedakan antara hack inti dan patch?
sumber
Ini adalah sesuatu yang sering saya tangani (dan saya sedang kerjakan sekarang), dan sayangnya, sejauh ini ini adalah proses yang sepenuhnya manual - kami memiliki proses otomatis yang menandai setiap file yang dapat dimodifikasi sebagai bagian dari audit otomatis awal kami untuk klien dukungan baru. Kami kemudian meminta seseorang untuk membedakan file-file itu, dan mengesampingkan setiap false positive yang jelas (yaitu, perubahan spasi putih).
Kemudian, bagian yang menyenangkan - seorang anggota senior dari tim kami yang telah bekerja dengan Magento untuk beberapa waktu harus melihat hasil untuk menentukan apakah ada file yang dimodifikasi dapat menjadi hasil tambalan. Kami telah melihat memperbarui sistem kami untuk memeriksa semua tambalan yang kami ketahui / dapat kami tangani, dan itu mungkin bekerja untuk CE, tetapi pada EE itu bahkan lebih menantang, karena dukungan EE terkadang mengeluarkan tambalan secara langsung untuk klien yang tidak pernah dirilis dengan cara lain atau katalog secara konsisten.
Jadi, ketika kita melakukan tinjauan tingkat ini, kita mengandalkan pengalaman masa lalu menerapkan tambalan ini + akal sehat (yaitu, apakah itu hanya perubahan ke titik akhir API? Jika demikian, apakah titik akhir yang diubah hadir dalam versi yang diperbarui? Jika demikian, itu tambalan dan dapat diabaikan).
Secara teori akan sangat mudah untuk menerapkan semua tambalan yang tersedia di halaman unduhan CE, dll., Untuk setiap versi CE yang berlaku dan memeriksa hal tersebut (FYI, kami tidak menggunakan diff untuk pass pertama - kami menggunakan hashing, di sebagian karena kami membuat teknologi ini menjadi alat yang dapat memeriksa situs dari jarak jauh tanpa perlu mengunduhnya terlebih dahulu). Itu akan mengesampingkan sebagian besar tambalan, tetapi masih tidak membantu untuk tambalan CE atau EE yang tidak diposkan ke area unduhan publik untuk CE atau area unduhan klien / terlindungi untuk EE. Itu akan membutuhkan Magento untuk membuat kebijakan yang konsisten bahwa SEMUA tambalan tersedia untuk SEMUA pelanggan, dan mengirimkannya ke tempat yang bisa kami tuju.
Jadi, saya tidak berpikir ada cara untuk mengotomatisasi 100% ini sampai terjadi perubahan di sisi Magento, sayangnya.
sumber
git diff depot/master origin/master. Tantangannya adalah .gitignore. Pilihan lain, adalah untuk mengkloning versi ke direktori terpisah, lalu salinapp/code/coredirektori situs di atasnya.git diff -wakan memberi tahu Anda.Salah satu cara yang saya dekati ketika saya melakukan banyak upgrade dan mencoba mensistematisasikan prosesnya adalah dengan benar-benar melakukan patch secara langsung ke repositori kode inti yang Anda gunakan untuk berbeda.
Ini sebenarnya memiliki dua manfaat:
Tidak ada lagi false positive yang muncul di diff Anda.
Katakanlah Anda memiliki situs yang tidak memiliki tambalan tertentu. Anda mungkin mengatakan itu masalah karena itu akan muncul sebagai kode yang hilang di diff Anda meskipun secara teknis mereka tidak kehilangan apa-apa dibandingkan dengan unduhan baru yang belum ditonton. Tetapi pada kenyataannya, bahwa mereka kehilangan tambalan sebenarnya adalah masalah yang harus diselesaikan - jadi itu sempurna yang muncul di diff Anda untuk Anda perbaiki bersama dengan peningkatan.
sumber
Saya tidak berpikir bahwa memiliki Magento di repo proyek Anda pada awalnya adalah ide yang baik, jika Anda mengelola lebih dari 2-3 klien. Karena selalu lebih mudah untuk mengacaukan tambalan sistem yang diterapkan dengan peretasan inti.
Pilihan terbaik, menurut saya, adalah memiliki mirror repositori Magento komposer dengan tag versi, yang mengarah ke versi Magento tertentu dengan kemungkinan tambalan resmi yang diterapkan.
Juga akan lebih mudah untuk mempertahankan tambalan Anda sendiri ke file, seperti Mage_Core_Model_Config untuk situs web yang memuat banyak dan lainnya, dengan memperkenalkan angsuran mereka melalui komposer dengan nomor versi yang cocok dengan angsuran Magento Anda.
Jadi, dalam hal ini, pemutakhiran semua proyek pelanggan Anda ke kode Magento yang ditambal hanya akan menghasilkan benjolan versi file komposer Anda. Juga menjaga kode proyek terpisah dari inti, akan memaksa pengembang Anda untuk tidak meretas inti.
Adapun definisi tambalan dan peretasan, saya lebih suka menyebutnya seperti ini:
Jadi dengan memindahkan inti ke repo terpisah, Anda akan memastikan bahwa Anda hanya memiliki versi tambalan sesuai dengan item 1. Dan Anda dapat dengan mudah menginstal tambalan Anda sendiri di atas komposer ke kumpulan kode lokal, sehingga Anda memiliki segalanya sesuai dengan poin 3. Dalam kasus 2 dan 4 Anda dapat membuat hook komit git di repo proyek untuk melarang komit kode apa pun ke dir itu.
sumber
Saya melihat ke file tambalan yang diterapkan dalam
/app/etc/folder itu dan bekerja mundur. Tetapi ketika saya belajar dari peningkatan, saya hanya dapat menghapus file pada versi yang memiliki file tambalan di dalamnya dan lain kali ditambal itu bersih.sumber
Apa pun dari Magento, aku akan menelepon tambalan. Yang lainnya adalah retasan.
sumber