Jak uniknąć edytowania rdzenia Drupal?

Budowałem wymianę z usługą XML partnerów i nie mogłem poprawnie uzyskać XML, ale tak jak w przypadku wszystkich rzeczy Drupal, błąd xmlrpc i rejestrowanie działań jest mniej niż niezawodny.

Zrobiłem to w pliku / 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;
}

Dostałem potrzebne dane i po 10 minutach interfejs partnera odpowiednio zareagował na moje żądanie, ponieważ (szokujące, że wiem) dzienniki są dobre.

Lubię dodatkowe logowanie i chcę je zachować. Jaki jest czysty, prosty i co najważniejsze, zatwierdzony przez Drupala sposób?

Rdzeń hakerski jest zdecydowanie odradzany dla niewtajemniczonych, ponieważ skutecznie redukuje społeczność wsparcia tysięcy do społeczności wsparcia jednego (lub jakiejkolwiek wielkości twojego zespołu). Bez tej najlepszej praktyki pomoc nowym osobom w Drupal byłaby prawie niemożliwa. Utrudnia to również modułowość, aw niektórych przypadkach bezpieczeństwo.

To powiedziawszy, rdzeń hakerski nie zawsze jest tak zły, jak nam się wydaje. Bez modyfikacji rdzenia nie mielibyśmy dystrybucji takich jak Pressflow i tym podobne rdzenie rozszerzające w interesujący sposób. Bardzo ważne jest, abyś dokładnie wiedział, co robisz, że rozprowadzasz swoje łatki wraz z dystrybucją (najlepiej w sposób, który pozwala na ich ponowne zastosowanie automatycznie po aktualizacji) i że przechowujesz szczegółową dokumentację tego, co zmieniłeś i dlaczego to zmieniłeś.

W zależności od tego, jak masz strukturę, z pewnością możesz wprowadzić powyższą zmianę xmlrpc_request(), utworzyć łatkę, a następnie użyć czegoś takiego jak Drush Make, aby zautomatyzować jej stosowanie (zwróć uwagę, że Drush Make przenosi się do samego projektu Drush w wersji 5.x. ), dostarczając dodatkową dokumentację w pliku makefile i gdzie indziej, co robi zmiana i dlaczego jest to konieczne / pożądane.

Innym powszechnym wzorcem do ulepszania podstawowych funkcji jest tworzenie otoki, która dodaje odrobinę funkcjonalności do podstawowej funkcji, i wywoływanie otoki zamiast implementacji rdzenia. Gdy jest to wykonalne, sprawia, że ​​rzeczy są znacznie bardziej modułowe. Rozważ następujące:

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

Ponownie, w zależności od tego, co robisz, może to być lub nie być wykonalne, ale kiedy już to zaoszczędzisz, masz kilka kłopotów z próbą upewnienia się, że rdzeń pozostaje załatany i udokumentowany. Chociaż w tym przypadku taka jednorazowa funkcja wydaje się idealnym kandydatem na takie opakowanie. Jeśli twoja implementacja jest przechwycona w module, możesz nawet ją rozwinąć, aby kontrolować poziom rejestrowania całego rozwiązania, wyłączając tę ​​funkcję w witrynach produkcyjnych:

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

Krótko mówiąc, chcesz zmaksymalizować to, co możesz zrobić z modułami (i możesz dużo zrobić), ale istnieją uzasadnione powody, aby zmienić rdzeń. Należy to robić ostrożnie, to wszystko.

Jeśli trzeba zmienić podstawowe lub contrib modułów należy.

1. Utwórz łatkę ze zmianami.
2. Użyj systemu wdrażania, takiego jak drush make, który automatycznie zastosuje łaty po aktualizacji rdzenia lub modułów.
3. Dokument dokument dokument.