Bagaimana saya menghindari mengedit inti Drupal?

21

Saya sedang membangun pertukaran dengan layanan mitra XML, dan saya tidak bisa mendapatkan XML dengan benar, tetapi seperti semua hal Drupal, kesalahan xmlrpc dan pencatatan tindakan kurang kuat.

Jadi saya melakukan ini di include / xmlrpc.inc.

function xmlrpc_request($method, $args) {
  $xmlrpc_request = new stdClass();
  $xmlrpc_request->method = $method;
  $xmlrpc_request->args = $args;
  $xmlrpc_request->xml = <<<EOD
<?xml version="1.0"?>
<methodCall>
<methodName>{$xmlrpc_request->method}</methodName>
<params>
EOD;
  foreach ($xmlrpc_request->args as $arg) {
    $xmlrpc_request->xml .= '<param><value>';
    $v = xmlrpc_value($arg);
    $xmlrpc_request->xml .= xmlrpc_value_get_xml($v);
    $xmlrpc_request->xml .= "</value></param>\n";
  }
  $xmlrpc_request->xml .= '</params></methodCall>';

  /* This part here */
  watchdog('xmlrpc',$xmlrpc_request->xml);
  /* End ridiculously tiny hack */

  return $xmlrpc_request;
}

Saya mendapatkan data yang saya butuhkan dan dalam 10 menit antarmuka mitra merespons dengan tepat untuk permintaan saya karena (mengejutkan saya tahu) log baik.

Saya suka logging ekstra, dan saya ingin menyimpannya. Apa cara yang bersih, mudah, dan yang paling penting, yang disetujui Drupal untuk melakukan itu?

OhkaBaka
sumber
2
Saya tidak mengerti mengapa ini diturunkan. Ya, pengeditan inti tidak disarankan tetapi @OhkaBaka mengakui bahwa ini meminta saran tentang cara mengelola ini dan memberikan contoh dunia nyata. Seiring dengan kebutuhan untuk men-debug situasi, ada alasan yang sah untuk mengedit inti. Ada beberapa bug di core w / working patches di antrian masalah yang tidak akan diterapkan, dan ada beberapa hal yang tidak benar-benar memiliki solusi.
mpdonadio
1
Jawaban di bawah ini bagus. Satu hal yang akan saya tambahkan adalah Anda tidak perlu logging dihidupkan setiap saat di situs langsung Anda. Nonaktifkan modul khusus Anda saat Anda tidak menggunakannya, atau terapkan tambalan atau modul Anda ke situs pengembang saja. Meminimalkan perubahan dan mendokumentasikan dengan hati-hati akan membuat Anda tetap waras.
greg_1_anderson
@ greg_1_anderson - Anda akan menemukan bahwa solusi saya di bawah ini sudah mengatasi ini melalui penggunaan variabel log_level (meskipun menggunakan konstanta jelas akan lebih bersih, saya menghilangkannya untuk memberi penekanan pada pola). Dengan cara ini Anda dapat menggunakan metode pembungkus yang sama pada dev / live dan sisa kode Anda dapat bergantung padanya tanpa mengubah panggilan fungsi. Yang Anda butuhkan hanyalah mengatur level logging dari modul Anda menggunakan variable_set()atau mekanisme serupa yang dapat diekspor jika perlu. :]
David Watson
1
@ David: Ya, itu luar biasa. Saya ingin menjaga modul dev tetap aktif, dan mengaktifkannya di hook post-sql-sync, per drupalcode.org/project/drush.git/blob/HEAD:/examples/… Teknik Anda mendapatkan nilai tertinggi juga, meskipun saya pikir saya juga akan melakukan variabel_set dalam kait post-sync drush daripada fitur. Menerapkan tambalan pada sistem dev saja, seperti yang saya katakan di atas, mungkin merupakan ide yang buruk kecuali Anda yakin sistem tersebut benar-benar sistem awal; jika tidak, pertandingan mungkin secara tidak sengaja dilakukan dan didorong. Aduh.
greg_1_anderson
@ greg_1_anderson - Saya sebenarnya bermaksud untuk melihat apakah ada kait seperti itu, dan tidak menyadari sudah ada contoh di tempat; terima kasih banyak untuk tautannya! Mengetahui sekarang bahwa ini mungkin, saya setuju bahwa pengaturan ini di tingkat lingkungan jelas merupakan cara yang harus ditempuh, baik karena alasan yang Anda sarankan dan untuk membantu menjaga konfigurasi situs generik dipisahkan dari konfigurasi khusus lingkungan.
David Watson

