Drupal çekirdeğini düzenlemekten nasıl kaçınabilirim?

Bir ortaklar XML servisiyle bir değişim inşa ediyordum ve XML'i doğru anlayamadım, ama Drupal'daki her şeyde olduğu gibi, xmlrpc hatası ve işlem günlüğü daha az sağlam.

Bu yüzden bunu include / xmlrpc.inc içinde yaptım.

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;
}

İhtiyacım olan verileri aldım ve 10 dakika içinde ortağım arayüzü isteğime uygun bir şekilde cevap verdi, çünkü (şok edici olduğunu biliyorum) günlükler iyi.

Fazladan kayıt tutmayı seviyorum ve saklamak istiyorum. Bunu yapmanın temiz, anlaşılır ve en önemlisi Drupal onaylı şekli nedir?

Çekirdek kesmek, başlatılmamışlar için kesinlikle önerilmemektedir, çünkü binlerce destek topluluğunu bir destek topluluğuna (veya takım büyüklüğünüz ne olursa olsun) etkili bir şekilde azaltır. Bu en iyi uygulama olmadan, Drupal'da yeni olanlara yardım etmek neredeyse imkansız olurdu. Ayrıca modülerliği ve bazı durumlarda güvenliği de engeller.

Bunun söylendiği gibi, hack çekmeyi yapmak her zaman olduğu kadar kötü değildir. Çekirdeği değiştirmeden, Pressflow ve benzerleri gibi dağıtım çekirdeğini ilginç şekillerde elde edemeyiz . Ne yaptığınızı tam olarak bilmeniz, yamalarınızı dağıtımınıza dağıtmanız (tercihen onları yükseltme işleminden sonra otomatik olarak tekrar uygulamanıza izin verecek şekilde) ve ayrıntılı belgeleri tutmanız çok önemlidir. değiştirdiklerin ve neden değiştiğinin.

Nesnelerin nasıl yapılandırıldığına bağlı olarak, yukarıdaki değişikliği kesinlikle yapabilir, xmlrpc_request()bir yama yaratabilir ve daha sonra Drush Make gibi bir uygulamayı kullanarak otomatikleştirerek uygulayabilirsiniz (Drush Make'ın 5.x sürümü için Drush projesine girdiğini unutmayın. ), makefile ve başka yerlerde, değişikliğin ne yaptığı ve neden gerekli / istendiği konusunda ek belgeler sağlarken.

Çekirdek işlevlerini geliştirmek için başka bir yaygın model, çekirdek işlevine küçük bir işlevsellik katan bir sarmalayıcı oluşturmak ve çekirdeği uygulamak yerine sarmalayıcı olarak çağırmaktır. Mümkün olduğunda, bu işleri daha modüler kılar. Aşağıdakileri göz önünde bulundur:

/**
 * 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;
}

Yine, yaptığınız şeye bağlı olarak bu mümkün olabilir veya olmayabilir, ancak ne zaman o çekirdeğin yamalı ve belgelenmiş kaldığından emin olmak için kendinize birkaç baş ağrısından kurtuldunuz. Bu durumda, böyle bir kerelik bir işlev böyle bir sarıcı için mükemmel bir aday gibi görünüyor. Uygulamanız bir modülde ele geçirildiyse, tüm işlevlerinizin günlük düzeyini kontrol etmek ve hatta üretim sitelerinde bu işlevselliği devre dışı bırakmak için genişletebilirsiniz:

/**
 * 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);
  }
}

Kısacası, modüller ile yapabileceklerinizi en üst düzeye çıkarmak istiyorsunuz (ve çok şey yapabilirsiniz), ancak çekirdeği değiştirmek için meşru sebepler var. Özenle yapılmalı, hepsi bu.

Çekirdek değiştirmek veya modülleri katkıda bulunmak gerekirse.

1. Değişiklikleri olan bir yama oluşturun.
2. Core veya modülleri güncellediğinizde yamaları otomatik olarak yeniden uygulayacak olan drush make gibi bir dağıtım sistemi kullanın.
3. Belge belgesi.