Jawaban:

11

Inti peretasan sangat tidak disarankan bagi yang belum tahu karena secara efektif mengurangi komunitas pendukung ribuan menjadi komunitas pendukung satu (atau apa pun ukuran tim Anda). Tanpa praktik terbaik ini, membantu mereka yang baru ke Drupal hampir tidak mungkin. Ini juga menghalangi modularitas dan, dalam beberapa kasus, keamanan.

Ini telah dikatakan, inti peretasan tidak selalu jahat seperti yang kita inginkan. Tanpa memodifikasi inti, kami tidak akan memiliki distribusi seperti Pressflow dan sejenisnya yang menambah inti dengan cara yang menarik. Sangatlah penting bahwa Anda tahu persis apa yang Anda lakukan, bahwa Anda mendistribusikan tambalan Anda dengan distribusi Anda (lebih disukai dengan cara yang memungkinkan Anda untuk menerapkannya lagi secara otomatis setelah peningkatan), dan Anda menyimpan dokumentasi terperinci dari apa yang telah Anda ubah dan mengapa Anda mengubahnya.

Bergantung pada bagaimana Anda memiliki hal-hal terstruktur, Anda tentu bisa membuat perubahan di atas xmlrpc_request(), membuat tambalan, dan kemudian menggunakan sesuatu seperti Drush Make untuk secara otomatis menerapkannya (perhatikan bahwa Drush Make bergerak ke dalam proyek Drush sendiri untuk rilis 5.x ), sambil menyediakan dokumentasi tambahan di makefile dan di tempat lain tentang apa yang dilakukan perubahan dan mengapa itu perlu / diinginkan.

Pola umum lainnya untuk meningkatkan fungsi inti adalah membuat pembungkus yang menambahkan sedikit fungsionalitas ke fungsi inti, dan memanggil pembungkus sebagai pengganti implementasi inti. Jika memungkinkan, ini membuat semuanya jauh lebih modular. Pertimbangkan yang berikut ini:

/**
 * Wrapper function for xmlrpc_request() to provide logging.
 */
function mymodule_xmlrpc_request($method, $args) {
  $xrr = xmlrpc_request($method, $args);
  watchdog('xmlrpc', $xrr->xml);
  return $xrr;
}

Sekali lagi, tergantung pada apa yang Anda lakukan ini mungkin atau mungkin tidak layak, tetapi ketika Anda telah menyelamatkan diri Anda beberapa sakit kepala dalam mencoba untuk memastikan bahwa inti tetap ditambal dan didokumentasikan. Meskipun dalam kasus ini, fungsi satu kali seperti ini sepertinya adalah kandidat yang sempurna untuk pembungkus seperti itu. Jika implementasi Anda ditangkap dalam sebuah modul, Anda bahkan dapat mengembangkannya untuk mengontrol level log dari seluruh solusi Anda, menonaktifkan fungsi ini di situs produksi:

/**
 * Wrapper function for xmlrpc_request() to provide logging (if enabled).
 */
function mymodule_xmlrpc_request($method, $args) {
  $xrr = xmlrpc_request($method, $args);
  if (variable_get('mymodule_log_level', 0) > 0) {
    watchdog('xmlrpc', $xrr->xml);
  }
}

Singkatnya, Anda ingin memaksimalkan apa yang dapat Anda lakukan dengan modul (dan Anda dapat melakukan banyak hal), tetapi ada alasan yang sah untuk mengubah inti. Itu harus dilakukan dengan hati-hati, itu saja.

David Watson
sumber
9

Jika Anda perlu mengubah modul inti atau kontrib, Anda harus.

  1. Buat tambalan dengan perubahan.
  2. Gunakan sistem penyebaran seperti drush make yang secara otomatis akan menerapkan kembali tambalan saat Anda memperbarui inti atau modul.
  3. Dokumen dokumen dokumen.
googletorp
sumber
1
Saya benar-benar tidak mengharapkan validasi mengubah inti oleh imajinasi ... jadi saya sekarang terpaksa pindah ke pertanyaan sekunder: Apakah ini dengan cara yang lebih baik daripada melakukan hal yang sama dalam modul yang berdiri sendiri?
OhkaBaka